Bsides London Beyond The Code Supply Chain

This presentation, delivered 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.

Key Topics Covered

Software Supply Chain Fundamentals:

• The supply chain spans producers (third-party library makers), consumers (software developers), infrastructure providers, and end-user customers
• Key components: development environment, code repositories, dependencies, CI/CD pipelines, container environments, and runtime/cloud environments
• Each link in the chain represents a potential attack surface

Historical Context — This Is Not a New Problem:

• Earliest found reference dates to a 1974 research paper from UC Davis on trusting software components
• OWASP Top 10 tracking shows the evolution: absent in 2007, appeared as “Security Misconfiguration” in 2010, became “Using Known Vulnerable Components” in 2013/2017, and elevated to “Vulnerable and Outdated Components” (A06) in 2021
• The problem has existed for decades — what changed is the scale of incidents and regulatory attention

Catalytic Events:

• SolarWinds (build system compromise), CodeCov (credentials leaked via Docker image), and Colonial Pipeline drove the issue to the forefront
• Resulting regulatory and industry responses: US Executive Order on cybersecurity, NIST SSDF framework, and Google’s SLSA framework
• The industry’s buzzword response: SBOM (ledger of ingredients) and Provenance (proof of document authenticity)

The Software Industry’s Self-Created Problems:

• Build automation led to faster release cycles, which reduced incentive to upgrade dependencies
• Excessive focus on OSS codebases without supporting maintainers
• Impossible segregation of features and bug fixes in dependency upgrades
• Automated vulnerability notifications creating a “hedonic hamster wheel” of alert fatigue

Software Bill of Materials (SBOM) — Capabilities and Limitations:

• SBOM is an itemized list of software ingredients: name, version, checksum, license, and dependency list (typically one level deep)
• What SBOM helps with: identifying incorrect software use, knowing what to fix in scenarios like Log4Shell, assessing impact of security bugs in core components — essentially inventory problems
• What SBOM cannot do: detect build system compromises (SolarWinds), credential leaks from container images (CodeCov), anything not related to third-party code inventory, or determine whether a vulnerable function is actually reachable in your code
• SBOM is a good first step but not a complete solution — the industry has repeatedly failed at this first step
• Current gaps: compiler information, ML models, SaaS service dependencies, operating environment details (OWASP CycloneDX working to address some of these)

Centralized vs. Decentralized Dependency Approaches:

• Centralized (vetted software): dedicated volunteers review and maintain packages, separate branches for features and bug fixes, stability prioritized — e.g., Debian and Linux distributions; pros include single authority tracking bugs, deeper understanding; cons include limited tracking capacity and feature delays
• Decentralized (isolated software): consumers use packages directly with controlled upgrades, packages isolated per project — e.g., Python venv, npm, Homebrew; pros include full version control and per-project flexibility; cons include no centralized security fix push (critical in Log4Shell-type scenarios)

Provenance:

• Proof of authenticity of a document or artifact
• Key insight: if a software download link and its checksum are hosted on the same domain, a compromise of that domain invalidates both
• Provenance records and signing should involve a separate trusted third party to provide meaningful integrity guarantees

Frameworks for Action:

• SLSA (Supply-chain Levels for Software Artifacts): Google’s framework with maturity levels; started ambitious in v0.1, scoped down in v1.0 to three levels with Level 4 deferred; importantly SLSA is nontransitive — it only assures the current software, not its transitive dependencies
• NIST SSDF (Secure Software Development Framework): four sections — Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), Respond to Vulnerabilities (RV)
• NIST Cybersecurity Framework v2: added Govern section relevant to end users and consumers

Tooling Ecosystem:

• OpenSSF Scorecard: open-source project health checks
• Sigstore and cosign: software distribution and container signing for provenance verification
• SafeDep vet: organization-level package vetting with custom rule support
• Stacklok: VSCode plugin for dependency health checks with alternative suggestions

Critical Questions for Vendors:

• What should consumers actually do with the SBOM they receive?
• Do vulnerability reports include reachability analysis (can you actually test it)?
• Are alternative suggestions provided for vulnerable libraries?

Actionable Takeaways

1. 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 actually reachable in your code.
2. Evaluate your dependency management approach (centralized vs. decentralized) and understand its security trade-offs, especially for incident response scenarios like Log4Shell where centralized update mechanisms are critical.
3. Implement provenance verification by ensuring that signatures and checksums are stored and verified through a separate trusted authority, not co-located with the artifact being validated.
4. Adopt the SLSA framework to establish maturity levels for your software supply chain, understanding that SLSA is nontransitive — you must verify your dependencies’ supply chain integrity independently.
5. Use the NIST SSDF framework’s four pillars (Prepare, Protect, Produce, Respond) as a practical roadmap for organizational software security regardless of your role as producer or consumer.
6. Integrate supply chain tooling into your workflow: OpenSSF Scorecard for dependency health, Sigstore/cosign for artifact signing, and SafeDep vet for organization-level package vetting with enforceable rules.
7. Challenge your SBOM vendors with pointed questions: what actionable steps can you take with the SBOM data, do they perform reachability analysis, and do they suggest safer alternatives for vulnerable components?