SBOMs are key, but they are only the first step in your software supply chain security journey. Here's what you need to focus on for a comprehensive approach to security across the entire software development pipeline.
Increased use of third-party code and the risks it poses to software supply chains has fueled interest in software bills of materials (SBOM). In addition, the federal government has made software supply chain security a priority following the SolarWinds attack.
An SBOM can inform a user about the third-party components in the software they're using and make it easier to find and mitigate vulnerabilities after they're discovered. However, organizations need to recognize that SBOMs alone cannot adequately protect their software supply chains.
Henry Young, policy director for the BSA, an international software advocacy group, maintained in a posting at the organization's website that an SBOM will not address most of the daily cyber risks confronting an organization. For example, he pointed out an SBOM will have limited value in making procurement decisions for a number of reasons. Chief among them is that vendors will be updating SBOMs so frequently, that the user's SBOM will likely be out of date by the time a procurement decision is made.
However, Young said that an SBOM will significantly improve an organization’s response to and recovery from a cyber incident by expediting an organization’s determination about whether it is using software with a known vulnerability, and if that vulnerability is exploitable.
Gartner Analyst Mark Driver recently wrote in an Emerging Tech report on SBOMs:
"SBOMs are not a panacea. They are only as useful as the processes and tools implemented to process, analyze, and leverage the information they contain."
—Mark Driver
In the report, which noted that demand for SBOMs would increase from 5% today to 60% in 2025, Drive wrote that additional tools and techniques, such as software composition analysis and code signing, were also "necessary elements of a complete software supply chain management effort."
Here's what you need to know about SBOMs—and the required next steps for your software supply chain journey.
[ Get a free SBOM and supply chain risk analysis report ]
Binary analysis allows deeper visibility
While the inventory of software components an SBOM can provide an organization is an essential part of software supply chain security, more will need to be done to validate those components.
Richard Hill, director of IAM Research at the analyst firm KuppingerCole, recommends ensuring source code integrity by putting security into place on the source control management system and on associated software repositories.
Software code and other artifacts need to be scanned for vulnerabilities, he continued. To guard against tampering, build integrity processes need to verify the provenance of build artifacts and check code to see if it has been signed and validated. Container artifacts, such as Docker images, also need to be scrutinized for vulnerabilities and compliance issues. Other types of scans, such as API scans, should occur in the CI/CD pipeline, he added.
In addition to obtaining SBOMs for software that they use, the Enduring Security Framework working group provided recent comprehensive guidance to software teams, recommending that organizations perform binary and software composition analysis (SCA) scans. Third-party software, sometimes delivered in binary format, is like a black box for the engineer or the organization who is integrating it, the panel explained. The software may not be actively maintained and may have security weaknesses or vulnerabilities.
Binary scanning and software composition analysis (SCA) tools can often detect unknown files and the open source components contained in binary packages, identifying the security weaknesses associated with these components without the need for source code, the panel explained.
Those activities are highly recommended to verify the integrity of the third-party software, it added. What's more, it continued, the output can be compared with the SBOM, or the source codes provided by the third party, to verify the vendor's SBOM.
Build out from SBOMs to assess risk
An SBOM can give an organization an understanding of the composition of a product, but for a deeper understanding of the risks posed by it, other technologies are needed, such as context-based analysis and Vulnerability Exploitability eXchange (VEX) reports. Those technologies allow an organization to assess the exploitability of a vulnerability.
Context-based analysis identifies and prioritizes vulnerabilities in digital systems. It goes far beyond analyzing just software components, accounting for hardware architecture, OS configurations, encryption mechanisms, keys, hardening mechanisms, control flow, and APIs in its assessment of a vulnerability's impact on a system.
SBOMs inform an organization about the ingredients in a software package, while context analysis adds meaning to the process. It allows an organization to get a more accurate picture of the risk it faces so it doesn't waste time tackling non-issues and so it can spend more time on issues that matter.
VEX reports can complement an SBOM. They allow a software supplier or other preparers to present their assessment of vulnerabilities they've found in a product. It, too, seeks to separate non-threatening flaws from those that need priority attention.
A VEX report doesn't provide the kind of in-depth information produced by context-based analysis, but when used in conjunction with an SBOM, it can give an organization a better view of the true exploitability of the vulnerabilities it finds and help streamline the remediation process.
Community participation is key for supply chain security
Software these days not only leans on third-party dependencies, but it also depends on the cloud. That's why organizations may also want to look beyond SBOMs to "SaaSBOMs".
Walter H. Haydock, a non-resident fellow at the Center for Security and Emerging Technology and an author at Deploy Securely, and Chris Hughes, co-founder and CISO at Aquia, wrote in an article on CSO Online that with nearly ubiquitous move to Software as a Service (SaaS), the ambiguity with what's in an SBOM at one point in time to the next "presents a hurdle toward the effective use of SBOMs as a risk management tool."
"In addition to a lack of answers as to what consumers will do with SBOMs once they receive them, it is even less clear as to how to develop them for vendor-managed deployment models such as software as a service (SaaS)."
—Walter H. Haydock and Chris Hughes
Such an expansion of the SBOM concept will include information on a cloud service provider's infrastructure-as-a-service (IaaS) or platform-as-a-service (PaaS) on which an organization's software runs. Building a so-called SaaSBOM also requires taking an inventory of APIs. That can give an organization a leg up on future SBOMs, since such an inventory may eventually be added to the minimum requirements for a standard SBOM.
Henrik Plate, a security researcher at Endor Labs, a dependency management company, said that SBOMs are valuable for giving organizations views into the third-party dependencies used by software, they can gain even more visibility by participating in the open source projects maintaining those dependencies.
"You should actively contribute to the projects that are key to the success of your applications and business. You'll know exactly what is used and what isn’t, down to the level of single functions deep down in the pile of open-source projects you depend on."
—Henrik Plate
Ed Moyle, a member of the ISACA Emerging Trends Working Group and systems and software security director at Drake Software, said it was important to understand what open source projects you're dependent on, and the relative health of those projects. "In cases where the health of a project is slipping, consider helping out. A lot of open source projects are starved for resources—if you're a commercial entity and you are dependent on a given project, consider ways to support the community and keep it healthy."
"People sometimes think of open source as a one-way value diode where they suck value out and don't contribute back. But really, it's a community. Be part of that community and you can actively help keep those projects healthy. The stronger and healthier the community is, the more likely they are to be able to respond quickly, to apply resources to code audits and vetting."
—Ed Moyle
An end-to-end software security approach is critical
Hill emphasizes in his report that a comprehensive security approach demands an end-to-end focus on software's development, engineering, release and full lifecycle.
"[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."
—Richard Hill
