APPLICATION SECURITY | SUPPLY CHAIN SECURITY

July 10, 202612 min read

Software Supply Chain Attacks: Defending Against Dependency Confusion, Typosquatting, and Compromised Packages

Sources:CISA Software Supply Chain Security Guidance|SLSA Supply Chain Levels for Software Artifacts|OpenSSF Scorecard

Eric Bang

Founder & Cybersecurity Evangelist

245%

year-over-year increase in software supply chain attacks between 2022 and 2024 — the attack surface grows with every new open source dependency

XZ Utils 2024

a backdoor planted by a nation-state actor over two years of social engineering of the open source maintainer — affecting a core compression library in Linux distributions

npm

hosts over 2.5 million packages — a dependency tree of 100 npm packages typically pulls in 1,000+ transitive dependencies from thousands of different authors

SBOM

Software Bill of Materials — a machine-readable inventory of all software components — is now required for federal government software suppliers and increasingly demanded by enterprise procurement

The four main attack techniques and how each works

Software supply chain attacks follow distinct patterns. Understanding each helps prioritize the right defensive controls.

Dependency confusion (namespace collision)

Dependency confusion exploits the package manager resolution order. In npm, PyPI, and RubyGems: if a package exists in both a private registry (your internal packages) and the public registry (npm, PyPI), some package manager configurations will prefer the public registry version — even if the private version is the intended one. An attacker registers a package on npm with the same name as your private internal package (discovered from error messages, job postings, or leaked package names) but with a higher version number. Package managers configured to check public registries first will install the attacker's version instead of your internal version, executing the attacker's postinstall script. Fix: use npm scope (@yourorg/package-name) for all internal packages, configure package managers to resolve internal package names only from your private registry.

Typosquatting (name confusion)

An attacker publishes a malicious package with a name nearly identical to a popular legitimate package: requests vs request, lodahs vs lodash, crypt vs crypto. Developers mistyping package names install the malicious version. Typosquatting packages typically execute their payload in the package's install script (postinstall in npm, setup.py in PyPI) — the malicious code runs at npm install time, before the package is even used. Defense: audit your package.json/requirements.txt for unexpected package names, use npm audit and pip-audit for known-malicious package detection, and consider requiring all package installs be reviewed before being added to project dependencies.

Account takeover of legitimate package maintainers

Attackers compromise the account of a legitimate, trusted package maintainer (often through credential stuffing using breach data) and publish a malicious update to an existing package under the trusted package name. The malicious version is automatically installed by consumers who have broad version ranges (^1.0.0 accepts any patch and minor update). The 2021 ua-parser-js npm attack is the canonical example: a popular package with millions of weekly downloads was hijacked and a malicious version containing a cryptocurrency miner and credential stealer was published. Defense: pin exact package versions in production (not ranges), monitor for unexpected new versions of your dependencies, and use npm audit signatures to verify package integrity.

CI/CD pipeline injection

Build pipelines execute code from many sources: the repository being built, external action scripts (GitHub Actions uses actions from other repositories), Docker base images, and build dependencies. An attacker who compromises a GitHub Action that your pipeline imports (or who creates a similar-named action) can inject code into your build process, exfiltrate secrets from the build environment (AWS credentials, code signing keys, API tokens stored in CI secrets), or tamper with the build artifacts before they are deployed. Defense: pin all GitHub Actions to specific commit SHAs rather than mutable tags (v1 can be moved to point to different code; a specific SHA cannot), audit all third-party actions your pipelines use, and use environments with secrets limited to specific workflow steps.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

SBOM: inventory before you can defend

A Software Bill of Materials is a machine-readable list of all software components in your application. You cannot monitor, audit, or respond to supply chain compromises in dependencies you do not know exist.

Generate SBOMs for all production applications

SBOM generation tools: Syft (open source, supports containers and application directories, produces CycloneDX and SPDX format SBOMs), Trivy (open source, vulnerability scanning and SBOM generation), Microsoft SBOM Tool (open source). For npm projects: npm sbom --sbom-format cyclonedx. For container images: syft ubuntu:latest -o cyclonedx-json. An SBOM for a typical web application contains 500-2000 components including transitive dependencies. The SBOM should be generated at build time and stored alongside the build artifact — not generated retroactively from source code analysis.

