Cybersecurity is top of mind today for both the private and public sector around the world. In light of recent cyberattacks, organizations now realize they must pay closer attention to the security of the software they use. But to do so, they must first know what software – proprietary and open source–that’s actually in use. To shift from a passive stance (if we get hacked) to a proactive mindset (when we get hacked) requires increased knowledge of all software assets. Improving your security posture demands a hardened software supply chain – one that explicitly declares software components, enabling organizations to identify and mitigate risks before they become a crisis.
A Software Bill of Materials (SBOM) can help address these needs. An SBOM uniquely identifies a piece of software, its dependencies, and license data in an automatically-generated machine-readable format. Organizations benefit from not only increased awareness but also reduced license, compliance and security risks with SBOMs.
The benefits of producing and consuming SBOMs and most notably their potential to track known and newly emerged vulnerabilities are already widely recognized. SBOMs play a central role in the Executive Order on Improving the Nation’s Cybersecurity issued by the White House in May 2021 (EO 14028). And according to the Linux Foundation Report on SBOM and Cybersecurity Readiness, “90% of organizations [surveyed] have started their SBOM journey”.
Newcomers to the SBOM ecosystem, however, struggle with SBOM adoption. According to the report “the overall leading SBOM consumption concerns included uncertainty around industry requirements for SBOMs (49%), the availability of tools to automate the consumption of SBOMs (48%)”, and “46% of the overall sample is struggling to understand which vendors will be providing SBOM tools and capabilities.”
Open Source: From Plan to Practice
Industry organizations and vendors need to step up and help build confidence with SBOM standards, tooling, and best practices. VMware’s engineers are part of that effort. By actively participating in evolving SBOM data formats such as The Software Package of Data Exchange (SPDX), an internationally recognized ISO standard, and the Automating Compliance Tooling (ACT) Project, VMware’s engineers support the development of open source tooling for efficient and effective exchange of SBOMs to enable license compliance, security, export control, pedigree and provenance workflows. Tern, an open source inspection tool for generating SBOM for container images and Dockerfiles, began its life at VMware and now thrives under the stewardship of the ACT project and VMware engineer and Tern maintainer, Rose Judge’s expertise. You’ll also meet VMware engineers in the The Update Framework (TUF), a framework for securing software update systems. Jussi Kukkonen and Joshua Lock play key roles in the TUF project.
The SBOM Wish List
But an SBOM can be more than just a static manifest, produced at a single point in time. SBOMs can deliver real value, when integrated with the development process, the maintenance process, and the compliance process. In my work in this area, I’ve assembled a wish list of SBOM capabilities.
- As an SBOM consumer, I’d like to integrate SBOM capabilities into my existing vulnerability management practices and easily identify the vulnerable components in my software, and know the vulnerability’s impact so that I can quickly mitigate potential damages.
- As an SBOM consumer, I’d like to break a flattened SBOM into individual component-level micro SBOMs so that I can compare/validate a component’s information against another document, update a component, audit components against predefined policies, or remove a confidential component from the publicly available SBOM.
- As an SBOM producer, I’d like to collect smaller, component level SBOMs (micro SBOMs) for my modular software ingredients and “stitch” them together into a single top-level SBOM (flattened SBOM) and provide it to my users/customers.
- As integrity and authenticity are priority for me, I’d like to verify the source of the SBOM data I’ve received and confirm that it is accurate and has not been altered. A signed, fully attested and verified SBOM – that’s the end goal.
Oh…did I mention? I’d like all that to scale. There’s work to be done, that’s for sure! And incentives to improve SBOMs come from all directions, industry, vendors, community leaders not to mention the US White House Executive Order.
Conclusion
Solving the software supply chain challenge, and supporting and simplifying SBOM operationalization–that’s one of the many open source initiatives VMware invests in. And we do so in collaboration with the communities around the ACT Project, SPDX and Vulnerability-Exploitability eXchange (VEX), to “make sure that we can integrate this [SBOMs] into daily operation, into existing tools, and the final status of hooking it into the existing vulnerability and cybersecurity ecosystem,” as Allan Friedman, a Senior Advisor and Strategist at the Cybersecurity and Infrastructure Security Agency, has said in an interview for Nextgov.
At VMware, we’re not only contributing to making the existing tools even more powerful, but building new ones that fill the gaps and make the SBOM ecosystem user friendly and beneficial for all.
What is your organization doing today to make SBOMs a core part of its process for building and shipping software?
Stay tuned to the Open Source Blog and follow us on Twitter for more deep dives into the world of open source contributing.
