content: source track draft: simplify and clarify level goals

[zachariahcox]

Context

This was mostly ported from gdoc, (requires [email protected] membership.)

The content is intentionally incomplete.
The final draft document will need wholistic review before progressing to the full proposal phase.

Goals

The source track is about communicating trustworthy claims.
These proposals for levels try to describe the absolute bare minimum policies and controls required to make sense of the code in a repo.

This proposal moves most of the other "good idea" policies into a different, non-leveled, section.
One of the goals of slsa is to help teams make improvements to their process in a prioritized way.

Many of these good ideas should be called out and documented somewhere, but they are not directly required for the repo to produce trustworthy attestations, so we're proposing to document and discuss them separately.

Update! As discussed in slack, products like the ossf scorecard might be better fits for describing policy details. The scorecard is much more opinionated about things like branch protections already!

This pr addresses the topics raised in the following issues.
We should re-valuate the status of these issues when this PR merges:

• VCS and SCP concerns are mixed or too prescriptive #1076
• Source control platforms also provide identity #1075
• Clarify that self-hosted SCPs are allowed #1077
• should the source track focus on "proposed changes" or "sequences of revisions?" #1095
• Clarify Robot Approval #1080

[netlify]

✅ Deploy Preview for slsa ready!

Name	Link
🔨 Latest commit	31d63ba
🔍 Latest deploy log	https://app.netlify.com/sites/slsa/deploys/66be166c8cfd5e000899bfdf
😎 Deploy Preview	https://deploy-preview-1097--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 site configuration.

[TomHennen]

Creating an attestation of these basics will likely be the entry point to "slsa source level 1" which this PR does not attempt to define directly.

Are you thinking something other than #1094?

[zachariahcox]

Are you thinking something other than #1094?

@TomHennen, Nope! I think the definition of Level 1 would just be "emits one of those attestations."
This is a nice corollary to the build track, where level 1 is "artifact has any provenance at all."

Probably a draft for source track level 1 should be: "Package has provenance claiming how it was built, when it was built and who contributed to it. Can be used to prevent mistakes but is trivial to bypass or forge."

[zachariahcox]

this would benefit from a review from @samwhite-gl and GitLab!
What's the best way to ping those folks?

[TomHennen]

I have a couple of pending comments that I figured I'd get to you sooner rather than later. (I'm going to be a bit distracted this week so I might not get this the full attention it deserves)

[mlieberman85]

@zachariahcox Can you add in a note somewhere at the top that most of the examples use Git, but there should be nothing that restricts only the usage of Git, just that Git is the most popular version control for code? I think that will help clear up any confusion.

I know the vast majority of folks will be using Git but we probably also want to make sure folks know that this could be used for things other than Git, but that for practical purposes most examples will use Git.

[mlieberman85]

LGTM I think this looks good for this draft. One other thing that I think we might want to include is a bit more clarity around the separation of concerns between the code management/review tools like Gerrit, Github, Gitlab, and the usage of those tools, e.g. repo with a particular set of rules on Github.

In the build track I think we do a reasonable job at saying your build tool should have these features and when using them you must make sure that you take advantage of those features. I think that could be done with a table similar to the table here https://slsa.dev/spec/v1.0/requirements#build-levels that splits Producer from Build Platform. This is unclear from the current open issues if it would be covered.

[zachariahcox]

@zachariahcox Can you add in a note somewhere at the top that most of the examples use Git, but there should be nothing that restricts only the usage of Git, just that Git is the most popular version control for code? I think that will help clear up any confusion.

I know the vast majority of folks will be using Git but we probably also want to make sure folks know that this could be used for things other than Git, but that for practical purposes most examples will use Git.

good idea! I but a comment at the top of the levels section, but we could move it even higher into the objective section if that would read better.

[zachariahcox]

I think that could be done with a table similar to the table here https://slsa.dev/spec/v1.0/requirements#build-levels that splits Producer from Build Platform. This is unclear from the current open issues if it would be covered.

I like it. Tracked #1111

This makes me wonder if we should use the term "producer" in this source track document to align with the definition on the build track.
That's a problem for the next pr!

[TomHennen]

Ok, it seems like all major comments have been addressed. This is draft so review requirements are relaxed. We have approval from a second maintainer. So I'll merge. We can continue to make updates in other PRs as we move towards release.