Continuous SBOM monitoring for new vulnerabilities

A point-in-time SBOM has limited value. The value comes from continuous monitoring: when a new CVE is published for a component in your SBOM, your security tooling alerts on affected applications. Tools that operationalize this: Dependabot (GitHub) monitors dependency files and opens PRs for vulnerable package versions, Snyk continuously monitors SBOMs and application dependency files, OSS Index (Sonatype) provides free vulnerability data for SBOM components. The goal: time from CVE publication for a dependency to remediation PR opened is measured in hours, not weeks.

SBOM for procurement and vendor risk

Enterprise procurement increasingly requires software vendors to provide SBOMs for purchased software — both to understand the open source component risk and to comply with Executive Order 14028 requirements for federal agencies. When evaluating vendor software: request the SBOM, run it through a vulnerability scanner, and assess: does this vendor have a process for patching components with known vulnerabilities? What is their average time to update a vulnerable dependency? Vendor SBOM review catches cases like a vendor shipping software with a years-old Log4j version.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Free daily briefing

Briefings like this, every morning before 9am.

Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.

Controls that prevent supply chain compromise

Defensive controls address different attack techniques. Implement layered controls because no single control addresses all attack vectors.

Lock file enforcement (prevent dependency drift)

Lock files (package-lock.json for npm, poetry.lock for Python, Cargo.lock for Rust) pin exact versions and hashes of all dependencies including transitive dependencies. Commit lock files to your repository and enforce their use in CI: npm ci (not npm install) uses package-lock.json exactly; pip install with --require-hashes enforces hash verification. Never regenerate lock files in CI — only in human-reviewed developer workflow. A lock file with hash verification prevents both version drift and tampered package content (a changed package with the same version number has a different hash).

Private package registry with proxying and scanning

Route all package installs through a private registry that proxies public registries (JFrog Artifactory, Sonatype Nexus, AWS CodeArtifact). The private registry: scans all packages for known malware and vulnerabilities before serving them to developers, caches approved versions (preventing supply chain attacks that modify a package after your initial pull), and enforces your organization's approved package list. For dependency confusion prevention: configure the private registry to serve internal packages under your organization's scope and block any public package with the same name as an internal package.

OpenSSF Scorecard and sigstore for package trust

OpenSSF Scorecard evaluates open source projects against security best practices: branch protection, code review requirements, CI/CD security, dependency update automation, and others. Use Scorecard to assess the security posture of critical dependencies before adopting them — a package with a score below 4/10 for projects you depend on represents supply chain risk. Sigstore (cosign) provides cryptographic signing for containers and packages — verifying that a package you install was built by the expected maintainer from the expected source code. npm provenance (released 2023) allows npm packages to be published with build provenance that links the package to its source repository and CI build — verify provenance with npm install --foreground-scripts.

CI/CD hardening: least-privilege secrets and pinned actions

For GitHub Actions: use GITHUB_TOKEN with minimum required permissions (set permissions: read-only at the workflow level, only elevate for steps that write). Pin all third-party actions to full commit SHAs: uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 not uses: actions/checkout@v4. Never pass production secrets (AWS prod credentials, code signing keys) to pull request workflows — PRs from forks can access secrets in some configurations. Use OIDC (OpenID Connect) for cloud credentials in CI: temporary credentials issued for each build rather than long-lived access keys stored as secrets.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Detecting a supply chain compromise after it occurs

Despite preventive controls, compromise is possible. Early detection limits the blast radius.

Monitor for unexpected outbound connections from build systems

A supply chain attack payload commonly exfiltrates data (CI secrets, source code) or establishes persistence during the build phase. Build runners should have network egress restrictions: only allow connections to known registries (npm, PyPI, your private registry) and block all other outbound connections. Any outbound connection to an unexpected destination from a build runner is an immediate incident indicator. Network-level controls on build infrastructure are often absent — the build environment is treated as trusted when it is actually a high-value target.

