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.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 🆕 New
Development

No branches or pull requests

4 participants