Why are SBOMs failing to stop supply chain attacks?

A software bill of materials (SBOM) has the potential to prevent most supply chain attacks.

An SBOM is like a “list of ingredients” tag for software that, along with signatures and attestations, enables traceability, including information like:‍

• Who created the software (attribution).
• Where this software comes from (provenance)
• What the software contains.

A standard format is also an ideal tool for sharing this information between CNAPP tools.

However, the lack of motivation to properly verify software integrity and the lack of support from developer tools limit the utility of SBOMs. 

Let’s analyze the role of SBOMs in the software lifecycle, and what is holding back their adoption.

SBOMs in the software lifecycle

Software development goes a bit like this: Someone takes a few libraries and tools, puts them all together with code, and creates a new piece of software. It’s also a chain; someone will take this software and build something new on top of it.

With so many dependencies between components, an incident on a small component can compromise millions of systems. This is what happens with OpenSSL, an open source cryptography library used by most computer systems. A vulnerability in OpenSSL often becomes a global security risk.

This potential impact is what makes supply chain attacks so attractive for malicious actors.

Software attestations are great for protecting your infrastructure against most supply chain attacks. They are structured data containing SBOMs, as well as any kind of arbitrary data like the origin source, or a list of vulnerabilities. Attestations can be signed by the developer and software repository.

Attestation for container images can be downloaded and verified with docker scout attest:

Learn more in How to secure Kubernetes deployment with signature verification.

By verifying a container image digest against its attestation signatures, you can determine whether someone has modified the image or impersonated the repository. Be aware that this check has its limitations; it won’t cover cases where the repository itself, or its keys, are compromised.

Ideally, you would perform this check before using any software, especially before deploying it to production. Then, you would also generate and sign SBOMs when packaging your own software.

For a Kubernetes development, the lifecycle would look something like this:

On paper, this looks great: You know what you’re using and where it came from. This protects you from most supply attack vectors.

So why are the adoption rates for SBOMs so low? Let’s explore some challenges SBOMs face in achieving support and effectiveness.

Challenge 1: Inconsistent tool support

Everyone who’s dealt with digital signatures knows the pain it entails.

Although many software development tools support attestations, getting all these tools to work together across developers and infrastructure teams requires some setup and fighting with the command line. Implementing this system doesn’t scale to corporate environments or big teams.

This causes a vicious cycle. Without tool support, adoption is low, and this low adoption doesn’t motivate tool support.

However, with good support from the tools, digital signatures are almost transparent. One good example is Apple’s notarization system. Apple’s developer tools automatically generate, sign, and notarize the apps for the developers. This doesn't generate an SBOM, but it deals with signatures mostly seamlessly.

Challenge 2: You can’t trust every SBOM

When you buy mayonnaise, its ingredient list won’t tell you whether it contains Salmonella. In the same way, a developer won’t know if their software contains malware.

The SBOMs provided by developers are good for quick checks, like when exploring new libraries, base images, or tools. However, both users and repositories need to perform their own tests to be certain of what they’re using. For container and Kubernetes workloads, image scanners are the tool to perform these checks.

As most container registries don’t perform their own scans to complement what the developer declared, their SBOMs are just informative.

However, you can perform your own image scanning. Doing so on your CI/CD pipelines will allow you to block releases if the images don’t follow your organization’s security policies. Also, by integrating an image scanner with a Kubernetes admission controller, you can generate comprehensive SBOMs that complement developer-provided ones and block offending images from reaching production.

Challenge 3: Vulnerabilities change over time

One of the things that image scanners look for is known vulnerabilities.

With that information, you can decide to block the deployment of those container images that contain a critical and exploitable vulnerability. In fact, some tools are starting to include vulnerabilities in the SBOM they generate.

However, one scan is not enough. As new vulnerabilities are discovered every day, you need to continuously check your images for them. If an SBOM declares vulnerabilities, don’t take that information at face value. Check when that scan was performed, and complement that SBOM with your own checks.

Luckily, some CNAPP platforms already do this for you:

• They perform an initial scan to know what’s on the image and its vulnerabilities.
• They complement the scan results with context from your infrastructure.
• They store this information in SBOM format, so they don’t need to re-scan the image to look for new vulnerabilities.

Challenge 4: Internal threats

Finally, an SBOM doesn't cover cases where malicious actors have inside access.

This could be because a team member has been compromised, as in the incident with Axio’s npm package; or because some employees are impostors, working for organized groups with malicious intent. Either way, an attacker can use this inside access to hide malicious payloads in your software.

One of the most severe incidents was the 2024 backdoor in XZ Utils, a library used in OpenSSH, a remote access utility installed on most servers and development machines. A malicious contributor had been providing useful code for years until they suddenly snuck in a backdoor.

Sadly, you often need to execute the code to detect these malicious payloads, and traditional image scanners don’t perform this kind of dynamic attack. Furthermore, when AI is used recklessly to generate code, it introduces noise that makes it harder to detect anomalous code.

That’s why SBOM and attestations alone are not enough to detect new vulnerabilities, and you need to put extra checks in place.

Luckily, AI is also demonstrating its power in finding software vulnerabilities. This means internal threats can be detected if AI is implemented alongside image scanners in CI/CD pipelines.

Conclusion

An SBOM is a standard tool for sharing information between CNAPP components.

A software supply chain is a chain of trust, where every link matters. Everyone in the chain must perform their checks, communicate their findings through the SBOM, and certify their authority with signed attestations.

Since this is all voluntary, organizations often don’t put the necessary checks in place. There’s also a lack of support in software development tools. All this means too many SBOMs don’t hold the useful information they should.

But that doesn’t mean we should just give up on SBOMs. Just as with other cornerstones of our society, like food, health, and industry, we need regulations to enforce supply chain trust in software. 

Even if SBOMs are imperfect, they’re still an invaluable tool for your internal infrastructure. You can start generating SBOMs with image scanners and using them as inputs to your policy evaluators, or you can provide them with your software to build trust with your users. The world will eventually catch up, and you’ll be a step ahead.