The widespread availability of third-party and open source software has significantly accelerated modern software development. These technologies also pose a risk, because the external code used by a company has not gone through vital security review processes. A software bill of materials (SBOM) can help provide governance over these external components. An SBOM lists the libraries used by a piece of software and in some cases describes their vulnerability and license status.
SBOM-based governance is frequently required by regulators, customers, and internal legal/audit teams. This is due, in part, to the large number of high-profile cyber-attacks resulting from poor software supply chain management practices, as noted in our recent webinar, The Power of SBOMs: Securing the Software Supply Chain.
We've previously covered why SBOMs are essential for every organization and described the elements of an SBOM. In this blog post, we'll discuss strategies for incorporating SBOMs into your software development life cycle (SDLC).
SBOM generation during the design and build processes
The best approach for SBOM generation is to automate it as part of the continuous integration and continuous delivery (CI/CD) pipeline. This ensures an up-to-date SBOM is always produced whenever the code changes. It also allows you to set up release gates that check an SBOM for issues like unacceptable licenses or critical vulnerabilities.
Developers have several SBOM generator choices. Open source tools like CycloneDX and SPDX include ecosystem-specific build plugins that create SBOMs using processes tailored specifically for Go, Python, and many other programming languages. CycloneDX, developed by Open Worldwide Application Security Project (OWASP), supports more than 200 tools and numerous programming languages. It is designed specifically for cyber risk reduction. SPDX originated as a way to communicate license information for components used in software; SPDX has since expanded to also include vulnerability information.
Both formats are in active use and one format can generally be converted to the other. However, interoperability between formats is still an evolving capability. Conversion accuracy will depend on how the SBOM was generated and what tooling is used for the conversion.
Managing security and license risk during the QA phase
The Quality Assurance (QA) phase of the SDLC is a good time to perform checks that would interfere with development but are important for ensuring that published software meets company security and legal requirements. It can also serve as an important final check even when security and licensing is monitored in the build phase.
Audit and legal requirements generally only apply to published or released software, and SBOMs can be used to set up a "control gate" as part of the QA process. This control should scan the SBOM for known security vulnerabilities and check that there are no vulnerabilities that violate your organization’s policies. Similarly, software licenses should be checked to ensure that there are no licenses with unacceptable requirements and restrictions.
When performing these checks to satisfy audit or regulatory requirements, it is important to store an appropriate audit trail tracking inputs (e.g. SBOMs), results of scans, and timestamps / signatures / other evidence that can help establish the validity of the stored data. SBOMs provide a full historical record of what components were in each software version when they are stored as part of this audit log. This provides a record of what was known about the software at a given point in time, especially when coupled with scan results. Maintaining these records can help accelerate compliance reviews and audit processes.
Using SBOMs in production
After passing QA, software is generally cleared for release to production. SBOMs can serve a critical role in maintaining visibility and monitoring of production software assets. A best practice is to maintain an SBOM for any version of any piece of software that is still in use – whether in a company's own infrastructure or at a customer site.
With this record of which software is in production and what components are in that software, SBOM scanning / monitoring tools can be used to continuously monitor for vulnerabilities that affect production code. When vulnerabilities are discovered, the stored SBOMs help guide remediation efforts by showing which software versions are affected. This provides the information needed to guide remediation efforts and communications with customers when paired with information about where particular software versions are deployed.
Software versions running in a company's infrastructure can be patched or updated and remediation guidance can be sent to customers for software that is deployed on-premises at a customer site.
In cases where a newly discovered vulnerability does not apply to a particular product, the Vulnerability Exploitability eXchange (VEX) standard provides a way to notify customers that an application is not vulnerable. Storing these VEX records provides another type of record that is useful for audit purposes: it's a record of what was known about certain vulnerabilities at what time. This establishes a record of compliance when a company is subject to requirements on timely acknowledgment and remediation of vulnerabilities.
From compliance to competitive edge: The transformative power of SBOMs
Using SBOMs throughout the software development life cycle can provide new opportunities for companies to streamline their security and compliance workflows. SBOMs support critical record keeping and provide ongoing visibility into the current state of software assets and those assets' vulnerability and license status.
As more industries become subject to SBOM regulations, getting started with SBOMs now will help your organization stay ahead of these mandates and take a more thoughtful and intentional approach to compliance. Ultimately, well-designed SBOM-oriented development practices demonstrate foresight, reduce exposure to software liability, and streamline your SDLC.
