Software bill of materials: What you need to know

Cybersecurity is an endlessly challenging topic, and recently, the software supply chain has proven to be vulnerable.

Executive Order 14028, which President Biden signed in May 2021, sets out a comprehensive approach to securing our digital infrastructure. The order establishes a set of principles for securing the software supply chain and directs federal agencies to take specific actions to improve the security of the software they produce and use.

The order also creates a Software Bill of Materials (SBOM) task force to develop recommendations for improving software security and supply chain risk management. Creating an SBOM can be a time-consuming process, but it is essential for managing software development projects and achieving compliance with the cybersecurity executive order.

What is a software bill of materials?

Creating a SBOM is the first step in managing a software project, as it provides a clear overview of all of the aforementioned information and how it is all related. It is a list of software components required to create a functioning software application or a system. This includes both the source code and any third-party libraries or frameworks used for that particular software. An SBOM includes information on versions, dependencies, licenses, and other relevant metadata.

Organizations can use the SBOM to track the provenance of software, understand its composition and ensure that it meets security and compliance requirements. They can also use it to track dependencies and security vulnerabilities in software products. This can help system owners evaluate needs, such as which dependencies are critical and which are important, cosmetic, easily exchanged or unnecessary.

By knowing which versions of which components are in use, organizations can quickly perform remediation and/or mitigation of identified vulnerabilities.

The U.S. National Institute of Standards and Technology (NIST) and the National Telecommunications and Information Administration (NTIA) have released guidance on how to create and use SBOMs. Here some best practices for doing it quickly and well:

• Use automation to create the SBOM - Automated tools can crawl the codebase and generate an SBOM by reading code metadata, including including comments, package manifests, and build titles. They can also track dependencies by reading package metadata.
• Include all software components, including those not directly visible to the user, such as libraries and frameworks. The format of the SBOM will vary depending on the needs of the organization, but it should be machine-readable and easy to update.
• Include additional files if necessary - Depending on your organizational or clients’ requirements, you may have to provide additional companion files to the SBOM called Vulnerability Exploitability eXchange (VEX) and Vulnerability Disclosure Report (VDR). These are machine-readable attestation files that provide information about the impact and status of identified vulnerabilities.

SBOM best practices

In the context of DevSecOps, an SBOM can help organizations automate the process of tracking and approving software components.

An SBOM is an important tool to help ensure that all required components are accounted for and sourced. There is no one-size-fits-all when creating SBOMs, but there are some best practices to keep in mind:

• Keep the information in the SBOM accurate and up to date. As the organization updates, adds or removes software components, it should also update the SBOM to reflect those changes.
• Ensure that the SBOM covers all types of software in your system—including purchased, open source or in-house software.
• Store the SBOM in a central location where it can be easily accessed by all members of a development team.
• Track all dependencies across supply chains, including transitive dependencies. A transitive dependency is a dependency of a dependency. Tracking transitive dependencies is important because they can pose capability and security issues.
• Adopt a “shift left” approach. In the context of DevSecOps, an SBOM can help organizations automate the process of tracking and approving software components. By automatically creating an SBOM for each software build, organizations can ensure that only approved components are included in their code repositories. This can help reduce the risk of vulnerabilities introduced by unapproved components.
• Establish continuous vulnerability monitoring of identified components in the SBOM for the latest security threats to reduce risks to your software.
• Sign the SBOM using cryptographic keys—to self-attest that the SBOM itself was not tampered with and that it comes from a trusted source.

For more details on SBOM, email cyberdevelopment@cgifederal.com. Learn more about CGI Federal's cybersecurity services here.