Software bill of materials (SBOMs), an ingredient list for software, are going to finally provide missing foundational information on software consumption so federal agencies can improve their software supply chain security … someday. To be sure, the Commerce Department has nurtured an SBOM-interested community for years and those efforts have benefited many industries, especially medical device companies. A recent executive order singled out the utility of SBOMs. And the Department of Homeland Security is now similarly aiding the SBOM community and providing money to improve SBOM open source software and products. But when will all this SBOM activity actually benefit federal agencies, those entities hit by massive software supply chain compromises like SolarWinds and beset by open source vulnerabilities like log4shell?

There are three schools of thought. Optimists believe better SBOMs and better SBOM tools will unlock the security benefits soon. Pessimists believe that the root cause of software supply chain insecurity is legal or bureaucratic and that SBOMs will be only marginally useful absent other changes. There’s also a cautious optimist position that views SBOMs as useful on the assumption that SBOMs are created when software is built (not before) and only SBOMs for important software (not all software) is stored and analyzed.

Though we’re with the optimists, we acknowledge that which camp you fall in determines your views on when SBOMs will finally be useful.

SBOM optimists: SBOMs will be useful tomorrow

Members of this camp concede that SBOMs have not been useful directly to federal agency software security yet. One day however, in their view, having a full list of software components will allow federal CIOs and security teams to quickly identify and remediate vulnerabilities identified in important software. These advocates are not discouraged by the Cyber Safety Review Board report on log4j, which found that even organizations with SBOMs didn’t actually use them to remediate log4j.

There simply need to be improvements. First, SBOMs themselves must be improved. This explains efforts like SBOM plugfests, which seek to “align” SBOM formats and improve “interoperability.” SBOMs will be useful, so this camp implicitly argues, once these technical objectives are met. Second, SBOM optimists believe that more SBOM-related tooling, especially for storage and analysis, will change the equation. In other words, there are now plenty of SBOM generation tools; the pressing need is for tools that ensure these SBOMs result in improved software security decision-making. There need to be tools, both open source and proprietary, that generate, store and analyze SBOMs. This thinking animates a new DHS effort to fund start-ups to collaborate on SBOM open source libraries and build SBOM-related features into their products.

In short, SBOMs will help federal agencies soon, just not yet.

SBOM pessimists: There are deeper problems

There’s a quieter and gloomier camp when it comes to SBOMs. These thinkers wish that it were so that SBOMs are the missing element in federal software security. Unfortunately, these pessimists believe that there are deeper, more structural obstacles to federal software security.

One view is that software supply chain insecurity is the federal status quo because software providers are not legally liable for providing software free of defects, unintentional or malicious. Therefore technical fixes like SBOM do not address the root legal cause and cannot be expected to help without legal changes first. Another view is that the federal information security apparatus, while filled with dedicated and intelligent individuals, have ossified and turned into a box-checking exercise. This is a cynical view, but one that is surprisingly widespread.

Therefore SBOMs are a sideshow, according to the pessimists, and unlikely to help anytime soon.

SBOM cautious optimists: Philosophical and procedural changes are needed

There’s another camp, closer to the optimists, that views SBOMs as useful in the medium-term, if certain philosophical and procedural changes occur.

First, these cautious optimists believe SBOMs should be created at the time software is built, not after-the-fact. After-the-fact SBOMs are likely to be inaccurate, since recovering software identity information from a software artifact is technically challenging. Creating an SBOM at build-time is more likely to be accurate since all the pieces of software must be present at that moment. This increased accuracy, so these advocates believe, will make SBOMs more useful. Some tools are beginning to embrace this philosophy.

Second, only SBOMs from crucial software should be collected. What is crucial? It will depend upon the organization, but for many organizations a first-cut definition is all software running in production. Collecting SBOMs for only this software reduces the scope of the SBOM challenge, decreasing the number of SBOMs to be collected, stored and analyzed, simplifying the whole process.

This camp therefore sees positive SBOM progress as likely, though the changes are less technical and more philosophical and so can’t be implemented at the click of a button.

SBOMs are the future, but is the future now?

There’s wide consensus that SBOMs are a constructive building block for software supply chain security, perhaps especially for federal software supply chain security. But less appreciated is that there are different schools of thought on when the promises of SBOMs for federal government software supply chain security will be realized.

To be clear, we’re with the optimists. That said, a mingling of perspectives makes it more likely that SBOMs improving federal software supply chain security won’t forever be a “someday” phenomenon.

John Speed Meyers is a security scientist at Chainguard, a software supply chain security company. Adolfo García Veytia is a software engineer at Chainguard, specializing in SBOM tooling.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.