Getty Images/iStockphoto
SBOMs and security: What IT and DevOps need to know
By integrating software bill of materials creation into the software development lifecycle, IT and DevOps teams can build more secure and maintainable applications.
As digital technology and the pace of development advance rapidly, software projects have become more complex. Today's applications often include code and dependencies originating from a variety of sources, including commercial, open source and other third-party components.
Using software components from multiple sources helps DevOps teams create and deploy software more efficiently while reducing costs and enhancing scalability in response to demand. However, these extensive networks of external dependencies also create an opportunity for malicious actors to exploit vulnerabilities.
The Synopsys annual report "Open Source Security and Risk Analysis," which analyzed codebases for vulnerabilities and license conflicts, found that 96% of roughly 1,700 scanned codebases contained open source components. But although many applications rely on open source libraries, that code might not be completely trustworthy.
To ensure security, it's essential to have a comprehensive list of all code libraries, components and dependencies used in developing software projects. This comprehensive inventory, known as a software bill of materials (SBOM), has become a key element of the secure software development lifecycle.
Defining an SBOM and its typical components
An SBOM is a list of all code components used during the development and delivery of a software project.
The term software bill of materials derives from the bills of materials used by traditional manufacturers, which list all physical raw materials and other assembly components needed to create an end product. It was imported into the IT industry to describe the software dependencies used during the development process.
SBOMs have gained significant attention recently due to the rise of supply chain attacks, such as the well-known SolarWinds hack, and the increased complexity of modern software projects. In the United States, the White House issued an executive order requiring software vendors that sell products to the federal government to attest to the security of their software, a process likely to involve providing a detailed SBOM. Because this practice is beginning to enter the commercial sector, SBOMs are likely to become a must for all software products.
An SBOM typically includes the following information about each software component:
- Name, release date and version number.
- Supplier name and contact information.
- Transitive dependencies.
- Licensing information.
- List of associated known security vulnerabilities and their mitigations.
SBOM reports can be created either manually, by the teams involved in the software development process, or automatically, using a software generation tool. Reports should be in a machine-readable format -- such as JSON, CSV, SPDX or RDF -- to simplify the process of analyzing their contents using other automation tools.
How does SBOM creation fit into a DevSecOps workflow?
Integrating SBOM creation into IT and DevOps workflows is essential to ensure software is secure, resilient and compliant with relevant regulatory requirements related to software security and licensing.
The SBOM process can be integrated into the DevSecOps lifecycle at several stages:
- Development. Developers should start creating an SBOM in the early stages of the development process, before the application is deployed. This ensures the development team tracks all software components used in the project, identifies security vulnerabilities, and takes appropriate action to secure the code or remove compromised components.
- CI/CD. DevOps teams can integrate SBOM creation into their CI/CD pipelines to automatically generate a list of all open source or third-party dependencies and code. The generated SBOM enables DevOps teams to detect vulnerable components before deploying the application.
- Testing. In the software testing stage, the security team can contribute to the SBOM by identifying the most critical components in the software supply chain. This enables DevOps teams to dedicate more time to ensuring the security of these components before deployment.
Tools used to generate SBOMs
DevOps teams can choose from a wide range of tools to generate an SBOM. The following are some of the most popular open source options:
- CycloneDX Maven plugin. This Java plugin can generate an SBOM for a package or an entire software project.
- The SBOM tool. This command-line tool, which can be integrated into CI/CD pipelines, runs on macOS, Linux and Windows and generates SBOMs compatible with the SPDX 2.2 specification.
- Syft. This command-line tool and library generates SBOMs from container images and file systems.
- SPDX SBOM Generator. This tool generates SPDX-compatible SBOMs from package managers or build systems. It can discover the relationships between components and identify each component's licensing and compliance information.
What are the benefits of SBOMs for security?
Although SBOMs cannot directly prevent cyber attacks on IT systems, they provide various benefits to DevOps teams that can mitigate potential attack vectors.
More efficient threat detection and response
SBOMs improve security by providing full visibility into all components used in the software project. This enables the development team to track security vulnerabilities in any components in real time and act instantly to address and mitigate the risk before threat actors can exploit it.
This, in turn, accelerates incident response. An SBOM helps IT teams quickly identify compromised components in the event of a security incident, reducing the time needed to investigate and remediate the security issue.
Reduced software supply chain security risk
SBOMs enhance software supply chain transparency by providing insight into all software components, whether they originated inside or outside the organization. This helps IT teams detect signs of a software supply chain attack early on.
Incident response teams can use SBOMs to identify compromised software components that might have been introduced during a supply chain attack. If a compromised component is found within the software product, the development team can then work to patch or fix the issue. This proactive approach can prevent potential security breaches and ensure the integrity of the software.
Compliance with industry, government and licensing requirements
SBOMs can also support technical teams in meeting their compliance obligations in an increasingly tight global legislative landscape. New and evolving security regulations require software vendors to meet strict requirements to protect users' personal information.
For example, industry standards such as the Payment Card Industry Data Security Standard and HIPAA set restrictions on using certain software components, and third-party vendors sometimes require specific terms to use their components in a particular application. SBOMs let developers and IT teams track every component's use to ensure it meets these licensing and usage terms, avoiding legal and financial penalties.
Better communication across DevSecOps teams
SBOMs can also improve collaboration and communication among all parties involved in a software project, including developers, security and IT ops teams, and other departments.
Maintaining a comprehensive inventory of all the code components used in an application enables IT, security and DevOps teams to monitor for newly discovered vulnerabilities in any components and act to fix them before they can be exploited by threat actors. SBOMs facilitate informed discussions by providing a shared vocabulary to discuss software components' vulnerabilities and functional issues within the software project.
