The Software Bill of Materials, Part 2: Drivers, motivators, and challenges

The many actual benefits discussed in part 1, both for suppliers and customers, have been significant drivers for the popularity of SBOMs. Still, working with an SBOM presents a set of challenges to be aware of and to overcome. In this part, we take a more detailed look at the drivers, motivators, and challenges for the usage.

---

Catch up on other posts in our SBOM series:

The Software Bill of Materials, Part 1: Benefitting from the SBOM

The Software Bill of Materials, Part 3: The SBOM file

The Software Bill of Materials, Part 4: SBOM with Debricked

Compliance and regulatory requirements 

New regulations and requirements have appeared from a range of different organizations, governments, and similar. These requirements are in response to the many supply chain attacks that we have witnessed over the last few years.  

Cybersecurity executive order  

Perhaps the one that is most cited is the Biden cybersecurity executive order from May 2021. It is noted that the private sector needs to step up the game if they are to provide systems to the U.S. Federal Government. To enhance software supply chain security, the order lists a set of requirements that need to be fulfilled for these suppliers.

One part of the order discusses SBOMs and specifically requires that the purchaser is provided an SBOM together with the purchased software. At the same time, the National Telecommunications and Information Administration (NTIA) was tasked to create a list of the minimum required elements of such an SBOM. 

Proposed DHS law 

Related is the H.R.4611 – DHS Software Supply Chain Risk Management Act of 2021, which is a proposed law that will require contractors to the Department of Homeland Security (DHS) to submit an SBOM together with a certification that there are no security vulnerabilities in the software. Alternatively, if there are known vulnerabilities, they must provide a list of these.  

The EU Cyber Resilience Act 

In the EU, there is a proposal for a regulation for cybersecurity requirements, the Cyber Resilience Act. Regulations are mandatory to follow for all member states. Among other things, the Cyber Resilience Act requires manufacturers to draw up an SBOM. Different from the U.S. regulations, this EU regulation will apply to all manufacturers of products with digital elements that connect to a device or a network. On the other hand, only top-level dependencies need to be included in the SBOM. 

FDA requirement 

For specific markets, the FDA is currently pushing for an SBOM to be a mandatory requirement for healthcare products. This is in response to an increased number of cybersecurity incidents in healthcare, as, e.g. reported by Forbes. Moreover, patient data protected by healthcare products are typically very sensitive, and service disruption by these products can jeopardize the life of people. 

Other guidelines 

In addition, guidelines from the National Highway Traffic Safety Administration mention SBOM as a means to track vulnerabilities in the vehicle development process. These guidelines are non-binding and voluntary but underline the importance perceived throughout several verticals. 

The cybersecurity threat landscape 

Requirements and legislation will drive the adoption, but these requirements emerge from the actual need in industry and society. The cybersecurity threat landscape is present with or without regulations, and many businesses adopt SBOM practices regardless of external requirements. Let us take a brief look at the cybersecurity threat landscape and how it is developing. 

New vulnerabilities 

First, the number of vulnerabilities registered as CVEs in the National Vulnerability Database is increasing. In 2017, the number of new vulnerabilities jumped to more than 14 000 after previously never exceeding 8 000 in a year. Since then, the number has steadily increased, and in 2022 it surpassed 25 000.

There are more vulnerabilities if we include the GitHub Advisory Database and those that are language specific, e.g., FriendsOfPHP and the Python Packaging Advisory Database, but there are significant overlaps. 

Exploiting vulnerabilities is a common attack vector 

A known vulnerability can be used as an attack vector in a breach. With many vulnerabilities across a range of applications, there are more opportunities to mount attacks. Surely enough, looking at the top attack vectors as observed by IBM Security X-Force in the 2022 report, 34% was due to exploiting vulnerabilities, second only to phishing. Thus, fixing security vulnerabilities must be top-of-mind for organizations relying on software applications in their business. 

Cost of breaches 

So, clearly, there are not only breaches due to security vulnerabilities, but they are prevalent. Add to this; a breach is very costly. The global average cost of a data breach caused by a vulnerability in third-party components is estimated to be $4.55 million. If you do not take application security seriously, it is just a matter of time before it happens. 

In all, it is clear that the cybersecurity threat landscape calls for investing in application security. The alternative is just too costly. With assessing and remediating security vulnerabilities being a top SBOM use case, it is natural to adopt it.  

Reliance on software 

Software is shaping our society, and every day we have become increasingly reliant on software. In the smart city, we try to optimize for sustainability and efficiency through sensors, actuators, databases, communications, and processing.

The data that is collected, processed, and stored will often be sensitive, so we need confidentiality. Also integrity protection is needed to ensure that the data is not modified in transit or at rest. All parts and their functionality are controlled by software. 

