In my mind’s eye, the “electric sheep” are the products we build and sell to generate revenue. To create “electric sheep”, we build “supply chain robots” that dream of “electric sheep”. The robots are our automated pipelines, our CI/CD systems, and our infrastructure. They construct the sheep, herd them along the software development lifecycle (SDLC), and shepherd them to market.
That all sounds great but, there are wolves at the door. Smart digital wolves. And they are not just trying to eat the electric sheep, they mean to reprogram the robots, poison the assembly line, and turn our own infrastructure against us. The reality of software supply chain security today is that we need supply chain robots to protect everything from the digital wolves.
After a few major attacks, the US government decided to protect itself as governments should. On May 12, 2021, the White House dropped Executive Order 14028 on Cybersecurity. And with that, if you wanted to sell to the federal government, you had a whole new set of regulations to meet.
So you skim the Executive Order. It reads like an android interpretation of lawyers and lawmakers notes on engineering security documentation. Excellent vague bits like the following:
For reference it sends you down the rabbit hole of NIST standards, which are just as vague. The next step is to leverage your company’s ISO subscription to start digging into ISO 27001. ISO 27002 guidelines give you a glimmer of hope but still no real answers.
How do you turn this mountain of abstract policy into concrete action?
SLSA (pronounced “salsa”) is a comprehensive security framework for software supply chains. Think of it as a maturity model - organizations can progressively improve their security posture by advancing through levels. Each track focuses on different aspects of the supply chain: Build focuses on artifact creation integrity, while Source focuses on code trustworthiness. The framework is designed to be practical and incrementally adoptable, allowing organizations to start where they are and improve over time. Version 1.2 introduces the reintegrated Source Track after focusing solely on Build in v1.0.
SLSA provides us with:
The framework establishes three trust boundaries encouraging the right standards, attestation, and technical controls, so we can harden the system from these threats and risks. SLSA is a check-list of standards and controls to prevent tampering, improve integrity, secure packages and infrastructure in your projects, platform, and enterprises. It is about identifying and closing attack vectors in the Supply Chain and proper governance of artifacts throughout the chain.
Validating Artifact Integrity through verification is a key component of SLSA which helps to:
Most importantly for our EO 14028 journey: SLSA translated policy requirements into technical implementation steps.
The two tracks are complementary but independent. Build Track has levels L0-L3, while Source Track has levels L1-L4. Organizations can advance on one track without necessarily being at the same level on the other, though both are important for comprehensive supply chain security. The Build Track addresses threats during the compilation and packaging phase, while Source Track addresses threats in code creation and management. Together, they provide end-to-end visibility and protection from source code to deployed artifact.
The Build Track uses provenance as a receipt for your software build. It answers three critical questions:
This matters because many supply chain attacks happen during the build phase: attackers compromise build systems, inject malicious code, or substitute artifacts. Provenance creates an auditable trail.
Build L0: No guarantees; you’re not doing SLSA yet
Build L1: Provenance exists
Build L2: Hosted build platform
Build L3: Hardened builds
Build L3 became our target for most releases. It requires significant platform investment but provides strong protection against sophisticated attacks.
Here are some things I would like to see in the future for Build Track beyond L3:
The Source Track addresses “How do we know this source code is what the organization intended?” It focuses on the change management process: how code gets into the repository and onto protected branches.
Source L1: Version controlled
Source L2: Source attestations and controls
Source L3: Protected references with continuous enforcement
Source L4: Two-party review
SLSA isn’t just a checklist, it is a comprehensive framework that addresses supply chain security systematically. The two tracks, source code security and build integrity, complement each other. No need to achieve the highest levels immediately, start where you are and progress incrementally. The attestation model is powerful. It creates verifiable evidence that can be validated by any consumer without requiring trust in just one party.
Implementation details vary by ecosystem because what works for Python is different from what works for Rust, but the principles remain consistent. Start with Build L1 or Source L2 and progress from there. Both tracks are important for comprehensive security, though you may prioritize one based on your specific threats.
If you have a lot of electric sheep, you need a fleet of supply chain robots to tend them. Build a platform to manage the chaos, herd the cats, eliminate the unicorns, and eradicate the chaos from your Software Supply Chain.
SLSA is how we get from safe enough to being as resilient as possible, at any link in the chain.
When we started this journey, Executive Order 14028 was nothing more than pages of requirements with no clear implementation path. SLSA translated those abstract requirements into concrete, measurable levels. Build Track mapped to build tool requirements and environment hardening. Source Track mapped to access control and provenance collection. As more requirements emerged from the EU, Australia, India, and others, SLSA provided a consistent framework to address them all.
The incremental nature of SLSA levels meant we could show progress, justify investment, and continuously improve rather than attempting a massive all-at-once transformation.
You now have an EO 14028 compliant pipeline. Use it for everything.
The pipeline builds the pipeline. Use SLSA as your roadmap. Build a platform to manage the chaos.
And remember: compliance doesn’t equal security, but SLSA helps you achieve both.
Brett Smith is a Distinguished Software Developer at SAS Institute, where he helps architect and secure supply chain pipelines for an Analytics, AI, and Data Management company.
]]>With the introduction of the Source Track, SLSA v1.2 represents a major milestone in the development of SLSA. The Source Track covers threats from the authoring and reviewing and management of source code. For more details on how SLSA addresses these threats please refer to Threats & mitigations.
Please, refer to the What’s new section for further details.
SLSA v1.2 is backwards compatible with SLSA v1.1.
The SLSA specification follows the Community Specification lifecycle going through several stages of maturation. This release is the culmination of that process. During the development of SLSA v1.2 we received and addressed feedback from the community. We’d like to thank everyone that took the time to review the release candidates and PRs and everyone that contributed to its development.
After today’s release development of the SLSA specification continues with the development of the Build Environment Track and the Dependency Track. Learn how you can get involved with their development.
]]>With the introduction of the Source Track, SLSA v1.2 represents a major milestone in the development of SLSA. Indeed, while SLSA v1.0 introduced the notion of tracks with different levels focusing on different aspects of the software supply chain, its scope was limited to the Build Track, a narrower scope than what SLSA v0.1 covered. The Source Track picks up the source management related requirements that v0.1 touched on but in a much more complete and thorough way, comparable to what was done in the Build Track.
Please, refer to the What’s new section for further details.
SLSA v1.2 is backwards compatible with SLSA v1.1.
The SLSA specification follows the Community Specification lifecycle going through several stages of maturation. The publication of a candidate for Approved Specification starts a 2 week review period during which the community at large is invited to review the draft and raise any issues. If you do find any issue, please, open an issue on GitHub. If no major issues are found during this review period the v1.2 RC2 draft will then be published as Version 1.2, the new Approved Specification, effectively replacing Version 1.1. Otherwise a v1.2 RC3 will be published instead.
]]>This example runs through the release workflow in the SLSA E2E demo repository. If you want to try running the verification steps yourself, download the latest AMPEL binary. We also recommend downloading bnd to inspect the generated attestations.
We’ll walk through the steps in the workflow. When the workflow runs, all the verification
results are displayed on the run page on GitHub (example).
If you look at the execution output (example),
you’ll notice that those steps that involve AMPEL are marked with its traffic
lights (🔴🟡🟢), those that use bnd are marked with its pretzel icon (🥨).
This walkthrough will analyze how the Fritoto project releases secure binaries. Fritoto (a play on Friday + In-toto) is a utility that generates attestations that inform if a software piece was built on a Friday. Why? Well… you don’t deploy on Fridays, right? Fritoto’s attestations let you write policies to prevent shipping software laced with Fridayness.
(Note that Fritoto is a joke project, but it is fully functional if you want to attest those cursed EoW builds).
As a security tool, Fritoto has implemented a secure end-to-end build process, starting with a hardened revision history and extending all the way to the secure execution of its binaries.
Let’s inspect their hardened supply chain security architecture!
All security guardrails are worthless if attackers can inject malicious code into
the codebase. To ensure all changes going into the codebase are properly vetted,
the Fritoto team have secured their git repository with
sourcetool, the SLSA Source
Track CLI.
The SLSA Source tools allowed the project to onboard its repository in minutes, hardening the revision history and setting up tools to continuously check that repository security controls are properly set. Once the SLSA Source workflows are in place, each commit receives its own SLSA Source attestations, confirming that all changes have been merged while the security controls were in place.
By checking the SLSA Source attestations, Fritoto makes sure all builds are run on a commit guaranteed to be part of a revision history were all changes were properly vetted.
Before allowing any other steps of the release process run, Fritoto leverages AMPEL to enforce a policy that verifies the build point’s source attestations:
- name: 🔴🟡🟢 Verify Build Point Commit to be SLSA Source Level 3+
uses: carabiner-dev/actions/ampel/verify@HEAD
with:
subject: "gitCommit:${{ github.sha }}"
policy: "git+https://github.com/carabiner-dev/policies#vsa/slsa-source-level3.json"
collector: "note:https://github.com/${{ github.repository }}@${{ github.sha }}"
signer: "sigstore::https://token.actions.githubusercontent.com::https://github.com/slsa-framework/source-actions/.github/workflows/compute_slsa_source.yml@refs/heads/main"
attest: false
- name: 🥨 Export source attestations
id: export-source-attestations
run: |
bnd read note:${{ github.repository }}@${{ github.sha }} --jsonl >> .attestations/attestations.bundle.jsonl
echo "" >> .attestations/attestations.bundle.jsonl
In this fragment of the release workflow, AMPEL pulls the commit’s VSA (Verification Summary Attestation) from the git commit notes and verifies that the repository had Source Level 3 protections in place, ensuring no rogue commits altered the code base.
Second, using bnd, we extract the attestations and add them to a jsonl (linear JSON) bundle where we’ll collect all the build process’ security metadata.
Now that the source is trusted, the Fritoto release process checks its builder. It uses Chainguard’s Go image to build binaries for the supported platforms. This image ships with some attestations already built in, making it is easy to verify with AMPEL. We will leverage its SLSA Build provenance attestation to make sure the image and the Go compiler within come from Chainguard’s SLSA3 build system.
To verify it, AMPEL pulls the provenance attestations attached to the image using
its coci (Cosign/OCI) collector driver. Then it runs them through the project’s
builder PolicySet. AMPEL will also generate a VSA capturing the results of the
verification which we’ll also save for later in our jsonl file.
- name: 🔴🟡🟢 Verify Builder Image
uses: carabiner-dev/actions/ampel/verify@HEAD
with:
# The verification subjest: The image digest
subject: "${{ steps.digests.outputs.builder }}"
# Use the modified policy set
policy: "git+https://github.com/${{ github.repository }}#policies/fritoto-verify-builder.hjson"
# Collect builder attestations attached to the image
collector: "coci:cgr.dev/chainguard/go"
# We don't specify the signer here as it's baked in the policy code, but
# we could do it:
# signer: "sigstore::https://token.actions.githubusercontent.com::https://github.com/slsa-framework/source-actions/.github/workflows/compute_slsa_source.ml@refs/heads/main"
attest: false
A PolicySet is a group of policies that AMPEL applies together. Fritoto’s build image PolicySet performs the verifications suggested in the SLSA spec by reusing three policies from AMPEL’s community repository:
"policies": [
{
"id": "slsa-builder-id",
"source": {
"location": { "uri": "git+https://github.com/carabiner-dev/policies#slsa/slsa-builder-id.json" }
},
"meta": { "controls": [ { "framework": "SLSA", "class": "BUILD", "id": "LEVEL_3" } ] }
},
{
"id": "slsa-build-type",
"source": {
"location": { "uri": "git+https://github.com/carabiner-dev/policies#slsa/slsa-build-type.json" }
},
"meta": { "controls": [ { "framework": "SLSA", "class": "BUILD", "id": "LEVEL_3" } ] }
},
{
"id": "slsa-build-point",
"source": {
"location": { "uri": "git+https://github.com/carabiner-dev/policies#slsa/slsa-build-point.json" }
},
"meta": {
"controls": [ { "framework": "SLSA", "class": "BUILD", "id": "LEVEL_3" } ],
"enforce": "OFF"
}
}
]
The policies are referenced remotely but if you look at each policy, you’ll see that they verify the build type, look for the expected builder ID, and verify the build point (although this one is not enforced in the policy set for now, as the build point is missing from the image attestation).
The policy set defines the contextual data required by each policy. Also, you’ll notice that the signer identities are verified and “baked” into the policyset code:
"identities": [
{
"sigstore": {
"issuer": "https://token.actions.githubusercontent.com",
"identity": "https://github.com/chainguard-images/images/.github/workflows/release.yaml@refs/heads/main"
}
}
]
By codifying the signer identities and contextual values in the policy, you can make them immutable when you sign the policy.
As part of their build process, the Fritoto builder creates additional attestations to ensure the build is safe to ship to its users and increase the transparency of the released assets. All of these additional attestations will describe data about the build commit, they will be collected and checked before releasing the binaries.
The following additional attestations are produced before the build:
First, to keep track of all dependencies, the build process builds an SPDX
Software Build of Materials. The release workflow uses Carabiner’s
unpack utility as it generates an
attested SBOM natively but you can use any SBOM generator such as Syft or Trivy
and then tie the SBOM to the commit in an attestation with bnd predicate.
Next, the build process generates an attestation of an OSV vulnerability scan. It is wrapped and signed as an attestation.
But alas! OSV scanner found that the project is susceptible to CVE-2020-8911 and CVE-2020-8912 (BTW, we’ve injected these vulns on purpose for this demo 😇). Later in the release process, AMPEL will gate on any detected vulnerabilities before shipping the binaries, so we need to address them or the policy will fail. How? Well, we VEX!
VEX, the Vulnerability Exploitability Exchange lets software authors and other stakeholders communicate if a software piece is affected by a vulnerability.
As these CVEs are known not to be exploitable in Fritoto,
the release engineers issue two OpenVEX attestations assessing the project as
not_affected
by them. They do this using vexctl the
OpenVEX CLI that manages VEX documents, and then signing them into attestations
using bnd. In the demo, the VEX documents are generated on the fly and will be
published in the attestations bundle.
Next up, Fritoto leverages beaker, an experimental tool from Carabiner Systems that runs your project’s tests and generates a standard test-results attestation from the tests run. Since it is just a standard statement, the same policy works with a tests-result attestation from any other tool.
Again, this statement will describe the test run at the specific build point, that is, it will have the commit’s sha as its subject.
It is time to run the build. But before doing so, we need to verify that the conditions snapshotted in all the attested data check out with out expectations. AMPEL will gate the build by applying a preflight PolicySet to all the collected attestations, stopping the workflow if anything goes wrong.
# Gate the build enforcing the preflight policy
- name: 🔴🟡🟢 Run Release Pre-flight Verification
uses: carabiner-dev/actions/ampel/verify@HEAD
with:
subject: "sha1:${{ github.sha }}"
policy: "git+https://github.com/${{ github.repository }}#policies/fritoto-gate-build.hjson"
collector: "jsonl:.attestations/attestations.bundle.jsonl"
attest: false
In this case, AMPEL collects the attestations with its jsonl collector from the file that the release process has been assembling on each step. You’ll notice that the policy set is referenced remotely; this ensures that the policy code cannot be changed during the build process. Note that while AMPEL policies and policy sets can be signed, we are using them unsigned in the demo to see their code more easily.
We won’t go into the policy details, but you can check the policy set code and see that it reuses three community polices that:
As we mentioned before, the OSV scan returned two CVEs, but thanks to the OpenVEX attestations, the release is allowed to run because the non-exploitable vulnerabilities policy leverages the VEX transformer in AMPEL. This transformer reads attested VEX statements and suppresses any non-exploitable vulnerabilities according to the signed VEX data.
Next, the workflow runs the build using the verified image. After running the build script, we’ll have the binaries of the Fritoto attester for various platforms ready to ship.
After the build is done, the workflow will assemble the binaries’ SLSA Build provenance attestation using the Kubernetes Tejolote attester. Tejolote queries the build system and extracts data about the jobs that produced the artifacts, their build environment, and their configuration:
- name: 🌶️ Generate SLSA Provenance Attestation
id: tejolote
run: |
# Generate the provenance attestation with the Tejolote attester
tejolote attest github://${{github.repository}}/"${GITHUB_RUN_ID}" \
--artifacts file:$(pwd)/bin/ \
--output .attestations/provenance.json --slsa="1.0" \
--vcs-url=cgr.dev/chainguard/go@${{ steps.digests.outputs.builder }}
# Sign the provenance attestation
bnd statement .attestations/provenance.json >> .attestations/attestations.bundle.jsonl
echo "" >> .attestations/attestations.bundle.jsonl
This step adds the provenance attestation to the same jsonl bundle with the rest of the attestations which we will publish along with the artifacts.
Note that for demonstration purposes, the build process is running Tejolote in the same job, which is not ideal (or SLSA 3 compliant). Tejolote is designed to run outside of the workflow; it observes the build system running and attests when the build is done. But for the demo, it will do for now.
Finally, Fritoto performs a SLSA Build and Source verification on the built binaries to ensure everything securely ties together. To spare downstream consumers from doing the same heavy checks, the project will issue separate VSAs, one for each binary, which can be later used to check that every verification up to this point actually took place and the results passed as expected (see End User Verification).
Here, the workflow runs ampel verify on each binary, applying the
fritoto-gate-publish.hjson,
and attests the results in individual VSAs:
- name: 🔴🟡🟢 Verify All Artifacts and Generate VSAs
id: artifact-vsas
run: |
echo "$HOME/.carabiner/bin" >> $GITHUB_PATH
ls -l bin/
for binfile in $(ls bin/\*);
do ampel verify "$binfile" \
--policy "git+https://github.com/${{ github.repository }}#policies/fritoto-gate-publish.hjson" \
--collector jsonl:.attestations/attestations.bundle.jsonl \
--attest-results --attest-format=vsa --results-path=vsa.tmp.json \
--format=html >> $GITHUB_STEP_SUMMARY;
bnd statement vsa.tmp.json >> .attestations/attestations.bundle.jsonl;
echo "" >> .attestations/attestations.bundle.jsonl;
rm -f vsa.tmp.json;
done
The fritoto-gate-publish policy set performs the following checks:
SLSA_BUILD_LEVEL3SLSA_SOURCE_3By verifying the VSAs, we don’t have to do all the checks for the image and source again!
Verifying this step is special as we will mix attestations that describe different components of the build process: the built binaries (from the build provenance), the git commit (the source VSAs), and the builder image (from the VSAs generated by AMPEL when it verified the container). Now, the new VSAs we are about to produce will have each fritoto binary as their subject… how do we check all those subjectes from a single policy set? The answer: Chain them!
To support this scenario, AMPEL supports the notion of chained subjects. The chain connects an initial subject (the Fritoto binary) to another resource, such as the build image or the source commit.
To connect the binary in the policy to the image and its build point commit, the Fritoto team wrote selectors that act as carabiners clipping the binary to both by extracting data from the build provenance attestation. Here is an example, shortened for illustration (this is the HJSON variant with comments):
chain: [
{
predicate: {
type: "https://slsa.dev/provenance/v1",
// The selector chains the attestation. It looks in the
// resolvedDependencies dection of the build provenance
// for the buildPointRepo context value defined above.
selector: '''
predicates[0].data.buildDefinition.resolvedDependencies.map(
dep, dep.uri.startsWith(context.buildPointRepo + '@'), dep
)[0]
'''
}
}
]
This selector code extracts the URI from the resolvedDependencies field in the
build provenance when it matches the repository name. AMPEL then synthesizes a
new in-toto subject from the extracted data and re-fetches the new subject’s
attestations, evaluating the policy on the commit instead of the binary.
After running the prerelease policy, AMPEL generates a SLSA VSA for each binary, attesting to everything we’ve seen so far. Here is an example:
{
"predicateType": "https://slsa.dev/verification_summary/v1",
"predicate": {
"dependencyLevels": {
"SLSA_BUILD_LEVEL_3": "1",
"SLSA_SOURCE_3": "1"
},
"inputAttestations": [
{
"digest": {
"sha256": "2f0f9f9a37f20449875d851b74cfaaaeaccb954a71c8d1ce78fba7bcbfb7990f",
"sha512": "f045158113f9cc8cd298c3903d5eb94aef5113c09f00e69d01e045aae71d015a9d6d535591d92571048c952807ed9f9cc4a3b9f877efc46fc76ad076c83b61e0"
},
"uri": "jsonl:.attestations/attestations.bundle.jsonl#12"
},
{
"digest": {
"sha256": "6e437c982c3eb448f08feee2549829923f7b61da2d485fbe34571436c27b1ef7",
"sha512": "de594ea3853663abf58d804ee4d5eca056a7eb193a5694abce4f8d1c15025f073a39319bf45f14a5d0bff1b24188917e6a5a58d774a8c820b25a1639dd2b70bb"
},
"uri": "jsonl:.attestations/attestations.bundle.jsonl#6"
},
{
"digest": {
"sha256": "ebf2acb09c2febca789fd30ab4badbdb73d574caa7a747387cc47d68e10204e7",
"sha512": "fff6203a5b0a183c0ca0bd7793a6b8de7450d557f57ccb663ac9f136b0de3fc8acdb7cc4f52e8932b774924e0fc331410a314a12f6d4af874013a3c4dd958873"
},
"uri": "jsonl:.attestations/attestations.bundle.jsonl#1"
},
{
"digest": {
"sha256": "d78b94aec61b5d8e1fcf1f4b3a486748d52d1de45072530f95908d5798e26c9a",
"sha512": "7003ca97a7519986d80737596a6da22dbefc4101e3082c67f647566f5a87670ebd7ecfb1cf6bf7c38d934122f0e57ef35a4d9dd93e29cc802e5fe76492db05c9"
},
"uri": "jsonl:.attestations/attestations.bundle.jsonl#3"
}
],
"policy": {
"digest": {
"sha256": "175812c1dd152826cdd604aa14a35674c2f5073ef7a822cf8a2dde02026c03bd",
"sha512": "195fcb1023068374c404bf679ce7697e80b45e7a8736d58bb64e89fea5d9f5afa8cfcbc4411a83acd6c18131e7198f717e045d7649388599700008272c12e342"
}
},
"resourceUri": "https://github.com/carabiner-dev/demo-slsa-e2e/releases/download/v0.1.8/fritoto-linux-amd64",
"slsaVersion": "1.1",
"timeVerified": "2025-10-10T01:14:42.461212072Z",
"verificationResult": "PASSED",
"verifiedLevels": [
"SLSA_BUILD_LEVEL_2"
],
"verifier": {
"id": "https://carabiner.dev/ampel@v1"
}
},
"_type": "",
"type": "https://in-toto.io/Statement/v1",
"subject": [
{
"name": "fritoto-linux-amd64",
"uri": "bin/fritoto-linux-amd64",
"digest": {
"sha256": "3e6d22582191fb4b22632907f3b24a22629325e32b6cd4fe9692a63938819983",
"sha512": "3f06fb85ff6aef9d2a86590ab83a8b9c14dacc85e29e4d273993b01426a752fc2fe0ead6c22dcaac1ed31ec50e9cbadea63b4e2daf3c58cfc63df398e343dc5e"
}
}
]
}
Notice in the VSA the subject is the darwin/arm64 binary and how its
SLSA_BUILD_LEVEL_2 level is recorded, but also the verified levels of its
dependencies. The important parts in this document are:
PASSED)SLSA_BUILD_LEVEL_2)dependencyLevels):
SLSA_BUILD_LEVEL_3 (the go container image)SLSA_SOURCE_3 (the build point commit, protected with the SLSA source tools)This VSA can be used to communicate to users all the verifications performed on the binaries, they can act as guarantees that the released assets were built in a secure environment.
Now that the Fritoto project has produced VSAs for all its binaries, the project users should be able to use them! Especially since Fritoto is a “security” (wink wink) tool that runs in CI. So how can a user verify the executables?
To verify the Fritoto binaries, users only need the latest release of AMPEL installed. AMPEL can check the binary directly or verify its hash (as published on the project’s release page). The Fritoto team has published a policy to verify the project’s binaries. You don’t need to download the policy or the attestations; AMPEL can fetch them for you when it needs them using the releases collector driver:
# Download the binary from GitHub:
curl -LO https://github.com/carabiner-dev/demo-slsa-e2e/releases/download/v0.1.8/fritoto-linux-amd64
# Verify it using the fritoto-check-artifacts policy which uses the VSA.
ampel verify fritoto-linux-amd64 \
--policy "git+https://github.com/carabiner-dev/demo-slsa-e2e#policies/fritoto-check-artifacts.json" \
--collector release:carabiner-dev/demo-slsa-e2e@v0.1.8
The results in the terminal show the checks performed on the VSA with their respective verification results:
+--------------------------------------------------------------------------------------------------------------------+
| ⬤⬤⬤AMPEL: Evaluation Results |
+-------------------------+-------------------------+--------+-------------------------------------------------------+
| PolicySet | fritoto-check-artifacts | Date | 2025-10-09 19:25:06.805181588 -0600 CST |
+-------------------------+-------------------------+--------+-------------------------------------------------------+
| Status: ● PASS | Subject | - sha256:884aa2480316522ff74cebf2eb2ca16d... |
+-------------------------+-------------------------+--------+-------------------------------------------------------+
| Policy | Controls | Status | Details |
+-------------------------+-------------------------+--------+-------------------------------------------------------+
| slsa-build-deps-level-3 | BUILD-LEVEL_3 | ● PASS | All verified dependencies are SLSA_BUILD_LEVEL_3+ |
| vsa-verify-verifier | - | ● PASS | Attestation was issued by trusted verifier |
| vsa-verify-resourceuri | - | ● PASS | VSA verification of expected resource URI |
| slsa-build-level-2 | BUILD-LEVEL_2 | ● PASS | VSA attesting a SLSA_BUILD_2+ compliance verification |
+-------------------------+-------------------------+--------+-------------------------------------------------------+
The Fritoto project releases a lot of security metadata along with its binaries. The attestations bundle contains 17 statements, if you want to see what is in there, you can use bnd, the attestations multitool:
bnd read release:carabiner-dev/demo-slsa-e2e@v0.1.8
🔎 Query Results:
-----------------
Attestation #0
✉️ Envelope Media Type: application/vnd.dev.sigstore.bundle.v0.3+json
🔏 Signer identity: sigstore::https://token.actions.githubusercontent.com::https://github.com/slsa-framework/source-actions/.github/workflows/compute_slsa_source.yml@refs/heads/main
📃 Attestation Details:
Predicate Type: https://github.com/slsa-framework/slsa-source-poc/source-provenance/v1-draft
Attestation Subjects:
- gitCommit: cb5a32d292d1222e8d55a5d0d0585e2da0efe7a1
Attestation #1
...
This command displays details of the release attestations: who signed them, their subjects, and their type. Using bnd you can extract the attestations or view the predicates or unpack them to single files.
Exploring the secure data should give you an idea of the kinds of policies that can be written, and since all the tools used here are open source, you can use them in your projects too! If you write something cool, consider contributing it to AMPEL’s community policies for others to reuse!
This case study went through the basic steps of a secure build leveraging the SLSA model:
The example project repository is open source, feel free to suggest improvements or fix any bugs, just not the CVEs,please ;)
This is a list of the tools used in the demo, most of them have GitHub actions you can use, check the Fritoto release workflow for examples.
Fritoto, the SLSA e2e demo:
https://github.com/carabiner-dev/demo-slsa-e2e
🔴🟡🟢 AMPEL, The Amazing Multipurpose Policy Engine (and L)
https://github.com/carabiner-dev/ampel
🥨 bnd, the attestation multitool
https://github.com/carabiner-dev/bnd
sourcetool, SLSA Source’s CLI to secure your git history
https://github.com/slsa-framework/source-tool
Tejolote, The kubernetes SLSA Build Attestter
https://github.com/kubernetes-sigs/tejolote
OSV Scanner, Vulnerability scanner leveraging OSV data
https://github.com/google/osv-scanner
Vexctl, OpenVEX’s tool to manage vex documents
https://github.com/openvex/vexctl
Beaker, Test run attester
https://github.com/carabiner-dev/beaker
Unpack, experimental dependency extractor
https://github.com/carabiner-dev/unpack
We’re looking for examples in the form of blog posts that document the entire end-to-end story with working implementations that people can try for themselves.
There’s no specific deadline, but a reasonable goal would be to have example implementations published by September 30th, 2025.
For the purposes of the end-to-end story we’ve broken the SDLC into 5 stages which we’d expect an end-to-end implementation to cover: Source, Build, Verification, Publication, and Use.
The source stage covers applying SLSA requirements to source code management leveraging the SLSA Source Track proposed in SLSA 1.2 RC1.
Implementations should:
Potential tools: slsa-source-poc, gittuf
The build stage covers applying SLSA requirements to the way software is built and how the dependencies used in a build are managed. It leverages the SLSA Build track, and the draft Build Environment and Dependency tracks.
Implementations should:
Potential tools: GitHub provenance generation, SLSA GitHub Generator, Konflux, Google Cloud Build, osv scanner (vuln scanning), vexflow, hermeto
The verification stage covers the point at which a built software artifact is verified against expectations. This will go beyond the basics identified in verifying build artifacts and include verifying Source, Build Environment, and Dependency information.
Implementations should:
Potential tools: Ampel, Conforma, slsa-verifier
The publication stage covers the point at which a software artifact is made available to consumers.
Implementations should ensure that:
The use stage covers the point at which a consumer is going to use the artifact.
Implementations should:
Potential tools: Drop, slsa-verifier
Some implementations may wish to go above and beyond what’s been requested.
That may include:
Submissions should document:
To submit your example end-to-end implementations please either send a PR creating the blog post yourself (example) or create an issue with the title “SLSA e2e: …”. If your example is too large for either of these formats, you may put the remaining walkthrough content in an external resource (i.e. a git repository) and link to it.
If you have any questions, or would like any feedback on your proposal, please reach out in Slack or by creating an issue.
]]>With the introduction of the Source Track, SLSA v1.2 represents a major milestone in the development of SLSA. Indeed, while SLSA v1.0 introduced the notion of tracks with different levels focusing on different aspects of the software supply chain, its scope was limited to the Build Track, a narrower scope than what SLSA v0.1 covered. The Source Track picks up the source management related requirements that v0.1 touched on but in a much more complete and thorough way, comparable to what was done in the Build Track.
Please, refer to the What’s new section for further details.
SLSA v1.2 is backwards compatible with SLSA v1.1.
The SLSA specification follows the Community Specification lifecycle going through several stages of maturation. The publication of a candidate for Approved Specification starts a 2 week review period during which the community at large is invited to review the draft and raise any issues. If you do find any issue, please, open an issue on GitHub. If no major issues are found during this review period the v1.2 RC1 draft will then be published as Version 1.2, the new Approved Specification, effectively replacing Version 1.1. Otherwise a v1.2 RC2 will be published instead.
]]>The biggest changes made or proposed include:
You can find all the changes merged and proposed during the sprint here.
As a part of our process we reviewed how the SLSA Source PoC claims to meet the requirements (design) to see if we agree on the approach (this helps make sure we’re all thinking the same thing about the requirements!) and if we can find any gaps in what it’s doing. The verdict was quite positive! It seems like a reasonable model that can allow implementation of the SLSA Source Track for GitHub users and will hopefully serve as a model that users of other source control platforms can use to implement their own Source Track compliant SCS (with or without the help of the platform they rely on). There are some limitations from this approach and it does make some things more difficult. So it may also result in some feature requests for source platforms that could make controls even stronger. (issue)
Of course the Source PoC isn’t done yet and the design and implementation will need some updates to match the changes made this week, and whatever the spec winds up being when approved. It also needs some TLC before it’s safe and easy to use. This approved proposal for funding from the OpenSSF TAC will help there.
Two-party review is a controversial topic within the SLSA community and as a result was deferred due to an inability to get agreement on if it should be included. We’re taking another shot at it now because the recently revamped slsa.dev/threats page makes it clear that two-party review is the strongest control we have against many of the threats listed for threat B - Modifying the source.
As noted by some, this is one of the first controls enterprises enable while also being a control that can be very difficult for small projects to enable. To account for this we are making this the highest source level as 1-3 are much more easily attained by single-maintainer projects. Those projects can advance as far as possible without adopting two-party review.
To further reduce the burden of this requirement we suggest that reviews cover ‘security relevant properties’ to allow reviewers to focus on the most pressing aspects of code-review and avoid the perception that these reviews require discussion of ‘trivial’ issues such as variable names. Of course, organizations may still set a higher bar for review if they wish.
We discussed some other changes but didn’t get time to include them.
There are some security-relevant properties that don’t neatly fit into a level, that affect multiple levels, or that producers might like to claim in a different order (e.g. a producer might want to attest that they conduct TWO_PARTY_REVIEW before they can claim they use a Source Control System that meets all the requirements of Source Level 3).
SLSA “Properties” would be a mechanism for enforcing and communicating these claims that is independent of any implementation. (issue)
With the release of the Source Track, we will establish clear guidelines for how SCS can issue tamper-resistant claims about revisions. We need to add better documentation on how consumers should verify those claims. How can a consumer verify a revision is the SLSA level they expect? How can they verify that the revision came from the repo/branch/tag they expect? How can they verify that the policy is still what they want? How can they verify that the policy continuity is still intact?
We also need to document how the Source track and the Build track fit together. Most users consume source indirectly in the form of artifacts built from that source. (issue)
We’d like to get the source track released (or at least in a release-candidate) in June ahead of OSS NA. To do that we’ll need to evaluate open issues and address them as needed, comb through the spec to make sure the language is right and all the links work. Most importantly we’ll need to get and address feedback from the community. We made a lot of progress, but there’s still a lot to do!
]]>Following the Community Specification lifecycle, the SLSA v1.1 Release Candidate 2 specification went through a 2-week review period during which no major issues were raised. As a result, SLSA v1.1 is now being published as an Approved Specification.
This release brings several changes aimed at enhancing the clarity and usability of the v1.0 specification. It also introduces backwards-compatible clarifications to the SLSA threat model, attestation model and verification procedure. This includes the addition of verifier metadata to the Verification Summary Attestation (VSA) format. Please, refer to the What’s new section for further details.
SLSA 1.1 is backwards compatible with SLSA 1.0.
So what’s next? The SLSA specification group has been busy developing several new tracks covering critical areas of the software supply chain. Read more about them here in the future directions section. Come join the group and contribute to the next version of SLSA!
]]>What does this update mean for SLSA implementors? Good news! This means that SLSA 1.1 is backwards compatible with SLSA 1.0.
Although this is a relatively minor update, the SLSA specification group has also been busy developing several new tracks covering areas such as source and build environment. We had originally hoped to release these 1.1 improvements as part of larger update but in the end we felt that the 1.1 release was warranted.
So what’s next? The SLSA specification follows the Community Specification lifecycle going through several stages of maturation. The publication of a candidate for Approved Specification starts a 2 week review period during which the community at large is invited to review the draft and raise any issues. If you do find any issue, please, open an issue on GitHub. If no major issues are found during this review period the V1.1 RC2 draft will then be published as Version 1.1, the new Approved Specification, effectively replacing Version 1.0.
]]>This blog post explores the attacks from the defender’s perspective and highlights how SLSA can be used to help defend against them. It also describes some additional capabilities which might be required to mitigate this and other supply chain risks more robustly.
The convenience of package registries has been recognized by developers and organizations worldwide as an effective way to manage and distribute internally developed software packages using existing tooling. One common approach involves running an internal, private instance of a package registry to distribute internal dependencies and configuring all build processes to first look for a package in the private registry and only if it is not found there going to the public instance of the package registry to fetch it1.
This works but is fragile. If someone in the organization attempts to build software that uses internal packages but doesn’t correctly configure the build to use the private registry instance first then the package installer will attempt to fetch internal packages from the public registry instance. Under normal circumstances this will return an error, as the internal package name would not be present in the public instance.
The attacker begins by performing reconnaissance to acquire names of internal packages. This can be done using a number of techniques, e.g., trawling through organization’s open source repositories, inspecting shipped software or simply guessing the names. Once the attacker has the names of internal packages, they register these targeted packages with the public registry and release a new version with a malicious payload. At this point the attacker has to wait for one of the misconfigured builds to run and use the attacker’s package — resulting in compromise. Effective use of this technique is described in detail in blog posts such as Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies.
The workflow for developers to add a new dependency to a software project commonly involves modification of a manifest file to list the new package by its name and version. The package name is usually manually typed in, copied/pasted from the web, or added by the IDE. Most of the input modes that involve humans are prone to transcription errors and typos, ranging from missing hyphens, lookalike characters, to transposed letters. Under normal circumstances the build would fail if a non-existent dependency is requested.
The attacker pre-registers (or “squats”) a large number of package names with commonly seen typos in them—usually using popular package names as the starting point—and waits for victims to install their packages. The attack is opportunistic since, unlike dependency confusion, it doesn’t target a specific organization. Notably, however, unlike dependency confusion, this attack has the potential to result in a more severe and hard to detect compromise. Public availability of packages that attackers target for squatting enables them to distribute original copies of the targeted packages and only deliver malicious payload at a later date by releasing an update. This attack vector can result in applications incorporating and using the attacker’s package in production.
There are a number of potential vectors that attackers can use as the source of names to squat on to increase the chances of success, e.g. package names popular in other ecosystems, variants of the package name used by Linux distributions or OSS package names “hallucinated” by LLMs.
The fragility of just using package names as the way to identify software packages is hopefully obvious by now. Let’s first explore common recommendations(1, 2). to mitigate dependency confusion attacks and their limitations:
In case of typosquatting attacks the mitigation is not very straightforward and for the most part requires intervention at the point when developers are adding a new dependency. Effective mitigation could involve presenting the developer with metadata about the package being added (e.g. number of dependents, downloads) and prompting them to verify and ensure that the package being installed is the one that developer intended. This unscalable approach is prone to human errors, which can happen for reasons ranging from time pressure and fatigue to the lack of security expertise and simple misreading of key parts of metadata.
Now let’s look at how SLSA’s existing controls can can be used to prevent each of the attacks.
A much more robust way to address dependency confusion is to use SLSA. SLSA build provenance contains metadata about an artifact, which includes the URL of the source repository and identifies the build system that produced the artifact. This metadata enables secure binding of the package name and version to the canonical source repository and its build system, which is referred to as expectations forming in SLSA.
Let’s examine how SLSA build provenance prevents successful dependency confusion exploitation:
Attackers are unable to forge SLSA Level 2+ build provenance thus all dependency confusion attempts will be immediately detected due to a different canonical source repository or builder ID. Native support for SLSA build provenance and its verification in ecosystems like npm will enable this robust form of protection against dependency confusion attacks.
Dealing with typosquatting attacks is trickier because at the time of the attack the developer is adding a new dependency, potentially interacting with it for the first time. Trust on first use (TOFU) is a common approach to bootstrapping trust and forming expectations, however, since it’s impossible to know the developer’s intent, all tooling can do is present them with the metadata about the package they are adding. Unfortunately that metadata could be for the attacker’s impostor package.
Effective mitigation of typosquatting attacks requires ongoing integration of heuristics to proactively flag packages that appear like typosquatting attempts into all workflows that add new dependencies. Heuristics could range from evaluation over static data (e.g. package age) to ones requiring more time and resources (e.g. graph resolution or dynamic analysis). Managed ingestion, described below, is one very efficient and effective way to deploy such protections across larger enterprises.
Effective OSS supply chain security risk management hinges on an organization’s ability to control what OSS can be used in an organization’s products. This concept is not new, as it mirrors the approach taken in food supply chain management, where control over the ingredients included in food products is paramount. The concept is also reflected in OpenSSF’s s2c2f framework, which highlights control over ingestion in organizations as a crucial first step towards securing their software supply chains.
For a typical build process this means control over resolution of the OSS dependency graph and retrieval of the resolved dependencies from the Internet. Historically both processes lacked explicit control and transparency leading to a significant level of trust being placed in package managers and their associated registries.
Managed ingestion describes a dedicated deliberate process that happens separately from the build and involves an organization importing and assessing OSS packages before making them available to developers internally. While there is more than one way to implement managed ingestion, combining managed ingestion with existing artifact management solutions creates a very potent capability that provides organizations with control over the graph resolution and an opportunity for centralized supply chain risk management. Native support for different package ecosystems provided by most modern artifact management solutions ensures compatibility with most existing build and dependency management tools.
In this context, based on practical experience, managed ingestion needs to provide the following capabilities:
The process of using OSS packages via registries presents a lot of risks beyond typosquatting and dependency confusion—and requires the same level of attention and control as the build process itself. Managed ingestion is the fundamental capability required to successfully manage OSS supply chain risk. As part of the ongoing SLSA dependencies track effort we will work to formalize these concepts, including those from s2c2f, within the SLSA specification.
Multi-registry behaviour is ecosystem and configuration specific, e.g. PyPI configured with the discouraged –extra-index-url flag would pick the highest version if a package is present in private and public instance. Overall the mechanics of the attack remain the same. ↩