By Deb Radcliff, industry analyst and editor of CodeSecure’s TalkSecure educational blogs and podcasts (syndicated at Security Boulevard, YouTube, and Bright Talk).
In the software product industry, bills of materials for software (SBOMs) are still in their infancy. So said Chris Hughes in our recent roundup of 2024 predictions. And so says Steve Springett, Chair of the OWASP CycloneDX Bill of Materials Standard, and director of product security at ServiceNow, a cloud-based platform provider supporting digital connectivity and transformation, with nearly $7 billion in subscription revenues in FY 2023.
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 (SCVS), 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 (product developers, buyers, legal, GRC, SOCs, etc.), 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.
Q: How mature would you say SBOMs are today?
A: “I think we’re in our infancy. 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. This includes development groups using components as well as their downstream customers consuming their software products.
Q: What do you mean by quality SBOMs?
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. So, one aspect of quality means keeping track of all those modifications made to your open source. If you backported security fixes, those backports should be documented in your SBOM. If you added features, those need to be documented.
Also, being able to track how the SBOM was created. 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.
Q: How will the BOM maturity model help?
A: Identifying the use cases that your organization and your customers care about and mapping them to SCVS (the OWASP Component Software Verification Standard) 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.
The BOM Maturity Model also includes the concept of profiles that can be applied to stakeholder roles within an organization. For example, your infrastructure team, application security team, AI ethics team, and legal team all care about different things. With mature SBOM data, different teams can create their own policies and communicate that to their customers.
Q: Can you share an example of this chain of stakeholders benefiting from more mature SBOM output?
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. Because the BOM maturity model covers the breadth – all the different types of data related to a component, and the depth of coverage of each of those pieces, you can now—if you’re doing a conversion—identify what type of data is going to be lost and to what extent.
The BOM maturity model covers hardware, any type of software, and firmware with specialized requirements for each class and category of product. 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.
Q: What SBOM improvements do you see in the next twelve months?
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. This applies to hardware, software, and firmware, particularly for products developed for or used by the U.S. Government.
From a capabilities perspective, CycloneDX has a rich data model. Having come from the OWASP world, the model is security-focused, and that includes all of the modifications and providence data, and of course the related vulnerability information.
Q: What advice do you have for product companies?
A: If we’re talking about crawl, walk, run, then, start by implementing SBOMs into your build pipelines. Make it a natural artifact of producing software. Step two: Begin using the BOM Maturity Model to identify things that your product company and customers would benefit from if you communicated that and add support for that type of data.
Step three: tackle the harder problems of pedigree and modifications to open-source components. This is a hard problem and no out-of-box solution covers most of this today. That data is valuable to development teams and the buyers of their products and should be visible to them as needed to secure their products and their customer’s environments.
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. Steve Springett, Chair of the OWASP CycloneDX Bill of Materials Standard, and director of product security at ServiceNow
Commercial licensing is also important. What happens if that license expires? You have a denial of service. Steve Springett, Chair of the OWASP CycloneDX Bill of Materials Standard, and director of product security at ServiceNow
