A big day for SBOMs!

A few hours ago, Dick Brooks of Reliable Energy Analytics sent around a link to an important announcement on Microsoft’s developer blog, to the main mailing list for the NTIA software component transparency initiative. Not being an avid follower of developer blogs, I must have missed this one, so I was pleased that Dick shared it.

The post is of course filled with developer-speak, and if you’re not much more familiar with that arcane dialect than I am, you won’t understand a lot of it. Here are the important points that I see:

The first paragraph says “…Microsoft has chosen to use Software Package Data Exchange (SPDX) for all SBOMs we generate, and we have embarked on the mission to do this for all software we produce.” In other words, all software that Microsoft produces will come with a software bill of materials, and it will be in the SPDX format. SPDX is a project of the Linux Foundation and is one of the two leading SBOM formats (the other is CycloneDX, an OWASP project). As the first paragraph also notes, SPDX was recently designated an ISO standard.

The author lists three reasons why SBOMs are useful:

• Software transparency: SBOMs provide a list of ingredients used in the creation of a piece of software, such as open source software, components, and potentially even build tools. This enables producers and consumers to better inventory and evaluate license and vulnerability risk.
• Software integrity: While code signing is still the industry standard for trusting software and its integrity, SBOMs contain package and file checksums to enable consumers to validate the hashes, which can be useful in scenarios when signatures aren’t present.
• Software identity: When vulnerabilities (CVEs) are created, they are assigned to a Common Platform Enumeration (CPE) identifier, which can have issues attributing a CPE to a specific piece of software. Software IDs within SBOMs provide a much more accurate way to identify software.

The first of these, software transparency, is without much doubt the reason most often cited when it comes to a discussion of whether SBOMs are needed. The other two are important, although frankly I’m not quite sure what the author has in mind in citing these two. I expect to learn more about that in the coming days.

Clearly, Executive Order 14028, which mandated that government agencies require SBOMs from their software suppliers (this provision will be in effect next August, according to OMB), was the biggest driver for Microsoft’s decision – or at least I interpret the fact that the first words of the post refer to the EO to be evidence of that motivation. Of course, now that Microsoft has broken the ice, I expect a lot more software suppliers to make similar announcements soon.

But there’s another motivation for Microsoft’s announcement. This can be seen in the last two sections of the paper, and especially in the diagram at the bottom – which is pretty much a diagram of the SolarWinds hack. I’m not referring to the Sunburst malware that was used to attack around 250 SolarWinds users (unfortunately, including some very high-profile government agencies). I’m referring to the Sunspot malware, which the Russians used to plant Sunburst in seven SolarWinds updates.

Along with Stuxnet (and perhaps ahead of it), Sunspot was one of the most amazing pieces of malware ever created (Microsoft estimated that the Russians had 1,000 people working on it). The red text in the diagram at the bottom of the post is almost exactly what Sunspot did to plant Sunburst in the SolarWinds build process (the Russians had to carry out the process completely through Sunspot, working remotely). This was so ingeniously covered up that an SBOM produced when they normally are – at the end of the build process – would never have shown anything to be amiss.

Thus, Microsoft is going far beyond simply producing their SBOMs at the end of the build process. Instead, they’re producing and validating them at various stages in the process, so that an attack like the Russians mounted on SolarWinds won’t succeed – it will be discovered, and the build process will be halted. While this isn’t to say that nobody will ever come up with a way to fool Microsoft’s SBOM process, it is to say that Microsoft is setting a great example for the rest of the software industry.

At the moment, I don’t expect many, if any, software developers to duplicate Microsoft’s SBOM process. However, I do expect that the combination of Joe Biden and Microsoft will provide the impetus for the software industry to finally start releasing SBOMs to their users. Just having a single SBOM – produced at the end of the build process – gets the user light years ahead of where they were without any SBOM at all, in terms of being able to identify and mitigate software vulnerabilities. And having SBOMs for a good percentage of the software products that your organization is running…well, that will put you megaparsecs ahead!

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 National Technology and Information Administration’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.