Friday, February 9, 2024

SBOM regulations are batting .000


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