When your CI pipeline builds an image and pushes it to your registry, how do you know that image actually came from your source code?

For most teams, there is no way to prove it. Everyone just trusts the image build pipeline.

Attackers make use of this trust and compromise the build system rather than attacking a hardened production cluster.

We have seen this happen multiple times.

In all these cases, attackers targeted the build and delivery process rather than the application itself.

This is exactly the problem SLSA is designed to solve.

SLSA helps answer important questions such as,

In today's edition, I will cover:

and more..

SLSA stands for Supply Chain Levels for Software Artifacts (pronounced "salsa").

It was introduced by Google's security team in June 2021. It was inspired by Google's internal Binary Authorization for Borg system, which has been protecting production workloads inside Google for almost a decade. In fact, Google requires all production workloads to follow this security model.

SLSA is a software supply chain security framework from OpenSSF that measures how trustworthy your build process is.

The obvious question is,

How can the trustworthiness of a build process be measured?

Well SLSA does it through provenance. It is a signed document that records things like the following.

Now lets look at the provenance document in detail.

A provenance document is a JSON file that describes your build, who built it, how, and when.

The following image shows an example Provenance document.

The provenance document gets wrapped inside a larger document called an in-toto statement, then the whole thing is signed. The final signed document is known as an attestation.

At this point, two obvious questions come up:

Lets understand both.

In most projects, container images are built and published through CI/CD pipelines. Since the CI system performs the build, it is also responsible for generating the provenance document.

Then it is stored in your container registry, right next to your image. When your image is pushed to ECR, GCR, or Docker Hub, the provenance is pushed alongside it as an OCI attachment.

This means any system (eg, Kubernetes) that pulls the image can also retrieve and verify its provenance.

The following diagram shows how SLSA works in a typical CI/CD pipeline.

Here is how it works:

Next we will look at the important concepts called SLSA trust levels.

SLSA defines different levels of trust for the image build process.

It helps teams to implement security gradually instead of trying to do everything at once. As you move up the levels, the build becomes more secure and harder to tamper with.

Also, these levels provides a way to showcase your software supply chain security to customers, auditors, and regulators as well.

Lets look at each levels.

This is where most software projects start. There is no provenance, no verification, and no way to prove where an artifact came from.

At this level, the build system generates provenance for every artifact. The provenance is not yet strongly protected against tampering, but it provides an audit trail.

The build runs on a hosted CI platform such as GitHub Actions, GitLab CI etc. The platform generates and signs the provenance. In this level, forging provenance is harder because an attacker would need to compromise the CI platform itself rather than a developer workstation.

Level 3 introduces strong protections against build system tampering. It has two key requirements.

Provenance is useless if nobody checks it.

You need to enforce it in your Kubernetes cluster to ensure, only verified images gets deployed.

With tools like Kyverno, you can block any image that does not have a valid provenance as illustrated in the image below.

If you're new to SLSA, don't worry about achieving Level 3 overnight.

Start with Level 1.

Simply generating provenance for your builds gives you visibility into how your artifacts are created and provides a foundation for stronger supply chain security.

From there, you can gradually adopt signed provenance, hardened builds, and runtime verification.

If you are on GitHub Actions, you can achieve SLSA Level 3 today using the official slsa-github-generator. It uses a trusted reusable workflow that runs separately from your build job, so your build steps never touch the signing material.

The following image illustrates the GitHub Actions SLSA workflow.

If you want to try this setup, we have a detailed hands on guide where you can learn the following.

👉 Detailed Guide: SLSA Provenance Workflow using GitHub Actions

Here are three supply chain incidents every DevOps engineer should know.

In May 2026, attackers compromised multiple TanStack npm packages by abusing GitHub Actions and publishing malicious package versions. The malware targeted developer machines and CI/CD pipelines, attempting to steal GitHub tokens, cloud credentials, SSH keys, and other secrets.

Attackers compromised the build server itself. The malicious SUNBURST code never existed in source control. It was injected during compilation, then signed with the official SolarWinds certificate and shipped to ~18,000 organizations, including US government agencies. The source code was clean. The build was not.

Attackers modified the Codecov bash uploader script that thousands of CI pipelines downloaded with curl | bash. For nearly two months, the script silently collected and exfiltrated environment variables from CI jobs. This included cloud credentials, API tokens, access keys, and other secrets stored in build environments.

A widely used GitHub Action was compromised. The malicious version dumped CI runner memory and leaked secrets from 23,000+ repositories into public build logs. The root cause was simple. Many workflows trusted a mutable action reference (for example, @v44)instead of pinning to a specific commit.

You will notice a common pattern in these attacks. Attackers rarely target production systems first. Instead, they target the software supply chain. The build system, CI/CD pipeline, or build dependencies.

Once the build process was compromised, every artifact produced by it became untrustworthy.

This is exactly the problem SLSA is designed to solve. It provides a verifiable record of where, how, and by whom an artifact was built, making it much harder for attackers to tamper with the software supply chain without being detected.