The role of the SBOM in software development and software supply chain security is gaining renewed attention in the aftermath of the SolarWinds Compromise.
Here’s an overview of the SBOM, the standards that govern it, and the evolving role it’s playing in software supply chain security.
What Is an SBOM?
A software bill of materials lists all the open source and commercial software components present in your software codebase. Some in the tech industry liken an SBOM to a list of ingredients. Others point out the parallels it has to a service bill of materials in the automotive industry, where hundreds or even thousands of suppliers provide components to build automobiles.
Today’s software industry depends on the reuse of components. Complex cloud-native applications might include hundreds or even thousands of software components that software development and cybersecurity teams must track through all stages of the DevSecOps life cycle.
Consumer app stores have shaped software customer expectations with frequent releases. In response, software vendors and government agencies are increasingly depending on open source software (OSS) and commercially available software to augment the custom-built code that their in-house or contract developers are creating. Reusing code makes sense for reasons of efficiency and saving time.
Because SBOMs contain licensing, component, and patch information, the file serves three audiences:
- Business departments such as contracts, legal, logistics, finance, or operations where organizations track software licensing across their business units
- Development teams and enterprise architecture groups need to track the open source, commercial, and custom-built software components that are presently used across the applications they develop, manage, and operate across their enterprise
- Cybersecurity teams that can use SBOMs as the basis for their vulnerability scanning strategy
Ultimately, there’ll be organizations that see cross-functional team angles around the SBOM as they move towards more cloud-native applications.
Industry and government typically stick to three main SBOM standards to govern SBOM format and structure for their organizations.
CycloneDX is a lightweight software bill of materials (SBOM) standard useful for application security contexts and supply chain component analysis. Here are three popular use cases for this SBOM standard:
- Inventory of all first and third-party software components for risk identification because a well-formed SBOM includes all direct and transitive software components and information about the direct relationships between them.
- Known vulnerabilities because an SBOM in CycloneDX format includes three fields: cpe, swid, and purl. The CPE specification targets operating systems and applications. It has since been deprecated. Software ID (SWID) is used primarily identifying installed software. The Package URL (PURL) standard governs the representation of software package metadata to enable the local software packages universally regardless of the vendor or project where the packages belong.
- License compliance because CycloneDX incorporates SPDX license IDs to document stated license of open source components. CycloneDX expresses licenses in three ways: SPDX license ID, SPDX license expression, or license name.
The full CycloneDX specification is available online at GitHub or the CycloneDX site.
The CycloneDX Core working group with origins in the OWASP community provides strategic direction and maintenance of the standard.
The Software Product Data Exchange (SPDX) is a standard format for communicating the components, licenses, and copyrights associated with a software package. Their vision is to provide common formats for organizations to share essential data, reducing redundant work. The project includes the following components:
- SPDX Specification
- SPDX License List
- SPDX tools and libraries
SPDX is a grassroots open source project hosted by the Linux Foundation. It draws representatives from vendors, foundations, and system integrators.
A tech team and legal team do the work behind the project. SPDX holds a scheduled monthly status call about their progress.
NTIA Software Component Transparency
The United States Federal Government increasingly depends on complex cloud-native applications. The National Telecommunications and Information Administration (NTIA) is driving an effort called NTIA Software Component Transparency. It’s an effort to build consensus about SBOMs across government agencies and industries.
This initiative dates back to 2018, when the NTIA kicked off an industry-led, multi-stakeholder process on software component transparency to include perspectives from across the software supply chain to understand the challenges that organizations face and the benefits they seek from a truly transparent SBOM. Another hope of this initiative is to establish an open non-regulatory process for honest exchanges and practical enterprise-focused outcomes that speak to the security and economic benefits that the SBOM provides.
The SBOM is no longer just the purview of your legal or contracts department.
Getting to know and maybe even love the SBOM requires treating it as a foundational element for developing software. CIOs, CTOs, and CISOs must work with their development, security, and business teams to make the SBOM a core element of software project collaboration because a well-formed SBOM has cross-functional team benefits in our current security climate post-SolarWinds hacked world.
Do you want to generate SBOMs on the OSS in your development projects? Download Syft, our open source CLI tool, and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems.