With his years of work on the CycloneDX standard, Springett understands the issues holding back SBOM usage-particularly when it comes to standardization, dependency tracking, and verification.
Not to mention, he also chaired OWASP's Software Component Verification Standard, which, like CycloneDX as the standard for expressing SBOM data, is tied to his latest endeavor, the OWASP BOM Maturity Model.
The OWASP BOM Maturity Model plays a crucial role in supporting the five dimensions of SBOM quality as outlined in the CycloneDX Authoritative Guide to SBOM. The model serves as a customizable template for all stakeholders, to optimize the SBOM data supporting their uses.
In this interview, Springett explains how far SBOMs have come, and how much they need to improve.
There are an abundance of tools that can create SBOMs. Fewer can consume SBOMs. And fewer still can produce quality SBOMs-and those that do are using multiple tools strung together looking at software through different lenses.
Part of the maturity roadmap is talking about how we improve SBOM data so that consumers of SBOMs can make risk-informed decisions.
A: We need to improve the depth and breadth of data that we include in the SBOM. For example, pedigree: Open-source components can be modified, renamed, and redistributed.
If you backported security fixes, those backports should be documented in your SBOM. If you added features, those need to be documented.
Not all SBOMs and not all tools that generate them are created equal.
If you can start capturing the evidence, techniques, methods, and confidence level of each technique in your SBOM, you can communicate the level of assurance about your SBOM creation.
A: Identifying the use cases that your organization and your customers care about and mapping them to SCVS is one way that you can start comparing whether an SBOM format meets your requirements and whether or not you are getting right data for the type of analysis you'd like to perform.
With mature SBOM data, different teams can create their own policies and communicate that to their customers.
A: A large contractor standardized CycloneDX in a way that their downstream suppliers are also required to supply CycloneDX SBOMs. For cases like this, documenting in an SCVS profile what the precise requirements are for that SBOM is a way to communicate downstream in a machine-readable way what the contractor's minimum requirements for an SBOM are.
Another use case involves SBOM conversions, which are challenging because formats are not field-to-field equivalent.
As a product company, you can use the BOM maturity model to ensure that the SBOM that you are generating in your build pipeline meets the expectations for software that you produce.
If you are a provider for the U.S. government, we offer out of the box profile for the NTIA's Minimum Elements for SBOMs. You can create your own requirements as well.
Tools are now starting to emerge that are using this model, and just like SBOMs past, you'll see the emergence of new tools that have adopted SCVS adopting these profiles, conversion calculators and other SBOM data that will be much more transparent to the users.
A: If we're talking about crawl, walk, run start by implementing SBOMs into your build pipelines.
The organizations that take a holistic view of software transparency, which not only includes the inventory of components, their modifications, all the providence data, and everything used to create and distribute SBOMS - those are the ones that will ultimately succeed.
The post Improving Software Quality with the OWASP BOM Maturity Model appeared first on CodeSecure.
This Cyber News was published on securityboulevard.com. Publication date: Wed, 14 Feb 2024 01:43:03 +0000