When you experience enough high-profile security breaches, like have happened recently (e.g., Log4j), eventually somebody is going to do something about it. And that someone is President Biden, who issued Executive Order 14028.
Among other things, EO 14028 included a recommendation for a requirement for a software Bill of Materials (SBOM) to ensure the safety and integrity of software applications used by the federal government.
What is an SBOM?
According to the National Telecommunications and Information Administration (NTIA), the driving force behind the SBOM, “An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships. SBOMs may include open source or proprietary software and can be widely available or access-restricted.”
The SBOM actually supports three categories of stakeholders: those who build software, those who purchase software and those who operate software. That pretty much describes every organization doing business, or wanting to do business, with the US government. And since even those not doing business with the government look to the government for guidance in the area of cybersecurity, the SBOM is likely to become the de fact approach for all businesses going forward.
There are three items which constitute the minimum elements for a SBOM:
- Data fields: baseline information that must be tracked
- Automaton support: must be machine-readable
- Practices and processes: for SBOM requests, generation and use
Why is it important?
Why is an SBOM important? According to the Cybersecurity & Infrastructure Agency (CISA), “A software bill of materials (SBOM) has emerged as a key building block in software security and software supply chain risk management.” In other words, it’s all about the supply chain.
The US government understands that when it comes to cybersecurity, their supply chain is only as strong as its weakest link. The SBOM is the government’s attempt to standardize and secure the software that comprises their supply chain. Their hope is that a properly-managed SBOM will reduce cost, security risk, license risk and compliance risk.
But, NTIA is under no illusion that the SBOM is a silver bullet by itself. They view it as just one part of a comprehensive, system-wide approach to cybersecurity.
For all the good that an SBOM can do, it really is only focused on secure software components. With respect to the software itself, the SBOM is focused on “low level” security. The thought being, when you develop software, you should do so with vetted, secure components, which makes perfect sense.
But what about software security at higher levels? At the system level, where the components interact with other components, and the software interacts with other software? The perfect complement to the SBOM would be something that provides a higher level, system view of the software threat landscape.
How Threat Modeling Complements the SBOM?
The perfect complement to the SBOM is threat modeling. While you can standardize the components that comprise secure software with an SBOM, there’s no way to do that at the system level. There are just too many possibilities to standardize. You need something more holistic. Enter threat modeling.
For software builders, integrating threat modeling into a CI/CD pipeline comprised of SBOM software components, is about as close as you can get today to end-to-end, secure systems development.
To learn more about how you can integrate threat modeling into your CI/CD, reach out the ThreatModeler. We’re happy to answer any of your questions.
