-
Notifications
You must be signed in to change notification settings - Fork 229
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
TODO: Need mitigation description for "Dependency confusion" threat #1181
Comments
@meder would you be interested in sending a PR for this? It's very much inline with the dependency track and your recent blog post. |
I would suggest that all builds should pull only from an internal artifact registry and that admission to that registry be explicitly managed and audited. Especially the namespace. |
I suppose there are two ways to look at the mitigations on the threats page: using existing SLSA tracks vs best practices. I was leaning towards applying the existing SLSA tracks lens, given that I see explicit callouts to SLSA not addressing some threats. I think the idea is to give others a way to understand what SLSA does and doesn't address. Once the dependency track is a thing the page could be updated. |
This is what I was thinking. For now just say it's not addressed but link to Meder's recent blog post for ideas. Then update once the dep track is done. Assigning this to Meder per his request as it's well aligned with the dependency track. |
…t. (#1226) 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. --------- Signed-off-by: Meder Kydyraliev <[email protected]>
The 'Dependency Confusion' threat (link) needs a mitigation section and perhaps examples.
The text was updated successfully, but these errors were encountered: