What Will it Take to Establish a Ground Truth for SBOMs?
A Software Bill of Materials – also known as an SBOM – has emerged as another effective tool in the arsenal as organizations look to secure their supply chains. But there is currently a lack of standardization for SBOMs, making it challenging to establish a ground truth.
Use of SBOMs has gained momentum since the Biden Administration’s executive order mandating that IT providers that work with the federal government must provide an SBOM to do so. This is not just a U.S. practice; the European Union has also mandated SBOMs as a prerequisite for an organization that transacts with government agencies and regulated organizations.
By 2025, 60% of organizations building or procuring critical infrastructure software will mandate and standardize SBOMs in their software engineering practice, up from less than 20% in 2022, according to Gartner. Additionally, by 2024, 90% of software composition analysis tools will be able to generate and verify SBOMs to help securely consume open source software, up from 30% in 2022, the firm added.
The impetus for SBOMs also comes in light of the discovery of the Apache Log4j vulnerability – which is still present in many environments and is expected to wreak havoc for years to come.
Given their ability to verify information about code provenance and relationships between components, which helps software engineering teams detect malicious attacks during the SDLC, there is no question that SBOMs are useful.
But they can also create complexity because of the wide-ranging supply chain dependencies that exist in all software packages. This can slow down the development process, which is not something DevSecOps professionals want to hear since speed is a main priority for developers.
Nor is that good news for security teams, which need SBOMs that are constantly updated in real-time so they can effectively flag the software components that might become potential attack vectors for hackers.
Adopting a Standard for SBOMs
To reduce the complexity and establish a ground truth for SBOMs and navigate relationships and dependencies in the software supply chain, Gartner is advocating that software engineering leaders adopt one of the three common industry standards for SBOM formats: Software Package Data Exchange (SPDX), Software Identification (SWID) and CycloneDX.
While the firm doesn’t endorse any standard, Gartner says SPDX has gained the most industry traction. There does not appear to be a broad consensus yet on any particular standard.
Standardizing will help software engineering teams easily share metadata about the components contained in software packages, the firm explains. A lack of standardized data exchange formats impedes the ability to share the metadata within the SBOM among teams, partners, suppliers and customers.
Some in the security industry have also begun calling for a non-vendor affiliated organization to spearhead an SBOM benchmark list to serve as a ground truth for using these tools.
Dynamic SBOMs Are A Source of Truth
One of the biggest ways SBOMs provide value is by enabling teams to monitor vulnerabilities as third-party suppliers discover them. But you can’t be kept apprised of these without the ability to “trust but verify” and continuously monitor the vulnerability status of a supplier’s software dependencies.
Because SBOMs are not static documents, the only way to keep data in sync with changes is by using tools that are dynamic and automatically updated as software is modified and added.
A Dynamic SBOM responds to real-time changes in the software lifecycle and this leads to a more accurate software supply chain that can be better maintained and secured. For organizations that build and manage many software products, this capability is critical.
To be clear, an SBOM doesn’t automatically provide the ground truth; it’s the way in which they are designed and the processes that guide them that will in the future. A set of benchmarks will also be key to making these tools more effective and reliable.
Get Closer to the Truth With Rezilion’s Dynamic SBOM
Rezilion’s Dynamic SBOM creates a continuous inventory of all of your software components, maps any recognized vulnerability to these components, and assesses your attack surface. Learn more about how we can help you create a Dynamic SBOM at https://www.rezilion.com/platform/sca-dynamic-sbom/.