This summer, the U.S. federal government published the minimum required elements of a software bill of materials (SBOM) in compliance with the recent Biden Administration's executive order (EO). The EO raises the bar for product security by requiring a SBOM for all software sold to the federal government, in an effort to ensure the integrity and provenance of the software used within any portion of an organization’s products.
With these new minimum SBOM requirements, the Administration is modernizing federal government cybersecurity through the standardization of elements that improve cybersecurity vulnerabilities. While these guidelines only apply to organizations that conduct business with the federal government, we are likely to see this extend into other areas as well.
We should embrace an SBOM mandate — not only as a step forward for securing our national infrastructure and economy, but as a new opportunity to innovate, compete, and increase the ROI of building secure software by design.
What is a Software Bill of Materials?
A SBOM derives from manufacturing bill of materials (BOM), which is a list of materials that tracks inventory and details all items included in the product. SBOMs include all open source or third-party components present in a codebase, as well as licenses that govern those components, the versions of the components used, and their patch status. By providing a SBOM for each product, organizations are able to ensure code is compliant, high quality, and secure.
Any organization that builds software needs to maintain a SBOM for their codebases, which typically use a mix of custom-built code, commercial off-the-shelf code, and open source components. Industry analysts estimate that the vast majority of IT organizations use open source software for mission-critical workloads. Still, few companies have much visibility into their software supply chain, and even fewer can produce an accurate, up-to-date SBOM that lists all open source components in their applications, as well as in those components’ licenses, versions, and patch status.
With a SBOM, organizations can quickly respond to security, license, and operational risks by revealing which open source or proprietary code objects are embedded in the software. Knowing this allows end users to better understand how bad actors might target new software by attacking old code elements that may have unpatched vulnerabilities. From failing to comply with open source licenses to inactive and unmaintained components, SBOMs not only increase transparency, but help reduce compliance and operational risks.
SBOM Minimum Elements
To create a comprehensive SBOM, the National Telecommunications and Information Administration (NTIA) defines three minimum elements for organizations to focus on: data fields, automation support, and practices and procedures.
SBOM Data Fields
Data fields include information that describes the components that comprise a piece of software. This information assists with the identification of the component to enable mapping to other sources of data. Data fields can include:
SBOM Automation Support
Automation support ensures organizations looking to closely and continuously track SBOM component data are able to present it in a digestible format. Software Package Data Exchange (SPDX), CycloneDX, and Software Identification (SWID) Tags, are the most human and machine readable formats.
SBOM Practices and Procedures
Practices and procedures help set the standard for how and when SBOMs should be updated and delivered. Six guidelines to keep in mind include:
At A Glance: SBOM Tools
There are different types of tools that can help organizations generate SBOMs, from production, to consumption and transformation. SBOM-action in GitHub helps those that want to generate SBOMs with current package managers and has a command line interface that enables the generation of SBOM information, including components, licenses, copyrights, and security references using specifications that align with current known minimum elements from NTIA.
At StackShare we believe you shouldn’t wait for a compliance mandate to guard against vulnerabilities. Organizations need to be proactive and understand what open source third-party components are present in your code base. SBOMs provide clear visibility into your tech stack that can empower you to mitigate these potential risks – for a comprehensive inventory on open source components, software composition analysis (CSA), we compiled the best open source vulnerability scanners for developers.
Private StackShare for Teams takes software supply chain transparency one step further, complimenting your SBOM with its visibility and collaboration features. Get a live inventory for your SBOM of all your tech stacks and the people using them in one dashboard. Deliver compliant, high quality, and secure code by keeping an updated inventory of third-party and open source components.
Keep your SBOM up to date with automatic package change detection and Stack Alerts anytime packages are added, removed, or updated in any of your connected repositories. See all versions of your tools in use, and update when versions change, with Tools Report. Respond quickly to security, license, or operational risks that come with open source uses by maintaining an up to date SBOM with Private Stackshare for Teams.
Check out Private StackShare on the GitHub Marketplace and sign up for free today.