Tuesday, July 12, 2022

One month ‘til EO compliance is due. Do you know where your SBOMs are?


Executive Order 14028, Improving the Nation’s Cybersecurity, was issued on May 12, 2021. It includes a provision regarding SBOMs, as is fairly well known. The EO itself didn’t include any due dates, but it delegated the task of administering compliance for the whole government to the Office of Management and Budget (OMB).

OMB produced a memorandum last August 10, which discusses the different phases of compliance and an overall timeline. It includes this sentence (on page 3):

Within one year of the publication of this memorandum, agencies must implement the security measures designated by NIST for all categories of critical software included in the initial phase.

I did some advanced math and calculated that the due date is less than one month from now (I originally had the 12th in mind, which is why I wrote the post today. Oh, well. The content’s what matters).

So given that there are 28 or 29 days until compliance, what do federal agencies have to do regarding SBOMs? There’s a big list of requirements. Are you ready for it? Here goes…

1.      They have to ask their software suppliers for an SBOM.

That’s it. Of course, if the supplier doesn’t provide them at least one SBOM, the agency isn’t on the hook for non-compliance, since they tried. And the supplier isn’t on the hook, either, since the EO only applies to federal agencies.

However, I don’t doubt that most suppliers will be able to provide the agency with at least one SBOM for every product the agency obtains from them. How do I know this? Because software suppliers are using SBOMs very heavily now, as described in this post. It turns out that the suppliers find SBOMs very helpful for managing software component security. Who would have thought? My guess is most suppliers won’t have a problem sharing their SBOMs (and the fact that it’s mandatory under the EO will also mean something to them, even though neither they nor the agency will end up in the slammer if they don’t comply at all).

However, you might ask, “What are those agencies supposed to do with the SBOMs, once they have them?” Ah, there’s the rub. The EO says nothing about that subject, but it did delegate the task of providing all of the guidelines regarding EO subjects to NIST. NIST put out a document (actually, a first draft of the first revision of NIST SP 800-161, the supply chain cybersecurity framework) in December that, among other topics, addressed SBOMs.

Here is my generally-positive-but-not-completely-so review of the document. The big problem with the document, IMHO, is that the SBOM portion of the document (pages 242-246) was written for federal agencies, yet all but two sentences apply to suppliers, not the agencies. Granted, the agencies need to know what to ask the suppliers to do regarding producing and delivering SBOMs, so that part is generally useful.

The problem is that the two sentences (on page 244) are NIST’s only answer to the question I asked above: What should the agencies do with the SBOMs when they receive them? And here are the two sentences:

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.

To be honest, if I were to develop a two-sentence summary of what an agency – or any end user organization – should do with SBOMs, I couldn’t come up with something much better than that. On the other hand, those two sentences are far too general to provide any real guidance to an end user organization. In fact, the only real end-user guidance I know of is this document produced by Fortress Information Security (for whom I do consulting, although I wasn’t one of the authors of the document). Literally everything other SBOM document that I know of is aimed at software suppliers.

But the lack of official guidance is only one problem facing the federal agencies when they start receiving SBOMs in August. The other problem is that there’s only one complete software tool for end users, that will ingest both SBOMs and VEX documents and output a list of exploitable component vulnerabilities in the software. That is Dependency-Track, which – believe it or not – was developed ten years ago by Steve Springett (co-leader of the CycloneDX SBOM format project). I wrote about Dependency-Track about two weeks ago, when it became the first complete tool after it started ingesting VEX documents, along with SBOMs (which it has ingested since 2012, before the term “SBOM” was being used.

Dependency-Track is very good and is very heavily used by software suppliers (as the first post I linked above shows), but it’s open source, which is a problem for some organizations. So there really need to be other products and especially services that will utilize both SBOMs and VEXes to manage software component vulnerabilities.[i] At the moment they’re not here, and they won’t be here in August, either.

However, there’s a lot happening in the SBOM world now (one good thing is CISA’s SBOM Listening Sessions, where groups gather to discuss different issues with SBOMs. They’re open to anybody, and don’t require a reservation. Today they kicked off with two sessions, and they were both very well attended. To find out the topics and times, go here and look for the listening sessions), so it doesn’t bother me (or the federal agencies, I assume) that the SBOMs are unusable at the moment.

That will change this fall, and I’m sure that, by the beginning of next year, there will be a lot of options for SBOM/VEX consumption tools, as well as guidance on using both SBOMs and VEXes for vulnerability management. In the meantime, we can all learn a lot more about SBOMs and VEXes, so that we’re ready for them when they become much more widely available than they are now.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. 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.


[i] There will be a subscription-based service available soon that will do what Dependency-Track does, as well as other risk analysis based on SBOM data. However, I don’t have details on that service yet. I anticipate that a lot of organizations will be glad to turn the whole job of software risk management based on SBOMs over to a third party, rather than have to do it themselves.

No comments:

Post a Comment