-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
content: draft: Flesh out 'Distribution Channel' threats. #1190
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 <tomhennen@google.com>
Signed-off-by: Tom Hennen <tomhennen@google.com>
Signed-off-by: Tom Hennen <tomhennen@google.com>
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Tom Hennen <tomhennen@google.com>
Signed-off-by: Tom Hennen <tomhennen@google.com>
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 <tomhennen@google.com>
FWIW I'm considering moving these things to usage and just pointing most of (G) there. Any thoughts welcome. |
I take it back. The 'Usage' section says "A usage threat is a potential for an adversary to exploit behavior of the consumer." Verification would seem to be out of scope. |
Signed-off-by: Tom Hennen <tomhennen@google.com>
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 <tomhennen@google.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nicely done! Thanks @TomHennen
Taking into account some review that @zachariahcox did on #1191 I think we're good to go here. |
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 #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. --------- Signed-off-by: Tom Hennen <tomhennen@google.com>
These threats generally match the threats for 'Artifact Publication' with
the twist that the consumer must do the verification instead.
Explicitly calling out that modification in transit to the consumer is in scope for this threat.
Consumer verification may be simplified if a VSA was issued at publication time.
fixes #1180