A Vision for Software Bill of Materials in the DoD

Former DoD Chief Software Officer lays out a strategic vision for using Software Bill of Materials (SBOM) to achieve "visual clarity" of vulnerabilities in software that powers everything from administrative networks to weapons systems.

This article by Ryan Heidorn originally appeared in National Defense Magazine.

“Everything we do today as a society in some way, shape, or form is touched by software.”

That was the message from Jason Weiss, who, during his last public appearance as the DoD’s Chief Software Officer, laid out a strategic vision for using Software Bill of Materials (SBOM) to achieve “visual clarity” of vulnerabilities in software that powers everything from administrative networks to weapons systems.

With the rise in supply chain attacks targeting software vulnerabilities, there is heightened focus on gaining visibility into the software we use, in order to better protect against exploitation of software’s individual components. President Joe Biden’s 2021 executive order “Improving the Nation’s Cybersecurity” requires agencies to adopt SBOMs, likening them to “a list of ingredients on food packaging.” In that manner, the SBOM is expected to articulate “the details and supply chain relationships of various components used in building software.”

The need to visualize software “ingredients” was painfully highlighted in December 2021, when a critical vulnerability discovered in Log4j—open-source code widely used in applications that impact virtually every organization—sent IT teams across the world scrambling to understand if and where they were affected.

At an April 7 cybersecurity conference hosted by NDIA New England, Weiss highlighted a “lack of visual clarity in this ecosystem,” going on to explain that “despite existing DoD processes for ATO, governance, audits, and cybersecurity dashboards, the Department consistently lacks the necessary visual clarity to fully appreciate the threat surface across the totality of its software supply chain.”

Obtaining a complete and granular picture of where software is deployed would allow the DoD to forecast risk in software supply chains and enable stronger risk-based decision making. Achieving that visual clarity also enables the DoD to take advantage of existing threat intelligence as applied across that more comprehensive picture. For example, Weiss envisioned the DoD, before selecting an open-source software library for use within a critical program, could ask the FBI, “what do you know about this committer?” [A committer is a contributor to an open-source software project.]

Based on intelligence, the DoD could assess the threat against the full scope of systems that the identified software library would feed into. This level of clarity would therefore serve two purposes: 1) Forecasting software supply chain risks, and, 2) Providing a reference for threat remediation when vulnerabilities are identified.

Producing SBOMs that can be easily automated and integrated, of course, is only a first step. As Weiss noted, “The real value of SBOM is found in consumption… We need to be able to consume that information,” not just generate the information, to validate that everything in the SBOM is true and that the software supply chain was accurately represented.

Weiss emphasized that clarity needs to extend to wherever software is used, including to IT infrastructure that is delivered as a service. BOMs can amplify visibility not only for the software capabilities coming out of the DoD’s software factories (in the Air Force, these are organizations such as Kessel Run and Platform One), but also for other technologies, like cloud, that increasingly can be understood as “software defined.”

To react quickly to threat intelligence, Weiss said that the DoD should standardize on a format and create a unified repository for SBOMs.

The repository could be established at various levels within the DoD, such as at the PMO, PEO, or military service levels, but Weiss advocates for developing this capability at the enterprise level (across the whole DoD), saying it would provide the most benefit, both proactively—to guard against threats by having enough visibility to action on threat intelligence—and reactively when threats arise by understanding the entire scope of where vulnerable software is used.

To enable the “visual clarity” within Weiss’s vision, creating consumable SBOMs needs to become ingrained at the time the software is created. The DoD needs to pick a standard–Weiss prefers CycloneDX—and enforce this wherever software is developed. SBOMs (and other forms of BOMs) can deliver exceptional visibility into the software that powers everything around us, but only if they are easily consumed and centrally managed.

Weiss has provided a clear vision to help solve a critical problem. Since everything we do is touched by software, and software vulnerabilities are inevitable, the threat cannot be ignored. Building visual clarity across the broad threat surface of its software supply chain would empower the DoD to forecast risk and respond quickly and decisively to threats. What remains to be seen, however, as Weiss returns to private industry, is whether others in the DoD take up the banner and push this initiative forward.