To really secure software, you need to know what’s inside its code. That’s why a software bill of materials is essential today. It used to be that we didn’t worry that much about our code’s security. Bad binaries, sure. The code itself? Not so much. We were so foolish.
Then came one security slap in the face after another: The SolarWinds software supply chain attack, the ongoing Log4j vulnerability, and the npm maintainer protest code gone wrong have made it clear that we must clean up our software supply chain. That’s impossible to do with proprietary software since its creators won’t let you know what’s inside a program. But with open-source programs, this can be done with a software bill of materials (SBOM), pronounced “s-bomb”.
Indeed, SBOMs are no longer just a good idea; they’re a federal mandate. According to President Joe Biden’s July 12, 2021, Executive Order on Improving the Nation’s Cybersecurity, they’re a requirement. The order defines an SBOM as “a formal record containing the details and supply chain relationships of various components used in building software.” It’s an especially important issue with open-source software, since “software developers and vendors often create products by assembling existing open-source and commercial software components.”
Is that true? Oh yes. We all know that open-source software is used everywhere for everything. But did you know that managed open-source company Tidelift counts 92% of applications containing open-source components. In fact, the average modern program comprises 70% open-source software.
Clearly, something needs doing. The answer, according to the Linux Foundation, Open Source Security Foundation (OpenSSF), and OpenChain are SBOMs. Stephen Hendrick, the Linux Foundation’s vice president of research, defines SBOMs as “formal and machine-readable metadata that uniquely identifies a software package and its contents; it may include other information about its contents, including copyrights and license data. SBOMs are designed to be shared across organizations and are particularly helpful at providing transparency of components delivered by participants in a software supply chain.”
Best SBOM practices
An SBOM should include:
- The application’s open-source libraries
- The program’s plugins, extensions, and other add-ons
- Custom source code written in-house by developers
- Information about these components’ versions, licensing status, and patch status
- Automatic component cryptographically signing and verification
- Automatic scanning to produce SBOMs as part of your continuous integration/continuous deployment (CI/CD) pipeline
The SBOM should also use a consistent format. Popular SBOM formats include Software Package Data Exchange (SPDX), Software Identification (SWID) Tagging, and OWASP CycloneDX. While these are all standards, the 2021 executive order doesn’t mandate a specific SBOM format. So far, none of the three has arisen from the others to set a de facto industry standard.
To make SBOMs practical, there’s a push not merely to automate SBOM creation but to make it part of your CI/CD pipeline. As the National Telecommunications and Information Administration (NTIA) puts it, the ultimate goal is “machine-speed” SBOM generation.
SBOM use cases
SBOMs also have three different use cases. Broadly speaking, these are
- Software producers use SBOMs to assist in the building and maintenance of their supplied software.
- Software procurers use SBOMs to inform pre-purchase assurance, negotiate discounts, and plan implementation strategies.
- Software operators use SBOMs to inform vulnerability management and asset management, to manage licensing and compliance, and to quickly identify software and component dependencies and supply chain risks.
These are quite different. A developer wants tools that will work on their CI/CD pipeline, such as CircleCI, Jenkins, or Travis CI. An operator, or customer, might not even know what a CI/CD pipeline is but may care deeply about asset management and security patch updates.
Gartner estimates that by 2025, 60% of organizations building or procuring critical infrastructure software will mandate and standardize SBOMs. Today, it’s less than 20%.
Top SBOM programs
With three different SBOM formats and a wide variety of metadata to track within an SBOM, it’s no surprise that there’s nothing like a top SBOM program. Eventually, there will be, but we’re not there yet.
Many, but not all, SBOM programs, bundle code security scanners, and other programs. Whether you want them depends on your needs. Gartner recommends you use tools with the following capabilities:
- 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.
None of the following programs deliver on all these recommendations. Even the most mature of these programs — Anchore, FOSSA, and Rezillion — are still works in progress.
I advise you to try most, if not all, of these programs and see which one works best for you and your specific use case. Then give the vendors and developers your feedback. If we do this by 2025, we’ll probably have a clear best program for all our different uses.
Here are eight SBOM programs that deserve your attention:
Anchore
Anchore has been in the SBOM business for six years. Its foundation is built upon two open-source projects. These are Syft, a command line interface (CLI) tool and library for generating SBOMs from container images and filesystems, and Grype, an easy-to-integrate vulnerability scanning tool for container images and filesystems.
Together, you can use them to generate SBOMs at each stage in the development process, from source-code repositories and CI/CD pipelines to container registries and runtimes. These SBOMs are kept in a centralized repository for complete visibility and ongoing monitoring, even post-deployment. It supports CycloneDX, SPDX and Syft’s own SBOM format.
Anchore bundles its SBOM functionality into Anchore Enterprise 4.0 software SCM (supply chain management) platform. Anchore’s goal is to be your all-in-one software supply chain and SBOM security company. They’re well on their way.
FOSSA
FOSSA’s flagship programs are an Open Source License Compliance manager and an Open Source Vulnerability Scanner. If you think about it, SBOM fits quite naturally with these programs.
In FOSSA’s approach, you can integrate its SBOM tool with your favorite version control system such as GitHub, BitBucket or GitLab. Or you can use its CLI and run it locally or integrate it as part of your CI/CD pipeline.
Either way, when you scan your projects, FOSSA will automatically identify both the direct and deep dependencies for your target codebase. These deeply embedded code problems, such as indirect dependencies calling on Log4j, can hide within programs and still be used by hackers to wreak havoc.
Mend
Once known as WhiteSource, Mend offers a variety of software composition analysis (SCA) tools. SBOM is incorporated within its Mend SCA tool. As such, Mend is not so much a developer program or CI/CD tool as a programmer’s open-source license and security mechanism.
Thus, Mend can be used to track each component, including direct and transitive dependencies, identify vulnerabilities, provide a remediation path, and update SBOM records automatically as components change. The company claims its patented reachability path analysis shows you which vulnerabilities can be safely ignored either because the libraries are not used by your application or not used in a manner that exposes the vulnerabilities.
Rezilion
DevSecOps company Rezilion uses SBOM as part of its holistic software security and vulnerabilities systems. Its Dynamic SBOM uses dynamic runtime analysis to track your software attack surface as your code changes. So, it constantly looks up known weaknesses for your code’s components. In other words, it’s a two-for-one approach to tracking and securing your code.
Besides providing a live inventory of all software components in your CI/CD, staging, and production environments, it constantly updates your SBOM. You can export your SBOM as in CycloneDX and an Excel spreadsheet.
SPDX SBOM Generator
A standalone open-source tool, SPDX SBOM Generator does just what its name says: It creates SPDX SBOMs from your current package managers or build systems. You can use its CLI to generate SBOM data from your code. It reports on your code’s components, licenses, copyrights and security references. This data is exported in the SPDX v2.2 specification. If all you need are the basics, it will work well for you.
Tern Project
Another open-source SBOM project, Tern might pair well with SPDX SBOM Generator. Instead of working with package managers or build systems, this SCA tool and Python library generate an SBOM for container images and Dockerfiles. It also produces SBOMs in SPDX.
TauruSeer
This SBOM program is offered as a software-as-a-service (SaaS). Relying on a patented application-centric integration methodology, TauruSeer combines its Cognition Engine security scanning with its SBOM. The package will help you secure and track your code for your developers and customers.
Vigilant Ops
Vigilant Ops is a medical device cybersecurity company that, with its InSight Platform, has turned its attention to SBOM. Its SaaS platform generates, maintains., and authenticated sharing of certified SBOMs. It incorporates security using continuous vulnerability monitoring and alerting. Its SBOM certification uses patented algorithms to ensure that all components are validated, and vulnerabilities are linked.
Its security features can also be used with SBOMs generated by other programs. These are encrypted both at rest and in transit.
Copyright © 2022 IDG Communications, Inc.
