content: Update mitigation section for the Dependency Confusion threat. #1226
Conversation
Signed-off-by: Meder Kydyraliev <[email protected]>
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
meder
changed the title
Signed-off-by: Meder Kydyraliev <[email protected]>
| @@ -775,9 +775,18 @@ The consumer requests a package that it did not intend. | |||
| on the victim's internal registry, and wait for a misconfigured victim to fetch | |||
There was a problem hiding this comment.
to be clear, is "fetch" the problem here or the fact that a bespoke tool needs to know that that a build should be failed if a package doesn't match its expected issuer and producer and you have to know ahead of time what's expected.
potentially the mitigation for this is just a redirect to the "verifying-artifacts" file?
There was a problem hiding this comment.
dependency resolution algorithms are tricky already. It's also not great to write tools that only know how to fail the build instead of how to fetch the right deps.
|
@meder we talked about this PR during the SLSA meeting on 11/11/2024. It is my opinion that this would fall in the Dependency Track, not the Build track. The OpenSSF S2C2F already has a requirement (ENF-1) to mitigate against Dependency Confusion attacks. Per the meeting discussion, they said that we should admit that this is hard, and if there are blogs or articles about ways to mitigate against this, we should share them here. So I'm sharing some links below - but again - I think this belongs in the SLSA Dependency Track and we should wait to cover this there.
|
|
And here's a blogpost on the topic: Defender's Perspective: Dependency Confusion and Typosquatting Attacks. |
Documenting a SLSA-native and build trackccentric mitigation for Dependency Confusion attacks (#1181)
Would love to hear thoughts/opinions on the best way to reflect differing levels of adoption / maturity in native provenance verification across different ecosystems.