Why you need an SBOM (Software Bill Of Materials)
There's been a lot of talk about SBOMs in tech media. This blog post will help answer three crucial questions you may be asking:
- What's an SBOM?
- Why do I need an SBOM?
- How do I get an SBOM?
What's an SBOM?
SBOM stands for "Software Bill of Materials." It works hand in hand with the concept of a Software Supply Chain where both terms come from manufacturing and supply chain management. It's essentially a structured list of the third party components that go into your software.
There are a number of SBOM standards, but we'll focus on the CycloneDX standard here. CycloneDX grew out of the Open Web Application Security Project (OWASP), is licensed under Creative Commons Zero v1 (think a "public domain" license formulated to meet the laws of many countries), and is a widely known and respected standard. It is one of three standards accepted in the NIST SBOM guidance.
We won't dive deep, but here's a component listing for the @babel/polyfill NodeJS module from the ProtonMail web client's SBOM in CycloneDX's examples repository. It provides a variety of information about the component, including a published hash for that release that can be used to verify the authenticity of the component.
You don't need to read the example through and understand it thoroughly. But it's good to look through if you're interested. It provides a standardized way for you or a recipient of your software to understand what is in it, how to validate it, and to check it for known issues.
<component type="library" bom-ref="pkg:npm/%40babel/polyfill@7.10.4">
<group>@babel</group>
<name>polyfill</name>
<version>7.10.4</version>
<description>
<![CDATA[Provides polyfills necessary for a full ES2015+ environment]]>
</description>
<hashes>
<hash alg="SHA-512">f0161c9d5a90e64303d875e81c89c11fb1f56ffb8fdca767c026173aa1675ea82e3b2baee38dd65eeb1b2146d611f6376744f1934335b86ffc62e00c84d97ace</hash>
</hashes>
<licenses>
<license>
<id>MIT</id>
</license>
</licenses>
<purl>pkg:npm/%40babel/polyfill@7.10.4</purl>
<externalReferences>
<reference type="website">
<url>https://babeljs.io/</url>
</reference>
<reference type="issue-tracker">
<url>https://github.com/babel/babel/issues</url>
</reference>
<reference type="vcs">
<url>git+https://github.com/babel/babel.git</url>
</reference>
</externalReferences>
</component>Why do I need an SBOM?
An SBOM analysis is essentially a security and licensing tool, providing you and your customers an "OSS bill of materials."
For yourself
1: It helps you ensure the security of the software you use.
Many developers use open source components to speed development and avoid the reinventing of wheels. As some have put it, it allows developers to "stand on the shoulders of giants." But the more third-party dependencies you have, the less control you have over what's in them.
An SBOM helps you ensure the security of the software you run. This shows all of the third-party dependencies in a software package you might be using and provides a machine-readable way to automate security evaluations. For example, the @babel/polyfill module listed above is at version 7.10.4, but it was deprecated at 7.4.0 for reasons of performance and modernity and the last update was issued years ago at 7.12.1.
The SBOM segment above is itself from an example timestamped in August of 2020. You can not only run automated reports on the SBOMs of software you use at the time of installation, but a periodic run will help you see when parts are deprecated and help you understand when you might need to update. If, for example, the version you have is no longer receiving security updates, your regular checks might turn up a CVE for a dependency that you might otherwise not realize applied to your production systems.
2: It helps you ensure you're within the bounds of the licenses in your components.
There's a wide spectrum of open source licenses with a variety of permissions and obligations. When you use open source components, you implicitly agree to those licenses. An SBOM makes it easier to catalog the licenses in your dependencies. For example, the component shown above uses the highly permissive MIT license.
Companies have been sued over open source licenses. Wikipedia has a page on open source license litigation that covers both copyright and patent cases related to open source. In general, open source licenses are intended to promote use and innovation, but may have conditions that some businesses find onerous or incompatible with their intended use. Your stakeholders, shareholders, and customers will appreciate knowing the obligations created by the licenses so you/they can honor them, purchase a less restrictive/encumbered license (if offered), or replace incompatible dependencies.
For your customers
It serves as a transparency tool to give your customers the ability to run their own analysis to prove to themselves the security of the dependencies upon which your software relies and that the licenses to which they may be agreeing are compatible with their use.
Your customers would want an SBOM for the exact same reasons you would want one… or more. There's a federal SBOM requirement (Executive Order 14028 - "Executive Order on Improving the Nation’s Cybersecurity") which requires vendors to United States federal agencies to provide an SBOM with their software, either as a file in the package, or published on a website. That is part of a worldwide trend among governments and enterprises are following suit.
An SBOM is becoming a requirement to get a sales meeting, especially if you're selling to a government agency or selling to those who do.
How to generate an SBOM?
An important precursor to building an SBOM is running a Software Composition Analysis (SCA).
The first step is to run your analysis and use it to learn about your software's direct dependencies (dependencies you specify) and transitive dependencies (the dependencies your dependencies have). If your dependencies have known vulnerabilities, you have the opportunity to remediate those issues and regenerate your SCA before generating your SBOM.
Once you have a report, you can select the sources (one some or all) and generate an SBOM.
While you'll generally create the SBOM before a release, you can use SCA throughout your development effort for effective SBOM management, adding a trigger as a git hook on developer machines running our gg-shield client. This way you can address vulnerabilities and licensing issues as you go and not get any big surprises when you build the release SBOM.
Summing up
A Software Bill of Materials is increasingly becoming a prerequisite for selling software as government, enterprise, and even SMB customers become more security conscious and security savvy. The good news is that you can not only automate creating one, but the requisite steps give you insight into known issues with both the dependencies you declare and the dependencies they declare. This allows you to develop more secure software, comply with applicable licenses, and give your customers documentation to help their peace of mind.