content: draft: Remove provenance requirement by TomHennen · Pull Request #1505 · slsa-framework/slsa

TomHennen · 2025-10-27T14:41:23Z

Creating this PR to get an idea of what it would mean to remove the provenance (and VSA) requirement from the spec.

It seems like the majority of what we're looking for in provenance can be subsumed by other existing requriements we already track with provenance becoming a (convenient) implementation detail.

If we do this we might also want to move the provenance and VSA parts of this page to their own page to keep the level requirements clear.

If we accept this change it would mean that 'provenance' becomes a nice feature of any particular SLSA Source Track implementation but won't be required.

Creating this PR to get an idea of what it would mean to remove the provenance (and VSA) requirement from the spec. It seems like the majority of what we're looking for in provenance can be subsumed by other existing requriements we already track with provenance becoming a (convenient) implementation detail. If we do this we might also want to move the provenance and VSA parts of this page to their own page to keep the level requirements clear. If we accept this change it would mean that 'provenance' becomes a nice feature of any particular SLSA Source Track implementation but won't be required. Signed-off-by: Tom Hennen <tomhennen@google.com>

netlify · 2025-10-27T14:41:30Z

✅ Deploy Preview for slsa ready!

Name	Link
🔨 Latest commit	`59bfd38`
🔍 Latest deploy log	https://app.netlify.com/projects/slsa/deploys/69036345e808c40008a689f7
😎 Deploy Preview	https://deploy-preview-1505--slsa.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Signed-off-by: Tom Hennen <tomhennen@google.com>

zachariahcox · 2025-10-27T16:21:58Z

docs/spec/draft/source-requirements.md

+Evidence of these controls (and their continuity) will appear in the history for
+revision `abc123`.


do we have an example or idea for this?
It seems like this was most of what a "provenance" attestation provided.

Ah, so in git you probably need something else. Since this is an example I can put the provenance back in here and maybe qualify (in a git implementation using provenance)

zachariahcox · 2025-10-27T16:41:45Z

docs/spec/draft/source-requirements.md

-statement of fact from the perspective of the SCS. The SCS MUST document the
-format and intent of all Source Provenance attestations it produces.
-
-Source Provenance MUST be created contemporaneously with the branch being


This "contemporaneous, tamper-resistant" piece still seems valuable for generating VSAs.
For volume / storage reasons, it seems necessary that things like ruleset insights data will need to age out.

If it's just a practical perspective then this change doesn't preclude a SCS from taking that approach, it just doesn't require it. There can be other implementations (not necessarily git/GitHub!) that keep that data ~forever.

If we think there's some specific outcome that we might lose, the history requirement does specifically state the SCS has to prevent tampering it. We can have something similar for technical controls/continuity if needed.

@TomHennen , were you suggesting to move the source provenance content elsewhere? It could be part of the repository even if it isn't a core part of the spec itself.

@TomHennen , were you suggesting to move the source provenance content elsewhere? It could be part of the repository even if it isn't a core part of the spec itself.

Yes, I was just thinking we could move it to a different page within the repo. If we even decide to make this change :)

arewm

This change generally seems to be aligned with Mark's viewpoint expressed in #1010. If we merge this, could we also try to clarify the guidance on new tracks? As it relates to the source track, who are the entities that we need to trust (primarily the SCS) and how would consumers verify/validate their trust in those entities?

arewm · 2025-10-28T19:06:12Z

docs/spec/draft/source-requirements.md

