Software Supply Chain Security: Securing Build Pipelines with SLSA & Sigstore

Software supply chain attacks have become one of the most dangerous threats in modern cybersecurity. When attackers compromise a build pipeline or inject malicious code into a widely-used open source package, they can compromise every organization that uses that software—potentially thousands of companies at once. High-profile incidents like SolarWinds, Log4j, and the Codecov breach have made it clear: traditional perimeter security isn't enough. You need to secure the entire software supply chain, from source code to deployment. Two frameworks have emerged as the foundation of this effort: SLSA (Supply-chain Levels for Software Artifacts) and Sigstore. Together, they provide a practical, standards-based approach to securing build pipelines and verifying software integrity.

To understand why SLSA and Sigstore matter, you first have to understand the scope of the problem. Modern software is assembled, not written from scratch. A typical application includes hundreds of open source dependencies, built by automated CI/CD pipelines, and deployed across cloud environments. Each link in this chain is a potential attack vector.

Attackers have exploited every part of the supply chain. They've compromised source code repositories, injecting malicious code directly into projects. They've attacked build systems, modifying code during the build process so the binary doesn't match the source. They've poisoned package registries, publishing malicious packages with names similar to legitimate ones (typosquatting). And they've compromised update mechanisms, tricking users into installing trojanized updates.

The challenge is that traditional security tools don't address these threats. Vulnerability scanners find known CVEs in dependencies, but they can't detect if a package was tampered with during the build. Access control protects your repositories, but what if the build service itself is compromised? You need something different: a way to verify that the software you're running is exactly what it claims to be, built from the source code you expect, through a build process you can trust.

SLSA (pronounced "salsa") is a framework developed by Google and the Open Source Security Foundation (OpenSSF) that defines four progressive levels of software supply chain security. Think of it like a maturity model for your build pipeline—Level 1 is basic, Level 4 represents the highest level of security.

Each SLSA level adds specific requirements. SLSA 1 requires a fully scripted, automated build process and provenance generation—metadata about how the software was built. This gives you basic visibility into where your software comes from, though it doesn't prevent tampering.

SLSA 2 adds requirements for version-controlled source code and a hosted build platform with authenticated build provenance. At this level, you can trace an artifact back to its source code commit, and the build provenance is signed by the build platform, making it harder to forge.

SLSA 3 hardens the build platform itself, requiring that builds run in isolated environments that can't be tampered with by other builds or users. The provenance can't be falsified by a compromised project—only by a compromised build platform. This is the target level for most enterprise applications.

SLSA 4 is the highest level, requiring two-person review of all changes, hermetic builds that don't access the network during compilation, and provenance that's impossible to forge even if the build platform is partially compromised. This level is appropriate for critical infrastructure and high-security environments.

The value of SLSA is that it gives you a clear roadmap. You don't have to achieve perfect security overnight. You start at Level 1, work your way up, and each level gives you meaningful security improvements.

If SLSA defines what you need to achieve, Sigstore provides the tools to achieve it. Sigstore is an open source project—also under the OpenSSF—that makes software signing and verification simple, secure, and accessible.

Traditional code signing has always suffered from key management problems. Developers lose signing keys, keys get stolen, storing and rotating keys is a nightmare. Sigstore solves this with keyless signing, using short-lived certificates tied to developer identities instead of long-lived signing keys.

Here's how it works: when you sign an artifact, Sigstore's Fulcio certificate authority issues you a short-lived signing certificate, valid for just minutes. The certificate is tied to your identity—your email address, GitHub account, or other OIDC identity. You sign the artifact with this temporary key, then the signature and certificate are recorded on Rekor, Sigstore's immutable transparency log.

Because the keys are short-lived, there's no long-lived secret to steal or lose. Because everything is recorded in a transparency log, anyone can verify when and by whom an artifact was signed. And because it uses standard identities, developers don't need to manage or protect special signing keys.

Sigstore also includes Cosign, a tool for signing and verifying container images and other artifacts. Cosign works with Sigstore's keyless signing or with traditional keys, making it easy to add signing to existing CI/CD pipelines.

SLSA and Sigstore are complementary. SLSA defines the security requirements and levels; Sigstore provides the cryptographic tools to implement them. Together, they form a powerful approach to securing build pipelines.

