The Benefits and Challenges of Building an SBOM

The EO 14028 regarding supply chain security and the need to generate a Software Bill of Materials feels closer to more and more organizations. It might feel like a threat - and that’s a fair feeling. The whole topic of Billing of Materials is not new, but it is a relatively recent trend for software. According to Gartner: “by 2025, 60% of organizations procuring mission-critical software solutions will mandate SBOM disclosure in their license and support agreements, up from less than 5% in 2022.” - there is a lot of pressure if you’re operating in that space.

You probably have a lot of questions: How do I generate an SBOM? Where do I need to store it? What’s the format of the SBOM? And why does my organization actually need it?

Before you get into the weeds and get all overwhelmed by the allegedly important SBOM,let’s weigh out the pros and cons of an SBOM. In the previous article we covered what is an SBOM and whether you ACTUALLY need it. At the moment it is a rare occasion that your organization will need an SBOM if you’re not doing business with US Federal Agencies.

This doesn’t mean that being ahead of the game and knowing the value of the SBOM will not be beneficial for you and your organization in the near future. In this article we’ll have a look at the benefits and challenges of an SBOM. The transparency aspect of an SBOM sounds important - and it is. However, SBOMs are still quite immature and it might be a challenge to adopt and get value out of it. Let’s dive right in.

Benefits of an SBOM: when is it helpful? What is it helpful for?

The first thing we need to keep in mind is that an SBOM gives transparency and visibility to an organization about the components of their software. This transparency and visibility aspect of the SBOMs is what allows for the rest of the benefits of using and generating an SBOM.

1. Software Supply Chain Security

An SBOM is a list of the components that are used in an application. These components (or dependencies) can be Open-Source Software (OSS), native software that you have built in-house and/or commercial software that your organization has procured. 

The software supply chain comprises all the above. So, if a malicious actor wants to obtain access to a target organization’s systems, they will likely try to target weak links or dependencies in the software supply chain. Once a user installs an infected package, the vulnerability spreads to the software and this is considered a supply chain attack. 

An SBOM provides great transparency of all the components in your software. With this increased visibility and with the use of a vulnerability scanning tool, such as Snyk, you can identify known vulnerabilities and prevent supply chain attacks.

2. Licencing & Regulatory Compliance

Licenses and standards instruct organizations to comply with some rules, prove they follow processes and that their software is free from harmful 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 benefit you in meeting these standards.

Additionally, with the recent supply chain attacks, such as this of SolarWinds in 2020, the Biden Administration has issued an executive order that aims to improve US’s cybersecurity defense. One of the requirements is that vendors should provide an updated SBOM to increase transparency and prevent similar attacks.

3. Consumer Confidence

Imagine the SBOM as the food label that is at the back of the grocery items. Often we consult these labels before we make a purchase. Similarly, software buyers can refer to the SBOM to determine whether the product is safe, free from vulnerabilities and suitable for the buyer. 

Research has shown that in 2015, 35% of software development projects were open source components, and in 2022 that number increased to 90%. Considering the supply chain attacks, malicious actors now have more possibilities to attack a software package than before through the open source components. 

Creating an SBOM is a proactive approach to understanding the supply chain and ensuring the various components will not harm the software or be vulnerable for potential attacks. Additionally, an SBOM can be critical when an organization is about to be merged or acquired. An SBOM can simplify the audit process, provide transparency and increase trust from the prospects perspective.     

What are the challenges that come from having to extract an SBOM?

While the benefits of an SBOM are important and in some cases pivotal for an organization, adopting, generating, maintaining and storing an SBOM are still considered hurdles that present challenges for software teams and organizations.

1. System complexity

With more and more tools, software components and cloud applications, the complexity of the systems is growing continuously. Extracting an SBOM in this complex environment is ultimately quite complicated and it would be really time consuming if we had to do it manually for every software component. The solution to these challenges is to use a Software Composition Analysis tool. This allows you to… 

Another limitation of the SBOMs when it comes to system complexity is the depth of the SBOM analysis. In order to identify transitive dependencies that could unfold potential vulnerabilities, we need to look deeper than just the “top layer” of the software components. For example, looking just the SBOM of your Docker container will probably not show vulnerabilities that exist in an earlier stage of your software development cycle. 

2. Size of the SBOM files

SBOMs are dynamic and large documents/files. By dynamic we mean that, in order to have an updated SBOM you need to generate a new one every time a new component is released. These files are large and need to be stored somewhere. The combination of the frequent SBOM creation and their large size, makes storing an expensive variable you need to consider. You can store your SBOMs in an artifact repository or in a git repository. However, these files contain sensitive information and need to be stored in a secure place, and at the same time to be easily accessible by the necessary individuals. 

3. Adoption of SBOM

Even though an SBOM used right can be a valuable resource, the adoption of SBOMs is slow and still immature. At the moment, providing an SBOM is not a requirement and thus not many organizations ask for it. Unless you are working with a federal agency you don’t need to have one. 

Now, the benefits are great as we saw before, however with slow adoption the difficulty of generating, maintaining and sharing an SBOM will remain present. As SBOMs become a more frequent requirement, more tools will appear that make this process and the adoption easier and more spread.

4. Need for 3rd party tool support

We mentioned earlier that in order to generate an SBOM manually you need time and resources, and with the complexity of the systems, it is probably a painful process. The need for 3rd party tools, such as SCA emerges.  

You don’t just need third party tools to generate an SBOM, but to also extract the value out of it. It is important to remember that an SBOM is just a list of the software components. Simply generating an SBOM does not give much value unless you plug it into a 3rd party tool that will help you identify existing vulnerabilities, e.g. Snyk.

5. Variable names and exchangeability 

Although there are two primary standards for software bill of materials (SBOM) - SPDX and CycloneDX - and official recommendations from NIST and EO regarding the data fields that SBOMs should include, a recent study found that 63% of respondents stated that SBOMs generated in practice do not meet the minimum requirements. 

This is due to two main factors: data availability and software vendor customization. Some software vendors do not include all the recommended data because it is not readily available, and others only incorporate a subset of the minimum recommended data or customize the requirements to suit their own needs. 

As a result of the lack of consensus, one-fourth of the respondents reported that their organizations use customized, non-standard formats. As a result, communication and adoption are a struggle. 

6. Accuracy of results

When you generate an SBOM you might find hundreds of vulnerabilities in the component list. However an SBOM does not tell you specifically whether you have been using these vulnerabilities in your actual software. In order to narrow down the vulnerabilities and focus your attention to the ones that matter and could potentially cause issues to your software, you need to review the Vulnerability Exploitability Exchange (VEX).

The bottom line

The goal of this article is not for us to direct you on whether you should focus on generating an SBOM or not (even though we have strong opinions on it),  but rather present the facts. The pros of generating a Bill of Materials for your software are really important. Supply Chain Security and Compliance are core concerns for organizations operating in regulated industries, such as banking, medical device manufacturing, automotive industry and for organizations that work with US Federal agencies. 

On the other hand the challenges for generating and storing an SBOM are worth considering. The slow adoption of the SBOMs though could be a curse and a blessing. While the adoption is slow, given the buying power of the Federal Government, the rest of the software industry will more likely follow the trend and require SBOM for all critical software. Starting experimenting with SBOMs in your organization will put you ahead of the competition and will increase your internal software security.