[Technical Initiative Funding Request]: SLSA Source Final Spec Implementation

[TomHennen]

Technical Initiative

Supply-chain Levels for Software Artifacts (SLSA) Project

Lifecycle Phase

Incubation

Funding amount

50000

Problem Statement

With the release of the SLSA Source Track specification (part of SLSA 1.2) the source tooling needs to be updated to finalize the implementation of the spec. The SLSA source tooling includes source-tool, the reusable actions that generate and verify source provenance and the policy repository with (future) supporting tools.

Who does this affect?

The source tools are the only existing implementation of the Source Track. They are the reference and only choice for anyone attempting to secure code repositories. This means that adoption of the new SLSA Source Track depends on building the missing spec features.

Have there been previous attempts to resolve the problem?

No. The project underwent a significant improvement effort to incorporate best practices and make it easier for non-technical users to onboard repositories, all while the final Source Track specification was being drafted. Now that the spec is out (or should be close, depending on when you read this), we need to adjust the project to meet the adjusted requirements for the first implementation of the specification.

Why should it be tackled now and by this TI?

We are planning to build SLSA v1.2 support into the source tools to time the next major release with the release of the specification. This will ensure SLSA Source can be operational soon after the specification is out, boosting adoption.

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

A software engineer familiar with SLSA and the open source development. This individual will work closely with the SLSA specification working group to ensure the changes meet the requirements.

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

This is an engineering proposal; as such it requires engineering resources to design the required features and development time to update the Go code base and the reusable workflows that power provenance generation in the user’s repositories.

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

No, while the initiative depends on the release of SLSA 1.2, the specification is almost ready, the current draft is mature enough to allow the implementation to start.

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

The requested funds will cover engineering and development costs required to implement the missing SLSA 1.2 features.

Aside from updating the data formats to the final specification, there are a couple of features that need to be built:

1. Support for merge commits. Currently, merge commits are not fully support in source-tool. This prevents adoption of source-tool in any project that prefers that merge strategy (such as kubernetes and others in cloud native world).
2. Pluggable signing methods: source-tool is currently limited to signing attestations into sigstore bundles. We want to add a pluggable signing architecture to allow users to add more signing such as plain DSSE signing using plain keys from files or from other sources such as key/secret managers. The goal is to offer signing alternatives in situations where sigstore is not an option.
3. Managing the policies in the community repository is currently a manual-intensive activity that cannot scale in the long run. The project is thinking of automating the management of policies. This involves building tools to authenticate and authorize users, updating repository policies.
4. The current implementation handles policies in one central GitHub repository. Some orgs may wish to handle their policies themselves. We’ll add support for ‘bring-your-own-policy-repository’ to let organizations manage their policies themselves.
5. Update the existing tooling documentation and create new documentation for the policy repository tools. Also, write a new blog post announcing the first release.
6. Aligning with OpenSSF’s graduation criteria, implement OSPS baseline controls in the source track repositories.

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?

Tom Hennen

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

SLSA Steering Commitee

CC @mlieberman85 @arewm @michaelwinser @adriandiglio

What license is this funding initiative being used under?

Apache 2.0

Code of Conduct

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

SOW Calendar, Deliverables and Milestones

Deliverable	SOW Item(s)	Estimated Week
Phase 1: Planning & Final Review
Final spec (or latest draft) review and development plan	1	Week 1-2
Plan and design of policy repository tooling	2	Week 1-2
Phase 2: Core SLSA v1.2 Implementation
Update attestation formats and controls to match the latest v1.2 spec	3	Week 2-10
Phase 3: Extended Tooling & Features
Finalize support for attesting merge commits	5	Week 8-16
Add support for capturing code reviewers in provenance	4	Week 8-16
Support for 3rd-party policy repositories	8	Week 8-16
Phase 4: Documentation Updates
Update source tools documentation	9	Week 16-20
Create new policy repository documentation	10	Week 16-20
Blog post about first official release	11	Week 16-20
Phase 5: Baseline Integration
Finalize OSPS Baseline implementation in SLSA Source repositories.	12	Week 20-24

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.

1. Final review of the tooling based on the SLSA 1.2 spec (or the latest draft), and development plan of the required changes.
2. Plan and design of the policy repository tooling.
3. Update attestation formats, requirement checks, and controls to match the final v1.2 specification.
4. Add support for capturing code reviewers in generated source provenance.
5. Finalize support for attesting merge commits.
6. Pluggable support for attestation signing for folks that don't or can't use Sigstore.
7. Policy repository tooling (TBD)
8. Support for 3rd-party policy repositories
9. Finalize OSPS Baseline implementation in SLSA Source repositories.

[TomHennen]

CC @puerco

[steiza]

/vote

[git-vote]

Vote created

@steiza has called for a vote on [Technical Initiative Funding Request]: SLSA Source Final Spec Implementation (#538).

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.

[mlieberman85]

Given that this is an extension of the POC work, I asked @TomHennen to provide some transparency into how the initial work went so the TAC can better gauge if the continued work makes sense.