This presentation at BSides London 2023 provides a comprehensive examination of software supply chain security and the role of Software Bill of Materials (SBOM). Anant Shrivastava traces the history of supply chain risks from a 1974 research paper through modern incidents like SolarWinds and CodeCov, critically evaluates what SBOMs can and cannot solve, compares centralized (vetted) versus decentralized (isolated) approaches to dependency management, and outlines actionable frameworks (SLSA, NIST SSDF, CSF) and tooling for producers and consumers of software. A recurring theme from the live talk: “We end up solving problems that we created a few years or months ago” — an industry pattern of reactive solutions to self-inflicted complexity.
Summary
The talk begins by establishing that supply chain security is about trust in the entire process from raw materials to end user. The software supply chain has four primary entities (producers, consumers, infrastructure providers, end users) and six building blocks (developer, code repositories, CI systems, CD systems, containers, dependencies, and service providers). Each link represents a potential attack surface.
The historical context is emphatic: this is not a new problem. A 1974 Air Force document first discussed compiler backdoors and trust in the software building process. Ken Thompson’s 1984 “Reflections on Trusting Trust” showed how to backdoor a compiler. OWASP has tracked this issue since 2004, evolving from “Security Misconfiguration” (2010) through “Using Known Vulnerable Components” (2013/2017) to “Vulnerable and Outdated Components” (A06:2021). Anant’s pointed observation: “When a vendor says software supply chain is a very new problem — it has existed for a very long time. People didn’t have something to sell us, so they had something to talk about. Now when they have something to sell us, now they’re talking about it.”
What changed was the convergence of high-profile incidents (SolarWinds build system compromise, CodeCov credentials leaked via Docker image, Colonial Pipeline) and the resulting US Executive Order that led to NIST SSDF and Google SLSA frameworks, producing the industry buzzwords: SBOM and Provenance.
SBOM is explained through analogy: a recipe book with a list of ingredients — software name, version, checksum, license information, and dependencies (one level deep). Its purpose is inventory management, grounded in the principle that “if you don’t know your assets, you cannot protect them.” The talk emphasizes that 80% of code in typical applications consists of imported third-party libraries, yet organizations are importing 100% of a library to use 10% of its functionality.
The limitations of SBOM are stated bluntly. It cannot tell you what compiler was used, what ML models are in use, what SaaS services were consumed, which CI/CD system built the software, or what operating systems were involved. Critically, SBOM cannot determine whether a vulnerable function is actually reachable in your code path — you may import a library but never call the vulnerable function. CycloneDX is working on VEX (Vulnerability Exploitability eXchange) to address this gap. The SolarWinds hack happened because the CI system was compromised — SBOM would not have prevented it.
The comparison between centralized and decentralized dependency approaches is practical. Centralized (vetted) models like Debian maintain packages with dedicated volunteers, separate feature and bug fix branches, and push security fixes centrally — but can only track a limited number of packages and delay features. Decentralized (isolated) models like npm and Python venv offer flexibility and per-project control but provide no centralized security fix mechanism — critical in Log4Shell-type scenarios where knowing what needs fixing is the first step. The talk notes that npm audit identifies vulnerabilities but does not tell you what to do about them.
Provenance is explained as proof of document authenticity, with the key insight that if a download link and its checksum are hosted on the same domain, compromising that domain invalidates both. True provenance requires a separate trusted third party for signing and storage.
Frameworks covered include SLSA (Google’s maturity-level framework, which notably removed Level 4 — reproducible builds — as too ambitious and is nontransitive, only assuring current software and not its transitive dependencies), NIST SSDF (four pillars: Prepare, Protect, Produce, Respond), and NIST CSF v2 (adding a Govern section for governance policies).
The tooling ecosystem includes OpenSSF Scorecard for project health scoring, Sigstore/Cosign for container signing and provenance verification, SafeDep Vet for organization-level package vetting with custom policy rules (e.g., “no GPL dependencies,” “no dependencies with no activity for 6 months”), and StackLok as a VS Code plugin that rates modules and suggests alternatives.
The Q&A session produces valuable practical guidance. For vulnerability prioritization, the recommended approach layers code coverage analysis (is the vulnerable function actually used?), CVSS scoring, EPSS (Exploit Prediction Scoring System), and KEV (Known Exploited Vulnerabilities). Semgrep can identify whether a vulnerable function is actually called in your codebase. Most bugs in practice exist in transitive dependencies (2nd/3rd level), not direct dependencies.
Three critical questions to ask SBOM vendors: (1) “What do I do with the SBOM?” — if the answer is “nothing, you just needed to have one,” run away; (2) “Are you validating vulnerabilities or just spotting them?” — test with a sample project containing a vulnerable dependency in unused code; if they flag it, that is a false positive; (3) “Do you have alternative solutions to vulnerable libraries?” — the minimum a vendor should provide.
Key Themes
- SBOM as First Step, Not Silver Bullet: SBOM solves inventory problems but cannot detect build system compromises, credential leaks, or determine code reachability — the industry has repeatedly failed at even this first step
- Self-Inflicted Complexity: Automation and fast release cycles reduced incentive to maintain dependencies; the industry is now solving problems it created
- Centralized vs. Decentralized Trade-offs: Neither model is complete — centralized provides security push but limits flexibility; decentralized provides flexibility but leaves security response to individual developers
- Vendor Skepticism: Test vendor claims with sample projects rather than trusting marketing; three pointed questions can separate genuine capabilities from buzzword compliance
- Provenance Must Be Independent: Co-locating artifact and attestation on the same infrastructure defeats the purpose of integrity verification
Notable Points
- The Bill of Materials concept will be the dominant keyword for the next 5–10 years, extending to Cryptographic BOM and other variants
- SLSA deliberately removed Level 4 (reproducible builds) in v1.0 as too ambitious for current industry maturity
- SafeDep’s organizational rules (blocking dependencies by license, activity level, or star count) represent a practical approach to policy-driven dependency management
- IBM took 45–50 days to inventory whether they were affected by Log4Shell — SBOM would have reduced this to minutes
- The VEX (Vulnerability Exploitability eXchange) standard from CycloneDX is the emerging solution for the reachability gap in SBOM
Actionable Takeaways
- Understand that SBOM is a necessary first step for inventory management but not a silver bullet — it cannot detect build system compromises, credential leaks, or determine if a vulnerable function is reachable in your code
- Evaluate your dependency management approach (centralized vs. decentralized) and understand its security trade-offs, especially for incident response scenarios like Log4Shell
- Implement provenance verification by ensuring signatures and checksums are stored and verified through a separate trusted authority, not co-located with the artifact
- Adopt SLSA to establish maturity levels for your software supply chain, understanding that SLSA is nontransitive — verify your dependencies’ supply chain integrity independently
- Use NIST SSDF’s four pillars (Prepare, Protect, Produce, Respond) as a practical roadmap for organizational software security
- Integrate supply chain tooling: OpenSSF Scorecard for dependency health, Sigstore/Cosign for artifact signing, SafeDep Vet for organization-level package vetting with enforceable rules
- Challenge SBOM vendors with three questions: what actions to take with the SBOM, whether they perform reachability analysis, and whether they suggest safer alternatives
- Prioritize vulnerabilities using: code coverage analysis, CVSS scoring, EPSS (exploit prediction), and KEV (known exploited vulnerabilities) — use Semgrep to determine if vulnerable functions are actually called
