I learned long ago about a
debilitating occupational disease that afflicts people involved in the
cybersecurity field. Here is how the disease evolves:
1.
Cybersecurity people know that their future
depends in great measure on having a large and growing market for whatever they
have to offer: consulting services, software tools, writing books, organizing trade
shows, etc.
2.
They’re also humble enough to realize that
whatever their selling points may be, there are lots of other people and
organizations with similar selling points. There are very few of us (certainly
including me!) that can count on future success based solely on our innate
brilliance and charisma.
3.
Given the above, what’s plan B? Even though you might
be smart, responsive, insightful and everything else a customer could possibly
want, there’s something else required for you to be successful in the long run.
4.
Can you guess what it is? You’re right! If the
market is growing (and the more rapidly, the better), it doesn’t matter that
you have a lot of equally smart, responsive, insightful competitors. The need
for whatever you have to sell is growing fast enough that there will always be
a shortage of smart, responsive and insightful people and organizations. You
may not be the cream of the crop in your particular niche, but you don’t need
to be that, either. Even though there are some first-tier players who will be
the first ones hired, there will always be enough remaining business so that you
and the other second-tier players (nobody ever says they’re third tier, of
course) can still do very well, thank you.
What can make the market for
cybersecurity services and tools grow? I can think of three scenarios:
1.
From previously not being too concerned about
cybersecurity, a large segment of mangers and directors of private and public
organizations suddenly wake up one morning and decide they need to get their
security act together and fast. In other words, all the lessons they’ve been
hearing about the need for cybersecurity suddenly start making sense to them,
without being driven by any external events; they suddenly call back the
security people who have been cold calling them for years and ask when they can
start to work for them (or ship them their latest and greatest tool). I assign
a probability of somewhere between .00001 and -1.0 to this scenario.
2.
There’s a huge and devastating cyberattack, or
even better, a series of devastating cyberattacks on different types of
organizations. Fortunes are lost, secrets are exposed, lives are ruined, etc. This
has a somewhat higher probability than the first scenario, although this is
still unlikely.
3.
Tough regulations are imposed, which effectively
require every organization to finally open their checkbooks and buy as many
cybersecurity services and tools as possible. What’s the penalty? Death would
be best, but maybe just big fines, a few years in the slammer….Be creative.
What’s the probability of the
third scenario being realized? That’s the question…
I bring this up because a lot of
people in the software bill of materials (SBOM) “industry” seem to be trying hard
to convince everybody (including me, and perhaps themselves) that regulations are
coming Real Soon Now. Those regulations will make it mandatory for software
suppliers to provide SBOMs to their customers – and on a regular basis, not
just as a one-off.
I used to be one of these people. When
it became known in early 2021 that the White House was working on an executive
order (EO) regarding cybersecurity, I learned
it was likely that SBOMs would be addressed in the new EO. When that order came
out, I convinced myself that, even though the only “requirement” for SBOMs was
that federal agencies start asking for them from their suppliers, there would
be a real requirement when the Office of Management and Budget (OMB) put out
their guidance in about a year’s time (as required by the EO).
However, when OMB put out their guidance
in September 2022, it left it up to each federal agency to decide whether and
how to ask for SBOMs from suppliers. At that point (or really, before then), I
decided it was unlikely that SBOMs would become a requirement under the EO.
Nevertheless, there were still the
changes to the Federal Acquisition Regulation (FAR) that were required (using
very general language) in EO 14028. When these changes were implemented, would
those changes effectively make it mandatory for suppliers of software to federal
agencies to provide regular SBOMs to those agencies? A lot of people clung to
that hope, especially when it was announced
in October that the FAR changes being proposed “would, among other things,
require contractors to develop a Software Bill of Materials — or SBOM — for all
software used when performing contracting tasks.”
Unfortunately, last week those
hopes were set back, as described in this article:
SBOMs, or itemized lists of components that make up software
products, have been widely viewed as a helpful tool in advancing software
security by enabling organizations to identify potential exposures in their
technology. But some argue that requiring SBOMs is cumbersome because various regulations have defined
their scope differently. Lawmakers notably excluded a federal contractor SBOM measure from a
must-pass defense policy bill in 2022.
Most contractors “do not create their own software and
instead use commercial off-the-shelf products for which SBOMs might not be
readily available and may need to be generated specifically for the contractor
and government transactions,” said a comment filed by Anderw Howell of the
Operational Technology Cybersecurity Coalition, a group representing industrial
control systems vendors.
The OTCC comments add that a separate SBOM memorandum from the Office of Management and
Budget does not match that of the proposed rule, arguing that such a dynamic
would give contractors a headache. The OMB memo lists SBOMs as an optional
entity that can be provided upon request, while the contractor directive
requires SBOMs be listed for all software used in a contracting job, regardless
of a cybersecurity incident.
SBOM community members have also
placed their hopes in two new sets of regulations, which at one point seemed likely
to require SBOMs:
1.
The FDA’s Premarket
Guidance for medical devices, which came out in October. Many people hoped
this would require that medical device makers (MDMs) provide SBOMs to their
customers (mostly hospitals) regularly. However, the FDA merely required that the
MDM provide a single SBOM to the FDA with their required “premarket submission”,
which is required for them to be allowed to market their device in the US. Moreover,
this SBOM won’t be shared with any entity outside of the FDA.
2.
The EU Cyber Resilience Act, which has not received
final approval from the EU Parliament but now seems to be at least in its
close-to-final draft,
was also considered likely to require that SBOMs be distributed to software and
device customers on a regular basis. However, the draft (now approved by the EU
Council) only includes the following statement regarding SBOMs (in Annex I,
page 166): “Manufacturers of the products with digital elements shall…identify
and document vulnerabilities and components contained in the product, including
by drawing up a software bill of materials in a commonly used and
machine-readable format covering at the very least the top-level dependencies
of the product.” In other words, the CRA just requires the software or device
manufacturer to “draw up” an SBOM and keep it, but says nothing about providing
it to customers or anyone else.
In these three cases, we’ve been
shown once again that there is no appetite among regulators to establish
mandatory requirements for SBOMs. The reason for this is quite clear: There is
currently no agreement among regulators, manufacturers, or end users regarding
what should be included in an SBOM and how it should be implemented.
Here’s an idea: Let’s put a
five-year moratorium (at least) on the idea that somehow SBOMs can be regulated
into widespread use. I can think of no case in which a technology (other than a
safety or health technology like seat belts or lists of ingredients in food)
has been brought into use by regulations. Why should SBOMs be any different?
What can be done is to a) identify
what barriers are currently preventing SBOMs from being put into widespread use,
and b) identify how those barriers can be removed. The OWASP SBOM Forum is
currently doing exactly this, especially regarding the naming
problem and VEX.
If you’d like to hear more about this, drop me an email.
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 lead the OWASP SBOM Forum. If
you would like to join or contribute to our group, please go here, or email me with any questions.
No comments:
Post a Comment