A dependency substitution attack is the replacement of an intended trusted dependency with an attacker-controlled or otherwise unsafe alternative. It matters because software builds are vulnerable when dependency choice can be influenced by naming, source, metadata, or policy weakness.
What is Dependency Substitution Attack?
Substitution can happen through dependency confusion, malicious mirrors, lockfile tampering, registry compromise, or deceptive package naming. The attacker’s goal is to have untrusted code treated as a normal dependency by the build system.
What Dependency Substitution Attack Commonly Supports
Common uses include supply chain threat modeling, dependency governance, and registry hardening.
Dependency Substitution Attack vs. Verified Dependency Resolution
Dependency substitution changes what code a build consumes without the team intending it. Verified resolution ensures dependencies come from expected packages and sources.
Frequently Asked Questions
How is substitution different from ordinary malware delivery?
It abuses trusted dependency workflows rather than relying on a separate malicious executable or phishing step.
What controls help most?
Allowlists, pinning, provenance, signed artifacts, and locked registry configuration all help materially.
