Tuesday, November 23, 2021

Patrick Miller gets SBOMs (almost) right


Noted power industry cybersecurity consultant Patrick Miller recently put up a blog post consisting of a recorded interview and transcript of a discussion of software bills of materials. He did a good job of articulating the most important argument for having SBOMs: they will allow software users to find out about dangers lurking in components of the software they run, vs. being totally blind to those dangers.

However, Patrick gets off track when he discusses how the users will actually learn about those dangers, in this passage:

PATRICK:

Effectively what happens is (the users) take (the SBOM) from the manufacturer, they use a tool to compare the two, and they know what's in there. They can say, 'Yes, all the things we expect are in there and nothing else is in there. They didn't insert garlic into my soup and now I'm going to get sick,' for example.

GAIL:

As part of the critical infrastructure, I ask for the SBOM, the manufacturer produces an SBOM, I run my tool against what they've given me, and it comes back a little different. What happens then?

PATRICK:

Well, that's when you have a risk. You have to have the conversation with the vendor to find out: did you actually get what you expected?

In some cases, there are things like file integrity and certificates that can go a long way to helping this. In some cases, it may just be that there's a mismatch in the tools. But that's an interesting conversation for you to have with your vendor and should be the first thing you do if things don't match up. You need to talk to your vendor right away, because things should line up.

I think Patrick is describing a sequence like this:

1.      The user receives software (either new or an update to software they’re already using); the supplier provides an SBOM with it.

2.      As a check on the supplier, the user uses a binary analysis tool to create an SBOM from the delivered software binaries (this isn’t an easy thing to do for various reasons, but it’s possible for someone with the right software development experience).

3.      The user compares the SBOM they received from the supplier to the one they created and looks for discrepancies.

4.      If they find a discrepancy, the consumer talks with the supplier to find out whether this was due to an innocent mistake, or whether it was a deliberate attempt to hide something – perhaps there’s a vulnerable component in the software and they don’t want the customers to know about it?

However, this sequence simply couldn’t happen, for several reasons. First, SBOMs are almost all generated by automated tooling on the supplier side, usually as part of the software build process – and I’m talking about machine-readable SBOMs, which are the only ones that scale. There are single software products, including one that’s installed today on millions of corporate desktops across the US, that have upwards of 5,000 components; the average product contains over 100 components. It’s kind of hard to create those SBOMs by hand. While it would certainly be possible to edit the JSON or XML code that constitutes the SBOM after it’s been produced, it wouldn’t be easy.

More importantly, it’s just about 100% certain that there will be a mismatch between an SBOM produced from binaries (as in step 2 above) and one that’s created with the final software build, without the supplier having to obfuscate anything. There are various reasons for this, including that there are almost always other files or libraries that aren’t part of the software as built, but that are essential for it to run; the binary analysis will capture these files, as well as those for the “software itself” (and unfortunately, the fact that SBOMs created from the build process don’t include files installed with the software means that the SBOM your supplier sends you will almost always leave out these additional files – and therefore you won’t learn about vulnerabilities in those files. This is an ongoing problem with SBOMs, although it’s certainly not a fatal one).

A bigger reason is the one I alluded to in step 2 above: creating SBOMs using a binary analysis tool is always going to be much harder than creating one through the build process, since the output from the tool will inevitably miss a lot of components and misidentify others. That’s why there is a lot of judgment required to clean up the output from the tool; and even after applying that judgment, the resulting SBOM will virtually never match an SBOM produced from the final build.

Binary analysis is required in order to learn anything at all about the components of legacy software, for which no SBOM was produced at build time (i.e. just about all legacy software today). It’s like a colonoscopy: It has to be done, but it certainly isn’t a lot of fun.

More importantly, if the supplier decides to alter one SBOM (perhaps by renaming a few vulnerable components with the names of non-vulnerable components), they are going to have to replicate this work in future SBOMs for the same product. A new SBOM needs to be generated with every change to the software, which means with every new version and every patch application. The devious supplier will have to make the same change in all of these new SBOMs.

But the biggest reason why Patrick’s scenario is highly unlikely is this: Why should the supplier go to a lot of trouble to obfuscate vulnerable components, when virtually any SBOM you look at has vulnerable components (i.e. components for which one or more open CVEs are listed in the NVD) – and it’s certain that new vulnerabilities will be identified in those components in the future?

The problem isn’t so much that there are vulnerable components. The real question is how the supplier deals with component vulnerabilities, whenever they appear.

A 2017 study by Veracode stated “A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered.” I would hope that number would be higher nowadays, but one thing is certain: It will definitely be higher, once most software suppliers are distributing SBOMs to their customers. Components in the software will have fewer vulnerabilities, plus suppliers will work to patch those vulnerabilities more quickly than they would have otherwise (if they would have patched them at all).

Is this because the suppliers have all just experienced a Road to Damascus moment, and decided to completely change their former ways? No, it’s because it’s human nature to pay closer attention to doing your work correctly when somebody is looking over your shoulder. That’s why the SBOM effort by NTIA (and now CISA) is called the Software Component Transparency Initiative. It’s all about transparency.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they shared by the CISA’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

 

No comments:

Post a Comment