DustiLock is a tool to find which of your dependencies is susceptible to Dependency Confusion attack.
What is Dependency Confusion?
A technique discovered by @alex.birsan to hijack a privately used package by registering its name (if available) on a public registry with a higher version number. This may cause artifact servers and build tools to “confuse” and use the attacker’s package.
go build ./dustilock
-r– Recursive scan (default=false)
-p <path>– Custom path to scan (default=current working dir)
-a– Audit only, will not fail for detections (default=false)
./dustilock -p /tmp/code -r DustiLock started scanning directory "/tmp/code" (recursive=true) ... error - npm package "private-org-infra" is available for public registration. /tmp/code/test-project/package.json one or more packages are available for public registration
Using in CI Workflows
This tool can be easily integrated into modern CI workflows to test new code contributions.
Using in GitHub Actions
Add the following to your workflow file as a step:
- name: DustiLock uses: firstname.lastname@example.org
- name: DustiLock uses: email@example.com with: recursive: true path: my-nested-project # disable failing the build when having alerts (default = false) audit: true
How to Deal With Vulnerable Packages?
To mitigate the risk, you need to register a dummy placeholder package with the same names as your internal packages (if any), to prevent such an attack. When registered, do use a low version number (e.g. 0.0.1), so it won’t be used instead of your internal package.
At this moment, this tool can check:
- Alex Birsan for sharing his research and helping to secure the open-source supply-chain.
- https://github.com/davidfischer/requirements-parser for examples on python requirements.txt dependencies
Copyright (c) 2021 Checkmarx