slsa
slsa copied to clipboard
slsa-framework
KMS requirement for SLSA 3/4 is too prescriptive
This is the wording in particular that I'm looking at:
The provenance signing key MUST be stored in a secure key management system accessible only to the build service account.
In particular, this precludes models that take advantage of ephemeral keys and CAs (e.g. Sigstore's Fulcio), which are not KMS systems. However, I'd argue that despite something like Fulcio not satisfying this as-written, it is a strictly stronger model because long-lived key material is never exposed to the build service.
As a sort of meta-comment, SLSA doesn't really touch on the exclusive use of [very] short-lived credentials, despite the fact that exfiltrating long-lived creds is a key attack vector. I was mentioning to @kimsterv that the use of exclusively short-lived credentials (e.g. Workload Identity) and keys (e.g. Fulcio) might make a nice basis for SLSA 5.
I think the language around all of the signing stuff needs to be improved a bit. Key management is only one part of the puzzle, without rotation/revocation you're really not left in a much better place than not signing things at all.
Agreed. The current wording is too prescriptive. The overall intent is to require the build service to move provenance generation to a trusted control plane such that it requires significant effort to compromise. The three bullets there, including the KMS one, are to address particular issues that are likely to come up but are not intended to be comprehensive.
Any suggestions on how we can improve this? Is there a way we can talk about key management / signing such that it doesn't prescribe exactly how the secret material must be protected? Or alternatively, should we list options that we believe a good?
Mark: I think a bit of both: generalize the description to include both use cases, and also list some concrete options.
Current text:
This SHOULD be through a digital signature from a private key accessible only to the service generating the provenance.
' nice to know this has been highlighted before. ^_^
Preston and I happened to stumble over this requirement and brought it up this week because the existing text is vague enough to reasonably be seen not to fit very good implementations and also to reasonably be seen to fit very bad implementations.
Access to a private key can be seen as meaning visibility of the raw key value (exfiltration risk) or ability to use the key during compromise (use risk). It's easy to think of this as a requirement for reducing the odds of key exfiltration, but I think it would be best to make this about key access in the broad sense of ability to use the key.
related https://github.com/slsa-framework/slsa/issues/414 https://github.com/slsa-framework/slsa/pull/415 The wording has already changed to allow for non-falsifiable attestations secured by mechanisms other than digital signatures, let's ensure that intent is preserved.