At the heart of this approach is signed provenance. Every time your CI/CD pipeline builds an artifact—a binary, a container image, a package—it generates provenance metadata: what source code commit was built, what build command was used, what dependencies were included, when the build happened, and who triggered it. This provenance is then signed using Sigstore, creating an immutable, verifiable record of the build.

When you deploy or consume software, you verify the provenance before using it. You check that the artifact was built from the expected source repository, at the expected commit, through an approved build process, with the expected SLSA level. If anything doesn't match—if the provenance is missing, or signed by an unexpected identity, or shows the build came from an untrusted source—you reject the artifact.

This approach addresses the full range of supply chain attacks. Source tampering is detected because provenance shows exactly which commit was built. Build system compromise is harder because the build runs in an isolated, attested environment, and the provenance is signed by the build platform. Package registry attacks are neutralized because you verify the artifact's signature and provenance before using it, regardless of where you downloaded it from.

Implementing SLSA and Sigstore doesn't have to be all-or-nothing. A phased approach works best.

Phase 1: Baseline visibility (SLSA 1). Start by generating basic provenance for all your builds. Add a step to your CI/CD pipeline that records what's being built and generates provenance metadata. Use Sigstore's Cosign to sign both the artifacts and the provenance. You don't get strong security yet, but you get visibility—you can see what's being built, by whom, and from where. This is the foundation for everything else.

Phase 2: Build integrity (SLSA 2-3). Move your builds to a hosted build platform that supports authenticated provenance. GitHub Actions with Sigstore integration, GitLab CI, or Google Cloud Build all work. Enable signed provenance generation, and start verifying provenance before deployment. At this stage, you're preventing most common supply chain attacks—an attacker can't just modify a binary and push it to production without the provenance matching.

Phase 3: Hardened builds (SLSA 3-4). For your most critical applications, implement hermetic builds—builds that don't access the network, with all dependencies pinned and verified. Add two-person review requirements for changes to critical code. Implement build isolation so that one build can't affect another. This is the highest level of security, appropriate for your most sensitive workloads.

Along the way, start verification early. Even before you've achieved high SLSA levels for your own builds, you can start verifying provenance for third-party dependencies and open source packages. Many major open source projects now provide SLSA provenance and Sigstore signatures. Verifying them before use protects you from a huge class of supply chain attacks with minimal effort.

A few best practices will make your implementation smoother. First, start with your most critical applications. You don't need to secure every pipeline at once. Prioritize the ones that handle sensitive data, run in production, or are most exposed to attack. Get those right, then expand.

Second, integrate verification into your deployment pipeline. Verification shouldn't be a manual step—it should be automatic. Add a policy engine (like Kyverno or OPA Gatekeeper for Kubernetes, or admission control in your CI/CD system) that checks provenance and signatures before allowing deployment. If an artifact doesn't meet your SLSA requirements, it gets blocked automatically.

Third, don't forget dependencies. Your own builds are only part of the supply chain. The open source packages you use are just as important. Start requiring SLSA provenance or Sigstore signatures for critical dependencies. Use tools like osv-scanner or Snyk to check for known vulnerabilities and supply chain issues in your dependency tree.

Common pitfalls to avoid: treating SLSA as a checkbox exercise. SLSA isn't about achieving a number—it's about improving security. Focus on the actual security improvements each level brings, not just on checking boxes. Trying to jump to SLSA 4 immediately. Start where you are, work your way up. Each level gives you real value. Ignoring the human factor. Supply chain security isn't just about tools—it's about processes, training, and culture. Developers need to understand why these changes matter and how to work with them.

SLSA and Sigstore are still relatively new, but they're rapidly becoming the industry standard. Major cloud providers are adding SLSA provenance to their build services. Major open source projects are adopting Sigstore signing. Governments and regulators are starting to require supply chain attestations for critical software.

The trajectory is clear. In a few years, signed provenance and SLSA compliance will be table stakes for software—just like HTTPS is for websites today. Organizations that adopt these tools early will have a significant security advantage, and they'll be ahead of the regulatory curve.

Software supply chain security is a journey, not a destination. There's no single tool or framework that will solve all your problems. But SLSA gives you the roadmap, and Sigstore gives you the tools. Together, they provide a practical, standards-based approach to securing your build pipelines and protecting your organization from one of the most dangerous threats in modern cybersecurity. The question isn't whether you need to secure your software supply chain—it's how quickly you can get started.