By Doug Dooley, COO, Data Theorem
The software supply chain has become increasingly complex and dynamic with the rise of cloud computing, open-source software, and third-party software components and APIs. Widespread damage can occur for organizations if third-party APIs, cloud services, SDKs, and open-source software have security flaws. As a result, software supply chain security has emerged as a critical concern for organizations across industries. Supply chain attacks have become more frequent, sophisticated, and devastating, as evidenced by high-profile incidents such as SolarWinds, Kaseya and Apache Log4j.
To address the growing challenge of software supply chain security, organizations have turned to leveraging software bill of materials (SBOMs). SBOMs are a standardized inventory of software components used in a particular product or system, including their versions, dependencies, and sources. SBOMs provide transparency and visibility into the software supply chain. They can be an effective approach for identifying and mitigating security risks, compliance issues, and operational challenges – assuming organizations have the right tools to fully benefit from SBOMs, including runtime discovery, in place.
SBOMs are not a new concept, but their adoption has accelerated in recent years due to a number of important factors, including the following Top Five.
First, regulatory agencies, such as the U.S. National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA), have been advocating for SBOMs as a best practice for software supply chain security. NIST has released a draft guidance document on SBOMs, and CISA has mandated SBOMs for federal contractors and subcontractors.
Second, industry initiatives, such as the Open Source Security Foundation (OpenSSF) and the Software Assurance Forum for Excellence in Code (SAFECode), have promoted SBOMs as a key element of software security. OpenSSF has launched a working group on SBOMs, and published the Open Source Software Security Mobilization Plan to improve the resiliency and security of open source software (OSS), including guidelines for SBOM management; while SAFECode has published a whitepaper on SBOMs.
Third, supply chain attacks have highlighted the need for SBOMs as a proactive and preventive measure. SBOMs can help organizations detect and respond to vulnerabilities, malicious code, and unauthorized changes in the software supply chain. SBOMs can also support incident response and recovery efforts by providing accurate and comprehensive information about the affected software components.
Fourth, customer demands and market pressures have influenced the adoption of SBOMs. Customers are increasingly aware of software supply chain risks and are asking for SBOMs as part of their procurement and evaluation processes. Some industries, such as healthcare and automotive, have mandated SBOMs for safety and liability reasons. SBOMs can also enhance brand reputation, customer trust, and competitive advantage for software vendors.
Fifth, technological advancements have facilitated the creation and consumption of SBOMs. The emergence of open standards, such as CycloneDX and SPDX, has enabled interoperability and integration of SBOMs across different tools and platforms. The development of automated tools, such as software composition analysis (SCA) and vulnerability scanners, has enabled the generation and validation of SBOMs in a timely and accurate manner. The integration of SBOMs with other security measures, such as identity and access management (IAM) and security information and event management (SIEM), has enabled an effective view of software supply chain security.
However, SBOMs are not a silver bullet for software supply chain security. SBOMs are only as good as the data they contain, and the quality of data can vary depending on the source and the method of collection, particularly around the application software stack of APIs, cloud services, and SDKs. SBOM inventory is constantly changing, and being able to leverage their up-to-date data requires more than a snapshot from traditional source code static analysis approaches, but rather continuous runtime analysis and dynamic inventory.
For example, common vendor management and software composition analysis (SCA) approaches often lack source code access for mobile, web, cloud, and commercial-off-the-shelf (COTS) software, as well as third-party API services.
Following a more effective approach, organizations can benefit from a full-stack attack surface management (ASM) software supply chain solution that delivers continuous third-party application asset discovery and dynamic tracking of third-party vendors. These newer approaches automatically categorize assets under known vendors, allow customers to add additional new vendors, curate individual assets under any vendor, and alert on increases in policy violations and high embed rates of third-party vendors within key applications. These automated capabilities allow vendor management teams to remedy supply chain security problems faster and easier, and much more accurately than older approaches.
It is important to note that SBOMs also require collaboration and communication among multiple stakeholders, including software vendors, suppliers, customers, and regulators. SBOMs may also pose some privacy and intellectual property concerns, since they can reveal information about the software components and their relationships.
Overall, organizations need to adopt a comprehensive and risk-based approach to software supply chain security, of which SBOMs and tools to best leverage their information are an important component. Organizations should establish policies and procedures for SBOM creation, management, and sharing, as well as for SBOM validation and verification. Organizations should also integrate SBOMs with other security measures and practices, such as threat modeling, penetration testing, and code review to best ensure the security of their software supply chains.
