Is it time for SBOMs to leave the nest?

On February 4, NIST released their promised guidance on the items in Section 4(e) of Executive Order 14028. The heading of this section says, “Such guidance shall include standards, procedures, or criteria regarding…” Regarding what? There are a number of items relating to software security, but since my primary concern is software bills of materials, there’s only one that is directly applicable to that:

“(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website”.

Remember, the EO applies to federal agencies (and it is likely to be followed by a lot of private organizations as well, of course). It doesn’t apply to software developers, because the White House doesn’t have any inherent authority to regulate any organization other than federal agencies, without first getting Congress to give them the authority to regulate them (which of course they didn’t ask for, since this is an Executive Order).

However, you can see that item (vii) – like every other item in Section 4(e) – really applies to the software supplier. It says they need to give the federal agencies an SBOM for each product that they purchase. OK, that’s fine, but since the EO applies to the agencies, what are the agencies supposed to do when they get the SBOM? Are they only obliged to say “Thank you very much” when their supplier gives it to them?

Of course not. There are two important questions that need to be answered, regarding what a federal agency should do regarding SBOMs, while complying with the EO.

The first question is, “What is the agency supposed to ask the supplier to provide?” The new guidance document doesn’t offer anything new, but that question has already been addressed fairly completely in two other documents.  The first is the NTIA’s “Minimum Elements for a Software Bill of Materials”, a document specifically ordered by the EO. While there’s more that I think could have been included in this document, I think it did a good job of listing the most important elements that should be included in an SBOM, as well as minimum requirements for how often the SBOM should be produced, etc.

The second document is the draft set of guidelines that NIST put out in November, and which I wrote about in this post in December. As you can see in my post, I thought the document was overall good, although there were a couple parts that were real head-scratchers. My feeling is that, between these two documents, a federal agency should have a fairly good idea of what they should be expecting from their software suppliers – as long as they’re not looking for specific contract language, since that’s not in either of these documents (nor would I expect it to be).

Now to the second question that an agency needs to have answered: “What can we do with the SBOMs once we start receiving them? Should we frame them and put them on our wall? Should we print them on waxy paper and use that to wrap fish? More specifically, how can we use them to identify risks in software? After all, the EO called for SBOMS because they’re a tool that can be used to reduce software risks. But where’s the guidance on how we can do that?”

Aha, there’s the rub. In those two documents I just mentioned, there are more than 30 pages of text, yet they’re almost 100% dedicated to discussing what suppliers should do in providing SBOMs. Where’s the discussion of what the users (in this case, federal agencies) should do with the SBOMs? As far as I can see, there is no guidance for users in the Minimum Elements document, and there are literally just two sentences in the NIST guidance: “Develop risk monitoring and scoring components to dynamically monitor the impact of SBOMs’ vulnerability disclosures to the acquiring organization. Align with asset inventories for further risk exposure and criticality calculations.”

Now, NIST has never been the place to go for inspiring, uplifting prose, but I must say that I think the federal agencies will need a little more help than this, if they’re actually going to be able to make good use of SBOMs. In fact, since private industry will take its cue from what the Feds do regarding the EO, all of us will need more than these two sentences.

In fact, NIST isn’t alone in neglecting to provide guidance for software users; among all the documents published by the NTIA Software Component Transparency Initiative during its close to four years in existence, only one specifically purports to address the consumer, and even that document mostly discusses what suppliers should do in providing SBOMs to their customers – not how consumers can use the SBOMs to reduce software supply chain cybersecurity risk to their organizations.

Fortunately, I’m pleased to report that a private organization is readying a comprehensive guide to using SBOMs (and VEXes) for software risk management purposes (although the document isn’t in any way “definitive”. A definitive document about SBOMs is still far in the future); this will soon be made available without charge to any private or public sector organization that wants to see it. Noting that, for whatever reason, providing guidance on SBOM consumption is simply not the government’s cup of tea, this organization has stepped up to fill this particular void.

This is usually the point where I start to complain about what [insert name of government agency] is doing or – usually – not doing about [insert Tom’s Beef of the Day]. But this time, I’m going to surprise you. I now think that, as far as guidance on SBOMs goes, government has done about as much as it can be reasonably expected to do. Now the rest of us need to step up, as this privately-developed guidance will demonstrate.

We were very lucky that the NTIA (and in particular Allan Friedman) decided to take the little SBOM fledgling under its wing and nurture it…not to maturity but to the point where private industry, which of course will be the main beneficiary of having a robust SBOM ecosystem, can take over and make that ecosystem a reality.

And we’re also very lucky that the White House was persuaded to include SBOMs in EO 14028, even though SBOMs still have a long way to go before they can be widely used in the federal government. Just by “mandating” SBOMs, the WH made it clear that it’s time to have software component transparency. Now the private sector needs to make that happen. Moreover, it can make it happen now; two or three years ago, that would not have been possible.

How will the private sector do this? I’m beginning to have some ideas, but I’d like to hear what yours are as well.

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 necessarily shared by 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.