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