search

slsa-framework / slsa

Supply-chain Levels for Software Artifacts
https://slsa.dev
Other
1.48k stars 212 forks source link

Is "Source track" a misnomer? #1041

Open kpk47 opened 3 months ago

kpk47 commented 3 months ago

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 https://github.com/slsa-framework/slsa/pull/1037#discussion_r1544940615_

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 2 months ago

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.