Extracting SBOM Value with Component Analysis
In the prior blog post in this series, Exploring the Plurality of SBOMs, we discussed what an SBOM is and its value proposition. The word proposition is used because the act of generating an SBOM produces marginal value. Instead, the value of an SBOM is only realized once it is consumed in some fashion. This consumption aspect is still too often overlooked, as generation or submission/sharing of an SBOM is getting far more attention than the consumption side of the equation.
SBOM consumption use cases exist for software producers, procurers, and operators, and they are quite different from each other. Software producers need to manage the third-party and internal (think re-use) frameworks and components used to build a specific software offering. As time passes, a component must be upgraded as old functionality is deprecated and new functionality is introduced. A component may have a vulnerability published that requires that it be patched by the development team. Most of this monitoring can be automated with notifications provided via ChatOps and in some cases blended into the continuous integration (CI) pipeline.
For software procurement or acquisition professionals, the value of SBOMs is typically found in design, source, build, or analyzed SBOMs. As noted in the last blog in this series, these are SBOMs generated much earlier in the process and differ from the deployed (does it exist in a production environment?) and runtime (is it being actively used in a production environment?) SBOMs. Acquisition professionals can and should ask for SBOM data as part of their RFI and RFP processes to better understand the software supply chain they will be purchasing.
It is easy to think about the product, a software application, as some stand-alone thing, but that is exactly the perspective that the industry must change. A software application is really a software supply chain, and without visibility and understanding of what made the software, it is much harder to appreciate the attack surface of the application and the best way to manage its cyber risk. Using an analogy, it’s similar to knowing what type of chip is in a device – is it an Intel or an ARM chip? A lack of visibility of a device’s chip architecture can create an engineering nightmare. Analogously, a lack of visibility into the software frameworks and components installed as part of a software application can create a cybersecurity nightmare.
The software operators are the team in IT actively managing the production environment of the deployed application software. This is the team on the front lines charged with IT asset management, compliance activities, and vulnerability management to include timely patching of software. When a high-risk vulnerability is detected, regardless of if there is a patch or no patch available, this is the team that needs to rapidly assess the risk that the vulnerability poses to the continuity of business operations. This team must quickly enumerate how many different software applications are in production that use the vulnerable component, assemble an appropriate set of mitigations until a patch to resolve the vulnerability is available, and evaluate the impact (if any) since the vulnerability was in production for some period.
Many of the top SBOM tooling vendors myopically focus on the software producer, not the software procurer or software operator. Herein lies one of the greatest challenges and opportunities for industry. That isn’t to say that tools do not exist for managing the SBOMs submitted by software producers. Instead, it is an acknowledgement that the adoption and deployment rate of component analysis tooling at organizations who traditionally only consume software has not yet reached critical mass.
CycloneDX is self-described from the OWASP website as “a leading full-stack SBOM standard that provides advanced supply chain capabilities for cyber risk reduction.” The CycloneDX tool website, https://cyclonedx.org/tool-center/, offers one of the best resources for searching through different types of SBOM tooling. At the time of writing, the “Distribute” category had seven entries, four that were proprietary and three that were open source. If you’re looking to begin exploring how to aggregate and analyze SBOMs, the BOM Repository Server, described at the site as a lightweight repository server used to publish, manage, and distribute CycloneDX SBOMs, is a good option. However, the only UI it offers is the Swagger API details.
Another open source option from OWASP that offers a full UI capable of exploring CycloneDX SBOMs visually is Dependency Track. It’s listed in the Tool Center under the Analysis category, and it can be downloaded from https://dependencytrack.org/. Dependency Track includes a robust set of documentation and crisp UI. It also offers an API first design, so it is easy to integrate into other cybersecurity tooling as well.
Achieving a greater level of cyber resiliency today requires more than simple software composition analysis. Component analysis tools explicitly designed to consume SBOMs aggregated by software procurers and software operators must become commonplace in all organizations that use software, which is to say, all organizations.
