What if SBOMs are included in the new EO?

As I mentioned in Friday’s post, Reuters carried an article on Thursday that said there would soon be a new Executive Order regarding software security, and that it would include a requirement for software bills of materials. Of course, given how much I’ve advocated for SBOMs since last summer, it would be hypocritical of me to say that I don’t welcome the idea that there might be a mandate driving their production and use. Since I’m sure SBOMs will come sooner or later – they have to – I don’t mind the government putting their weight behind them, to speed up that process.

But here’s the problem: It would be an unmitigated disaster, were the feds (and I’m not sure who would enforce this order. DHS, and CISA specifically?) to simply mandate that certain software suppliers to the federal government start delivering SBOMs for all of their software products within say the next six months to one year. This is because there are still far too many unanswered questions about SBOMs, for this to be even remotely possible.

Here are two questions that have been answered (there are many others that have been answered as well):

Q: SBOMs need to be machine-readable, given the huge volume of components that software end users might want to track for vulnerabilities. For example, the average software product contains over 100 components (and some contain thousands). If an organization uses 200 different products and they get SBOMs for all of them, that means they should track 20,000 components. Can SBOMs be made machine readable?

A: This problem is solved. There are currently three generally accepted formats, all of which are machine-readable: SPDX, CycloneDX and SWID; it is likely that more will appear in the future.

Q: Speaking of SBOM formats, which is the best one?

A: Each of the three formats provides what the National Technology and Information Administration (NTIA) has defined as the minimal fields required in an SBOM. Beyond that, each format provides capabilities that are important to some suppliers and users but not others. The NTIA Software Transparency Initiative members have decided that there is no need to choose one format over the others – given that tools are already available to translate among formats.

But here are some questions that haven’t been answered yet and are unlikely to be definitively resolved in the next year. I wrote about two of the biggest last fall: the “naming problem” and the “problem” caused by the fact that the majority of vulnerabilities in components aren’t in fact exploitable in the end products that include those components, which I discussed in this post.

There are also some questions that can only be answered through experience – that is, through actual production and use of SBOMs. This is what the industry Proofs of Concept are doing. The healthcare industry has been conducting PoCs for SBOMs since 2018, and PoCs for electric power and autos will start in the near future. There will be other PoCs as well, as momentum picks up.

Answers to all of these questions are emerging from the PoCs, but trying to rush answers now would inevitably require finger-in-the-air-type guesses, rather than answers based on experience, which is what the PoCs are providing. These questions include:

1.      How often should SBOMs be re-issued?

2.      How can SBOMs be provided to end users in a way that doesn’t overwhelm them with seemingly random documents?

3.      What kinds of “intermediary” services would be required, to make SBOMs issued in one of the three current formats usable for vulnerability management purposes in the near future? This may be one way of “jump starting” successful use of SBOMs, vs. having to wait for the current vendors of vulnerability management products to modify their products to ingest SBOMs directly.

4.      What about other potential uses of SBOMs, like for license management? The fields for this are already in the SBOM formats, but in most cases they’re not being used now. There are certainly other uses for SBOMs as well. Facilitating these use cases doesn’t require technical changes, but it does require agreement on procedures.

5.      How can access to the data in an SBOM be protected, so that only the organizations (usually customers) that the supplier wants to have access in fact do so?

There are many more of these questions, of course. My point is that it would be a big mistake for the feds to mandate that SBOMs be produced and used until these questions are much closer to being answered than they are now.

Fortunately, one federal agency has already faced these issues and pointed out the best way to address them, while at the same time making a firm statement that SBOMs will be mandatory. The FDA in 2018 was concerned about securing the software in medical devices used in hospitals (e.g. infusion pumps) and stated that they would require SBOMs for those devices in the future. However, they didn’t set a date for this, or provide any specifics about what they would mandate.

The FDA did this because they knew full well that trying to issue specific regulations for SBOMs at that time would have led to nothing but confusion and bad feelings. Instead, they supported the NTIA Software Transparency Initiative as the best road to resolving all of these questions. They have still not set a date for regulation and they continue to support the initiative, including the healthcare Proof of Concept.

This approach turned out to be very successful. The healthcare industry – both the hospitals and the medical device makers – realized they had to cooperate to make SBOMs a reality, rather than just a vague aspiration. That is what the NTIA Software Transparency Initiative is doing, and especially the healthcare PoC. Other industries, including energy, can help advance this effort by starting their own PoCs.

If SBOMs are included in the EO, I think the best approach is to follow the FDA model: State that SBOMs will be required in the future (or perhaps even set a date to begin rulemaking, say 2-3 years from now).  This puts all the pressure needed on industry to resolve these and other questions, so that in a few years it will make a lot of sense to talk about some regulation of SBOMs (if it’s still needed. Perhaps SBOMs will be in such wide use already, that there will be no need to mandate anything more than that).

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.