Tag: SBOM

Supply chain attacks don’t just target your code—they target the code you depend on. High-profile breaches like SolarWinds and Log4Shell have exposed how vulnerable organizations are through third-party dependencies. To defend against these threats, you need more than just patch management: you need supply chain visibility, automated dependency scanning, and a robust Software Bill of Materials (SBOM) process.

Key Takeaways:

• Why supply chain security is a strategic necessity, not just a technical checkbox
• How automated dependency scanning uncovers hidden risks in your codebase
• What an SBOM is, how to generate one, and how it maps to compliance requirements
• Actionable examples using real-world tools for dependency analysis and SBOM generation
• Common mistakes in dependency management—and how to avoid them
• Checklists for auditing your own supply chain security practices

Why Supply Chain Security Matters

Modern software is assembled, not written from scratch. Most production codebases have thousands of direct and transitive dependencies—open-source libraries, third-party modules, container images, and even CI/CD plugins. Every one of these dependencies is a potential attack vector.

• According to Synopsys OSSRA 2024, 84% of codebases contain at least one known open-source vulnerability.
• CVE-2021-44228 (Log4Shell) affected millions of applications indirectly, as Log4j was embedded transitively in many Java projects.
• Attackers increasingly target the software supply chain: The OWASP Top 10 now highlights vulnerable and outdated components (A06:2021).

A single compromised dependency can enable attackers to:

• Inject malicious code (e.g., event-stream NPM attack, 2018)
• Exfiltrate secrets or sensitive data
• Sabotage build pipelines or deployment artifacts
• Trigger compliance failures (e.g., unlicensed or sanctioned packages)

Business impact: Supply chain attacks lead to regulatory fines, loss of customer trust, and prolonged incident response. The SolarWinds breach, for example, led to estimated damages exceeding $100 million and long-term reputational fallout.

Checklist: Is Your Organization at Risk?

• Do you know every open-source and third-party component in your production environment?
• Are you alerted to new vulnerabilities in dependencies after deployment?
• Can you trace a vulnerability from a CVE down to the affected asset in your inventory?

Understanding Dependency Scanning

Dependency scanning is the automated process of inspecting your codebase for known vulnerabilities in all direct and transitive dependencies. This is a cornerstone of supply chain security, providing both visibility and rapid detection of exploitable flaws.

How Dependency Scanning Works

• Analyzes package manifests (requirements.txt, package.json, pom.xml, etc.)
• Resolves the full dependency tree, including nested dependencies
• Cross-references dependencies against vulnerability databases (e.g., NVD, GitHub Advisory Database)
• Flags packages with known CVEs, outdated versions, or license compliance issues

Example: Scanning a Python Project with Safety

# requirements.txt
flask==2.2.2
requests==2.31.0
pyjwt==2.7.0

# Run Safety to scan for known vulnerabilities
pip install safety
safety check -r requirements.txt

This checks the listed dependencies for known vulnerabilities using Safety’s curated vulnerability database. If a CVE is found (e.g., CVE-2023-XXXX in pyjwt), it’s flagged with details and remediation advice.

Comparing Common Dependency Scanners

Tool	Supported Languages	CI/CD Integration	License/Cost	Notable Features
Safety	Python	Yes	Free/Paid	Offline DB, license checks
GitHub Dependabot	Python, JS, Java, etc.	Yes (GitHub Actions)	Free	Auto PRs, native to GitHub
Snyk	Multiple	Yes	Free/Paid	Policy controls, SBOM export
OWASP Dependency-Check	Java, .NET, JS, Python	Yes	Free	CVE mapping, HTML reports

Limitations

• Scanners only detect known vulnerabilities (CVE-based). They don’t detect zero-days or malicious code in new packages.
• False positives: Some flagged issues may not be exploitable in your specific context, but should still be reviewed.
• Transitive risk: Many vulnerabilities lurk in indirect dependencies that aren’t obvious from your top-level manifest.

Checklist: Effective Dependency Scanning

• Scan at every pull request and before releases
• Monitor new vulnerabilities post-deployment (e.g., via Snyk or Dependabot alerts)
• Document and triage exceptions with explicit risk acceptance

Building and Using an SBOM

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all components, libraries, and modules in a software artifact. The SBOM is now a compliance requirement for many regulated industries, and is central to CISA’s Secure Software Development Framework.

Key SBOM standards:

• CycloneDX: JSON/XML format, widely supported in open-source tools
• SPDX: Used in Linux Foundation projects

Example: Generating an SBOM with CycloneDX for a Python Project

# Install the CycloneDX Python tool
pip install cyclonedx-bom

# Generate SBOM from requirements.txt (CycloneDX JSON format)
cyclonedx-py requirements -i requirements.txt -o sbom.json

# View a snippet of the generated SBOM
cat sbom.json | jq '.components[0]'

