Computer software is a complicated construct composed of numerous diverse components. Open-source software is becoming ever more common as a building block in software.
This phenomenon is accompanied by an increase in exploitable vulnerabilities, so being able to tell quickly what your software is composed of is becoming increasingly important - both in applications that you develop yourselves and the ones from suppliers and vendors.
An important step to get complete insights into your applications is Software Bill of Materials (SBOM), which we’ll cover in this article.
What is an SBOM?
Put simply, an SBOM is a document that provides a complete inventory of all the components used in a piece of software and the connections between them.
Even though you may think the SBOM is a new idea, people have always had the need to understand the composition of their software, for example what components exist, external dependencies etc. Initially, the process was done manually, but as software became more and more complicated and interconnected a more automated format was required.
SBOM files include information such as the name, version number, and origin of each component, as well as any dependencies or libraries required for the software to function properly. The purpose of the SBOM is to provide transparency and visibility into the software supply chain, allowing organizations to better manage their software assets, identify potential security vulnerabilities or licensing issues, and facilitate effective software patching and updates.
There are different SBOM formats, but the most commonly used ones and the ones gaining more attention are SPDX and CycloneDX.
Using SBOMs is not a silver bullet solution that will solve all security related issues with open source and 3rd party software. Therefore techniques and frameworks like SLSA, package provenance and code-signing are important key elements in improving your security posture.
Npm has announced that package maintainers are now able to publish package provenance alongside their packages with verifiable links to their source repository and build instructions. Similar changes are coming to other ecosystems like Maven and PyPI. This will be covered separately in a future article. SPDX was developed in 2010 by the Linux foundation and CycloneDX is the format developed by OWASP, Open Worldwide Application Security Project. There are also tools to convert from one format to another.
Both SPDX and CycloneDX are human-readable. To see an example of a CycloneDX SBOM, look at this CycloneDX example SBOM repo.
The high-level object model for the CycloneDX SBOM format is this:
Source: CycloneDX SBOM example repo
Other great SBOM resources if you want to go in-depth:
Why are SBOMs important?
SBOMs are important because they provide organizations with the information they need to identify and mitigate risks associated with their software supply chains. SBOMs can also help organizations comply with regulatory requirements.
There are multiple on-going initiatives to emphasize the importance of security for open source and other components provided by 3rd parties. The Solarwinds attack in 2019 put supply chain attacks in the spotlight and also the need to improve resilience and protection.
The Biden administration has recognized the importance of SBOMs and has included them in its Executive Order 14028 on Cybersecurity. The order requires federal agencies to develop and implement plans to require SBOMs for software they purchase or use. The order also calls for the development of standards for SBOMs and for the creation of a public repository of SBOMs. An executive memorandum published in 2022 details further how agencies must comply with the guidance.
The NIS2 Directive, which was adopted by the European Union in 2020, also includes requirements for SBOMs. The directive requires operators of essential services to create and maintain SBOMs for their software and to make them available to the competent authorities upon request.
Although the scope of the executive order is only companies working with the US government, this will impact many enterprises. Those unable or unwilling to provide SBOMs will lose competitiveness. Also, not being able to provide the requirements of an SBOM might indicate a challenge to track all dependencies, which of course is a huge risk.
Gartner expects adoption of SBOMs to go from less than 20% in 2022 to 60% in 2025.
The initiatives and directives will lead legal requirements that companies need to comply with.
There’s no reason to wait. It’s always a good idea to have insights into what open source components are used and that exploitable vulnerabilities are remediated and that your organization is compliant with open source licenses. And complement with tools that allow you to control the use of open source.
How to create an SBOM
There are a number of ways to create an SBOM. You can use a commercial or any of the existing open-source SBOM tools, which will generate the SBOM files for you. The tool will need to be able to have access to your code base in order to scan your software for the components it contains.
Creating an SBOM file manually is error-prone and time consuming as you will need to identify the components in your software and then document the information about each component. The information you need to document will vary depending on the SBOM format you are using.
Once you have created your SBOM, you need to store it in a secure location. You should also make sure that you have a process in place to update your SBOM as you add new software to your environment. Remember also to request SBOMs from the providers and vendors of software you use. For example, Google’s Assured Open Source Software will provide a set of Open Source Software (OSS) packages that have been curated and where all have SBOMs in industry standard formats.
The formats are often represented in JSON or XML. Here’s an example of what an SBOM (CycloneDX, JSON) looks like:
Benefits of SBOMs
There are a number of benefits to using SBOMs, including:
- Improved security: SBOMs can help you identify and mitigate risks associated with your software supply chains. By knowing what components are in your software, you can better assess the risk of vulnerabilities and take steps to protect your systems.
- Compliance: SBOMs can help you comply with regulatory requirements. The Biden administration’s Executive Order on Cybersecurity and the NIS2 Directive both require organizations to create and maintain SBOMs. By using SBOMs, you can ensure that you are in compliance with these requirements.
- Reduced costs: SBOMs can help you reduce the costs of cybersecurity incidents. By identifying and mitigating risks early, you can prevent costly data breaches and other incidents.
- Improved decision-making: SBOMs can help you make better decisions about your software. By knowing what components are in your software, you can better understand the risks and benefits of different software products.
… and the challenges with SBOMs
While many tools will help companies to create SBOMS, most products are still immature when it comes to using them. There’s a lot of development ongoing and in the near-future we are likely to see tools that will support that use case as well.
Hint: Keep an eye on our blog.
Let’s talk
If you’re interested in discussing your use case and hearing more about the benefits that Bytesafe provides to organizations, feel free to schedule a Discovery Call.
If you are not already using SBOMs, now is the time to start. We are more than happy to help!
