Home/Security/Supply Chain Security and SBOM Management Strategy
SecuritySBOMSCA

Supply Chain Security and SBOM Management Strategy

The 2020 SolarWinds attack infected more than 18,000 organizations through a poisoned software update, and Log4Shell later underscored the same supply-chain risk. This post covers SBOM standards and tooling, signing, SLSA, VEX, and a practi

Supply Chain Security and SBOM Management Strategy
Contents
  1. Why Supply Chain Attacks Are Dangerous
  2. What Is an SBOM (Software Bill of Materials)
  3. SBOM Standard Formats
  4. SBOM Generation Tools
  5. Artifact Signing (Cosign)
  6. Supply Chain Security Checklist
  7. License Policy
  8. Dependency Confusion Attacks
  9. Protecting the Build Pipeline Itself (SLSA)
  10. VEX — Proving “Vulnerable but Not Affected”
  11. Korean Context
  12. Frequently Asked Questions (FAQ)

Why Supply Chain Attacks Are Dangerous

The 2020 SolarWinds incident planted malware in a legitimate software update and simultaneously infected more than 18,000 organizations. Log4Shell in 2022 further demonstrated how serious supply chain security can be.

What Is an SBOM (Software Bill of Materials)

An SBOM is an inventory of every component that makes up a piece of software. U.S. Executive Order 14028 made providing an SBOM mandatory for federal deliveries.

SBOM Standard Formats

FormatStewardCharacteristics
SPDXLinux FoundationISO/IEC standard; strong at license management
CycloneDXOWASPSecurity-focused; easy to integrate with vulnerability data

SBOM Generation Tools

Bash
# JavaScript/Node.js
npx @cyclonedx/cyclonedx-npm --output-format JSON > sbom.json

# Python
pip install cyclonedx-bom && cyclonedx-py environment > sbom.json

# Java (Maven)
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

# Container image
syft my-image:latest -o cyclonedx-json > sbom.json

# Generate an SBOM with Trivy and correlate vulnerabilities
trivy image --format cyclonedx --output sbom.json my-app:latest
trivy sbom sbom.json

Artifact Signing (Cosign)

Bash
# Sign a container image
cosign sign --key cosign.key my-registry/my-app:v1.0

# Verify the signature
cosign verify --key cosign.pub my-registry/my-app:v1.0

Supply Chain Security Checklist

CODE
Development stage:
□ Check open-source licenses (prevent GPL contamination)
□ Pin dependencies (package-lock.json, poetry.lock)
□ Use only trusted registries

CI/CD stage:
□ Auto-generate an SBOM on every build
□ Automatically match against CVE databases
□ Alert immediately when new vulnerabilities are found

Operations stage:
□ Manage an SBOM archive (retain per version)
□ Retroactively inspect existing deployments when new CVEs are published
□ Define patch SLAs for vulnerable components

License Policy

  • Allowed: MIT, Apache 2.0, BSD
  • Review required: LGPL, MPL
  • Prohibited: GPL, AGPL (source-disclosure obligation)

Supply chain security is not a one-time fix. Vulnerabilities like Log4Shell that hit hundreds of products at once can appear at any time.

Dependency Confusion Attacks

If an attacker publishes a higher version of a package on a public registry (npm/PyPI) using the same name as an internal private package, the build tool may pull the public copy and inject malware.

CODE
Defense:
- Enforce an internal scope (@company/...) and block installs outside that scope
- Pin private-registry priority and disable public fallback
- Verify install integrity (npm: --ignore-scripts, lockfile verification)

Protecting the Build Pipeline Itself (SLSA)

If an SBOM answers “what went into the software,” SLSA answers “can we trust that build?”

YAML
# GitHub Actions — 3
- uses: actions/checkout@<full-40-char-SHA> # SHA
permissions:
 contents: read # (default read)
 id-token: write # OIDC ( when )
  • Pin third-party Actions to a commit SHA, not a tag (v4), to prevent tag-tampering attacks.
  • Authenticate to the cloud with OIDC-based short-lived tokens instead of long-lived secrets.

VEX — Proving “Vulnerable but Not Affected”

Even if an SBOM is tagged with 100 CVEs, only some of them are actually exploitable. Recording judgments in a VEX (Vulnerability Exploitability eXchange) document—such as “this CVE is not reachable because we never call that function”—reduces pointless patch pressure and customer inquiries.

Korean Context

  • The Ministry of Science and ICT and KISA Software Supply Chain Security Guidelines set criteria for SBOM adoption.
  • SBOM requirements are expanding for public-sector and financial deliveries, so standardizing automatic SBOM generation in CI ahead of time is advantageous.

Frequently Asked Questions (FAQ)

Q. Does generating an SBOM complete supply chain security? No. An SBOM is only an “inventory list.” The core is operations: continuously monitoring existing deployments when new CVEs are published (continuous monitoring) and meeting patch SLAs.

Q. Should I use SPDX or CycloneDX? SPDX is more convenient if you focus on licenses and compliance; CycloneDX is more convenient if you focus on vulnerability integration and security. Many tools can emit both, so match whatever your consumers require.

✦ ✦ ✦
Sources and verification

Sources and checks vary by article. Only articles with a recorded check date, scope and sources below were checked, and only within that scope. For other articles, verify against the current docs for your version before applying anything, and email us about errors. Editorial policy · email us

This article has no recorded human check (date and scope) yet.

Published ·
Topic-related official docs (auto-linked · not per-claim sources)Linux man pages ↗OWASP documentation ↗CISA SBOM ↗

Comments

Be the first to comment.