7 min read
Your code base is growing more and more by the minute alongside the apps your business uses and develops. To give some context, the Linux Foundation Report estimated that “Free and Open Source Software (FOSS) constitutes 70-90% of any given piece of modern software solutions”. This means that 70-90% of your final software possibly depends on OSS. How do you know what’s in them and most importantly how do you know that the softwares you’re using to build your application is safe, secure and vulnerable-free? 🤔
This is where the Software Bill of Materials (SBOM) comes to “save the day”. Whether you’re deploying commercial apps or building your “own” software, a Software Bill of Materials (SBOM) will help you reduce incidents similar to SolarWinds and have full visibility into the software supply chain of the apps you deploy.Â
What is an SBOM?
Before we dive into the definition(s) of the Software Bill of Materials (SBOM), let’s take a step back and see the history of the SBOM. The concept originates from the traditional supply chain management term bill of materials. A bill of materials “is a list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts, and the quantities of each needed to manufacture an end product.”
Just like in manufacturing, software and applications consist of various other softwares, whether they are open source software (OSS) or commercial software, and an SBOM lists all these components.Â
With a simple search on the internet, we can find various definitions of an SBOM, but according to NTIA and CISA, an SBOM is a nested inventory for software, a list of ingredients that make up software components.Â
In simple words, a Software Bill of Material is a list of all the ingredients used to produce software. Definitions are good to give us an idea of what SBOM is, but what we need to know it’s who needs to have an SBOM and why is it important, especially nowadays?
Why would you need an SBOM?
In May 2021, the US government published an Executive Order (EO 14028) that recommends practices federal agencies should apply when acquiring, deploying, and using software. One of the requirements is a Software Bill of Materials (SBOM).Â
It states that software providers need to present a Software Bill of Materials (SBOM) to agencies before the latter proceed with purchasing and using the software. This means that for some software providers, an SBOM is almost mandatory ⏰
The goal of this EO is to “ensure software integrity to protect Federal systems from threats and vulnerabilities and reduce overall risk from cyber-attacks”, but this might not be far from being a security control, requirement and concern for a wider range of software buyers. Ensuring security is not just a matter of federal organizations but of every commercial organization as well. Â
With cyber attacks creeping in the vulnerabilities and dependencies of software, and security being the highest priority for software development (see the focus of the DevOps Enterprise Summit 2022 talks) and software procurement, having an SBOM seems to become the default in the near future.Â
If you watched the DOES22 talks and you’re still not convinced, here’s 4 reasons why an SBOM could be important for your software and your organization:
- Transparency
An SBOM will have all your software’s dependencies listed and visible to you to see the bigger picture and understand how your software is being built, what Open Source Software (OSS) is being used and identify any vulnerabilities quicker, before any damage has been done.Â
With more complex systems and more Open Source Softwares, it is crucial that you have a clear idea of the components that build your software and the tools your developers choose to work with.
- Security, security, security
With transparency in place, security becomes an easier task. Having an SBOM can assist in identifying and addressing any vulnerabilities or malicious software in the software product and its dependencies. It gives a thorough and up-to-date inventory of all the components and dependencies that make up a piece of software. A single vulnerability in a single component can have far-reaching effects in today’s software ecosystem, which is becoming more complicated and linked.
- Preventing supply chain attacks
And that’s where the prevention of supply chain and cyber attacks come into the picture. For an attacker to obtain access to a target organization’s systems, they will likely try to target weak links or dependencies in the software supply chain. Having an SBOM, you’ll be able to identify and address any vulnerabilities in the software supply chain and prevent supply chain attacks.Â
- Better compliance
Licenses and standards instruct organizations to comply with some rules, prove they follow processes and that their software is free from vulnerabilities. For instance, the Payment Card Industry Data Security Standard (PCI DSS), mandates that organizations maintain a thorough inventory of their software and its dependencies. By offering a detailed list of the parts that go into your software, an SBOM can assist you in meeting these standards.
From the above, it is clear that an SBOM is important for any organization that cares about staying secure and operating safely for them and their customers. Having a list of all components and software dependencies involved in the development and delivery of a software product, can increase software supply chain security and keep malicious actors out. But what exactly does an SBOM consist of and what do you have to present?  Â
What goes into an SBOM?Â
According to NIST (National Telecommunications and Information Administration) and The Minimum Elements For a Software Bill of Materials report, an SBOM must include the following data fields:
| Data Fields | Description |
|---|---|
| Supplier Name | The name of an entity that creates, defines, and identifies components. |
| Component Name | Designation assigned to a unit of software defined by the original supplier. |
| Version of the Component | Identifier used by the supplier to specify a change in software from a previously identified version. |
| Other Unique Identifiers | Other identifiers that are used to identify a component, or serve as a look-up key for relevant databases. |
| Dependency Relationship | Characterizing the relationship that an upstream component X is included in software Y. |
| Author of SBOM Data | The name of the entity that creates the SBOM data for this component. |
| Timestamp | Record of the date and time of the SBOM data assembly . |
What are the accepted SBOM formats?
As we said, a Software Bill or Materials (SBOM) is a list of ingredients and dependencies that make up a software. There are a few different ways to make an SBOM, such as using software composition analysis (SCA) tools, using SBOM data exchange standards, or using a combination of the two.
Whether you use SCA tools or not, the most important thing you have to pay attention to is the SBOM data exchange formats. These are accurate representations of the data source, making it possible for the different organizations and stakeholders to exchange SBOM data. Two of the most popular SBOM data exchange formats are:
- SPDX (Software Package Data Exchange)Â is an open standard by The Linux Foundation for communicating Software Bill of Materials information, including provenance, license, security, and other related information. It provides familiar formats for organizations to exchange important data.Â
- CycloneDX is also an open standard for representing SBOM data and was created by the OWASP community. It’s a more simplified version of SPDX and it’s primarily focused on security, in cases of vulnerability identification, license compliance, and outdated component analysis. Â
Conclusion
Long story short, the Software Bill of Materials (SBOM) is here to stay - at least for a while. Whether your organization is providing software to federal agencies or not, security, compliance and transparency are important aspects for all organizations. With the US government and the Executive Order initiating the need for an SBOM, the demand for it is expected to spread further from just the Federal agencies and to commercial organizations.Â
An SBOM might eventually be a security control, requirement and concern for a wider scope of software buyers and sellers. Consider your organization, when you want to purchase a software wouldn’t you want to know what software components it is built on? Is it secure? Does it have any vulnerabilities you should be aware of? All these are important questions to ask and consider.
