Are you incorporating Software Bill of Materials (SBOMs) into your security strategy and software visibility? If not, you may soon be required to have one — and keep it up to date — which is another set of concerns and work to manage.
If you haven’t already heard about SBOMs, here’s a bit of an overview. An SBOM is a formal record that contains the details and supply chain relationships of the various components used in building software. Software providers often create products by assembling open source and commercial software components, and an SBOM enumerates these components.
An SBOM can be useful for teams that develop software, organizations that buy the software, and users who operate the software. For example, it enables developers who rely on open source and third-party components to make sure the components are up to date and can respond to new vulnerabilities. Software buyers, on the other hand, can use an SBOM to perform vulnerability analyses to evaluate the risk a product poses.
Among the requirements of an executive order on improving the nation’s cybersecurity announced by the White House in May 2021 is that organizations provide purchasers of software products with an SBOM for each product directly or by publishing it on a public website.
The mandate is a key step for ensuring the security of software products — and a huge undertaking for companies that need to comply.
The executive order directs the U.S. Department of Commerce, in coordination with the National Telecommunications and Information Administration (NTIA), to publish the “minimum elements” for an SBOM, according to the department.
As the Commerce Department has noted, “an SBOM provides those who produce, purchase, and operate software with information that enhances their understanding of the supply chain, which enables multiple benefits, most notably the potential to track known and newly emerged vulnerabilities and risks.”
How SBOMs Offer A Clearer View of Software Risks
An SBOM forms a foundational data layer on which further security tools, practices, and assurances can be built, it said. The minimum elements are the essential pieces that support basic SBOM functionality, the department states, and serve as the foundation for an evolving approach to software transparency. The minimum elements comprise three interrelated areas including data fields, automation support and practices and processes.
The U.S. Cybersecurity & Infrastructure Security Agency (CISA), a part of the Department of Homeland Security that leads national efforts to understand, manage, and reduce risk to the cyber and physical infrastructure, said SBOMs have emerged as a key building block in software security and software supply chain risk management.
SBOM work has advanced since 2018 as a collaborative community effort, driven by NTIA’s multistakeholder process, CISA said. The agency said it will advance the SBOM work by facilitating community engagement, development, and progress, with a focus on scaling and operationalization. It will also assist in the development of new SBOM technologies and use cases.
SBOMs Are NOT Set it and Forget It
But while good for security and visibility, here’s the rub: an SBOM can be difficult to build and maintain. After an SBOM is developed, it needs to be updated whenever a change is made to any application component. This includes code updates, vulnerability patches, new features, and any other modifications.
Information integrity is key, so everything in an SBOM should be auditable, including all version numbers and licenses. Information needs to come from a reputable source and be verifiable by a third party. Unfortunately, this is typically done manually and changes can happen at any time. Since these need to be tracked in real-time for the SBOM to be effective, it’s a highly difficult task.
In addition, there is no clear standard for SBOMs, which are still under development. As a company’s environment changes, it needs to create new SBOMs. Thus, the number of SBOMs keeps growing without real reconciliation, which increases the maintenance challenge.
That’s why it is critical for organizations to look into strategies and tools that offer the ability to have a dynamic SBOM that can incorporate updates automatically as changes occur. While today’s SBOMs are not dynamic because they are static documents and do not automatically incorporate updates, the SBOMs of the future will be dynamic. In fact, this will eventually become a requirement, especially in organizations that create and update software products regularly.
DBOMs: The SBOMs of the Future Will Be a Dynamic Bill of Materials
Future SBOMs will also be integrated into a product’s security lifecycle and be produced automatically at predefined stages. They will also be interoperable, which will lead to greater adoption.
Companies using SBOMs now should follow some key best practices, including updating the SBOMs on a regular cadence and with each release; making SBOMs more comprehensive as a general rule by including as much information as they can about the different software components; automating SBOMs as part of their development workflow; and extending SBOMs to all their software.
Many software providers don’t really know what vulnerabilities are in their software and which are exploitable. As we see with Log4j, vulnerabilities in software are constantly discovered. We hope the discovery occurs at the hands of an ethical hacker or penetration tester who will responsibly disclose the bug to the software maker — and not by a criminal who will exploit it in the wild. Additionally, sometimes bugs can simply be difficult to locate. As we see with Log4j, the flaw is nested and tough to uncover with traditional tools.
Given the non-stop nature of vulnerability discovery, it is nearly impossible to know all vulnerabilities in an environment at any given time. This is why building security into the software development lifecycle is so essential. If development teams follow a DevSecOps model, there is less of a chance of finding a flaw in production.
