SBOMs are critical to software supply chain security. But they’re also just the first step in your journey through the software supply chain. Here’s what you need to focus on for a holistic approach to security across the entire software development pipeline.
The 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 SolarWinds attack.
An SBOM can inform a user of the third-party software components they are using and help find and mitigate vulnerabilities after they are discovered. However, organizations must recognize that SBOMs alone cannot adequately protect their software supply chains.
Henry Young, policy director of BSA, an international software advocacy group, kept in a assignment on the organization’s website that an SBOM will not address most of the day-to-day cyber risks an organization faces. For example, he pointed out that an SBOM will have limited value in making procurement decisions for a number of reasons. Chief among them is that vendors will update SBOMs so frequently that the user’s SBOM will likely be out of date by the time a purchase decision is made.
However, Young said an SBOM will significantly improve an organization’s response and recovery from a cyber incident by accelerating an organization’s determination of whether it is using software with a known vulnerability and whether that vulnerability is exploitable.
Gartner Analyst Mark Driver Recently written in an Emerging Tech report on SBOMs:
“SBOMs are not a panacea. Their usefulness depends on the processes and tools implemented to process, analyze and exploit the information they contain.
—Mark the driver
In the report, which noted that demand for SBOM would grow from 5% today to 60% in 2025, Drive wrote that aOther tools and techniques, such as software composition analysis and code signing, were also “necessary elements of a comprehensive software supply chain management effort.”
Here’s what you need to know about SBOMs and the next steps required for your software supply chain journey.
Binary analysis enables deeper visibility
While the inventory of software components that an SBOM can provide to an organization is a critical part of software supply chain security, more will need to be done to validate these components.
Richard Hilldirector of IAM Research at the analyst firm KuppingerCole, recommended Ensure source code integrity by implementing security on the source control management system and associated software repositories.
Software code and other artifacts should be scanned for vulnerabilities, he continued. To guard against tampering, build integrity processes should verify the provenance of build artifacts and check code to see if it has been signed and validated. Container artifacts, such as Docker images, should be reviewed for vulnerabilities and compliance issues. Other types of scans, such as API scans, should happen in the CI/CD pipeline, he added.
In addition to obtaining SBOMs for the software they use, the Sustainable Security Framework Working Group has provided recent comprehensive orientations to software teams, recommending organizations to perform binary analysis and software composition analysis (SCA). Third-party software, sometimes delivered in binary format, is like a black box for the engineer or organization integrating it, the panel explains. The software may not be actively maintained and may have security weaknesses or vulnerabilities.
Binary analysis and software composition analysis (SCA) tools can often detect unknown files and open source components contained in binary packages, identifying security weaknesses associated with these components without the need for source code, a explained the panel.
These activities are highly recommended to verify the integrity of third-party software, he added. Additionally, he continued, the output can be compared to the SBOM, or source codes provided by the third party, to verify the vendor’s SBOM.
Building from SBOMs to assess risk
An SBOM can give an organization a understand the composition of a productbut for a better understanding of the risks it poses, other technologies are needed, such as contextual analysis and Vulnerability Operability exchange ratios (VEX). These technologies allow an organization to assess the exploitability of a vulnerability.
Contextual analysis identifies and prioritizes vulnerabilities in digital systems. It goes far beyond the analysis of software components, taking into account hardware architecture, operating system configurations, encryption mechanisms, keys, hardening mechanisms, control flow and API in its assessment of the impact of a vulnerability on a system.
SBOMs inform an organization about the ingredients of a software package, while context analysis adds meaning to the process. This allows an organization to get a more accurate picture of the risk it faces so that it doesn’t waste time addressing non-issues and can spend more time on the issues that matter.
VEX reports can complement an SBOM. They allow a software vendor or other preparers to present their assessment of the vulnerabilities they have found in a product. It also seeks to separate non-threatening flaws from those that require priority attention.
A VEX report does not provide the type of detailed information produced by a background scan, but when used in conjunction with an SBOM it can give an organization a better view of the true exploitability of the vulnerabilities they find and help streamline the remediation process.
Community involvement is essential for supply chain security
Software nowadays not only relies on third-party dependencies, but also on the cloud. This is why organizations may also want to look beyond SBOMs to “SaaSBOMs”.
Walter H. Haydock, a non-resident scholarship holder to Center for Security and Emerging Technology and an author Deploy securely, and Chris Hughes, co-founder and CISO at aquia, written in an article on CSO Online which, with near ubiquity, has shifted to software as a service (SaaS), ambiguity with what’s in an SBOM at any given time “presents a barrier to 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 how to develop them for vendor-managed deployment models such as the software as a service (SaaS).”
—Walter H. Haydock and Chris Hughes
Such an extension of the SBOM concept will include information about the infrastructure as a service or platform as a service of a cloud service provider on which an organization’s software runs. Building a SaaSBOM also requires taking an inventory of APIs. This can give an organization a head start on future SBOMs, as such an inventory can potentially be added to the minimum requirements of a standard SBOM.
While an SBOM is valuable for giving an organization insight into the third-party dependencies used by its software, it can gain even more visibility by participating in open source projects that maintain those dependencies. “You must actively contribute to projects that are essential to the success of your applications and your business. You will know exactly what is being used and what is notdown to the level of unique functions deep in the stack of open source projects you depend on,” advised Henrik Plate, security researcher at Endor Labs, an addiction management company.
Ed Moyle, a member of ISACA’s Emerging Trends Task Force and director of systems and software security at Drake Software, said it’s important to understand which open source projects you depend on and the health relative to these projects. “In cases where the health of a project is deteriorating, consider helping out. Many open source projects lack resources. If you are a business entity and dependent on a certain 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 in value and don’t contribute back. But really, it’s a community. Be part of this community and you can actively help keep these projects healthy. The stronger and healthier the community, the more likely it is to be able to respond quickly, apply resources to code audits and verification.
Why next steps in supply chain security are critical
Hill points out in its report that the modern software development pipeline requires an end-to-end security approach.
“[When] Securing the software supply chain, the journey begins at the Security and Privacy by Design phase when software system architecture creation and design coding begins and continues throughout the deployment and cycle life of the software.
*** This is a syndicated blog from the Security Bloggers Network of ReversingLabs Blog Written by John P. Mello Jr.. Read the original post at: https://blog.reversinglabs.com/blog/sbom-critical-but-first-step-software-supply-chain-security