by Andrew McNamara, Tom Hennen

This is a request for examples (RFE) for an end-to-end implementation of the Supply-chain Levels for Software Artifacts (SLSA) 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.

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.

Potential tools: slsa-source-poc, gittuf

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, and the draft Build Environment and Dependency 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, other) 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.

Potential tools: GitHub provenance generation, SLSA GitHub Generator, Konflux, Google Cloud Build, osv scanner (vuln scanning), vexflow, hermeto

Verification

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:

  • 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.
      • (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.

Potential tools: Ampel, Conforma, slsa-verifier

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.
  • 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.

Potential tools: Drop, slsa-verifier

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) 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.