Build a software bill of materials (SBOM) for open source supply chain security

More than ever, developers are building web applications on the foundations of open source software libraries. However, while those libraries make up the software bill of materials (SBOM) components inventory, not all developers and business stakeholders understand the significant impact on open source supply chain security that stems from including 3rd party libraries. With this in mind, let’s explore the topic of SBOM security and the significance of tracking them for the applications you’re building.

Software supply chain security concern has been increasingly a worrying dilemma for organizations and governments alike. Threat Landscape for Supply Chain Attacks, a report published by the European Union Agency for Cybersecurity (ENISA), estimated a 400% increase in software supply chain attacks in 2021.

The vast use of open source software available to developers these days, and the ease of importing software components, both contribute to an increased risk factor due to security and legal concerns for a developer and subsequently, the business, which is why it's important to educate developers and security teams and provide them with advanced supply chain security solutions.

Before we get too far, let’s take a look at some SBOM basics and provide clarity around the technical terms that are used throughout this article.

What is a software bill of materials?

A software bill of materials, often abbreviated as SBOM, is a complete list of all software components used across an organization. The software bill of material list is made up of third-party open source libraries, vendor provided packages and first-party artifacts built by the organization.

Why do I need to build an SBOM?

An SBOM is essentially an inventory of all of the software components you utilize in your applications. Without it, you have no visibility into the license and security risks associated with software you are building or consuming. Maintaining an up-to-date SBOM format compliant software bill of materials is crucial to also keep up with rapid software development, in which components and their versions are swiftly changing.

What is CycloneDX?

OWASP CycloneDX is a software bill of material (SBOM) standard designed for application security contexts and supply chain component analysis, providing an inventory of all first-party and third-party software components. The specification is rich and extends beyond software libraries, to standards such as software as a service bill of materials (SaaSBOM), Vulnerability Exploitability Exchange (VEX) and more. The standard is an Apache 2.0 licensed open source project and is open for collaboration at the following open source GitHub repository: https://github.com/CycloneDX/specification.

Security concerns that demand developers to maintain a software bill of materials

A software bill of materials is not a terminology that resonates with developers. That’s because it‘s traditionally been an activity reserved for security and risk assessment teams in an organization. But, things have changed due to the tremendous rise of open source software components, as evident by the npm package registry, which spans more than 1,800,000 free and open source packages.

If you’re a developer and you doubt why you even need an SBOM for all the software components you use, then we just need to remind you of several high-profile security incidents that have happened in recent years due to open source software libraries:

1. event-stream: The popular npm package was compromised to include malicious code.

2. Log4Shell: The popular Java logging library Log4j was found to have a high severity remote code execution vulnerability. This vulnerability had existed for seven years before it was found!

When these security vulnerabilities or security incidents are discovered and take place, and your application uses one of these vulnerable versions, who do you think is responsible for upgrading these libraries and pushing a new version? That’s right, developers.

Even if the security team do their own thing, and maintain the software bill of materials on their own, when they discover such issues, they raise a flag, alarm the necessary teams, and look up for developers to upgrade vulnerable versions. But, in such a world of advanced workflow management, can’t we automate this entire process so that it is integrated more natively into developers workflows? Sure we can. That is what Snyk, which is free to use, is all about.

Why should developers care about the legal impact of their software bill of materials?

Today, legal aspects of using software are probably not what developers think about when they go about tinkering with their code and building applications. However, a couple of decades ago, this wasn’t the case. Developers and their staff were highly sensitive to the specific license of the software components that they brought into their code. What changed? Well, back then, the most commonly used licenses were of copyleft type, such as GNU’s General Public License (GPL), which had drawn several limitations on distributing software. The TL;DR of GPL is that it has a cascading effect, so any code built using a GPL-licensed component automatically becomes GPL-licensed itself — something to consider when you build your business model.

Some 20 years forward, we saw a huge step away from copyleft licenses. By 2015, the most commonly used license in open source repositories created on GitHub is an MIT license. Along with other licenses, MIT belongs to a family of permissive licenses, which shed many of the limitations of how software is to be used, and instead, increase the freedoms that developers have by using such licensed software.

