content: draft: Flesh out "Usage" threat #1191
Conversation
These threats generally match the threats for 'Artifact Publication' with the twist that the consumer must do the verification instead. Consumer verification may be simplified if a VSA was issued at publication time. fixes slsa-framework#1180 Signed-off-by: Tom Hennen <[email protected]>
Signed-off-by: Tom Hennen <[email protected]>
Signed-off-by: Tom Hennen <[email protected]>
Signed-off-by: Tom Hennen <[email protected]>
Signed-off-by: Tom Hennen <[email protected]>
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Hey @MarkLodato, if you have time can you take a quick look at 'I' in this PR and double-check my logic? I'd like to make sure I'm not missing anything (or if there's a good reason to include much of 'G' here too). Thanks! |
|
Oh, note that this is based on #1190 so that one needs to be merged first. |
Signed-off-by: Tom Hennen <[email protected]>
There are two ways to look at the usage threat: 1. Can the attacker modify the software being delivered to a consumer. 2. Can the consumer use the software insecurly allowing an attacker to take advantage of that insecurity to exploit them. IMO 1 has the same solutions as 'G' (PR slsa-framework#1190). I could repeat them here under usage, but instead I've updated 'G' to include modification in transit, and I've had 'Usage' address 2 above (albeit by just deferring to CISA's work in this area). fixes slsa-framework#1182 Signed-off-by: Tom Hennen <[email protected]>
Signed-off-by: Tom Hennen <[email protected]>
|
I think we're good to here. Issues have been filed where we might want to make some other things more clear. |
| </details> | ||
| <details><summary>Tamper with provenance or VSA <span>(Build L2)</span></summary> | ||
|
|
||
| *Threat:* Perform a build that would not meet expectations, then modify the |
There was a problem hiding this comment.
| *Threat:* Perform a build that would not meet expectations, then modify the | |
| *Threat:* Issue an attestation that purposefully misrepresents the subject. |
There was a problem hiding this comment.
I don't think this is quite right. In example 1 and 2 the threat described is that an existing attestation is tampered with, the mitigation described detects these problems because the attacker cannot modify the valid attestations without invalidating the expected signatures.
However, I think 'example 3' should probably be captured in a threat by itself as that deals with expectations mismatching which is usually captured elsewhere.
There was a problem hiding this comment.
Filed #1223 to track.
| field to match the digest of the malicious package. Solution: Verifier rejects | ||
| because the cryptographic signature is no longer valid. | ||
|
|
||
| *Example 3:* Adversary uploads a malicious package to `repo/evil-package`, |
There was a problem hiding this comment.
I think slsa doesn't help with this.
This is basically saying "slsa worked perfectly, but the artifact was not suitable for use because of external policy."
There wasn't really any tampering involved, right?
There was a problem hiding this comment.
SLSA should help here because the downstream consumer has an expectation for what the resourceUri is and they validate that expectation as expected by other threats example.
How the consumer establishes that expectation for VSAs is being clarified in #1220, but when checking provenance it's a bit more wishy-washy.
There are two ways to look at the usage threat:
to take advantage of that insecurity to exploit them.
IMO 1 has the same solutions as 'G' (PR #1190). I could repeat them
here under usage, but instead I've updated 'G' to include modification
in transit, and I've had 'Usage' address 2 above (albeit by just
deferring to CISA's work in this area).
fixes #1182
NOTE: this PR is based on top of #1190 since the solution presented in 1190 obviates the need for addressing that here.