Introduction to Software Supply Chain Security: Dependency Management and SBOM Utilization

Introduction

In recent years, the use of open-source software (OSS) has become indispensable in software development. As demonstrated by incidents such as the Apache Log4j vulnerability (CVE-2021-44228) and the SolarWinds supply chain attack, the security of dependencies acquired externally, in addition to the code developed in-house, can significantly impact the overall safety of products. This realization has led to a surge in focus on Software Supply Chain Security.

This article provides a step-by-step explanation of essentials, ranging from the basics of dependency management to the generation and utilization of a Software Bill of Materials (SBOM), as well as practical security measures. The goal is to offer developers and security engineers actionable insights that can be immediately applied to their CI/CD pipelines.

What Is Software Supply Chain Security?

The Reality of Supply Chain Attacks

Software supply chain attacks involve compromising trusted third-party components or tools during the development process, leading to widespread harm to customers and systems. For instance, in the 2021 Codecov breach, attackers gained unauthorized access to Codecov’s CI/CD environment, stealing environment variables and credentials sent by users through scripts. This attack went beyond affecting Codecov’s direct customers, impacting end-users as well.

Why Is It Important Now?

Traditional security measures have primarily focused on the applications and infrastructure managed by organizations themselves. However, modern software typically includes hundreds to thousands of dependencies, many of which are sourced from external repositories beyond direct control. Regulations like the U.S. Executive Order 14028 and the European Cyber Resilience Act (CRA) are also moving towards legally mandating supply chain security measures. As a result, the generation and sharing of SBOMs, along with continuous vulnerability scanning of dependencies, are rapidly becoming industry standards.

Basics of Dependency Management

Types of Dependencies and Their Risks

Dependencies can be broadly categorized into two types:

• Direct Dependencies: Libraries or packages explicitly declared and directly utilized by a project. For example, npm install express installs the Express library.
• Transitive Dependencies: Libraries used internally by direct dependencies. These are often unknowingly incorporated by developers and can become blind spots for vulnerabilities.

Key risks include:

1. Known Vulnerabilities: Dependencies containing publicly disclosed vulnerabilities, managed via the Common Vulnerabilities and Exposures (CVE) database.
2. Malicious Packages: Cases where malware masquerades as legitimate packages through techniques like typosquatting or brand hijacking.
3. Abandonware: Libraries that have not been updated for prolonged periods, leaving newly discovered vulnerabilities unaddressed.

Best Practices for Dependency Management

1. Utilizing Lock Files

Lock files like package-lock.json (npm), yarn.lock (Yarn), Gemfile.lock (Ruby), and Cargo.lock (Rust) fix the versions of installed packages, ensuring the same dependency tree is replicated across development, CI, and production environments. Including lock files in version control systems and reviewing changes during code reviews is highly recommended.

2. Regularly Updating Dependencies

Frequent updates to dependencies can address vulnerabilities present in older versions. Tools like Dependabot (GitHub) and Renovate (Mend) can automate updates by proposing them as pull requests. However, compatibility and integration tests must be conducted during updates to identify breaking changes in advance.

3. Principle of Least Privilege

Only introduce essential dependencies. Developers should avoid indiscriminately installing packages and instead select libraries that meet minimum functional requirements. For example, if only an HTTP client library is needed, avoid incorporating a full-stack web framework.

Fundamentals of SBOM (Software Bill of Materials)

What Is SBOM?

An SBOM is a document describing all components of software, including their versions, license information, and dependency relationships, in a machine-readable format. Widely adopted standard formats include SPDX (Software Package Data Exchange) and CycloneDX (Cyclone Data Exchange).

Key applications of SBOM include:

• Vulnerability Management: By cross-referencing components listed in SBOM with public vulnerability databases (e.g., NVD, Exploit-DB), affected components can be identified.
• License Management: Centralized documentation of component licenses to assess legal risks.
• Incident Response: Quickly determine which products are affected by critical vulnerabilities, such as those in Log4j.

How to Generate SBOM

SBOM generation should ideally occur automatically during the build process. Below are major tools used for this purpose:

• Syft (Anchore): A CLI tool for generating SBOMs from container images or file systems. Supports CycloneDX and SPDX formats, with JSON or text outputs.
• CycloneDX Generator: Offers plugins for major package managers like npm, Maven, NuGet, and Go modules. These can be integrated into build tools to generate SBOMs during every build.
• SPDX Tools: A suite of tools for generating and validating SPDX-compliant SBOMs. Available in Java and Python implementations.

Automating SBOM generation within the CI/CD pipeline is highly recommended. Below is an example of using GitHub Actions to generate an SBOM with Syft:

name: Generate SBOM  
on:  
 push:  
   branches: [ main ]  
jobs:  
 sbom:  
   runs-on: ubuntu-latest  
   steps:  
     - uses: actions/checkout@v3  
     - name: Generate SBOM with Syft  
       uses: anchore/sbom-action@v0  
       with:  
         path: ./  
         format: cyclonedx-json  
         output-file: sbom.cdx.json  
     - name: Upload SBOM as artifact  
       uses: actions/upload-artifact@v3  
       with:  
         name: sbom  
         path: sbom.cdx.json  

This workflow generates an SBOM for each push and saves it as an artifact. The generated SBOM can be used for vulnerability scanning and compliance checks.

Utilizing SBOM

Continuous Vulnerability Scanning

Vulnerability scanning based on SBOM forms the core of dependency security management. Tools like Grype (Anchore), Trivy (Aqua Security), and Snyk CLI can scan SBOM files against known vulnerability databases and report affected components.

