Proposal: Admit SLSA Verifier as a Core Projects

[puerco]

Proposal

Create a new repository at slsa-framework/verifier for the newly developed SLSA Verifier and classify it as a SLSA Core project.

This issue requests approval from the SLSA Steering Committee to:

1. Admit the new repository into the slsa-framework GitHub organization.
2. Classify the project as Core.
3. Add the project to the list of SLSA Core projects.

This proposal is made under the proposed SLSA Technical Project Policy.

Project overview

Repository: github.com/slsa-framework/verifier

Project name: SLSA Verifier

Proposed tier: Core

The SLSA Verifier will be the primary implementation for verifying artifacts and their associated provenance against the requirements defined by the SLSA specification.

The project is intended to provide the minimum practical verification tooling needed by SLSA users, including:

• Parsing and validating supported SLSA provenance formats.
• Verifying provenance authenticity and its binding to an artifact.
• Evaluating provenance against the requirements of supported SLSA tracks and levels.
• Providing a stable verification library and command-line interface.
• Serving as a reference implementation for SLSA verification behavior.
• Keeping a collection of predicate checks for SLSA verification
• Supporting interoperability and conformance testing across the SLSA ecosystem.

The verifier will supersede or provide the successor architecture for the existing slsa-verifier implementation. The new repository name reflects the intent for this to be the canonical SLSA verification project rather than a continuation constrained by the architecture of the existing implementation.

Scope classification

We propose classifying the project as a Core SLSA project.

The verifier is closely tied to the usability and implementation of the SLSA specification. Without practical verification tooling, producers and consumers cannot consistently determine whether provenance satisfies the specification’s requirements.

The project is intended to function primarily as:

• A conformance validator for SLSA provenance and requirements.
• A reference implementation of SLSA verification semantics.
• A reusable library containing SLSA verification types and logic.
• A basic developer tool necessary to make the specification usable.

These responsibilities place the project within the policy’s Core category of basic developer tooling, libraries, types, and conformance validators.

To the extent that the command line interface or future policy functionality is considered discretionary under the policy, this proposal also requests an explicit Steering Committee decision granting the project Core status. The Core commitment would apply to the verifier as a cohesive project, including the library and supporting CEL code, conformance logic, and the CLI used to expose that functionality.

Core project requirements

The project will meet the requirements for the Core tier as follows.

Maintainers

The project will begin with at least two active maintainers from different organizations:

Name	GitHub	Organization
Adolfo García Veytia	@puerco	Carabiner Systems
Hayden Blauzvern	@Hayden-IO	Google

The maintainers are to agree to actively review contributions, maintain compatibility with supported versions of the SLSA specification, manage releases, and respond to security reports.

License

The repository will use the Apache License 2.0.

Required repository files

Before or as part of the repository’s initial setup, it will include:

• README.md, including the required SLSA Core project banner.
• LICENSE, containing the Apache-2.0 license.
• MAINTAINERS.md or MAINTAINERS, identifying active maintainers and their organizations.
• SECURITY.md, including a security contact and response commitment.
• CONTRIBUTING.md.

The README will include the following notice:

SLSA Core project. Maintained by the SLSA community. Issues and security reports are handled per SECURITY.md. See the SLSA Technical Project Policy for what this means.

Project hygiene

The repository will:

• Run automated tests and required CI checks on changes.
• Require review before changes are merged.
• Maintain test coverage for supported provenance formats and verification behavior.
• Publish versioned releases on a regular cadence.
• Document supported SLSA specification versions.
• Maintain release notes and compatibility information.
• Avoid becoming dependent on a single maintainer or organization.

Relationship to the existing verifier

The new project is intended to become the canonical SLSA Verifier.

A migration plan will be prepared for the existing slsa-framework/slsa-verifier repository. That plan is expected to cover:

• Which existing features will be preserved.
• Compatibility expectations for current users.
• Migration of documentation and tests where appropriate.
• Deprecation and archival of the existing repository.
• Notice redirecting users to slsa-framework/verifier.
• The release and support timeline for the transition.

Approval of this issue authorizes creation of the new repository. Sunsetting of the old verifie work will be tracked separately.

Requested decision

The SLSA Steering Committee is asked to approve the following:

• Create slsa-framework/verifier (or allow the repo to be pushed to this location)
• Classify the repository as a Core SLSA project.
• Add verifier to the steering maintained list of Core projects.
• Authorize the maintainers to begin migrating from the existing slsa-verifier project.

Voting

Per the SLSA Technical Project Policy, this issue should:

• Be labeled new-project.
• Remain open for at least seven days.
• Be decided by a simple majority of the SLSA Steering Committee.
• Be closed with a summary recording the outcome and vote tally.

[Hayden-IO]

Speaking as a maintainer of slsa-verifier, I support this project. slsa-verifier is no longer able to be maintained as discussed in slsa-framework/slsa-verifier#872. There is still a need for basic tooling and reference libraries for build provenance, and this new project will fill that space while also being easy to maintain.

I am also willing to be the other named maintainer for this project. We'd like to reuse https://github.com/orgs/slsa-framework/teams/tool-maintainers as a maintainer group.

[lumjjb]

Binding +1

LGTM, with the proposed 2nd maintainer @Hayden-IO

The new project is intended to become the canonical SLSA Verifier.

It looks like some of these are likely longer horizon (i.e. deprecation/archival) and some are short term (notifying users, etc.). Do we have an estimate timeline/effort on what the user migration for deprecation will look like here - since it is a CLI and library i imagine the impact here of "archival" is minimal, and maybe we'd only want to support critical security updates for another 6 months while we transition?

My main concern is that we want to minimize any "throw away" efforts around migration.

[mlieberman85]

Binding +1

[tombedfordgit]

I'm in support of this / +1

[lehors]

I'm not a steering committee member but for what it's worth I support this proposal! +1 :)

[arewm]

Sounds good.

@puerco , if @Hayden-IO is willing to be recorded as a second maintainer, can you add him to the original issue text?

[puerco]

Done!