The software supply chain involves developing, maintaining and distributing software to end users. To enhance the functionality of the software being developed, developers frequently depend upon open-source components and libraries. These can be sourced from external vendors like Docker images or open-source projects and in-house providers.
But while third-party vendors are often critical to software functionality, they can also increase risk. A compromised software supply chain could lead to the distribution of malicious software, unauthorized access to sensitive data and potential disruptions to critical systems. As such, securing the software supply chain is crucial to ensure the integrity, confidentiality and availability of applications.
By implementing robust supply chain security practices, organizations can mitigate these risks and ensure the integrity and security of the software they deliver.
Software Bill of Materials Security
A secure software supply chain helps protect against malicious attacks, prevent financial losses, secure user data, ensure business continuity, comply with regulations, mitigate third-party risks and build trust with customers. A software bill of materials (SBOM) is a crucial part of this secure software supply chain.
An SBOM is a list of all the components and libraries that create an application or software. This security aims at identifying vulnerabilities in open-source components that developers often overlook.
SBOM security takes a more comprehensive approach to the software development process, from generating SBOM files for third-party components in the application stack and source code repositories to the continuous integration and continuous delivery (CI/CD) pipeline and container registries and runtime.
With enhanced transparency and vulnerability management, SBOM security aims to counteract potentially devastating cyberattacks. These attacks can result in the distribution of compromised software, unauthorized access, data breaches and system compromise.
Common SBOM Attack Scenarios
SBOM attacks fall into four major categories:
1. Dependency Confusion: The threat actors replace a legitimate software package with malicious code in the public repository. When developers inadvertently use malicious code in software applications, this can compromise the security of the product.
2. Supply Chain Tempering: The SBOM components of the product are analyzed and replaced with malicious content. This can occur at any stage of the software supply chain, such as during the development, build or distribution process. Users then install or activate the software with compromised components, leading to potential security risks.
3. Component Vulnerability Exploitation: Threat actors can compromise a vulnerable component of the SBOM file. A dependency with a known vulnerability can help attackers launch a targeted attack.
4. Trust Chain Attacks: The threat actors compromise trusted components listed in the SBOM update process. This can impact the software’s security and reliability.
Why Do We Need an SBOM in Supply Chain Security?
The rise of cyber threats in open-source components and third-party software is a major concern for supply chain security. SBOM security minimizes the risks that arise due to the use of vulnerable open-source software to develop applications and helps clients and customers of software products.
The Log4j vulnerability, also known as Log4Shell, is a critical security flaw discovered in the Apache Log4j library. This issue impacted applications and organizations all over the globe since Log4j is often integrated into third-party libraries.
Software vendors and open-source projects quickly released patches and updated versions of Log4j to address critical weaknesses. The Log4j vulnerability is categorized as a remote code execution (RCE) vulnerability, which means that an attacker can execute arbitrary code on a targeted system remotely.
Recent security breaches like Apache Log4j have led organizations that develop software to maintain an inventory, known as an SBOM file, of open-source and third-party packages, licenses, versions and patch statuses of vulnerable versions.
The SBOM standard is a unified structure or a generic schema of libraries, versions and other software compositions compatible with available tools, like vulnerability scanners, to identify an unpatched component.
There are two standards widely used by organizations: Software product data exchange (SPDX) and CycloneDX.
SPDX
The SPDX is a Linux-based international open standard (ISO/IEC 5962:2021) format for communicating the components, licenses, files and copyrights associated with a software package. The SDPX standard is available in the following formats: RDF, XLS, SPDX, YAML and JSON.
CycloneDX
CycloneDX is maintained by the Open Web Application Security (OWASP) foundation and is available in XML and JSON formats. It supports a range of development ecosystems and use cases and centers on automation, ease of adoption and SBOM enhancement throughout build pipelines.
Generating SBOMs
Syft is a command-line interface (CLI) tool by Anchore that generates SBOM files from container images or filesystems. Syft can generate an SBOM in any SPDX or CycloneDX format.
To generate a SBOM via Syft:
- Install the Syft tool from GitHub – https://github.com/anchore/syft
- Run the Syft tool on any Docker image; for example, Cytopia/dvwa vulnerable web app image to generate the SBOM file.
Figure 1. Generating SBOM in SPDX via Syft
Figure 2. Generating SBOM in CycloneDX via Syft
Figure 3. An SBOM created by Syft in CycloneDX format
Trivy can generate the SBOM in both the SPDX and CycloneDX formats.
Steps to generate an SBOM via Trivy:
- Install Trivy via the GitHub link – https://github.com/aquasecurity/trivy/discussions/2407.
- Run the Trivy tool on any Docker image. For example, Cytopia/dvwa vulnerable web app image to generate the SBOM file.
Figure 4. Generating SBOM in CycloneDX via Trivy
Figure 5. Generating SBOM in SPDX format via Trivy
Vulnerability Scanning With SBOM Files
Trivy can also be used to scan the container images, filesystems and Git repositories to identify vulnerabilities. It is designed to be used in continuous integration. Before pushing to a container registry or deploying an application, Trivy can scan local container images and other artifacts.
Figure 6. Trivy SBOM scan results
Grype is another vulnerability scanner by Anchore, which can identify vulnerabilities from container images and filesystems by scanning SBOM files.
Install the Grype tool via the link https://github.com/anchore/grype and perform the vulnerability scanning on the SBOM file generated by the Syft tool in either the CycloneDX or SPDX format.
Figure 6. Grype SBOM scan results
Note: The above screenshot displays the result of the vulnerability scanner Grype with input as an SBOM file in the CycloneDX format. The result of the scan displays the installed version of the software, vulnerability CVE, severity and fixed version, if available.
Best Practices for Securing the Software Supply Chain
Organizations should implement security measures to protect the integrity and security of their software supply chain and the associated SBOM data. Threat actors can leverage vulnerabilities in the software supply chain or exploit weaknesses in the SBOM inventory.
1. Secure Coding: Awareness among developers regarding secure coding guidelines can minimize the risk of introducing vulnerabilities during development.
2. Secure Build and Deployment: Secure build environments, secure distribution channels and strong authentication mechanisms can protect against unauthorized access and secure sensitive information.
3. Third-Party Management: SBOM scanning can help in evaluating the security of third-party components and libraries before integration into any software.
4. Continuous Monitoring and Incident Management: Implementation of continuous monitoring and detection mechanisms can identify potential threats and respond to incidents in a timely manner.
Use SBOMs to Improve Your Security
An SBOM provides a comprehensive inventory of software components and dependencies used in an application. It improves transparency, vulnerability management, risk mitigation, compliance and collaboration in the software supply chain.
By leveraging SBOMs, organizations can make informed decisions about software security, track and manage components effectively and enhance the overall security and integrity of their software applications.
