Most teams don’t start looking at SLSA because they’re excited about supply-chain theory. They start because something hurts. Slsa Levels Explained: What Level 2 Looks Like For Real Teams
- An auditor asks, “How do you know this binary came from your CI system?”
- A customer asks, “Can you prove no one built this on their laptop?”
- An incident happens, and suddenly everyone is trying to reconstruct how an artifact was produced three weeks ago.
What I usually see at that point is a lot of hand-waving:
-
“Well… Jenkins built it.”
-
“The commit hash is in the log somewhere.”
-
“We trust our pipeline.”
SLSA Level 2 exists for exactly this moment. It’s the first level where you can stop saying “trust me” and start saying “here’s the evidence.”
It’s also important to set expectations early: Level 2 is achievable and useful, but it’s not magical. It won’t stop every supply-chain attack. It won’t fix dependency vulnerabilities. And it won’t make your pipeline immune to compromise.
What it will do is give you a clear, defensible answer to one very specific question:
“Where did this artifact come from, and was it built the way we expect?”
That alone is often enough to calm auditors, unblock customers, and give your own team confidence in what they’re shipping.
What SLSA Actually Protects Against
Let’s be very explicit about the threat model, because this is where a lot of confusion comes from.
What Level 2 does protect against
In practice, SLSA Level 2 helps with:
-
Mystery builds
Someone uploads a binary to your registry and claims it came from CI. With provenance, you can verify whether that’s true.
-
Manual or local builds sneaking into prod
If artifacts must come from CI and CI emits provenance, a locally built binary sticks out immediately.
-
“Oops, we rebuilt it” incidents
When a team rebuilds an artifact after the fact and overwrites the original, Level 2 makes that detectable.
-
Basic tampering in the artifact pipeline
If someone swaps out an artifact after the build, provenance won’t match.
These are not theoretical problems. I’ve seen every single one of these happen in real teams.
What Level 2 does not protect against
This is just as important:
-
A compromised CI system
If an attacker controls your CI runner, Level 2 won’t save you. The provenance will faithfully attest to a malicious build.
-
Malicious dependencies
SLSA Level 2 doesn’t scan dependencies, pin them, or magically make them safe.
-
Vulnerable build scripts
If your does something unsafe, provenance just records that it happened.
-
Insider threats with CI access
If someone can push code and trigger CI, Level 2 assumes that’s legitimate.
Level 2 is about traceability, not trustworthiness of every input. That distinction matters when expectations start to drift.
What SLSA Level 2 Really Requires ?
The spec uses careful language. I’ll translate it into what you actually have to do.
Builds happen in CI, not on laptops
This is the foundation. If people can build release artifacts locally and upload them, nothing else matters.
In practice, this means:
-
Release artifacts are only produced by CI jobs
-
Credentials for publishing artifacts live in CI, not on developer machines
-
“Just this once” manual releases are treated as incidents, not exceptions
Why this exists: if you can’t constrain where builds happen, you can’t reason about how they happened.
CI generates provenance for each artifact
Provenance is just structured metadata that says:
-
What was built
-
From which source (repo, commit)
-
Using which workflow or job
-
When it happened
At Level 2, this provenance can be generated by the CI system itself. You don’t need a hermetic build environment or fancy isolation.
Why this exists: logs are messy and ephemeral. Provenance is machine-readable and durable.
You can link an artifact back to its build
This is the part auditors care about most.
Given an artifact in a registry, you should be able to answer:
-
Which CI job produced it?
-
Which commit triggered that job?
-
Where is the provenance that says so?
If that chain breaks, Level 2 isn’t really there, even if you “generate provenance.”
The Fastest Path to SLSA Level 2
Most teams overcomplicate this. The fastest path looks roughly like this.
Step 1: Lock down artifact publishing
Before touching SLSA tooling:
-
Remove local credentials for pushing release artifacts
-
Rotate secrets so only CI can publish
-
Make “CI-only releases” a hard rule
This is boring work, but it’s non-negotiable.
Step 2: Use your CI’s native provenance support
If you’re on:
-
GitHub Actions
use the built-in OIDC + provenance generation
-
GitLab CI
use their provenance and job metadata
-
CircleCI
use their build metadata and artifact associations
Do not start by building a custom provenance generator unless you enjoy pain.
Step 3: Attach provenance to artifacts
Two common patterns that work:
-
Store provenance as a separate artifact with a deterministic name
-
Attach it as an OCI attestation alongside container images
What matters is consistency, not elegance.
Step 4: Make verification possible (even if no one does it daily)
At Level 2, you don’t need automated policy enforcement everywhere. But you do need to be able to verify provenance when asked.
If verification requires tribal knowledge or Slack archaeology, it’s not real.
Shortcuts that usually backfire
-
“We’ll keep the logs, that’s enough”
Logs are not provenance. They’re evidence at best, and bad evidence at that. -
“We’ll sign everything later”
Signing without provenance doesn’t buy you much at Level 2.
What Evidence You Actually Need to Store
This is where teams waste the most time.
What auditors usually ask for
In my experience, they want:
-
A sample artifact
-
The provenance for that artifact
-
Proof that provenance was generated by CI
-
Proof that developers cannot bypass CI for releases
They almost never want terabytes of logs.
What actually matters in an incident
When something goes wrong, you want:
-
Provenance for the affected artifact
-
The source commit referenced in that provenance
-
The CI workflow definition at that commit
That’s usually enough to reconstruct what happened.
What teams over-store
-
Full build logs forever
-
Intermediate artifacts no one uses
-
Every transient CI job output
Logs are useful short-term. Provenance is what you keep long-term.
My rule of thumb
-
Provenance
retain as long as the artifact exists
-
Build logs
retain long enough to debug (weeks, not years)
-
Source
already in version control
What Level 2 Looks Like in Real Teams
Example 1: A containerized backend service
Day to day:
-
Devs merge to
main -
CI builds a container image
-
CI pushes the image and an OCI provenance attestation
-
The deployment system pulls the image by digest
During an audit:
-
Auditor asks about image
sha256:abcd -
Team fetches the attestation
-
Attestation shows repo, commit, workflow, timestamp
-
Question answered in minutes, not days
Example 2: A CLI tool distributed as binaries
Day to day:
-
Releases are tagged in Git
-
CI builds binaries on tag push
-
CI uploads binaries and a provenance file per binary
When a customer asks:
-
“How do we know this binary wasn’t tampered with?”
-
Team provides the provenance and shows how it maps to CI
-
No awkward silence, no “trust us” slide
None of this requires a perfect pipeline. It requires consistency.
7. Common Pitfalls I’ve Seen
-
Provenance exists but isn’t discoverable
If no one knows where it lives, it doesn’t count.
-
Multiple pipelines can publish artifacts
This destroys traceability fast. Pick one path.
-
Rebuilds overwrite old artifacts
Immutability matters more than people think.
-
Treating Level 2 as a checkbox
If the team doesn’t understand why it exists, it will rot.
A One-Page Mental Checklist for Level 2
Screenshot-worthy version:
-
Release artifacts can only be published by CI
-
CI generates provenance for each release artifact
-
Provenance links artifact → workflow → commit
-
Provenance is stored durably and discoverably
-
Given an artifact, we can explain its origin in minutes
-
Local or manual releases are impossible or loudly visible
If you can honestly check all of these, you’re effectively at Level 2.
What Comes After Level 2
Level 3 starts to care about how trustworthy the build environment itself is:
-
Stronger isolation
-
Harder guarantees about what ran
-
Fewer mutable inputs
This is worth it when:
-
You’re shipping widely consumed artifacts
-
You’re a dependency for other teams or companies
-
You’ve already been burned once
If you’re still struggling to answer “where did this come from?”, jumping to Level 3 is premature.
Get Level 2 solid first. It pays dividends on its own.
You Might Be Interested In
- Why Endpoint Security Is Essential?
- Ai Wont Solve Security It Changes The Battlefield
- How Cybersecurity Threats Affect Users?
- Secrets Scanning: What To Scan Code, Logs, Tickets And How To Respond?
- Kubernetes Networkpolicies: A Simple Approach To Reduce Lateral Movement
Conclusion
SLSA Level 2 isn’t about building a perfect supply chain or eliminating all risk. It’s about removing ambiguity from your build process. When something ships, you should be able to say where it came from, how it was built, and which system did the work without digging through Slack threads or old CI logs.
In real teams, Level 2 is often the point where supply-chain security stops being theoretical and starts being useful. It gives you leverage in audits, clarity during incidents, and a clean boundary between “this came from CI” and “this didn’t.” That alone solves a surprisingly large number of problems.
If you treat Level 2 as a checkbox, it will rot. If you treat it as a discipline CI-only releases, consistent provenance, and evidence you can actually find it will quietly pay off every time someone asks an uncomfortable question. Get this level right, and you’ll be in a much better position to decide whether going further is worth the cost.
FAQs about Slsa Levels Explained: What Level 2 Looks Like For Real Teams
What is SLSA Level 2 in simple terms?
SLSA Level 2 means that every artifact you release is built by your CI system, not by a human, and that CI produces structured proof describing how that artifact was built. That proof (provenance) ties the artifact to a specific repository, commit, and CI workflow run.
In plain English: if someone hands you a binary or container image, you can answer “this came from that repo, at that commit, built by this CI job, at this time.” You’re no longer relying on trust, memory, or screenshots of logs. You have something concrete and repeatable you can point to.
What attacks does SLSA Level 2 actually prevent?
SLSA Level 2 prevents a whole class of “we don’t know where this came from” problems. It stops locally built or manually modified artifacts from quietly entering your release pipeline, because those artifacts won’t have valid CI-generated provenance. If someone uploads a binary and claims it came from CI when it didn’t, you can detect that.
What it doesn’t do is stop an attacker who already controls your CI system. If CI itself is compromised, Level 2 will happily produce provenance for a bad build. This is why it’s important to see Level 2 as protection against process failures and ambiguity, not against every possible attacker.
What’s the fastest way to reach SLSA Level 2?
The fastest path is almost always organizational, not technical. First, make CI the only place that can publish release artifacts by removing local credentials and rotating secrets. Until that’s true, everything else is theater.
Once that’s done, use whatever provenance or attestation support your CI platform already provides. GitHub Actions, GitLab CI, and others can generate usable provenance today without custom tooling. Store that provenance next to the artifact in a predictable way, and make sure someone on the team knows how to retrieve it when asked. That’s usually enough to meet Level 2 in practice.
What evidence do we need to store?
At Level 2, the single most important piece of evidence is provenance for each release artifact. That provenance needs to show the source repository, the commit or ref that was built, the CI workflow or job that performed the build, and when it ran. If you have that, you can usually answer 90% of audit and incident questions.
You also need to be able to show that CI is the only system capable of producing release artifacts, which typically means configuration, access controls, and secret management rather than stored files. Everything else especially massive collections of logs is secondary and often unnecessary long-term.
Do we need full build logs forever?
No, and keeping them forever is usually a mistake. Full build logs are noisy, expensive to store, and surprisingly hard to interpret months later. They’re useful for short-term debugging, not long-term provenance or compliance.
For Level 2, provenance is the durable record you keep long-term. Logs can be retained for a reasonable window long enough to investigate failures or incidents and then safely expired. If you’re relying on logs as your primary evidence months or years later, something in your setup is missing.