Since software influences how we live and work, the need to have better insights into its inner workings becomes more important. The SBOM can be used to provide at least parts of this insight.  

Challenges 

From the previous discussion, it should be clear that SBOMs are here to stay. But, when generating and working with SBOMs, there are several challenges to consider. It’s not just to generate an SBOM and call it a day. Having an SBOM is not worth much if you cannot, or do not, use it for its intended purposes.

Completeness 

Completeness refers to the SBOM including all data that is expected. Looking at the various SBOM formats, there is support for many different entries. A complete SBOM does not have to include all this data. Instead, it does have to cover all software components that it sets out to include. Moreover, if there is information for a component that can be expected to be included, this must be included.  

Missing components 

If information is missing, e.g., there is an open-source software component that is used but not included in the SBOM, then this poses a risk to the receiving organization. It could mean critical vulnerabilities that can not be listed and assessed. It can also mean that the application uses a component with a non-permissive license in a way that violates the license. In addition to the security and license compliance risks, incomplete SBOMs will reduce the trust in the provider and can delay the time-to-market for an application.  

Missing information 

The same is true for open-source components that are included, but information about the component is incomplete. In many cases, vulnerability information is written directly in the SBOM. Then, if vulnerability information is only taken from NVD, there will likely be vulnerabilities that are present but not included.  

Known unknowns 

It can be argued that an incomplete SBOM can be worse than no SBOM at all. If we think the SBOM is complete, we will have a false sense of security, perhaps letting the guard down and not being fully prepared to handle an exploited security vulnerability. With knowledge of a vulnerability, even if it is not patched, other measures can be taken to avoid exploitation and breaches.

To help with “known unknowns,” the common SBOM formats have support for indicating if a dependency relationship is (possibly) incomplete or if all relations have been accounted for. 

Up-to-date 

An SBOM is not a one-off thing. It is a moving target that needs to be kept up-to-date. Having an outdated SBOM comes with the same risks as having an incomplete one, erroneous data.  

The SBOM can become outdated for different reasons. An application continuously developed and updated will soon have an outdated SBOM. New dependencies will be used, some will be updated to newer versions, while others might be removed.

Any assessments based on outdated SBOMs risk having errors. Vulnerabilities can be missed, while some might already be fixed. The first is a security problem, and the latter gives overhead for developers and security analysts since there will be false positives in the assessment. 

Outdated external data 

The SBOM can also be outdated in terms of the external data it can provide. In particular, security vulnerabilities are constantly discovered. If the SBOM includes a list of known vulnerabilities, e.g., CVE identifiers, such a list will be outdated as soon as there is a new vulnerability affecting any of the included components.

This should come as no surprise, and looking at the guidelines for how to use the SPDX specification, it is even explicitly stated that “SPDX consumers should always assume vulnerabilities enumerated by an SPDX creator to be out-of-date.” The need for having up-to-date SBOMs makes it important also to include a timestamp.  

Automation and SCA 

To help generate the SBOM, automation is almost always necessary. There are just too many dependencies in software today, and there is too much information that needs to be collected and to keep up-to-date to do it manually. An automated tool is less error-prone and can generate a full SBOM in a fraction of the time compared to manual processes. 

Instead of having to constantly update the SBOM due to external changes, an SCA tool can be used to keep track of vulnerabilities, alert you when they arise, and even help you to fix them. This will always provide an up-to-date view of the risks. For developers, by integrating the code repositories with the SCA tool, the view will also update when there are new or updated components. 

Actionable 

The SBOM is useless if the information in it is not used. It cannot do anything on its own, which is why it is crucial that it is actionable. This means that both the content of the SBOM needs to be in a format that can be easily consumed and that its content can be used for the use case it is generated for. It also means that there need to be organizational processes in place to use the SBOM when it is received. 

Targeting the use case 

An SBOM with only license information could be sufficient if only license compliance is considered, but not if you need to certify that there are no vulnerabilities. If you want to use the SBOM to create an attribution report for your use of open-source software, the license text also needs to be included. It is not enough with the license name. 

Concluding 

The current threat landscape with an increasing number of vulnerabilities and attacks should be enough drivers for adopting SBOMs on a wider scale. If that is not enough, the push from regulations and authorities will surely help organizations in the right direction.

However, as we have seen, it is not just to turn a switch and have everything working in two shakes of a lamb’s tail. Some challenges need to be considered for a purposeful deployment.

To help push forward, to have automation, and to have interoperability between organizations, there are a few well-defined formats for encoding the SBOM information. The leading formats, SPDX and CycloneDX, will be described in the next part.