File integrity monitoring on installed packages

After installing dependencies: hash the installed package files and compare against the lock file hashes and registry-published hashes. A package that installs differently than its registry hash indicates tampering. Tools: npm audit signatures verifies npm package integrity against the registry, pip's hash verification with --require-hashes, and enterprise registry proxies that validate hashes on pull. This catches attacks where a package's content is modified after publication (a rare but documented technique).

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

The bottom line

Software supply chain attacks scale because they target trust — the package you always trusted, the action you imported without reviewing, the build tool you never questioned. Effective defense is not about eliminating open source dependency (that is operationally impossible) but about making the dependency graph visible (SBOM), verifiable (lock files with hashes, sigstore signatures), and monitored (continuous vulnerability scanning). For CI/CD pipelines, the same principle applies: treat your build environment as a security boundary, not a trusted internal system.

Frequently asked questions

How do I check if an npm package is malicious before installing it?

Before installing an unfamiliar package: check the package's npm page for download count and maintenance status (very low download packages with recent publish dates are higher risk), review the package's GitHub repository for legitimacy (does it have issues, contributors, history?), run the package through Socket.dev (real-time npm package security analysis), check Snyk Advisor for security score, and search for the package name in vulnerability databases. For packages you are about to add as a dependency: read the package.json install scripts (postinstall, preinstall) — these scripts execute automatically at install time and are the primary malware delivery mechanism. Never install packages with suspicious install scripts you cannot read and understand.

What is the difference between a direct and transitive dependency vulnerability?

A direct dependency is a package you explicitly listed in your package.json or requirements.txt. A transitive dependency is a package that one of your direct dependencies depends on — you did not choose it directly but it is installed as part of your dependency tree. Most supply chain vulnerabilities affect transitive dependencies: Log4Shell affected Log4j, which was a transitive dependency for thousands of Java applications that did not directly import it. SBOMs capture all dependencies including transitive ones. Tools like Dependabot and Snyk detect vulnerabilities in transitive dependencies and generate remediation PRs that update the direct dependency to a version that pulls in a patched transitive version.

Should we audit all open source dependencies before use?

Manual audit of every dependency is not operationally feasible — a typical npm project has thousands of transitive dependencies. Apply risk-based prioritization: perform manual code review for direct dependencies with high privilege (packages that handle authentication, encryption, or make network requests), high usage (packages in performance-critical paths), or low package health scores (OpenSSF Scorecard below 4, last commit more than 2 years ago). Use automated tooling (Dependabot, Snyk, Socket.dev) for broad automated scanning of all dependencies. Reserve manual review for the highest-risk subset.

Sources & references

Free resources

Free download

Critical CVE Reference Card 2025–2026

25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.

Free download

Ransomware Incident Response Playbook

Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.

Free newsletter

Get threat intel before your inbox does.

50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.

Unsubscribe anytime. We never sell your data.

Author

Eric BangCISSP

Founder & Cybersecurity Evangelist, Decryption Digest

Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.

View profile →LinkedIn

Back to all briefings

Subscribe for Updates

software supply chain security dependency confusion attack typosquatting npm pypi open source security SBOM supply chain npm security CI/CD supply chain attack supply chain defense 2026

Black Hat Giveaway

Win a $2,495 Black Hat pass.

Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.

Software Supply Chain Attacks: Defending Against Dependency Confusion, Typosquatting, and Compromised Packages

The four main attack techniques and how each works

SBOM: inventory before you can defend

Controls that prevent supply chain compromise

Detecting a supply chain compromise after it occurs

The bottom line

Frequently asked questions

How do I check if an npm package is malicious before installing it?

What is the difference between a direct and transitive dependency vulnerability?

Should we audit all open source dependencies before use?

Sources & references

Critical CVE Reference Card 2025–2026

Ransomware Incident Response Playbook

Get threat intel before your inbox does.

Subscribe to enter the giveaway