We are at a time in the history of open source software which is seeing the immense growth of adoption and newly contributed software with very permissive licenses. Have we got accustomed to using open source software as the default? Are we now taking open source software licensing for granted?

Two, very highly popular cases of software’s legal issues that are concerning the project’s own license usage has been at the core of developers:

1. React, the immensely popular open source JavaScript view library had its license change from their own version of “BSD + Patents grant” to the permissive MIT license, due to the Apache Software Foundation banning the React project, condemning Facebook’s license as too restrictive. This was also met with pressure from developers worldwide who had considered ditching the project entirely and moving to alternatives, such as the Preact project. Quincy Larson has a useful timeline of events in the following freecodecamp article.

2. Elastic, the company and open source project of the same name, of the popular search tool and ELK Stack, also had to deal with license changes due to rising competition from cloud vendors and their impact on Elastic’s business.

As a developer who uses React, Elastic, or other open source software libraries, you will most probably be responsible for factoring a migration away from one project to another when license issues arise.

Furthermore, what happens if you end up building applications and shipping software which one of their nested components have a copyleft license? JavaScript and Node.js ecosystems are well known for the high number of npm packages that get installed. The risk to the business is very real, and it calls for your attention, as a developer, to be able to track and understand which software licenses are used across your projects.

The applications you build and the software you consume probably already include references for the license that is being used. For example, if you’re building JavaScript project, license information is part of the package.json manifest file:

1{
2  "name": "snyk",
3  "version": "1.0.0-monorepo",
4  "description": "snyk library and cli utility",
5  "files": [
6    "help/cli-commands",
7    "dist",
8    "bin",
9    "pysrc",
10    "config.default.json",
11    "SECURITY.md",
12    "LICENSE",
13    "README.md"
14  ],
15  "author": "snyk.io",
16  "license": "Apache-2.0",

The license described in this package.json file is using the common SBOM format referred to as SPDX to make sure it conforms with international and interoperability standards across tools.

What is SPDX?

The Software Package Data Exchange (SPDX) is a Linux Foundation collaborative project that provides a common SBOM format standard for tracking software bill of materials, making it easy to create interoperability reports by a variety of tools. More specifically, the SPDX License List provides a common licenses list identifier along with a canonical URL to each license.

The following SPDX License List web page provides the complete list of all licenses and their identifiers:

Snyk provides open source auditing capabilities which, similar to the above table, generate a software bill of materials reports to establish a comprehensive software audit, fully interactive, searchable and capable of filters.

Developers standardization of open source libraries usage

Mature engineering organizations graduate from the opportunistic and occasional usage of open source libraries to more intentional and planned usage of open source libraries in their projects which follow guidelines and best practices.

For instance, JavaScript development teams would want to ensure that developers across different teams standardize on using a single chosen HTTP requests dependency, instead of creating reliance on a multitude of dependencies, such as npm package request, axios, node-fetch, and others. The reasoning isn’t only an easier management of open source dependencies, but also for centralizing API knowledge and expertise, easier problem troubleshooting and more.

For any given development team, can you realistically answer the following questions:

• Which open source libraries am I using the most across all of the projects in my R&D organization?

• Which open source libraries that I’m using have been marked as deprecated?

• Which open source libraries in my projects are using copyleft licenses such as GPL-2?

• Which open source libraries have been published over 15 years ago and didn’t receive any update? Should you be worried about that?

All of these insights and more are benefits you get by maintaining a software bill of materials, an SBOM. Snyk makes such valuable open source package health information available too as part of the Snyk Open Source capabilities:

Why does SBOM accelerate your supply chain security readiness?

What is software supply chain security?

Traditional application security concerns in the software development security lifecycle have evolved from the developer’s own code to the entire developer-tooling infrastructure that makes up the building of software. As such, an incredibly large threat attack surface is created from the early step of the actual IDE tool that developers use to write code with, and all the to the open source components they build their applications with, and up to CI/CD pipelines, and deployment infrastructure configuration. In fact, one could argue the supply chain security risk further extends to the hardware chips in the computer you use as your development environment.

The United States Department of Commerce issued a document that is pursuant to Executive Order 14028 on Improving the Nation’s Cybersecurity, in which it cites The Minimum Elements For a Software Bill of Materials (SBOM). Let’s further unfold the story of supply chain and see what we can learn from it.

The software supply chain is essentially any and all components that are part of the complete workflow through which you build software. At first, you might think of the software supply chain as simply the dependencies that you add to your projects. That is true, but the software supply chain extends much beyond that.

Your IDE is also a crucial part of your software development workflow, right? What risk would it pose to the business if your favorite IDE had backdoors or malware in it? What if one of those IDE extensions or plugins had severe vulnerabilities in it, or flat out included malicious code?

Vulnerabilities in VS Code extensions

Vulnerable VS Code extensions aren’t just a theoretical concern. In May 2021, Snyk uncovered supply chain security vulnerabilities in Visual Studio Code extensions on the VS Code extensions marketplace that impact more than 2,000,000 developers based on their download counts.

These VS Code extensions, such as Open in Default Browser with over 520,000 downloads, or Instant Markdown with over 120,000 downloads, pose a real and genuine threat to developers. If developers are tricked by an attacker into clicking a link, they could introduce a path traversal vulnerability that exposes access to sensitive files and information in their development environment. In more severe cases of the vulnerabilities, a complete remote command execution is made available to attackers simply by developers clicking a link.

The following video demonstrates why software supply chain SBOM security is a crucial developer concern, showing an exploitation of the Instant Markdown VS Code extension and how it steals sensitive SSH keys from a developer:

Security vulnerabilities impacting Java IDE

If you think supply chain security is wreaking havoc on the JavaScript ecosystem, let me share with you ENISA’s timeline of 24 supply chain security incidents just in the time span of 18 months (January 2020 to July 2021), which includes cases of malicious supply chain security incidents impacting Java developers through the NetBeans IDE:

Maintaining a secure open source SBOM

So, how do you mitigate concerns of software supply chain security across your entire software development lifecycle (SDLC)? Maintaining an up-to-date SBOM is not only a good start, but one that has been mandated by the US government’s executive order due to the incredible threat landscape that open source software components pose to businesses and governments alike.

An important aspect of open source supply chain security is not just the security threat landscape stemming from known security vulnerabilities and potential zero-days of malicious acts, but also the overall package health. Signals relating to the project’s commit and release cadence, open issue counts, and overall community of contributors involved in the project, all contribute to the overall package’s health score and should provide guidance on the project’s overall maintenance and whether it is susceptible for malicious activities.

Snyk has built the Snyk Advisor to solve this exact problem for open source software supply chain security considerations of package health scores. It currently supports metadata for ecosystems such as JavaScript, Go, Python, and Docker-based container images and we highly recommend consulting it in your quest for open source libraries.

Generating an open source SBOM with Snyk

Snyk Open Source works with package manifests and lockfiles to build a full dependency graph, which is helpful to pin-point vulnerabilities in the hierarchy or other concerns such as deprecated packages. However, that in itself isn’t an SBOM.

Gareth Rushgrove, a VP of Product at Snyk, wrote about advancing SBOM standards with Snyk and SPDX. In this article, Gareth tells about Snyk’s exploring several ways of working with community tooling, and calls out snyk2spdx which is an open source project that converts the Snyk CLI output to SPDX format.

If you’re a fan of the Snyk API, Gareth also calls out using the Snyk API to fetch the underlying package manifest and vulnerability details as consumption source, which you can then convert to SPDX.

In summary, mandating SBOM as part of the software development and delivery process is an important aspect in today’s supply chain security concerns. It helps answer anything from inventory to integrity and provenance.

We highly recommend the following articles to further advance on your knowledge about supply chain security in open source and software bill of materials:

• Understanding the software supply chain security requirements in the cybersecurity Executive Order by Daniel Berman

• For a deep dive on license comparison check out the docs for Open Source Licenses: Types and Comparison

• Managing license compliance across your organization with Snyk’s license policies by Josepha Riveros

• Explore a practical license policy management on the Snyk platform through the Snyk documentation