If you're reading this, you already know that the cloud has transformed everything about how we develop and consume software. You also know that one of the biggest changes is the fact that almost all enterprise software now includes open-source components, which has supercharged development velocity and innovation.
But open source software (OSS) brings security risks, as well. To be clear, OSS itself isn't inherently less secure than other software. But there's a compound effect: if there's a vulnerability and/or an exploit in a particular OSS package—and that software is used by thousands of other software packages (lookin' at you, Log4Shell)—the problem will spread faster than chickenpox in kindergarten. It is this potential for far-reaching consequences that has prompted regulators to step in to help identify vulnerable systems and the root cause of security incidents.
Just over two years ago, U.S. President Biden issued an Executive Order directing (among other things) the National Institutes of Standards and Technologies (NIST) to issue guidance that would include standards, procedures, or criteria to enhance the security of the software supply chain, including "providing a purchaser a Software Bill of Materials (SBOM) for each product."
However, despite the mandate, NIST's governance, and the work of private industry and OSS organizations, software supply-chain security remains a troublesome problem.
The following are a few reasons why.
Reason #1: The SBOM standards aren't standardized
With the help of the Cybersecurity & Infrastructure Security Agency (CISA) and Office of Management and Budget (OMB), NIST released the guidance the White House asked for in 2021 and updated it in 2022 in its Special Publication 800-161, "Supply Chain Risk Management Practices for Federal Information Systems and Organizations." The publication included measures for managing supply-chain risks, including the use of SBOMs. It also referenced the minimum set of elements an SBOM should contain, as established by the National Telecommunications and Information Administration (NTIA) (more on this later).
Since that publication, other SBOM formats have emerged, including the Linux Foundation's Software Package Data Exchange® (SPDX®) Specification Version 2.3 and CycloneDX (a flagship project of Open Worldwide Application Security Project®, or OWASP). NTIA recommends coupling SPDX with Software Identification tags, or SWIDs (XML files associated with specific software products).
I looked up the word "standard" in the Merriam-Webster dictionary, which defined it as "something established by authority, custom, or general consent as a model, example, or point of reference." The lack of consensus related to SBOM formats precludes it from meeting this definition.
Above image borrowed from xkcd.com: A webcomic of romance, sarcasm, math, and language.
I admit that I'm no expert on standards or SBOMs (or anything beyond making chili and the proper use of semicolons). But it seems we haven't yet arrived at the "standard" part of standardization. This seems problematic. It's critical that we come together as a community to decide on what information we find important and attest to how we will derive it.
Reason #2: The amount of data contained in an "acceptable" SBOM may not be adequate
As I mentioned earlier, Biden's 2021 Executive Order also required the NTIA to produce minimal specifications for SBOMs, which it did (see the result here). Those specs included the following:
- The name of the software component
- The version number or identifier of the component
- A unique identifier for the component
- Information about the license under which the component is distributed
- Information about the dependencies of the component, including the names and versions of other components it relies on
- The platform or operating system for which the component is intended
- A cryptographic hash value used to verify the integrity of the component
- A brief description of the component and its functionality
- Information about the supplier or vendor of the component, such as name and contact details
- Information about known vulnerabilities associated with the component
- Information about the component's development, maintenance, and support lifecycle
- Information or references to evidence supporting the claims made in the SBOM
"These fields aim to provide transparency and improve the understanding of software components and their associated risks in the supply chain," NTIA wrote. "However, it's important to note that the specific fields included in an SBOM may vary depending on the requirements and context of the organization or industry using it."
The agency knew it was walking a fine line. Manufacturers and developers would be less likely to comply if the agency required too many fields. If it required too few fields, there wouldn't be enough information for the SBOM to be useful.
Was it the right balance? It depends on who you ask. Just last week, a colleague of mine said, "I just saw my first SBOM. I have to admit, I was underwhelmed." In his opinion, there was not enough information to trace a vulnerability if it became necessary to do so.
Reason #3: There are multiple ways to generate SBOMs
In its "Innovation Insight for SBOMs," Gartner notes that SBOMs should not be static documents and that they should be updated with each new release of a software component. The analyst firm advises organizations to select SBOM tools that:
- Create SBOMs during the build process
- Analyze source code and binaries (like container images)
- Generate SBOMs for those artifacts
- Edit SBOMs
- View, compare, import, and validate SBOMs in a human-readable format
- Merge and translate SBOM contents from one format or file type to another
- Support use of SBOM manipulation in other tools via APIs and libraries
There is a variety of different tools on the market that generate SBOMs, all of them with different bells and whistles. Some come bundled with scanning tools. Some are standalone. Some, like Open SBOM's SPDX SBOM Generator generate only one SBOM format. Others, such as Fossa, support multiple SBOM formats. Some can be run locally via a CLI.
Outshift by Cisco's Panoptica uses the latest industry standards to sign and verify software, including sigstore keyless, symmetric, and asymmetric code signing, to make sure your software is secure and reliable. You can use its free tier—which supports 15 nodes and one cluster—forever.
One challenge that has yet to receive much attention is the issue of integrating multiple SBOMs. In her blog, "KubeClarity: Multi SBOM Integration," author Pallavi Kalapatapu compares using Trivy and Syft, both open-source analyzers that can generate SBOMs for containerized applications. She notes that both of these tools have unique strengths and weaknesses when detecting libraries in a container.
"Managing multiple Software Bill of Materials (SBOMs) may seem quite challenging, given the complexities of handling a single one," she writes, adding that integrating multi-SBOM helps increase the coverage and accuracy of detection.
Kalapatapu describes how KubeClarity (an open source tool that detects and manages SBOMs and scans for vulnerabilities in container images and filesystems) ingests various SBOM formats and converts them into the native format required by vulnerability scanners. Since each vulnerability scanner expects SBOMs in specific formats, merging SBOMs involves the bulk of the work, requiring careful balancing and standardization of inputs to ensure compatibility.
Beyond the SBOM: So, what's next?
According to the experts featured in a recent webinar featuring several prominent industry experts, building software supply-chain security into solutions is crucial to avoid pipeline modification and increase adoption, but information interchange and trust remain complex challenges. Modifying the CI/CD pipeline to incorporate security measures will probably lead to reduced adoption, whereas building security measures into solutions will increase it. Supply-chain security must be addressed at the component level, and while managing fleets of applications may require commercial products, developers cannot rely on commercial solutions to solve the problems.
At the end of the day, the interchange of information and trust remains a complex challenge in software supply-chain security, and the responsibility for this exchange lies with vendors. There are a multitude of problems we'll need to address as we work on solutions.
Let me know your thoughts about SBOMs and software supply-chain management in the comments and don't forget to connect with Outshift on Slack!
Top comments (0)