What is an SBOM?
When making a good meal or buying food in the supermarket, we always pay attention to the ingredients used. You wouldn’t use meat of unknown origin in your chilli or make an omelette with eggs if you thought they might be out of date. If your friend is allergic to peanuts, you would look very carefully at the list of ingredients before sharing your cereal bar with her.
In exactly the same way that you wouldn’t want to put anyone at risk when serving food, we have to be aware of the “ingredients” in our software, so that we don’t do the same to our customers, or our software supply chain.
Software contains a large and wide-ranging number of components, parts, and interdependencies. Knowing the provenance of all the items in a product is critical, whether those elements originate with your team or outside of it, including open source software. The best way to do this is making a list of all the “ingredients” in your software. This is known as a software bill of materials or SBOM.
The SBOM’s role
An SBOM is a verifiable record containing full details of the components used in building software, including OSS and third-party software. The inventory that an SBOM provides is a crucial element of a secure software development framework, helping to detect vulnerabilities during software development, then playing an ongoing role during the life of the software.
OSS and other 3rd party software does not have the same level of controls as commercial off the shelf software (COTS). Open source and third-party code comes from well-known ecosystems, such as Apache Software Foundation and Eclipse Foundation, or respected artefact repositories, including Maven Central (Java), NuGet (.NET), npm (JS), PyPI (Python), and RubyGems (Ruby).
It’s important for your users to be able to access a list of code, and what it contains. This is where your SBOM comes into play. With an SBOM, software companies can identify:
- Your software’s “ingredients” – i.e. its components
- The origin of those components
- Licence information for each component
- Any vulnerabilities in your software
- Which parts require assessment and remedying
You must deliver the compliance artefacts beyond SBOMs to your customer. The National Telecommunications and Information Administration (NTIA) has outlined the minimum elements of an SBOM, such as data fields and their name, licence, and version. There is currently no standardised format for an SBOM, although there are industry-wide initiatives which are working to rectify this, such as CycloneDX, OpenChain, and SPDX.
Optimising your SBOM
An effective SBOM should have full visibility across multiple information sources. When optimised with cloud-based inventory management, an SBOM is an invaluable ongoing record of the development process. It contains information about 3rd party intellectual property, licence usage, compliance, vulnerabilities and security.
Don’t let one bad ingredient spoil your software
With a full catalogue of the origin and content of every ingredient in your project, you’ll be ideally placed to identify vulnerabilities and therefore fix any issues in good time, before they become problematic. By proactively identifying your software licence and security risks, you can ensure that one compromised ingredient won’t spoil your software or compromise your role in the software supply chain.
Traced’s SBOM Services
Any organisation that builds software should maintain an SBOM for their codebases. Find out how we can help you with our SBOM as a Service.
Contact us now to learn more about using SBOMs to help manage your vulnerabilities, and risk (financial, reputational, and legal).