Most teams still talk about "supply-chain security" as if it were one problem with one fix — pin your dependencies, run npm audit, done. It isn't. The Open Source Security Foundation's SLSA framework (Supply-chain Levels for Software Artifacts, at slsa.dev) puts a number on why: supply-chain attacks are up 650% year over year, and the framework itself is organized around a maturity model that runs from basic provenance hygiene to protection against sophisticated, well-resourced adversaries. SLSA is governed by a cross-organization, vendor-neutral steering group under the Open Source Security Foundation, with participants including Google, Intel, Datadog, and Chainguard, and its own framing describes the levels as examining "the builds, sources and dependencies" behind an artifact — not a formal four-part taxonomy, which is why this post proposes one. Yet in practice, most engineering orgs still treat "supply chain" as a synonym for "third-party packages" and stop there — leaving the build system, the CI/CD pipeline that orchestrates it, and the channel an artifact travels through to reach production largely unexamined. This post lays out an original four-surface framework — build, dependency, distribution, and CI/CD — with concrete mitigations mapped to SLSA's graduated levels, so a security team can answer "which surface is our weakest" instead of just "did we scan for CVEs."
What is the dependency surface, and why isn't a CVE scan enough?
The dependency surface covers every third-party package, transitive or direct, that your build pulls in — and a CVE scan alone misses two of its biggest threats: packages that are malicious by design rather than merely outdated. Dependency confusion is the clearest case: researcher Alex Birsan demonstrated in 2021 that uploading public packages matching the names of internal libraries used by more than 35 companies — including Apple, PayPal, and Microsoft — caused internal build systems to silently pull the attacker-controlled public version, netting him over $130,000 in bug bounties. Typosquatting is the sibling threat: Phylum's research team documented over 550 malicious packages uploaded to PyPI in a single week in March 2023, many riding on naming confusion with popular libraries. A version-matching CVE scan catches neither pattern, because the malicious package was never assigned a CVE — it was just published and trusted. Mitigating this surface means enforcing scoped/private registries, blocking installs at fetch time rather than auditing after the fact, and treating "a package I've never seen before" as a signal worth evaluating on its own.
What counts as the build surface, and what makes a build system trustworthy?
The build surface is the machinery that turns source code into a shippable artifact — the compiler, the build script, and, critically, the environment that machinery runs in. SLSA treats this as foundational because a compromised build system can inject malicious code into an artifact even when the source repository itself is clean and every dependency is legitimate; provenance describing "which commit, which build steps, which materials" only carries weight if the system generating that provenance can't be tampered with. SLSA's own framing calls build provenance generation "the first on-ramp" to the framework — you cannot reason about build integrity until you can prove what a build actually consumed and produced. A trustworthy build system runs on ephemeral, parameter-less infrastructure rather than long-lived shared runners a prior job could have poisoned, and it emits a signed attestation of its inputs and steps rather than an unsigned build log a defender has to trust on faith.
What is the CI/CD surface, and why is it a distinct risk from the build itself?
The CI/CD surface is the orchestration layer — the pipeline definitions, secrets, and triggers that decide when a build runs and what it's allowed to do — and it's distinct from the build surface because compromising the orchestrator doesn't require touching the compiler at all. A malicious pull request that modifies a pipeline YAML file, or a leaked CI secret with write access to a deploy step, can redirect a legitimate build toward an attacker's artifact without ever altering source code that a code reviewer would inspect. This is why guardrails belong at multiple points in the pipeline lifecycle — IDE, commit, CI, registry, admission, and runtime — rather than as a single gate at the end: a policy that only checks the final artifact can't catch a pipeline definition that was quietly edited to skip the check. Mitigating this surface means treating pipeline configuration as code subject to the same review requirements as application code, scoping CI tokens to the minimum permission needed per job, and requiring signed, policy-as-code gates before a build result can be promoted.
What is the distribution surface, and how does it differ from the artifact itself being safe?
The distribution surface is everything between "a good artifact was built" and "the right artifact reached the consumer," and it matters even when the artifact itself is clean, because tampering can happen entirely in transit or at rest in a registry. An attacker who compromises a package registry, or intercepts an unsigned artifact push, can substitute a different binary under the same version tag without touching the build pipeline at all — the classic scenario SLSA's distribution-integrity controls exist to close. This is where cryptographic signing and transparency logging do work that scanning cannot: a signature bound to a specific build identity, verified against an allow-list at consumption time, catches substitution regardless of how the artifact was altered. The mitigation here isn't "scan the download" — it's "verify the artifact was signed by the identity you expect, and that a public, append-only log (like Sigstore's Rekor) recorded that signing event," so tampering after the fact is detectable rather than invisible.
How do SLSA's levels map to mitigations across all four surfaces?
SLSA's levels give each surface a concrete bar to clear, moving from "any provenance exists" at Level 1 toward hermetic, tamper-resistant builds at Level 4 — though the exact per-level technical requirements are best verified against the current spec at slsa.dev/spec rather than assumed, since the framework has evolved across versions. As one practical illustration of how a platform maps its own build environments to these levels, Safeguard's attestation tooling documents Level 1 as achievable with any provenance-emitting build step, Level 2 as requiring a tamper-resistant build service such as GitHub Actions or GitLab CI, Level 3 as requiring an isolated, parameter-less build (GitHub reusable workflows or a dedicated VM runner), and Level 4 as requiring hermetic builds plus two-person review — that mapping is one vendor's interpretation of the spec, not a verbatim quote from SLSA itself, and teams should confirm against slsa.dev before setting a compliance target. The useful exercise isn't chasing Level 4 everywhere; it's asking which of your four surfaces — build, dependency, CI/CD, distribution — has the lowest current level, since that's where an attacker has the least resistance.
How Safeguard helps
Safeguard maps controls to all four surfaces rather than treating dependency scanning as the whole program. The Package Firewall sits as an install-time proxy in front of npm and pip, catching typosquats and dependency-confusion attempts on the dependency surface before a malicious package ever reaches disk. Attestation & Signing produces SLSA Provenance v1, CycloneDX and SPDX SBOM, vulnerability-scan, and review attestations in in-toto v1 format, signed via Sigstore Fulcio and published to the Rekor transparency log — giving the build and distribution surfaces a verifiable, tamper-evident record instead of a trusted log file. Guardrails & Enforcement extend policy checks across IDE, commit, CI, registry, and admission points, so a pipeline-configuration change or an unsigned artifact gets blocked at the CI/CD surface rather than discovered after deployment. Together, that's coverage across build, dependency, distribution, and CI/CD as one connected control set — not four separate tools a team has to reconcile by hand.