Software bills of materials (SBOMs) have become a central component of enterprise efforts to secure the software supply chain. President Biden’s 2021 Executive Order on Improving the Nation’s Cybersecurity, EO 14028, made it a requirement for federal agencies to implement SBOMs when developing software internally or procuring it from external contractors.

Concerns about the transparency and traceability of software supply chains have been driving broad interest in SBOMs in the private sector as well. A survey that Sonatype conducted earlier this year showed that 76% of enterprise organizations in the United States and the United Kingdom maintain SBOMs and that 60% require their software vendors and others they work with to do the same for their software. Other factors driving adoption include broader cybersecurity posture — improvement plans and concerns over software supply chain attacks, the study found.

EO 14028 and related documents focus on requirements to use SBOMs and on the content that SBOMs must include. But making SBOMs useful is tricky in modern development organizations. Here are five best practices for implementing SBOMs in continuous integration/continuous deployment (CI/CD) environments.

[ Learn more about SBOMs | Get a free RL SBOM and supply chain risk analysis ]

1. Automate SBOM generation

The key to operationalizing SBOMs in your CI/CD pipeline is ensuring that they are automatically created with each software build. Multiple tools for generating SBOMs are available that integrate directly into CI/CD tooling. Examples include OWASP Dependency-Check, CycloneDX, and FOSSA.

Choose a tool that is scalable, supports multiple languages, and works with widely accepted data formats. And ensure that the build-time SBOM tools you choose provide a holistic view of what’s in the application and cover what customers want enumerated in their SBOMs, said Tom Goings, product consultant at Tanium. 

Not all tools do the same thing. OWASP’s Dependency-Check, for instance, is a software composition analysis (SCA) tool that analyzes primarily open-source components within a project, identifying dependencies and checking for known vulnerabilities. CycloneDX does the same thing, but for both open-source components and custom or internally developed code.

The SBOM that you provide to customers should provide a comprehensive view of all the off-the-shelf, open-source, and internally developed components, Goings said.

“Build-time SBOMs allow software vendors to provide customers with a complete list of what is in their software when they ship. They are focused on providing details to customers about what is in the application they purchased.”
—Tom Goings

2. Ensure your SBOM has the required elements

An SBOM should list all components, including direct and transitive dependencies, libraries, frameworks, and any custom code, open-source code, and/or third-party modules in an application. The list of baseline elements that the National Telecommunications and Information Administration’s (NTIA) developed in response to EO 14028 identifies these elements: the name of the component, the component type, the author, the supplier’s name, the version string, the unique identifier, and component hash and dependency information.

Get as granular as you need when it comes to including information in an SBOM, advised Michael Mehlberg, CEO of Dark Sky Technology. “Provide a list of all components, source location, version information, and authorship information so that dependencies can be tracked for all dependencies in the entire dependency tree,” he said. Storage is cheap and processing power is easily available when it comes to storing and processing SBOMs. So there’s no need to shortchange or second guess what to include in an SBOM, he said.

“Generate an SBOM with the most information available, store it with your release, then operationalize it to track things like software license rights, security vulnerabilities, etc.”
—Michael Mehlberg

Including data on when during the software lifecycle the SBOM data was collected can also be useful. The NTIA recommends — but does not require — that federal agencies include data on whether, for instance, component data was collected from the software source, or at build time, or via a binary analysis tool. SBOMs can have differences based on when the data was collected, so documenting when, where, and how the data was collected can be useful, the NTIA has noted.

3. Export SBOMs in a standard data format

Using a standard data format for your SBOM is critical to interoperability so that different tools can process it.

The NTIA’s Minimum Elements for a Software Bill of Materials document requires federal agencies to generate and consume SBOMs in one of three formats: CycloneDX, Software Package Data eXchange (SPDX), or Software Identification (SWID) tags. Though all three formats can be used to represent SBOM information, each has a slightly different focus and use case. The primary use case for CycloneDX, for instance, is cyber-risk mitigation. With SPDX, the main focus is communicating information on the components, licenses, and copyrights associated with a software package. And SWID is a standard for uniquely identifying software applications and components.

Be sure the format is both human- and machine-readable and can be consumed by the software consumer, Dark Sky’s Mehlberg said. “Make sure the format captures the information you are required to capture and deliver to your consumers,” he advised. “CycloneDX, SPDX, and SWID are all great SBOM formats but have their own set of data they track, which may or may not be applicable to your software requirements.”

4. Ensure your SBOMs’ integrity and authenticity

It’s important that a software consumer is able to verify the authenticity and integrity of an SBOM and to ensure that the SBOM has not been tampered with during transit or storage. The NTIA recommends that software developers consider using existing mechanisms for integrity and authenticity — such as digital signatures and cryptographic hashes — for providing that assurance. “Those supplying and requesting SBOMs are encouraged to explore options to both sign SBOMs and verify tamper-detection,” the NTIA has noted in its guidance on the topic. “Such a mechanism should allow the signing of each component of a given piece of software and allow the user to determine whether the signature is legitimate.”

CycloneDX and SPDX both support the inclusion of such information in an SBOM.

5. Keep your SBOMs updated

Component information can change, and new vulnerabilities can emerge in third-party, open-source, and custom-built software. Keeping an SBOM updated is critical to ensure continuous security and compliance with licensing and regulatory requirements. It’s not just a nice-to-follow practice, but a required one for U.S. federal agencies. The NTIA requires a new SBOM every time a software component is updated. The requirement applies to every new build or release of software or when a component or dependency in a software build gets updated,

Anthony Tam, manager of security engineering at container security vendor Tigera, which also is the primary maintainer of Calico open-source software, said using an SCA tool to scan your software and its dependencies is a good measure for unearthing vulnerabilities and license issues that might have crept into your software since the last build. “It is important to continually monitor open-source components for new vulnerabilities, as they are constantly evolving,” Tam said. “When vulnerabilities have been identified, it is important to prioritize them based on severity and potential impact.” 

“Prioritization can be done by using a risk-based approach, considering factors such as the likelihood and potential impact of a vulnerability being exploited.”
—Anthony Tam 

Making SBOMs operational is key

While SBOMs are crucial to securing the software supply chain, they are of little value if an organization doesn’t know how to operationalize them fully. Mehlberg said an SBOM tells you what your software is made up of, but it says nothing about what is in it, the trustworthiness of the developers who developed it, the vulnerabilities associated with it, the quality of the code in the packages, or the licenses that could affect you legally. He recommends this routine:

“Get an SBOM. Check it. Track it. Then analyze it for security, trust, and legal risks.”
—Michael Mehlberg

Matt Rose, Field CISO at ReversingLabs, said that for SBOMs to be effective, organizations need to adopt the same integration and automation into DevOps for SBOMs as they do with all their other application security testing tooling.

“Without automation and standardization, SBOMs will be out of date and ineffective.”
—Matt Rose

*** This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by Jai Vijayan. Read the original post at: https://www.reversinglabs.com/blog/5-best-practices-sboms-cicd