This process outputs a detailed list of all packages, versions, hashes, and licenses. The SBOM can be used by security teams, auditors, or compliance officers to verify:

• Which components are present in a deployed artifact
• Whether any component has known vulnerabilities (when cross-referenced with CVE feeds)
• License obligations or export controls

Integrating SBOMs with Vulnerability Management

• Automate SBOM generation as part of your build pipeline (e.g., export from CI/CD on every release)
• Feed SBOMs into vulnerability management tools (e.g., Snyk, Anchore, or Trivy) for continuous monitoring
• Respond quickly to new CVEs by searching all SBOMs for affected components

Checklist: SBOM Best Practices

• Enforce SBOM generation and archiving for every release artifact
• Verify SBOM completeness (coverage of all components, not just direct dependencies)
• Share SBOMs with customers or regulators as required

Integrating Tools Into Your Pipeline

Securing your supply chain isn’t just about running a one-off scan. You need automated, repeatable checks that catch issues before they reach production. This means integrating dependency scanning and SBOM generation into your CI/CD pipeline.

Example: GitHub Actions Workflow for Dependency Scanning and SBOM

# .github/workflows/dependency-scanning.yml
name: Dependency Scanning & SBOM

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Set up Python and install dependencies
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install -r requirements.txt

      # Run Safety for dependency scanning
      - run: pip install safety
      - run: safety check -r requirements.txt

      # Generate SBOM with CycloneDX
      - run: pip install cyclonedx-bom
      - run: cyclonedx-py requirements -i requirements.txt -o sbom.json

      # Upload SBOM as an artifact
      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

This workflow guarantees that every commit is checked for vulnerable dependencies and that a fresh SBOM is produced for each build. Teams can then automate downstream processes (e.g., alerting, compliance archiving, or vulnerability triage) using these outputs.

Integrating with Other Systems

• Send scan results to Slack or email for real-time alerting
• Enforce policy gates (block merges if high-severity vulnerabilities exist)
• Use SBOMs to populate asset inventory in a CMDB or GRC tool

Checklist: Pipeline Integration

• Make scans mandatory for all new code, not just scheduled jobs
• Fail builds on high/critical vulnerabilities, optionally allow risk acceptance for lower severity
• Store SBOMs in a searchable, versioned repository

Common Pitfalls and Pro Tips

Even with automation, developers and security teams make predictable mistakes. Here are concrete examples—and how to avoid them.

Common Pitfalls

• Ignoring Transitive Dependencies: Many scanning tools only highlight direct dependencies by default. Always resolve the full tree. Example: A vulnerable urllib3 package may be included via requests, not listed in requirements.txt.
• “Works on My Machine” Syndrome: Developers may pin dependencies locally but forget to update lock files in source control. This leads to inconsistent builds and missed vulnerabilities.
• Suppressing Warnings Without Review: Some teams silence “noisy” alerts instead of investigating root causes. This can hide real risk, especially for components with infrequent updates.
• Stale SBOMs: Generating an SBOM once at release but not updating it after hotfixes, patching, or container rebuilds. Always regenerate SBOMs for every artifact version.
• Assuming Scanning Is Enough: Dependency scanning finds known issues, not malicious code. Malicious libraries or supply chain attacks that compromise package infrastructure (like typosquatting) may evade detection.

Pro Tips

• Use dependency locking (pip freeze, npm shrinkwrap, etc.) to ensure deterministic builds. This makes SBOMs accurate and repeatable.
• Layer tools: Run at least two different scanners (e.g., Safety and Snyk) to increase coverage and reduce false negatives.
• Automate notifications: Integrate alerts with ticketing systems (e.g., Jira) for immediate triage, not just email noise.
• Track dependency health: Prefer packages with active maintainers, recent commits, and a clear security policy. Deprecated or abandoned libraries are high risk.
• Monitor for newly disclosed CVEs in your deployed artifact’s SBOMs—don’t just scan before release and forget.

Checklist: Audit Your Supply Chain Security

• Are all dependencies (direct and transitive) regularly scanned for vulnerabilities?
• Is an SBOM generated and archived for every release artifact?
• Do you receive actionable alerts for new CVEs affecting your deployed assets?
• Are build failures enforced when critical vulnerabilities are found?
• Is there a documented process for risk acceptance and exception handling?

Conclusion and Next Steps

Supply chain security requires constant vigilance, not just a one-time scan. Automated dependency scanning and SBOM generation are essential controls for modern development teams—and are increasingly required by regulators and customers alike.

To harden your environment:

• Integrate dependency scanners and SBOM tools in your CI/CD
• Train your team to audit and remediate vulnerable components proactively
• Explore advanced solutions like Sigstore for artifact signing and provenance

For deeper reading, review the official CISA SBOM resources and the OWASP CycloneDX Project. Start auditing your own systems today—don’t wait for the next supply chain breach.