Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move source track VSA info to the VSA spec? #1148

Open
TomHennen opened this issue Sep 23, 2024 · 5 comments
Open

Move source track VSA info to the VSA spec? #1148

TomHennen opened this issue Sep 23, 2024 · 5 comments
Assignees

Comments

@TomHennen
Copy link
Contributor

TomHennen commented Sep 23, 2024

Eventually, I think this list should be moved closer to the VSA spec itself so that users can reference the schema and these specific requirements together.

Originally posted by @marcelamelara in #1094 (comment)

@zachariahcox
Copy link
Contributor

@TomHennen is there much work left to do here?

I think the goal is to say:

SLSA has two main phases: data production and policy evaluation. 

Provenance attestations are data production. 
They are generated by authoritative sources, sources responsible for overseeing the claims to which they attest. 

"VSAs" are policy evaluations. 
A policy can be evaluated against the tamper-resistant provenance attestations to produce a policy decision. 
The organization uses VSAs to determine whether a specific artifact, package, repository revision is suitable for the next phase of the SDLC.

@TomHennen
Copy link
Contributor Author

@TomHennen is there much work left to do here?

I think the idea in this issue is to move the parts of source-requirements that talk about how to populate a VSA out of source-requirements.md and move them to https://slsa.dev/spec/draft/verification_summary.

So it's just moving content. I'm not sure if I like that idea (haven't thought about it much), but I wanted to capture @marcelamelara's request from another PR.

Regarding your suggestion, yes that makes sense, though it does miss that VSAs are also intended to be used outside the organization. However, that might be tracked better in a separate issue or PR?

@TomHennen
Copy link
Contributor Author

We can probably also have a spot for other SLSA tracks to indicate what properties they cover and how VSAs should refer to the various types of things (source revisions, artifacts, build environments...). See #1115 (comment) for context

@TomHennen
Copy link
Contributor Author

I'd like to put this off until 1.1 is released. Otherwise it's just going to be more difficult for @lehors to produce the 1.1 version.

@lehors
Copy link
Member

lehors commented Oct 16, 2024

Yes, please! Thanks @TomHennen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🆕 New
Status: Ready for work!
Development

No branches or pull requests

3 participants