-The organization MUST provide evidence of continuous enforcement via technical
-controls for any claims made in the Source Provenance attestations or VSAs (see
-[control continuity](#continuity)).


Are we being too broad with this deletions? I feel like it would still be beneficial for organizations to provide evidence even if we don't specify provenance or VSAs.

It might go above and beyond what's needed in this PR. However I think providing evidence might be more of the responsibility of the SCS and is covered here?

If nothing else, for the purposes of this PR, we needed to remove the provenance specific requirements. If the SCS is recording this information, is there anything for the org to do?

arewm · 2025-10-28T19:08:25Z

docs/spec/draft/source-requirements.md

+above.  If the SCS DOES NOT generate a VSA for a revision, the revision is
+assumed to have Source Level 0.


Is it clear enough that this only holds in the example? The lack of a VSA doesn't mean Source Level 0 unless the the VSA is the mode of communication.

Fair point. Updated.

arewm · 2025-10-28T19:09:27Z

docs/spec/draft/source-requirements.md

+> For example:
+>
+> 1.  The SCS may record detailed metadata for revisions in signed
+Source Provenance, protecting it from tampering from other components of the


Should these occurrences still be capitalized if it isn't something that we are introducing in "the spec?"

It is still a defined term which we discuss further below. But we should revisit depending on what we decide to do with that content.

arewm · 2025-10-28T19:11:14Z

docs/spec/draft/source-requirements.md

-statement of fact from the perspective of the SCS. The SCS MUST document the
-format and intent of all Source Provenance attestations it produces.
-
-Source Provenance MUST be created contemporaneously with the branch being


@TomHennen , were you suggesting to move the source provenance content elsewhere? It could be part of the repository even if it isn't a core part of the spec itself.

adityasaky · 2025-10-28T23:47:43Z

I'd like to understand more of the motivation for this change.

It seems like the majority of what we're looking for in provenance can be subsumed by other existing requriements we already track with provenance becoming a (convenient) implementation detail.

I think this is a signal we need to do a better job in the source track of explaining what source attestations add over the other requirements. 😄

The requirements themselves tell me, a consumer, what controls to enable to get certain security properties. This, in and of itself, does not differentiate SLSA from numerous best practices guides which tell me to enable branch protection rules, disable force pushes to main, require code review, etc (e.g., the OpenSSF itself has https://best.openssf.org/SCM-BestPractices/). The attestations enable me to keep the SCS implementing the requirements honest. With SLSA, I can verify that I'm safe for every revision that matters rather than rely on enabling the right controls. So, while I understand the emphasis on the source track's requirements, I worry that we'll be losing a core value proposition of SLSA as a whole.

Looking at the alternatives proposed to the (optional) source provenance in this PR, I'd like to understand how they improve some aspect (e.g., adoption) of SLSA over requiring provenance. For instance, logging metadata to a transparency log sounds like the SCS is essentially implementing support for attestations which it then records in a transparency log. Adding an API that returns information again sounds like something the SCS could wrap in an attestation at the time a revision is created. OTOH, without attestations, we lose verifiability, non-repudiation, and the powerful interoperability across SLSA tracks we get using attestations as a common, consistent interface for each track.

patzielinski

I'm still trying to wrap my head around the source track as well as these changes on top, apologies if I misunderstand.

In a similar vein to the points @adityasaky raised above, it might be useful to spell out how the SCS can supply evidence of compliance to end users, but with the what (i.e. the evidence) no longer being attestations, there's a concern (in my mind) about just how interoperability is going to work. I do think there's value in at least mentioning transparency logs in the spec, fwiw. Maybe as an additional level above L4 or somehow else?

I think this is a signal we need to do a better job in the source track of explaining what source attestations add over the other requirements. 😄

I agree, I think the spec needs to motivate this better.

docs/spec/draft/source-requirements.md

patzielinski · 2025-10-29T14:50:48Z

docs/spec/draft/source-requirements.md

-attestation.
+tool (such as required GitHub Actions workflow) and tracks its status in
+provenance attestations, it must indicate the name of this tool, what it
+accomplishes, and how to find its evidence in the provenance attestation.


Is this bit still relevant with these edits?

I think so? What's being presented here is an example where the status of technical controls is tracked via attestations. So it seems fair to reference provenance.

Still, perhaps it could be generalized more.

Signed-off-by: Tom Hennen <tomhennen@google.com>

Co-authored-by: patzielinski <git@patzielinski.com> Signed-off-by: Tom Hennen <TomHennen@users.noreply.github.com>

TomHennen · 2025-10-30T17:51:37Z

Thanks for the comments everyone, I still need to review them a bit more. I did realize that the context of this change might not have been sufficiently clear, here's what I provided in another chat thread:

Context:

@MarkLodato's original feedback
His feedback on a PR that addressed the reorganization but not the provenance & VSA requirement
Notes about our discussion on how we can keep it as is for now but reword later if needed

And also, this is just a 'pathfinder' an example of what this might look like if we wanted to pursue it, but we don't need to do anything with it and might just close it.

TomHennen · 2025-10-30T18:50:04Z

Note: if we do keep this we'll also want to update some of https://slsa.dev/spec/draft/assessing-source-systems as it is attestation heavy. :)

TomHennen · 2025-11-21T17:40:17Z

I think this PR has served its purpose and we can now close it.

TomHennen requested review from adityasaky, arewm and zachariahcox October 27, 2025 14:41

github-project-automation bot added this to Issue triage Oct 27, 2025

github-project-automation bot moved this to 🆕 New in Issue triage Oct 27, 2025

fix lint

65922d6

Signed-off-by: Tom Hennen <tomhennen@google.com>

TomHennen added source-track slsa 1.2 Required for SLSA 1.2 release. Please apply it liberally! slsa 1.2-RC1 feedback labels Oct 27, 2025

github-project-automation bot added this to SLSA Source Track Oct 27, 2025

zachariahcox reviewed Oct 27, 2025

View reviewed changes

arewm reviewed Oct 28, 2025

View reviewed changes

patzielinski reviewed Oct 29, 2025

View reviewed changes

TomHennen and others added 2 commits October 30, 2025 13:05

clarify using source vsas

4bd5ab3

Signed-off-by: Tom Hennen <tomhennen@google.com>

Update docs/spec/draft/source-requirements.md

59bfd38

Co-authored-by: patzielinski <git@patzielinski.com> Signed-off-by: Tom Hennen <TomHennen@users.noreply.github.com>

adityasaky mentioned this pull request Nov 3, 2025

Clarify role of attestations in SLSA #1508

Open

TomHennen mentioned this pull request Nov 4, 2025

Source Track: Suggested reorganization #1459

Closed

TomHennen closed this Nov 21, 2025

github-project-automation bot moved this to Done in SLSA Source Track Nov 21, 2025

github-project-automation bot moved this from 🆕 New to ✅ Done in Issue triage Nov 21, 2025

		Evidence of these controls (and their continuity) will appear in the history for
		revision `abc123`.

		above. If the SCS DOES NOT generate a VSA for a revision, the revision is
		assumed to have Source Level 0.

Comments

Conversation

TomHennen commented Oct 27, 2025

Uh oh!

netlify bot commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for slsa ready!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arewm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adityasaky commented Oct 28, 2025

Uh oh!

patzielinski left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TomHennen commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TomHennen commented Oct 30, 2025

Uh oh!

TomHennen commented Nov 21, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

netlify bot commented Oct 27, 2025 •

edited

Loading

TomHennen commented Oct 30, 2025 •

edited

Loading