Skip to content
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

Open
lehors opened this issue Oct 9, 2024 · 4 comments
Open

TODO: Need mitigation description for "Dependency confusion" threat #1181

lehors opened this issue Oct 9, 2024 · 4 comments
Assignees
Labels

Comments

@lehors
Copy link
Member

lehors commented Oct 9, 2024

The 'Dependency Confusion' threat (link) needs a mitigation section and perhaps examples.

@github-project-automation github-project-automation bot moved this to 🆕 New in Issue triage Oct 9, 2024
@lehors lehors changed the title TODO: Needs mitigation description for "Dependency confusion" threat TODO: Need mitigation description for "Dependency confusion" threat Oct 9, 2024
@lehors lehors added the slsa 1.1 label Oct 9, 2024
@TomHennen
Copy link
Contributor

@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.

@michaelwinser
Copy link

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.

@meder
Copy link
Contributor

meder commented Oct 22, 2024

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.

@TomHennen
Copy link
Contributor

TomHennen commented Oct 22, 2024

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.

@TomHennen TomHennen assigned TomHennen and meder and unassigned TomHennen Oct 22, 2024
@zachariahcox zachariahcox moved this from 🆕 New to 🏗 In progress in Issue triage Nov 11, 2024
@lehors lehors added this to SLSA 1.1 Nov 26, 2024
@lehors lehors moved this to Todo in SLSA 1.1 Nov 26, 2024
TomHennen pushed a commit that referenced this issue Dec 13, 2024
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 🏗 In progress
Status: Todo
Development

No branches or pull requests

4 participants