Sonatype has partnered with the Cloud Native Computing Foundation (CNCF) for Security Slam, an event to help improve the security of open source projects. To extend the value of this event, we created a series of blog posts on best practices for open source maintainers.
Here in the second post of our series, we explore how your project can benefit from the use of a software bill of materials (SBOM).
Where to begin with security vulnerabilities
As an open source maintainer, you already work to ensure your project's code doesn’t contain vulnerabilities such as flaws, glitches, or other weak spots that a bad actor can exploit.
But that's only half the battle.
Since you rely on other open source components to save you time and deliver new capabilities, you need to manage the risks created by your web of dependencies and root out any security vulnerabilities nested within your dependency tree.
Consider how nearly 96% of all known vulnerable components have a fixed version available — an SBOM will help drive attention and create transparency around these things. You need to know if you're introducing any open source components that contain known vulnerabilities, or worse, malicious code that bad actors are waiting to exploit.
Fortunately, there are excellent tools available, many free for open source projects, that can identify vulnerable or malicious open source on every pull request. Adding a tool to your project is as easy as going to GitHub Marketplace, selecting one, and enabling it on your repository. As an added bonus, many of these tools also generate SBOMs, yet another critical element to improve open source security.
What an SBOM provides
In the fallout of the disaster that was Log4Shell, as of this writing, 33% of all Log4j package downloads continue to be vulnerable versions, despite declarations by some purveyors of vulnerability analyses. Software libraries, particularly transitive dependencies, can be really challenging to track down despite your best efforts.
Enter the SBOM, a comprehensive list of all dependencies (direct and transitive) that went into your current build and deliverables.
An SBOM serves as a resource for users adopting the software of your open source project, offering clarity into constituent dependencies used to build a given package. This creates more transparency and visibility into possible security issues, mitigations, and footprints. Your audience can utilize this information to assess the security, as well as provide feedback and contributions back to your project.
How to get started with an SBOM
To facilitate wider adoption of SBOMs, several organizations developed standard formats — unified structures to generate SBOMs for internal use or to share upstream with end-users and customers. Currently, there are two popular standards that make SBOM adoption easy: CycloneDX and SPDX.
In comparison to generating your own SBOMs, a tool such as CLOMonitor by CNCF automatically runs a number of health checks, one of which investigates if a project’s GitHub repository contains an SBOM file.
Many different tools offer methods of generating SBOMs under the CycloneDX or SPDX specification. We will cover a few examples (including open source, CNCF projects) below of how to get started with an SBOM.
How CNCF projects are creating SBOMs
There are native CNCF projects that also produce SBOMs. Here is a selection of them.
Pixie
Pixie, an open source Kubernetes observability tool, takes a manual approach to generating their SBOM, which updates each time they make a release. Users of Pixie can visit a static URL to get the SBOM for the latest version. This is by far the quickest way to get started, though you’ll still need a tool to help generate your SBOM.
Flux
Flux, an open extensible continuous delivery solution for Kubernetes, utilizes a specific GitHub Action to integrate an SBOM generation into a CI pipeline. This Action, which leverages Anchore’s Syft to create an SBOM in SPDX format, gives you the ability to automate the SBOM generation process.
Argo
Argo, a declarative GitOps continuous delivery tool for Kubernetes, also utilizes a GitHub Action to generate an SBOM with a tool from SPDX in that specific format. Argo goes a step further than many generator tools by signing and publishing the SBOM.
Why work with an SBOM
The shifting nature of software development
The word SBOM itself became an industry standard in the wake of President Biden’s May 2021 executive order for improving national cybersecurity. SBOMs are technically not new — the Cyber Supply Chain Management and Transparency Act of 2014 called for something very similar to the most recent iteration of an SBOM. Awareness around this emerging field of standards only seems to heighten in the wake of government orders and memos or in the fallouts of headline-grabbing vulnerabilities such as Spring4Shell, Log4Shell, and Struts2.
Increasingly, SBOMs are a necessary element of deliverables. For example the recent guidance for developers from the National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), and the Office of the Director of National Intelligence (ODNI) recommended that producers of open source projects provide an SBOM as a mitigation and assurance of good development practice. Simply, by providing an SBOM in your repository, you make a good-faith gesture that helps a user efficiently verify and vet your project.
Despite repeated recommendations, implementation of SBOM processes and practices remains relatively hard for developers and harder still for security teams who need to consume them. The first step for constructive SBOM evolution is to further establish and strengthen standards.
This also helps users of your product react to security vulnerabilities. As research in our recent State of the Software Supply Chain report revealed, 6 out of 7 security vulnerabilities exist in transitive dependencies.
The most efficient way to start solving that problem is to get started with what’s ready now and build up and out from there.
A simple best practice that fits into your workflow
An SBOM itself is not an analysis tool. It's a presentation of metadata. See it as a build artifact that describes a moment in time for the artifact in relation to its dependencies.
An SBOM itself is not an analysis tool. It's a presentation of metadata. See it as a build artifact that describes a moment in time for the artifact in relation to its dependencies.
An SBOM empowers those who create, maintain, contribute to, and utilize open source software to understand dependencies, track known and newly emerged vulnerabilities, and improve overall security of a project.
This allows you to spend less time searching for information and solve critical issues more efficiently.
Remember though, an SBOM is just one element to aid in open source software security. It's a crucial part of increasing transparency and forming a foundation on which to build security practices, processes, and tools that strengthen your open source project.
You unpack the real value when you share an SBOM's information, particularly with the contributors and users of your open source project.