Integrating scanning into the CI/CD pipeline ensures that code containing vulnerabilities is blocked from being deployed in production. Regular scans (e.g., nightly jobs) can monitor existing systems for potential impacts from newly disclosed vulnerabilities.

Governance Through Policies

Combining SBOMs with policy engines enables organizations to automatically block the use of unauthorized components or vulnerable versions. For instance, policies can include:

• Failing builds that include components with Critical vulnerabilities.
• Prohibiting the use of components with GPL licenses.
• Triggering alerts if specific packages (e.g., outdated versions of Log4j) are included.

These policies can be implemented using generic policy engines like Open Policy Agent (OPA) or Kyverno. Dedicated security platforms such as Snyk, Dependency-Track, and Mend offer GUI-based policy configuration and seamless CI integration.

Accelerating Incident Response

When a critical vulnerability is discovered in a component, having an SBOM allows organizations to quickly identify affected products. For example, during the disclosure of the Log4j vulnerability, organizations without SBOMs had to manually investigate all projects, whereas those with SBOMs could simply query their SBOM databases for affected products and versions.

Effective SBOM management goes beyond generation—it involves storing SBOMs in searchable databases, linking them to product releases, and maintaining version control. Dependency-Track is an open-source platform specializing in SBOM management, offering functionalities like SBOM uploading, vulnerability analysis, and policy enforcement in one place.

A Comprehensive Approach to Security

A Step-by-Step Framework for Supply Chain Security

A phased approach is recommended for implementing supply chain security measures:

1. Discover: Visualize all project dependencies, including archived legacy projects and software assets.
2. Assess: Evaluate vulnerabilities, licenses, and maintenance status for each dependency. Prioritize and address high-risk items first.
3. Remediate: Update packages with vulnerabilities, including transitive dependencies. If updates are challenging, consider alternative libraries or workarounds.
4. Monitor: Continuously scan CI/CD pipelines and production environments for new vulnerabilities or changes. Regularly regenerate SBOMs and track differences across versions.

Example Toolchain Setup

Here is an example toolchain:

• SBOM Generation: Syft (automated during builds)
• Vulnerability Scanning: Grype (used in CI with SBOM input)
• SBOM Management and Policy Enforcement: Dependency-Track (upload generated SBOMs)
• Dependency Updates: Renovate (creates regular pull requests)
• Container Image Scanning: Trivy (scans entire container images)

Combining these tools ensures security checks at every stage of the development process. However, implementing tools is just the first step; designing workflows that help teams understand results and respond appropriately is crucial.

Future Outlook for Supply Chain Security

Trends in Regulation and Standardization

U.S. Executive Order 14028 has effectively mandated SBOMs for software sold to the federal government. Similarly, the European Cyber Resilience Act (CRA) imposes security requirements on hardware and software products, including SBOM maintenance and disclosure. In Japan, the Cabinet Cybersecurity Center (NISC) is drafting guidelines on software supply chain security. These regulations are likely to become the de facto standard in the global software market.

Sigstore and the Evolution of Code Signing

Sigstore, a public key infrastructure (PKI) initiative supported by organizations like Red Hat, Google, and Purdue University, is gaining attention as a mechanism to ensure the authenticity of dependencies. By signing software artifacts during the build process and verifying the signatures upon use, Sigstore can detect tampering in the supply chain. Integration with GitHub Actions and Sigstore’s CLI tool, Cosign, is rapidly being improved.

Editorial Opinion

Key Evaluation Metrics

In the context of software supply chain security measures, the editorial team emphasizes three key metrics. First is the “depth of automation.” Manual dependency management is impractical, making comprehensive integration into CI/CD pipelines essential. Second is “breadth of visibility,” as tools must cover both direct and transitive dependencies. Third is “community engagement and support,” as the frequency of updates to vulnerability databases and the speed of bug fixes are critical for practical application.

Pitfalls in Implementation

Many organizations tend to generate SBOMs but fail to manage or utilize them effectively afterward. SBOMs should be treated as part of a continuous process, not as a one-time task. Post-generation activities like vulnerability scans, policy enforcement, and regular regeneration are essential. Legacy projects without lock files also pose challenges in recreating accurate dependency trees, often triggering numerous warnings during initial scans. Prioritizing and gradually improving such projects is a practical strategy. Concerns about long-term lock-in to specific SBOM formats (e.g., SPDX vs. CycloneDX) are often overstated, as modern tools support both formats and offer conversion options.

Future Directions

Over the next 1–3 years, software supply chain security is expected to evolve in the following directions:

1. SBOM generation will become a standard feature in build processes, with native support from language package managers and build tools.
2. AI-driven anomaly detection will gain traction, identifying malicious packages or attack patterns based on changes in dependency behavior.
3. Regulatory compliance will become a baseline for companies, with supply chain security investments increasingly seen as a source of competitive advantage.

Establishing robust SBOM generation and management processes now will prepare organizations for these changes, ensuring long-term security and compliance.

References

• National Institute of Standards and Technology (NIST). “Software Supply Chain Security Guidance.” https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security
• SPDX. “SPDX Specification.” https://spdx.dev/specifications/
• OWASP. “Software Supply Chain Security.” https://owasp.org/www-project-software-supply-chain-security/
• Anchore. “Syft – Generate SBOM.” https://github.com/anchore/syft
• Aqua Security. “Trivy – Vulnerability Scanner.” https://github.com/aquasecurity/trivy
• Dependency-Track. “Dependency-Track Project.” https://dependencytrack.org/
• Sigstore. “Sigstore – Software Signing for Everybody.” https://www.sigstore.dev/