Next week, I’ll tape a podcast sponsored
by an organization that provides product security services to software and intelligent
device suppliers. One of the questions they’ll be asking me is, “How should
product security teams prepare themselves for SBOMs and VEXes?” Those teams are
often referred to as product security incident response teams, or PSIRTs for
short.
This is an interesting question,
because I just wrote a post about the need for guidelines for SBOM and VEX use for end
users who aren’t software developers. I started the post by saying that plenty
had already been written about SBOM use for developers (suppliers), so I wasn’t
too worried about them.
However, with respect to use of SBOMs,
software or device supplier staff members fall into two groups. The first group
consists of the development people, who – as far as I know – understand SBOMs well
now and already have practical experience with them. These are who I had in
mind when I made the statement in the previous post. I think these people don’t
need a lot of help on using SBOMs, since so much has already been written about
that, and there are a lot of tools available for them.
But the second group consists of
the PSIRT – a team of security people (not developers) who don’t do development,
but instead work to make the product as secure as possible. Since the PSIRT’s
needs are quite different from those of the developers, they really can’t be
expected to have much knowledge of or experience with SBOMs (and certainly not with
VEXes).
My first idea for how PSIRTS
should prepare for SBOMs was “Pray”. However, while I’ve never denigrated the
importance of prayer, I do believe that isn’t all that can be said about the
subject. There are multiple things that PSIRTS can do to get ready for the new
SBOM world (and keep in mind that federal agencies will be required to request
SBOMs from their suppliers, starting in August). Most importantly, PSIRTs need
to do what all software users (which is just about every organization, public
or private, on the planet. I can’t speak for other planets at the current time)
need to do.
I hope to write other posts on the
topic of preparing to use SBOMs, but here is probably the most important thing
that all software users, including PSIRTs, should do:
Have a little humility. I’ve read and heard statements by various people about
SBOMs, that are simply way off the mark. They obviously have never bothered to study
up on the subject, but that doesn’t stop them from spouting off as if they
understand SBOMs very well. So here’s a tip:
If you think that SBOMs are so obvious that you, the great and powerful Oz, already
know everything you need to know about them, I can guarantee you’re wrong –
although there are enough other people like you that nobody may call you to
account for your statements.
However, I’ll also admit that learning
about SBOMs isn’t easy presently. The NTIA Software Component Transparency
Initiative – which ran from 2018 through the end of 2021 – published some
useful documents, all of which are available here. However, these documents are
sometimes contradictory (partly due to the fact that they were written by
different groups, sometimes in different years). More importantly, they don’t
tell a single coherent story, that will provide someone new to the SBOM topic an
in-depth introduction to it (on the NTIA site, there’s a good two-page document
titled “SBOM
at a Glance”, but it’s just that: a two-page introduction).
There will be a new initiative of
some sort under CISA, where Dr. Allan Friedman, who led the NTIA Initiative,
moved last summer. However, that hasn’t actually started yet (it hopefully will
start in about a month), and more importantly it’s not clear whether it will be
anything like the NTIA Initiative. The best thing about the latter was the fact
that lots of players from the private sector were able to freely discuss their real-life
experiences with SBOMs and shape the content of the documents that were produced.
However, because CISA (and probably
most of the federal government) has to operate by much more hands-off rules with
respect to the private sector than does the NTIA or the Department of Commerce
in general, it's possible that discussion will be much more constrained under
CISA. And in any case, because it will probably be 2023 before useful documents
are produced by the CISA initiative (which currently doesn’t have a name, at
least a publicly announced one), I certainly don’t advise waiting until those
documents are available, assuming they appear at all. This is especially
important because the deadline for federal agencies to start requiring SBOMs
from their software and device suppliers is this August.
However, this might be a good
thing, since a lot of people seem to believe that the federal government is “writing
the rules” – or even writing regulations – for SBOMs, and that the NTIA documents
were a kind of “first draft” of those rules. However, the fact is that the NTIA
doesn’t write regulations, laws, guidelines, guidance, edicts, Papal
encyclicals, fatwas, Talmudic teachings, or anything like that.
The NTIA facilitates meetings and online
discussions in which private industry players work out voluntary guidelines
that are necessary for a new technology to be realized in practice. A great
example of this is DNS. NTIA didn’t invent DNS, but it provided the forum where
telecom providers and the nascent ISP industry, as well as others, could discuss
how the DNS idea (which was developed in the academic world) could be made to
work in practice. NTIA was the first domain name registrar, and later
outsourced that function to the IANA (which now
administers DNS with a budget of $100 million. I once asked Dr. Friedman if his
budget for the SBOM Initiative was anywhere near that figure, and he surprised
me by answering no 😊).
I think we can all agree that DNS
works very well. After all, when was the last time that, in order to reach your
favorite web site (perhaps this blog?), you had to enter a 32-digit IPv6
address? It’s safe to say that the internet would still be about its size in
say 1992, without DNS. Yet, where are the laws or regulations that make DNS
work? There aren’t any. Virtually all internet users have implicitly agreed to follow
the guidelines developed at the outset under the NTIA’s guidance (but not, to
be sure, developed by the NTIA itself!). That’s all it takes.
The same thing will be true for SBOMS.
The guidelines that will make SBOMs work on a large scale will be developed by
private industry. The documents developed by the NTIA Initiative provided a
good start toward those guidelines, but that’s all they are: a good start. A
lot more needs to be done before they can be considered finished. My personal
opinion is that private industry needs to pick up the ball and run with it from
here on.
Fortunately, that is beginning to
happen. As I discussed in my previous post,
Fortress Information Security has produced an excellent document[i] that goes at least part of
the way toward providing the end-to-end narrative of utilizing SBOMs that is
required for SBOMs to become widely used (although I wish it were the only
thing that’s required!).
Other documents will surely follow,
from Fortress, from other private sector entities, and hopefully from CISA. I
also hope that one or more forums will arise in the private sector, where various
“players” in the “SBOM marketplace” will exchange ideas on how to remove the
various obstacles that are currently inhibiting widespread adoption of SBOMs –
just one of which is lack of comprehensive documentation for how SBOMs can be
used to reduce an organization’s level of supply chain cybersecurity risk.
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] I
have a consulting relationship with Fortress, and contributed some ideas to
that document, although I wasn’t one of the authors.
No comments:
Post a Comment