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

content: Update mitigation section for the Dependency Confusion threat. #1226

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion docs/spec/draft/threats.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

from the public registry instead of the internal one.

**TODO:** fill out the rest of this section
*Mitigation:* The mitigation is for the software producer to build internal
adityasaky marked this conversation as resolved.
Show resolved Hide resolved
packages on a SLSA Level 2+ compliant build system and define expectations for
build provenance. Expectations must be verified on installation of the internal
packages. If a misconfigured victim attempts to install attacker's package with
TomHennen marked this conversation as resolved.
Show resolved Hide resolved
an internal name but from the public registry, then verification against
expectations will fail.

For more information see [Verifying artifacts](/spec/v1.1/verifying-artifacts)
and [Defender's Perspective: Dependency Confusion and Typosquatting Attacks](/blog/2024/08/dep-confusion-and-typosquatting).

</details>

<details><summary>Typosquatting</summary>

*Threat:* Register a package name that is similar looking to a popular package
Expand Down