In this article, we pick the brains of Chris Blask, Global Director of Control System Security at Unisys and working chair for upcoming DBOM.io (going live in Mid 2021) and Allan Friedman, Director of Cybersecurity Initiatives at US Department of Commerce, National Telecommunications Information Administration (NTIA), who leads a government SBOM initiative through the NTIA.
Criminal gangs and state-sponsored shadow groups are increasingly targeting development servers and popular code repositories in their exploits to burrow deep into the digital supply chain. One of the ways out of this spiral is to create a common and reusable software bill of materials (SBOM) framework that travels with the developed applications and code components used in them to attest to the status of the code and its components. This allows buyers to make educated choices and manage their risks from third-party code in their enterprises.
In this article, we pick the brains of Chris Blask, Global Director of Control System Security at Unisys and working chair for upcoming DBOM.io (going live in Mid 2021) and Allan Friedman, Director of Cybersecurity Initiatives at US Department of Commerce, National Telecommunications Information Administration (NTIA), who leads a government SBOM initiative through the NTIA.
What is a Digital Bill of Materials (DBOM)?
Blask: “Think of a DBOM as a way to respond to requests from a big banking customer on an attestation infrastructure because clients want software, hardware and firmware bill of materials for the large enterprise servers we provide. The DBOM architecture based on the open source DBOM Node code is a standardized manner for supply chain partners to store the attestations they make to each other. The DBOM architecture gives partners in supply chain relationships standard places to attest clearly to each other, saying, ‘Here’s the software we gave you, the contract relationship between us, our open source components, what’s in them, who touched them, and their vulnerabilities.’”
What is an SBOM and how is it different from a DBOM?
Friedman: “A SBOM is essentially a list of ingredients for software. We build software out of other components that we should track for many reasons. Security is an obvious benefit, but SBOMs add great value in the areas of efficiency and accuracy through the entire application lifecycle, including planning for end of life. SBOMs are useful for the customers of software products, and also useful for those who build software.”
Pro Tip: For more on what an SBOM contains and how it’s used, see the NTIA’s two-page explainer here.
Friedman continues, “For example, if an organization wants an allow or deny list on specific application components, we need to track what the individual components are. If we find out tomorrow one of our popular packages has been backdoored in a supply chain attack, developers need to look into the products they’ve developed to see if their apps are affected. If we do this in a machine-readable format, it can be built into our tools to handle it automatically.”
Blask: “Automating the process would save enterprise software developers and their suppliers time and money while ultimately improving the quality of the software supply chain. SBOMs are more valuable collected, managed, and stored in a system of repositories that can be easily queried by other applications and systems.”
Pro Tip: A good example of SBOM built into a toolset is GrammaTech‘s CodeSentry (binary composition analysis platform) that automatically builds a detailed SBOM with known vulnerabilities in scanned components and dependencies, then tracks these vulnerabilities throughout the software lifecycle, making audit requests easier and more reliable.
How does the SBOM fit into the larger DBOM framework?
Friedman: “The goal of DBOM is to convey attestations about the hardware, firmware and software in a digital supply chain. One key type of attestation will be about the contents and building blocks of software. A DBOM will convey data, including software data. SBOMs need to move down the supply chain. One way of doing that (among others) is with a DBOM.”
Blask: “So, for example, Github is hosting the DBOM Project open source code, which can be used by anyone to stand up a DBOM Node and with that create or participate in DBOM Channels. Attestations such as SBOMs can be stored on DBOM Channels with the DBOM Nodes of each partner controlling access. Because DBOM frameworks are modular, anybody can set up any attestation channels they want for each of the partners in the supply chain that they care about. In software supply chain, you can talk about bugs and functional vulnerabilities in the application as it runs.”
Seems like DBOMs and SBOMs spread by gaining momentum with downstream suppliers along the supply chain. Is that accurate?
Blask: “Exactly! ‘Hey, manufacturer, why don’t you join my channel?’ Now everyone finds out things are better, faster, cheaper, easier to use and secure with the DBOM attestations tied to the digital components. The Department of Energy’s CyTRICS program is a good example. The concept is if I want to be a good vendor and make sure the digital products that I’m selling into the grid are worthy, I join the cyTRICS program. From first tier suppliers like Rockwell and Siemens to the suppliers behind them and down into the grid, if CyTRICS uses SBOMs on DBOM channels then DOE’s 3,300 US utilities and thousands of providers likely will as well.”
Once developers and buyers know what’s wrong with the code they’re developing or acquiring, what do they do with that knowledge?
Friedman: “Knowing that bad things are in code won’t solve all our problems but does create the foundation for future action. This fits into the good software development practices we know we should be doing, and in the tools coming on the market. SBOMs allow rapid response and better build tests and enables the great shift to the left when thinking about security and long-term risk in code dependencies even before developing the applications.”
