Software Bill of Material (SBOM) tools have come sharply into focus as a foundational component of any Software Supply Chain Security (SSCS) strategy, spurred on by the U.S. Executive Order to improve the security of the software supply chain. This was in response to a number of highly visible attacks on the software supply chain of some well knows software products and services, such as SolarWinds in 2020, as well as compromised open-source code and other backdoors embedded in routine maintenance updates. As part of the overall enhancement to SSCS, the Executive Order specifically calls out the documentation of a Software Bill of Materials (SBOM) for each software product. An SBOM creates a machine-readable inventory of the software components that make up a given software product. Software products are often a mix of custom-developed code leveraging open source and other commercially available software components, which DevSecOps should maintain and monitor. Having a Bill of Materials is nothing new in the traditional Supply Chain Management (SCM) process, and it shouldn’t be any surprise and makes perfect sense to apply this same concept to software.
Transparency benefits all stakeholders in the software supply chain
Transparency in the software supply chain benefits all stakeholders, from software suppliers to the software products' consumers and the providers in between, such as Managed Service Providers (MSP). It helps the software supplier to have a clear understanding of what software components make up their software product. It can also assist in monitoring software risks in their DevOps pipeline and prove software competency in case of company acquisitions or mergers. Suppliers of software products need to be assured that the software provided as an MSP is secure and can meet regulatory compliance requirements. Software consumers want to know that the software they use won't make them a target of a software attack.
Microsoft makes its own SBOM tool publicly available
Recently, Microsoft contributed its own internally used Salus tool for generating SBOMs to open source, which is publicly available on GitHub – a Microsoft company. The GitHub SBOM project page describes the tool as being enterprise-ready, highly scalable, and working across platforms including Windows, Linux, and Mac, which can be integrated into build workflows. Another benefit of the tool is that it’s Software Package Data eXchange (SPDX) 2.2 compatible, which is essential for companies supplying U.S. government software given its SBOM format requirements. Having an enterprise grade SBOM freely available should make it easier to meet the SSCS bar that is being raised leaving little excuse for organizations from taking a step in this direction.
Don’t stop at SBOM, take the next step in the SSCS process
Inventorying all of the pieces in a software product is a good and essential part of SSCS, but It should not stop there. For example, security must be put into place on the source control management (SCM) system and associated software repositories to ensure source integrity. Software code and other artifacts also need to be scanned for vulnerabilities. The build integrity processes must verify the build artifact's provenance and that the code has been signed and validated to detect tampering. Container artifacts such as Docker images must also be checked for vulnerabilities and compliance issues. Other vulnerability and misconfiguration scans, such as API scans, can occur along the Continuous Integration (CI) and Continuous Deployment (CD) pipeline. In short, when securing the Software Supply Chain, the journey starts at the security and privacy by design phase when creating the software system architecture and coding of the design begins and continues throughout software deployment and lifecycle.