Use Case: Supply Chain
Dependency confusion detection
An internal package name was registered on PyPI with version 9.9.9 — higher than the internal version 1.2.3. Three build pipelines downloaded the malicious public version before the attack was noticed.
When the package manager chooses the wrong version
Dependency confusion is an attack that requires no credential theft, no social engineering, and no malware distribution network. The attacker simply registers a package on a public registry that has the same name as an internal package used by the target. If the target's build environment resolves packages from both public and private registries without strict source pinning, the package manager's version resolution rules may prefer the public package — delivering the attacker's code to every build that depends on that package name.
rule: dependency_confusion_attack
type: sbom + build_log + behavioral
sources:
- github_actions_logs
- jenkins_build_logs
- gitlab_ci_logs
- edr_process_events (postinstall scripts)
trigger:
- condition: |
package_downloaded.source == "public_registry"
AND package_name IN internal_package_catalog
- OR:
- condition: |
newly_installed_package.postinstall_script_ran == true
AND outbound_connection.domain NOT IN approved_endpoints
enrichments:
- internal_package_catalog: artifactory, nexus, private_pypi
- package_diff: public_vs_internal_version
- sbom_impact: all_services_using_package
mitre: T1195.001 (Compromise Software Dependencies)MITRE ATT&CK mapping
Dependency confusion FAQ
What is dependency confusion and how does it work?
Dependency confusion exploits how package managers resolve package names when both a private registry and a public registry are configured. If an attacker publishes a public package with the same name as an internal private package but at a higher version number, some package managers will install the public version — which the attacker controls — instead of the internal one. Alex Birsan's 2021 research demonstrated this against Apple, Microsoft, PayPal, and others.
How does ManySignal detect dependency confusion attacks?
Three detection layers: (1) build log monitoring for packages being downloaded from public registries that match internal package name patterns, (2) SBOM analysis comparing expected package sources against actual download sources, and (3) postinstall behavioral analysis detecting scripts in newly installed packages making external network connections.
Which package ecosystems are covered?
npm (Node.js), PyPI (Python), NuGet (.NET), Maven (Java), RubyGems (Ruby), Go modules, and Cargo (Rust). Each ecosystem has different resolution behavior, and ManySignal's detection is tuned for the specific confusion vectors in each.
Can this attack be prevented entirely?
Yes, through registry configuration: scoping internal packages with organization-specific prefixes (@company/package-name in npm), pinning package sources in .npmrc or pip.conf, and using a private registry with deny-by-default for unknown packages. ManySignal recommends the preventive configuration and detects if the attack bypasses those controls.
Detect public registry squatting before your pipelines install it
Internal package catalog monitoring with build log analysis across npm, PyPI, NuGet, and Maven.