Security is Not an SBOM Problem

In this article, I cover:

• What a software bill of materials (SBOM) is, and how it helps with the information problem of vulnerability management

• That vulnerability management isn’t at all constrained by information, but by the operational pain of patching

• That this makes SBOMs, in most cases, a glorified JSON schema

Software Bill of Materials

A Software Bill of Materials (SBOM) is a standardized piece of metadata, provided with software, covering what that software is, who made it, its version, and crucially, all of the dependencies it contains. The goal is for everyone to provide SBOMs of the stuff they make, so that we can all know what software dependencies it’s made of, and make correct security and patching decisions. SBOM as a concept has been skyrocketing in popularity over the past couple of years. Twitter is talking about it. Defcon has talks on it. CISA is issuing guidance on it. Vendors are asking me about it as an exciting thing I should pay extra for.

The claimed advantage of SBOMs is nothing short of reshaping how we go about supply chain security. It would allow organizations to quickly ingest data about their dependencies to report and act on. This new, standardized information influx would empower organizations to fix their supply chain problems. Solarwinds and Log4Shell are often promoted as the kinds of vulnerabilities SBOMs will help us solve. CISA is pushing this heavily, and SBOMs even have their own executive order.

In a less hype-speak way, SBOMs aim to solve the problem of a lack of information in vulnerability management: With some assumptions on the validity of the SBOM, you can always know what's contained in your dependencies and their downstream dependencies.

Vulnerability Management is Not an Information Problem

In a modern-ish software shop operating on the cloud (I’m using AWS terms here going forward), developers make code changes and add dependencies to their particular language's dependency file, requirements.txt or maven.pom or whatever. This is built by their build pipeline into a container that's pushed to their container image store, probably ECR or something. This is deployed to EC2, ECS, or, if they're feeling fancy, EKS.

To check compliance and security checkboxes, this software company has probably turned AWS Inspector on to scan ECR and running instances. If they're feeling fancy, they have additional scanning in the build pipeline to scan for dependency and container information and vulns, but it doesn't really matter in this context; Inspector is going to find all of it. Specifically, AWS Inspector finds and reports on:

• All 3rd party software dependencies contained in software deployed on containers in ECR (Python, Java, etc., dependencies in your built software packages)

• All 3rd party software installed on the container

• All 3rd party software installed on the host running the container

This provides a lovely report of all the vulnerabilities it found, the containers it found them on, and the instances running them:

Usually this, but with depressingly more orders of magnitude of results

In the vast majority of software organizations, this information is quietly tucked away in a drawer and only pulled out in response to Log4Shell or other significant incidents, where the software shop needs to answer the question of "Oh shit, do we have log4j running anywhere?". Otherwise, they probably patch stuff every six months or something so their auditors don't yell at them too much.

If you're not a cloud-based software company, that’s fine. There are an endless number of vulnerability scanning and management tools. It’s not as easy a checkbox to click, but you end up with the same result: Tons of reporting on vulnerabilities you’re probably not patching.

But Why SBOMs?

SBOMs try to solve the lack of information in vulnerability management. Sadly, given the plethora of tools that already do that, this is far from the primary constraint on fixing vulnerabilities. Those are a tale as old as time:

• Limited capacity to patch, or to refactor to remove reliance on unpatchable systems

• Little operational expertise for patching, or tolerance for potential outages

• A lack of significance of most dependency vulnerabilities fostering a culture of not caring, except for very intense exceptions (Log4Shell, etc)

All these problems persist despite the reporting we have above; information is not our constraint. Most organizations have horrendous patching practices anyway because patching is hard. Since SBOMs only help solve the information problem of vulnerability management, they can only really help if we've already exhausted the value of our current information. We (as an industry, not my current company; my current company is obviously perfect, whoever it happens to be when you read this article) haven't. We aren't even close.

The informational advantages appear to be marginal at best. Sure, I am focused on more modern, SaaS-y situations. There is a genuine information benefit in shipping an SBOM with a close-sourced, compiled, statically-linked binary as your software product. For being a user of those binaries, all of the ways I’ve discussed to get dependency data don’t work. I'll accept that. However, that situation has become a lower percentage of deployed software with every passing year. More importantly, we don't patch adequately when we do have that information. So why would it be different for these use cases?

Relatedly, I dislike the trust in SBOMs. I prefer actively scanning my systems rather than trusting metadata shipped with a package. Sure, I can use the SBOM provided by a random SaaS or closed binary provider to know their dependencies, but a SaaS running many versions old unpatched Django or Struts or Spring will probably also lie in their SBOM? This doesn't even help me respond to a critical vulnerability in their product any better, even if it's accurate; the SaaS company already has my data. It makes them more contractually liable, sure, but that’s little solace post-breach that my lawyers will have a better time picking at the scraps.

So why SBOMs? It's probably marketing hype. SBOM as a concept is just past the peak of its hype curve (though it's been eclipsed by GenAI in the zeitgeist now; see my last blog). It has legitimate value, but at the margins. CISA gives a recommendation or two about it, there's a Black Hat or RSA talk, and now suddenly everyone is discussing it. My customers are asking for SBOMs instead of dependency lists as a CSV. Vendors are bolting it onto places of their product so they can write product marketing blogs about it and try to upsell you on the SBOM package or something. Give it a year or two, and we'll be back to having reasonable takes about SBOMs, but for now, it's hype. Some evidence:

Snyk specifically (but basically every dependency scanning vendor) has started shipping an SBOM API. They were all excited when they launched it. You can see in their (and everyone else vaguely in the space) blog posts that they think this is important to supply chain security. Clearly, this is a big deal, not just providing the same information existing APIs have for years in a different format. To be clear, taking advantage of hype is product marketing's entire job, so I don't besmirch Snyk too much here.

My point is that SBOMs are just a different format from what all these tools have been doing for over a decade; it’s just a different JSON specification than the APIs that have previously existed. That's neat! That’s good; it’s genuinely useful to move towards open standards for describing these kinds of things. But not presidential executive order big.

But I’m an optimist at heart, so here's looking forward to the post-hype usefulness! Once all vulnerability management tools use the same SBOM/dependency format (there are multiple, here’s the obligatory xkcd comic), I'll have to write fewer conversion scripts to fit my tools together. There are certainly worse outcomes.

I'd Love To Hear From You

Do you agree? Disagree? Intensely? Do you have any other feedback for me? Please leave a comment below; I'd love to hear it!

I'm not great at self-promotion, so if you enjoyed this post, please subscribe so you can get more and farm that sweet karma by posting it on HN and various social media sites. If it filled you with a deep rage, please subscribe so you can hate-read it and hate-share it with others.