---
title: "SLSA End-to-End: Request for examples"
author: "Andrew McNamara, Tom Hennen"
is_guest_post: false
---

This is a request for examples (RFE) for an end-to-end
implementation of the Supply-chain Levels for Software Artifacts
([SLSA](slsa.dev)) framework. The goal is to create a comprehensive
demonstration of how SLSA can be used to secure the software supply chain, from
source code to end-user consumption. These implementations will serve as a
reference for the community, showcasing best practices and providing a clear
adoption path for organizations looking to improve their software supply chain
security.

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.

## Timeline

There’s no specific deadline, but a reasonable goal would be to have example
implementations published by September 30th, 2025.

## Stages

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.

### Source

The source stage covers applying SLSA requirements to source code management leveraging the
SLSA Source Track
[proposed in SLSA 1.2 RC1](/spec/v1.2-rc1/tracks##source-track).

Implementations should:

-   **Protect a source repo with the SLSA Source Track:** Implement SLSA Source
  Level 3 for source control, including measures like branch protection,
  mandatory code review, and protection against tampering with the source code
  history. Use existing implementations if desired.
    -   **Record Source Provenance:** Generate and store SLSA source provenance
    attestations for all source code, capturing information about the author,
    committer, and the specific commit hash.
    -   **Issue Source VSA:** Generate a Verification Summary Attestation (VSA) for the
    source code, which cryptographically guarantees the integrity and provenance
    of the code.

<p style="text-align: right">
Potential tools: <a href="https://github.com/slsa-framework/slsa-source-poc">slsa-source-poc</a>, <a href="https://gittuf.dev">gittuf</a></p>

### Build

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](/spec/v1.1/), and the draft
[Build Environment](/spec/draft/#build-environment-track) and
[Dependency](/spec/draft/#dependency-track) tracks.

Implementations should:

-   **Generate Build Provenance:** Generate SLSA build Level 3-compliant build
  provenance, which includes information about the build environment, the
  specific build steps, and the inputs and outputs of the build process.
-   **Generate Build Environment attestations**: (Optional) Generate SLSA BuildEnv
  L2-compliant BuildEnv attestations, which includes integrity information about
  the build environment at the start of the build. If trusted hardware is available,
  additionally generate L3-compliant BuildEnv attestations.
-   **Generate an SBOM:** (Optional) Generate a Software Bill of Materials (SBOM)
  in a standard format (e.g., SPDX, CycloneDX) that lists all the components and
  dependencies of the built artifact.
-   **Generate additional attestations:** (Optional) Generate any additional
  attestations to capture evidence of steps that occur during the
  build stage that will be verified during the verification stage.
-   **Collect VSAs for all dependencies (source and binary) (as listed in resolvedDependencies):** For each dependency,
  retrieve and store its VSA to verify its origin and integrity.
    -   **Optionally (additionally) verify VSA during build and fail build if
    absent/doesn’t meet requirements:** Implement a build-time check to
    verify the validity of each dependency's VSA ([source](/spec/v1.2-rc1/verifying-source#how-to-verify-slsa-a-source-revision), [other](/spec/v1.1/verification_summary#how-to-verify))
    and fail the dependency does not meet the defined security policy.
-   **Scan for vulns:** (Optional) Integrate a vulnerability scanner into the
  build process to identify known vulnerabilities in the code and its
  dependencies and generate evidence of that scan.
    -   **Check for triage:** Implement a process for triaging identified
    vulnerabilities, allowing for the suppression of false positives and the
    tracking of remediation efforts. Generate evidence that triage occurred.

<p style="text-align: right">
Potential tools: <a href="https://github.com/actions/attest-build-provenance">GitHub provenance generation</a>, <a href="https://github.com/slsa-framework/slsa-github-generator">SLSA GitHub Generator</a>, <a href="https://konflux-ci.dev">Konflux</a>, <a href="https://cloud.google.com/build/docs/securing-builds/generate-validate-build-provenance">Google Cloud Build</a>, <a href="https://github.com/google/osv-scanner">osv scanner</a> (vuln scanning), <a href="https://github.com/carabiner-dev/vexflow">vexflow</a>, <a href="https://hermetoproject.github.io/hermeto">hermeto</a></p>

### Verification

The verification stage covers the point at which a built software artifact is
[verified against expectations](/spec/draft/verifying-artifacts).
This will go beyond the basics identified in verifying build artifacts and
include verifying Source, Build Environment, and Dependency information.

Implementations should:

-   **Allow software producers to define expectations used during verification
  (i.e. a policy):** Provide a mechanism for software producers to define a
  security policy that specifies the requirements for a successful verification.
-   **Verification:** Implement a verification process that checks the following:
    -   **Check build provenance:**
        -   **Comes from the expected builder:** Verify that the build was performed
      by a trusted and authorized builder.
    -   **Build was run in the expected build environment (optional):** Verify that
      the build ran in a good known build environment as advertised by the trusted
      builder.
        -   **From the expected build entrypoint:** Verify that the build was
      initiated from the correct and expected entry point.
        -   **Each source dependency has:**
        -   **A valid source VSA:** Verify the integrity and provenance of each
        source dependency by
        [checking its VSA](/spec/v1.2-rc1/verifying-source#how-to-verify-slsa-a-source-revision).
        -   **(optionally) has a desired source level:** Verify that each source
        dependency meets the minimum SLSA source level defined in the security
        policy.
    -   **Check SBOM:** Check that an SBOM from the expected tooling exists.
    -   **Check vulnerability attestation and triage:** Verify that all identified
    vulnerabilities have been triaged and that the remediation status is
    acceptable according to the security policy.
    -   **Check any additional policy rules (optional):** Verify that the
      package meets any additional rules as dictated by the policy using
      the provided attestations as evidence.
-   **Issue VSA including:**
    -   **SLSA Build Level:** The VSA should include the SLSA build level that the
    artifact has achieved.
    -   **SLSA BuildEnv level:** The VSA should include the SLSA BuildEnv level
    that artifact has achieved.
    -   **Minimum SLSA Source Level of all sources:** The VSA should include the
    minimum SLSA source level of all the source code used in the build. This can
    optionally include any dependencies if they are built from source.
    -   **SLSA dependency level:** The VSA should include the SLSA dependency level,
    which reflects the security posture of the dependencies.

<p style="text-align: right">
Potential tools: <a href="https://github.com/carabiner-dev/ampel">Ampel</a>, <a href="https://conforma.dev">Conforma</a>, <a href="https://github.com/slsa-framework/slsa-verifier">slsa-verifier</a></p>

### Publication

The publication stage covers the point at which a software artifact is made
available to consumers.

Implementations should ensure that:

-   **A valid VSA for the published artifact exists**
    -   Implement a mechanism to prevent the publication of artifacts that do not
    have a valid VSA.
-   **Consumers can fetch VSAs for published artifacts**
    -   Provide a mechanism for consumers to easily fetch the VSA for any published
    artifact.

### Use

The use stage covers the point at which a consumer is going to use the artifact.

Implementations should:

-   **Fetch the artifact & VSA:** Provide tooling that allows consumers to
  download both the artifact and its corresponding VSA.
-   **Verify the VSA:** The tooling should automatically verify the VSA against
  the artifact to ensure its integrity and authenticity following
  [the SLSA guidance](/spec/v1.1/verification_summary#how-to-verify).
-   **Fail if VSA fails verification:** The tooling should fail and alert the user
  if the VSA does not pass the verification process, preventing the use of a
  potentially compromised artifact.

<p style="text-align: right">
Potential tools: <a href="https://github.com/carabiner-dev/drop">Drop</a>, <a href="https://github.com/slsa-framework/slsa-verifier">slsa-verifier</a></p>

## Extras

Some implementations may wish to go above and beyond what’s been requested.

That may include:

-   **Advanced policy enforcement**: providing a more nuanced ability to set
  policy for advanced users.
-   **Integration with other security tools**
-   **Support for additional attestation formats**
-   **Support for attestations from different producers:** The implementation may
  be able to consume and verify attestations from different producers, such as
  different builders, source control systems, and SBOM generators.

## Submission

Submissions should document:

-   **How they work:** Explains the end-to-end workflow of the implementation.
-   **How they leverage existing standards:** Note which standards or existing
  projects are used in the submission.
-   **How can a user adopt this workflow themselves:** A step-by-step guide that
  allows users to set up and use the implementation in their own environment.
  This can link to existing documentation of any technology used.
-   **The policy management process for the software producer:** A document that
  explains how to create, manage, and enforce security policies.
-   **Gaps and future areas of improvement:** A document that identifies the
  current limitations of the implementation and suggests areas for future
  improvement.
-   **A working example:** A complete, working example of the implementation.

To submit your example end-to-end implementations please either send a PR
creating the blog post yourself
([example](https://github.com/slsa-framework/slsa/pull/1435)) or
[create an issue](https://github.com/slsa-framework/slsa/issues) 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](https://slack.openssf.org/) or by
[creating an issue](https://github.com/slsa-framework/slsa/issues).