Is "Source track" a misnomer?

[kpk47]

To clarify, I was wondering if we wanted to distinguish between attestations for source platform specific claims and those that may apply (I was thinking "pertain" earlier) more specifically to the source itself. I'm fine with clarifying this later if the need arises.

Originally posted by @adityasaky in #1037 (comment)

The Source track draft is narrowly scoped to defending against developer account compromise using development processes, and @adityasaky pointed out during review that perhaps the name implies a different scope.

Should we rename it? My straw proposal would be "Code review track," since the track is based around facilitating and enforcing a code review requirement.

[adityasaky]

Thanks for opening this issue! I think this ties into the threats the track is attempting to address. The current draft is focused on mitigating threat A (submit unauthorized changes) and not (yet?) on threat B (compromise source repo). I think the generic "source" name is fine if we expect mitigations against threat B to be part of the same track eventually. At the same time, they may be orthogonal to each other (eg. you could use gittuf to reduce the trust placed in a single copy of the repository without having multi-party code review requirements proposed in the current draft), so they're perhaps distinct tracks.

[arewm]

What are the threats to compromising the source repo that exist outside of submitting unauthorized changes? Would this consider threats against the hosting of the version control system?

[adityasaky]

Yeah. The PHP Git server incident mentioned in https://slsa.dev/spec/v1.0/threats-overview#real-world-examples is one example, but in my mind this would also extend to being able to verify the enforcement of security controls by mainstream forges as well.

[kpk47]

FYI - There's a related conversation happening on #1039, though about build threats rather than source threats.

Thanks for opening this issue! I think this ties into the threats the track is attempting to address. The current draft is focused on mitigating threat A (submit unauthorized changes) and not (yet?) on threat B (compromise source repo).

We sort of touch on Threat B by requiring the source move to a trusted platform rather than be in raw version control, but it's a pretty weak recommendation. TBH, I'm not convinced that Threat (B) should be in SLSA's scope, or Threat (G) for that matter. I'm more and more seeing SLSA as being about what trusted infrastructure should look like and how to use that infrastructure. How to prevent attacks on that infrastructure is a different problem, and I suspect that problem is less addressable with a specification.

Edit: I should note I'm biased since I was working on the conformance program proposal and found it to be a bottomless rabbit hole. Others may be more successful than I was.

[zachariahcox]

From the work we did in #1097, I think we have a functional objective for the source track. Similar to the build track, it's about producing attestations that are trustworthy.

Most of the policy related ideas are not required to improve the those attestations, and are left for external tools to evaluate. The source track ensure you can produce claims, VSA issuers decide what those claims mean. Consumers decide if they trust the VSA issuer or not.

[zachariahcox]

Marking "closed" for now! Please feel free to reopen if you feel we didn't address this topic fully 👍