[Technical Initiative Funding Request]: Revamp and Modernize SLSA Build Track Tooling

[Hayden-IO]

Technical Initiative

Supply-chain Levels for Software Artifacts (SLSA) Project

Lifecycle Phase

Incubation

Funding amount

$50,000

Problem Statement

The current SLSA reference tooling, specifically slsa-github-generator and slsa-verifier, requires modernization. The generator has a large, high-maintenance codebase that can be significantly simplified by leveraging new platform-native features like GitHub Artifact Attestations. The verifier is in need of a revamp focused around supporting end-to-end SLSA verification. For example, it's non-trivial to add new SLSA statement types to the verifier, making it difficult to add verification as new SLSA tracks are proposed. It also duplicates functionality that is available in other dedicated tools like Cosign, rather than focusing on policy-based attestation verification.

Who does this affect?

This affects developers and organizations attempting to adopt SLSA to secure their software supply chain. The complexity and maintenance burden of the current tooling can act as a barrier to adoption. It impacts security teams and consumers of SLSA attestations who need a streamlined, reliable, and policy-driven method for verification.

Have there been previous attempts to resolve the problem?

The existing tools represent the initial approach to solving this problem. That approach worked to establish the viability and utility of SLSA. However, the ecosystem has since evolved. This request proposes focusing on end-to-end verification, simplification and integration. We will leverage platform features (GitHub Artifact Attestations) and compose with other tools (e.g. Cosign) where possible. This reduces the maintenance burden and aligns the SLSA tooling with other tooling in the ecosystem.

Why should it be tackled now and by this TI?

Tackling this now will lower the barrier to SLSA adoption and allow the project to focus its resources on evolving the specification rather than maintaining complex tooling. Additionally, the SLSA community has called for examples of end-to-end SLSA usage, with these tools being examples of such.

Give an idea of what is required to make the funding initiative happen

1. Code Review and Planning: A thorough review of both the slsa-github-generator and slsa-verifier codebases to create a detailed plan for feature deprecation and migration.
2. Generator Rewrite: Replace the existing generator with a set of reusable GitHub Actions workflows that utilize GitHub Artifact Attestations.
3. Verifier Rewrite: Refactor the verifier to focus exclusively on SLSA policy verification, delegating signature verification to external tools like Cosign. Additionally, review in-toto/attestation-verifier and determine if this verifier should be used by the SLSA verifier or develop new capabilities in line with the proposed In-toto Policy Framework. This work will also include developing policies for the SLSA Build and Source tracks.
4. Documentation: Create comprehensive documentation for the new tooling and detailed migration guides for existing users.

What is going to be needed to deliver this funding initiative?

This initiative will require dedicated engineering resources for the code audits, architectural design, implementation of the new workflows and policies, and creation of documentation. Community engagement will also be important for gathering feedback on the new designs and deprecation plans.

Are there tools or tech that still need to be produced to facilitate the funding initiative?

No, the core technologies proposed for the project to rely on already exist and are mature. The work of this initiative is to revamp SLSA tooling to integrate with them.

Give a summary of the requirements that contextualize the costs of the funding initiative

The primary cost of this initiative is the engineering effort required for the rewrite. This includes:

• Engineering Time: For auditing existing code, designing the new architecture, and making decisions about feature deprecation.
• Development Time: For implementing the new, simplified generator and the policy-based verifier.
• Technical Writing: For producing high-quality documentation and migration guides to ensure a smooth transition for the community.

Who is responsible for doing the work of this funding initiative?

Adolfo García Veytia, Carabiner Systems

Who is accountable for doing the work of this funding initiative?

Hayden Blauzvern, Google

If the responsible or accountable parties are no longer available, what is the backup contact or plan?

SLSA steering committee

What license is this funding initiative being used under?

Apache 2.0, which is consistent with the existing SLSA project licenses.

Code of Conduct

• [x] I agree to follow the OpenSSF's Code of Conduct

List the major milestones by date and identify the overall timeline within which the technical initiative plans to accomplish their goals. Any payments for services, sponsorships, etc., will require LF Legal and Financial review.

• Milestone 1 (During Q1 2026): Complete code review and publish a detailed design/deprecation plan for both repositories.
• Milestone 2 (End of Q1 2026): Release a beta version of slsa-github-generator based on reusable workflows.
• Milestone 3 (During Q1 2026): Release a beta version of the new policy-based slsa-verifier with support for Build and Source tracks.
• Milestone 4 (End of Q2 2026): Complete documentation, implement OSPS Baseline controls as required by the OpenSSF project lifecycle, and cut major releases of the tooling.

If this is a request for funding to issue a contract, then OpenSSF will issue that contract. Please provide a Statement of Work (SOW) that we may review. Any contracting action will take 4-6 weeks to issue.

The key deliverables are:

1. A plan based on the code audit of the changes that will be made along with a deprecation timeline
2. A new major release of the SLSA GitHub generator
3. A new major release of the SLSA verifier
4. Documentation for these new tools
5. OSPS Compliance attestations
6. A blog post on SLSA once this work has been completed

[steiza]

/vote

[git-vote[bot]]

Vote created

@steiza has called for a vote on [Technical Initiative Funding Request]: Revamp and Modernize SLSA Build Track Tooling (#537).

The members of the following teams have binding votes:

Team
@ossf/tac

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 14days. It will pass if at least 55% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

[git-vote[bot]]

Vote status

So far 0.00% of the users with binding vote are in favor and 0.00% are against (passing threshold: 55%).

Summary

In favor	Against	Abstain	Not voted
0	0	0	9

Binding votes (0)

User	Vote	Timestamp
@steiza	Pending
@justaugustus	Pending
@mlieberman85	Pending
@scovetta	Pending
@bobcallaway	Pending
@lehors	Pending
@gkunz	Pending
@marcelamelara	Pending
@camaleon2016	Pending

[steiza]

I'm in support of this proposal. GitHub has been recommending the SLSA GitHub Generator for newly created repositories for several years, and there are lots of people using it, even though a lot has changed in the 3.5 years since it has been released and it could be streamlined from what we've learned in deploying build provenance to npm, PyPI, Ruby Gems, Maven Central, etc.

If for some reason this funding request doesn't pass, we should consider deprecating these tools, although as @haydentherapper described on the call, that could be a project in of itself.

[gkunz]

I too was wondering about how much these tools are being used, but based on the discussion on the TAC call and Zach's comment, I believe there is value in modernizing the tools.

[git-vote[bot]]

Vote closed

The vote passed! 🎉

55.56% of the users with binding vote were in favor and 0.00% were against (passing threshold: 55%).

Summary

In favor	Against	Abstain	Not voted
5	0	0	4

Binding votes (5)

User	Vote	Timestamp
@bobcallaway	In favor	2025-10-28 16:01:36.0 +00:00:00
@gkunz	In favor	2025-10-29 15:46:34.0 +00:00:00
@lehors	In favor	2025-10-29 8:18:14.0 +00:00:00
@mlieberman85	In favor	2025-10-29 10:25:42.0 +00:00:00
@steiza	In favor	2025-10-28 16:05:08.0 +00:00:00

[Hayden-IO]

Thank you all!

[kj-powell]

@afmarcum Can you please review?

[afmarcum]

Approved.