Software supply chain security is the discipline of knowing what is in your software, where it came from, and whether it was tampered with en route. Regulators (US Executive Order 14028, EU Cyber Resilience Act, India’s CERT-In requirements) have moved this from a best practice to a compliance requirement. This module covers SBOM, provenance, signing, the SLSA framework, and the dependency-security practices that actually work.
Why supply chain is under regulatory pressure
High-profile incidents changed the landscape:
- SolarWinds (2020): compromised build pipeline inserted malicious code into signed updates distributed to 18,000 organizations
- Log4Shell (2021): a single library vulnerability affected thousands of products; most organizations couldn’t even answer “do we use log4j?”
- xz Utils (2024): long-running social-engineering attack against an open-source maintainer; backdoor nearly shipped to all Linux distributions
Regulatory response: US federal vendors must provide SBOMs (EO 14028). EU CRA requires SBOMs and vulnerability handling for all “products with digital elements” from 2027. India’s CERT-In issued similar draft guidance in 2025.
SBOM — Software Bill of Materials
An SBOM is a structured list of every component in a piece of software. Two major formats:
- SPDX — older, broader, ISO standard. Spec maintained by Linux Foundation
- CycloneDX — newer, lightweight, OWASP-maintained. Richer for vulnerabilities
Both are JSON or XML. Tools generate them for you — you should rarely write them by hand.
Generating SBOMs
# From a source repo (Syft)
syft . -o cyclonedx-json > sbom.cdx.json
# From a built container image
syft ghcr.io/myorg/api:v1.2.3 -o spdx-json > sbom.spdx.json
# In CI — as part of release
- uses: anchore/sbom-action@v0
with:
image: ${{ env.IMAGE }}
format: spdx-json
output-file: sbom.spdx.json
# From a Java JAR / Maven project
mvn cyclonedx:makeAggregateBom
# Output: target/bom.xml
# Node project
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json
What a useful SBOM contains
- Component name + version + package manager
- License (SPDX identifier)
- Hash / checksum for integrity verification
- Dependency relationships (what depends on what)
- Supplier information (who published the component)
Scanning SBOMs for vulnerabilities
grype sbom:sbom.spdx.json
# Grype cross-references components against the NVD + GHSA + more
# Output: every CVE affecting your inventory, with severity
# For API-driven lookups
trivy sbom sbom.spdx.json
Ship the SBOM alongside your release. Customers (especially enterprise/government) will ask for it.
SLSA — provenance that proves how it was built
SLSA (Supply-chain Levels for Software Artifacts) is a framework with four levels:
- Level 1: build is scripted (not manual). Documented build process
- Level 2: hosted build, version controlled, generated provenance (attestation of build details)
- Level 3: source + build platform hardened. Provenance non-forgeable
- Level 4: two-party review of all changes, hermetic reproducible builds
Most organizations target Level 2-3. SLSA 4 is aspirational.
🔐 Intermediate Module · Basic Tier
Continue reading with Basic tier (₹499/month)
You've read 29% of this module. Unlock the remaining deep-dive, quiz, and every other Intermediate module.
99+ modulesAll levels up to this tier
20-question quizzesUnlimited retries with explanations
Completion certificatesShareable on LinkedIn
9 more sections locked below
