Software Bill of Materials

Most relevant for 🔍 Technical Evaluators

Software Bill of Materials (SBOM) is a list of all the open source and third-party components present in a codebase. An SBOM also lists the licenses that govern those components, the versions of the components used in the codebase, and their patch status, which allows security teams to quickly identify any associated security or license risks. There a few standardized formats that exist for SBOMs.

Processes and Tools

The adoption of open-source tools (see our resources page for a list of recommended tools) to generate Software Bills of Materials (SBOMs) for entire source code repositories and, when feasible, for each Docker image produced from those repositories, marks a significant step in enhancing the transparency and security of the software development process. SBOMs provide a detailed list of all components, libraries, and dependencies used in the software, offering critical insights into the software’s composition. This documentation is invaluable for tracking the provenance and ensuring the integrity of the software components, facilitating easier management of licenses, vulnerabilities, and compliance with security standards. By generating SBOMs, organizations can quickly identify and respond to security vulnerabilities or licensing issues that may impact their software, thereby improving their overall security posture.

Here is an example of the kind of output that an SBOM tool can generate, providing detail about the components, versioning, license, and cryptographic hash of a software dependency:

Furthermore, using a tool specifically for Docker images amplifies these benefits by addressing the unique challenges posed by containerized environments, such as layering and the use of base images that might include additional dependencies. This practice ensures that each layer of the Docker image is analyzed and documented, providing a comprehensive view of what’s inside the containers. This level of detail is crucial for security teams and developers who need to ensure that no insecure or outdated components are lurking within containers, potentially exposing applications to security threats. The ability to generate SBOMs at both the repository and Docker image level not only streamlines security practices but also enhances operational efficiency by allowing for automated tools to handle much of the vulnerability management workload.

In Case of Proprietary Code…

When engaging with vendors, particularly those who offer proprietary solutions, it is crucial to discuss the possibility of obtaining a Software Bill of Materials (SBOM). An SBOM serves as a detailed inventory of all components, libraries, and dependencies used in a product, providing transparency into its technical composition without necessitating the disclosure of proprietary intellectual property. This transparency is vital for assessing potential security vulnerabilities and compliance with licensing regulations. By requesting an SBOM, organizations can gain insight into the underlying architecture of the software they are purchasing, enabling them to make informed decisions about security risks and compatibility with their existing systems. Consequently, SBOMs are becoming a key element in the procurement process, facilitating greater trust and collaboration between buyers and vendors while safeguarding the confidentiality of proprietary technologies.

Legal Requirements for SBOMs

The United States has taken significant legislative steps to improve cybersecurity, especially in the wake of high-profile cyberattacks like the SolarWinds incident. Executive Order 14028, issued in May 2021, aims to secure software systems used by federal agencies by enhancing the transparency of software supply chains and enforcing several security measures. Among these measures are the requirements for service providers to secure software development environments, maintain trusted source code supply chains, and provide a Software Bill of Materials (SBOM) for each product. This ensures that all software components, their origins, and any known vulnerabilities are documented, enhancing the ability to monitor and address security risks effectively. While these requirements currently apply to vendors working with the U.S. government, they serve as a best practice framework that can benefit all software vendors by improving security during development and post-deployment.

Similarly, the DHS Software Supply Chain Risk Management Act mandates that contractors to the Department of Homeland Security must provide an SBOM for their IT products or services, detailing any known vulnerabilities and mitigation plans. This legislative approach has also been mirrored by the FDA, which has set requirements for medical device manufacturers to provide SBOMs due to increased cyber threats to healthcare institutions. These regulations are part of broader efforts, such as the Consolidated Appropriations Act of 2023, which empowers the FDA to regulate the cybersecurity of medical devices, including requirements for monitoring and addressing post-market vulnerabilities and ensuring devices are free from known risks before they are marketed. Both these examples underscore a growing legislative trend towards mandating the provision of SBOMs to enhance transparency and security in the software supply chain, a practice that is expected to expand further, including potential adoption in the EU through proposed legislation like the Cyber Resilience Act.