The Software Bill of Materials (SBOM) through an Open Source Lens

The software bill of materials (SBOM) and the open source software (OSS) communities have long had close ties because of their community governance models and strategies. 

However, OSS projects often don’t ship with SBOMs. 90% of enterprise IT leaders are using enterprise open source today, according to Red Hat’s The State of Enterprise Open Source Report. Also, the report cites 54% of enterprises are using OSS for application development. Such stats speak to the need for commercial organizations, and government agencies need to put the tools and processes in place to generate SBOMs for the OSS that serves as a foundation.

SBOM Roots are in Open Source

The CycloneDX specification — one of the major SBOM standards — is an open source project. However, the project doesn’t have a standards organization or committee behind it. Instead, it relies on a community approach to drive innovation at a rate that keeps pace with the technological change happening around it. There’s some merit to this approach because post-SolarWinds industries now must elevate the role of the SBOM as a foundation for security and collaboration across their software supply chain.

Since its launch in 2017, the CycloneDX specification’s adoption has grown to several thousand organizations, many of which are generating SBOMs automatically during their development life cycle.

Another open source link to the SBOM is the Software Package Data Exchange (SPDX) standard, which follows the meritocratic governance model that the Apache Software Foundation uses. The governance model is such that SPDX enables participants to influence a project through their contributions. An organization that’s hungry for positive change to the SPX standard has an incentive to participate actively and contribute to SPDX initiatives to ensure that their voices are heard.  Also, SPDX maintains a list of open source tools that support their SBOM standard.

The National Telecommunications and Information Administration (NTIA) Software Component Transparency Initiative also factors in OSS in their investigations and research into SBOM-related standards and formats. Consider that government agencies are increasingly moving to cloud-native applications; open source plays an integral role in government cloud initiatives. Government systems integrators (SIs) and small to mid-sized consulting firms serving the public sector who want to elevate the role of the SBOM in the public sector need to speak up through the NTIA initiative, CycloneDX, and SPDX to ensure their interests are heard. These groups help face down some of the common SBOM challenges in the public sector.

The OWASP Foundation has also done some thinking around SCA, OSS, and the SBOM that you can find on their website.

DIY SBOMs for OSS 

The stats for OSS usage in application development and digital transformation (53%) speak to the power and innovation that enterprises are finding with the open source way. If your software supply chain relies on open source just as most do today, it’s essential to take a do-it-yourself (DIY) approach to create SBOMs for the open source packages your complex applications rely on for critical features. An open source bill of materials is foundational to your security team’s vulnerability scans and general understanding of what software components are entering your DevOps toolchains.

There’s the formal approach to doing this with software composition analysis (SCA) which will provide you better visibility into the known vulnerable components within the software package while producing an SBOM. Yet your organization may not have the expertise or tools to bring SCA into your DevSecOps pipeline.

If you aren’t ready for formal SCA, you can implement a range of tools before or during the pre-commit or commit phases of your DevSecOps pipeline to create an SBOM for the OSS components of your project. Such a step also requires some accountability and ownership over the OSS SBOM. Candidates for the owner include the developer, development team lead, or the architect.  Another option would be to assign SBOM generation to a member of your software quality assurance (SQA) team by assigning them this role in the early stages of your project.

Final Thoughts

The open source ethos courses through the SBOM community, bringing opportunities for the larger IT community to contribute to these standards efforts with their expertise. The SBOM is gaining renewed attention in the tech world since the SolarWinds hack. It’s time for the open source communities behind these standards to continue evangelizing the necessity of SBOMs for enterprises designing, building, securing, and deploying complex cloud-native software. It’s also time for enterprises using OSS in their applications to step up their support of these efforts.