Although it might seem premature to discuss the future of the software bill of materials (SBOM) before they have even gained full use and acceptance in the industry. However, the future of the SBOM is intertwined with the maturity of software security practices and risk management for software reuse and acquisitions. If the industry is going to take software supply chain security seriously, the SBOM plays an integral role and we need to plan out how the evolution takes place.
Current Usage
The concept of an SBOM, as covered in a previous post (What Is an SBOM?) has been around for some time. However, its use in software security practice in organizations is in its infancy. Although current usage is just gaining traction, early adopters are already using SBOMs internally, as part of their due diligence of acquired and open source software. Fewer are producing SBOMs to disclose to their customers (so far, that will change!). Common use cases today include the following:
Due diligence: Software composition analysis isn’t a new process but has traditionally been done for due diligence when acquiring intellectual property through merger or acquisitions. In these cases, the emphasis was on software licensing, however, this emphasis has shifted to include security vulnerabilities and dependency disclosure. It is likely that SBOMs are strictly internal for audits and investigation.
Auditing external dependencies: As software supply chain security becomes part of regular security practice, SBOMs play a role in audits of external dependencies. Developers are looking for unknown dependencies used in open source or legacy software developed internally. SBOMs are the “official” record of these audits and associated vulnerability reports are used as inputs into risk management.
Risk management: Early adopter organizations are including software supply chain risks into their management framework. SBOMs are used to numerate the security risks in reused software which is then “plugged in” to their existing vulnerability management system.
Interchanging SBOMs
Automation and integration into development pipelines is essential for widespread use of SBOM and software composition analysis tools. Ideally, an SBOM is packaged with product delivery, whether binary or source format, and made available to download via a trusted site.
Organizations buying or reusing software need SBOM files in compatible formats to make interchange easy. This implies the need for a standardized format which makes interoperability and tool compatibility easier. There are several emerging standards for SBOM interchange such as Software Identification (SWID), Software Package Data Exchange (SPDX) and CycloneDX.
What still needs to be done
There are still roadblocks to widespread use of SBOMs in commercial software and open source communities. Open source projects may not be motivated to supply an SBOM and maintaining it would require extra work and support. Commercial software vendors face the same issues but are also concerned about revealing too much of their internals to the public. In addition, there is general hesitation for any developer or company to exposing vulnerabilities or outdated, unpatched dependencies.
The recent cybersecurity Executive Order is a major push needed to get the ball rolling on SBOM adoption. The federal government is a large consumer of software and their expectation of SBOM disclosure from suppliers will push adoption to many vendors. As more organizations realize the value of software supply chain security risk management, they will insist their suppliers do the same. The goal is to have SBOM generation be a normal output from software development and a standard requirement for software purchasing. Hopefully, the open source community follows along as well.
The Future for the SBOM
The future of the SBOM is in the hands of the software industry and the adoption of increased scrutiny of reused and purchased software. Supply chain attacks are now in the headlines which have highlighted a lack of emphasis in security practices across the industry. Primarily is the fact that 80% of software dependencies in software are never updated. Old, insecure versions of software abound in enterprise, desktop and embedded applications. Improvements have to be made and the SBOM is the key artifact.
As software organizations and the entire industry matures, adoption of Agile, continuous processes and DevSecOps grows, so too will the adoption of supply chain security management. The future is bright for the SBOM in several ways:
Growing adoption: Adoption, at least within the federal government sphere, is inevitable. Since most large enterprise software vendors deal with the government, adoption in the non-government space is likely to follow. In terms of embedded systems, adoption is likely to follow industry safety and security standards.
Standards integration: Software security standards are very much focused on software development rather than software acquisition, use and reuse. As these standards evolve, they will include software supply chain security in greater detail. Standards are already in place for SBOM file interchangeability, such as CycloneDX. The next step are the details on how software organizations integrate the SBOM into their practice and what standards bodies expect in terms of documentation and reporting.
Common practices: Alongside industry standards, best practices will emerge on software supply chain security. SBOM interchange between organizations will be commonplace and usage will be part of standard development practices.
Industry expectations: The major driving force for SBOM adoption is the expectation that software developers disclose their dependencies and vulnerabilities and that buyers and users insist that this information be part of any software acquisition. This is the expectation the US federal government is pushing for and, hopefully, this becomes normal across the industry. When software developers release and deploy software, an SBOM is released at the same time in an industry standard format. Software users, developers and buyers will come to expect the SBOM and use it in their own risk management system. In turn, software developers use the accumulated information in their SBOM for disclosure and so on, throughout the entire supply chain.
Automation, interoperability, and tool support: Automation is key to reducing the overhead and manual steps involved in consuming and creating SBOMs. SBOMs need to be in standard digital formats that interchangeable between different tools and tool vendors. In addition, tools are need to perform software composition analysis to create SBOMs in the first place. These tools need to work with application lifecycle management tools (ALM), risk management and vulnerability management tools.
Summary
The use of SBOMs has evolved over time but focus on software supply chain security is relatively new and is just gaining momentum. The future of SBOM usage, disclosure, sharing and consumption is very much in the hands of the industry. The US federal government is acting as a catalyst to make the SBOM an essential product of software development.
The future of SBOMs includes growing adoption beyond the US federal government to the point where producing SBOMs is common practice for developers. Software users, re-users and consumers will expect an SBOM for every software product or open source library they use. Automation is the key to success as generating SBOMs, risk management and cataloguing is too consuming for manual processes. Interoperability and vendor cross-compatibility will enhance adoption further.
Want to Generate an SBOM Today?
With CodeSentry from GrammaTech, there is no need to wait for your software vendor to provide you with an SBOM. By analyzing binaries of commercial off-the-shelf (COTS) software, CodeSentry automates the SBOM process—producing a report identifying the open source components and detecting vulnerabilities in the software. Try CodeSentry today.
{{cta(‘553adc0d-058d-44f1-a9f6-b6fa00b959b0’)}}
