Malicious dependency attacks in the software supply chain

The modern software development lifecycle (SDLC) is heavily reliant on open-source components, with roughly 90% of applications importing code from public repositories. In the past year alone, over 512,000 malicious open-source packages have been discovered, representing a 2.5x year-over-year increase.

Most security tools are reactive; they only detect known vulnerabilities or problems after a breach has already occurred. A more proactive approach is necessary to prevent novel malicious dependencies from breaching systems. Software supply chain security is a set of practices for verifying and de-risking third-party code, reducing the risk that malicious code will ever enter the environment in the first place.

How malicious dependencies compromise software security

Malicious code is written with harmful intent. In contrast, vulnerable code is written in good faith but contains unintentional weaknesses, such as susceptibility to code injection, that bad actors can later discover and exploit. Traditional security tools, such as static analyzers, are designed to catch logical errors and accidental security gaps, so they often cannot be relied upon to catch malicious code.

These supply chain attacks depend on developers’ trust in publicly available open-source repositories and package registries, such as npm, PyPI, and Maven. They can use a blend of technical and social engineering approaches. Some example attack subtypes:

• Typosquatting: Registering package names that look similar to popular packages (e.g., request vs. request) to catch distracted developers.

• Dependency confusion: Tricking build systems into pulling a malicious version of a public package instead of an internal private one by using higher version numbers.

• Tag hijacking/poisoning: Modifying version tags to point to compromised commits, such as in the March 2026 Trivy supply chain attack.

• Account takeover (ATO): Stealing or hijacking a legitimate maintainer’s credentials to inject malware into a trusted, existing library.

• Brandjacking: Leveraging the name and reputation of a known entity to publish "official-looking" malicious tools.

The true post-breach cost of malicious dependencies: security debt

The cost of malicious dependency attacks goes beyond the immediate cost of the data breach. Unauditable dependencies create security debt that compounds over time, eroding engineering efficiency, customer trust, and auditability across the entire organization.

• Engineering velocity: Every time a new supply chain security incident hits the news, engineering teams that lack a secure-by-default approach need to stop and react. Feature roadmaps freeze while engineers pivot away from building to triaging and auditing the incident.

• Compliance drag: 62% of open-source consumers use vulnerable versions of components. The average remediation time for critical CVEs (common vulnerabilities and exposures) is 500 days. Without a systemic, secure-by-default approach, reactive organizations may never catch up on their backlog of security tasks, and every audit cycle becomes a scramble.

• Loss of auditable provenance: Over time, a codebase with unverified dependencies becomes impossible to audit. It’s impractical to trace production code back to trusted sources without pre-verified dependencies, obstructing your ability to comply with SOC 2, FedRAMP, or the EU Cyber Resilience Act.

Why scanning alone can’t solve the malicious dependency problem

It’s not enough simply to add more dependency scanners to your pipeline.

• Vulnerability scanners are unlikely to catch new malicious dependencies, since they are often not associated with existing CVEs.

• Static analysis only flags logical errors in code. Since the code works as designed, providing the expected functionality while also executing hidden malicious tasks, it won’t be caught by static analyzers.

• Since post-install scripts run as soon as the package is downloaded, the damage may already be done by the time a typical scanner surfaces the issue, if at all.

• Policy engines vet public registries, but cannot verify whether a binary matches its supposed source.

• Patching services can fix known CVEs, but cannot identify new, unknown CVEs.

The defenses listed above are still good practice, but it’s clear that reactive detection can’t protect you from exposure to new malicious dependencies. Scanning for malware after it has already entered your environment is like installing a fire alarm that only goes off after the house has finished burning down. What would a proactive defense strategy look like?

Proactively defending against exposure to malicious dependencies

To prevent malicious dependencies from entering your environment in the first place, assume any dependency could potentially be compromised, and implement a “secure by default” approach.

Curate dependency ingestion

Organizations can limit exposure to malicious code by ingesting dependencies solely from trusted, securely pre-verified sources, rather than pulling public updates straight from upstream.

Chainguard Libraries addresses this by rebuilding all packages from verified source code, guaranteeing that the binaries match the source. Chainguard Repository is a complementary distribution layer that enforces configurable security policies and helps protect developers from upstream artifacts with license controls, CVE blocking, and cooldowns.

Policy-as-code guardrails

Take manual errors out of the equation by implementing automated security policies. Set up CI/CD gates that automatically block packages with “Known Malicious” flags, or packages less than 30 days old, which are a common window for typosquatting attacks. Chainguard Repository implements a 7-day cooldown by default. This simple precaution alone blocks 47% of malicious packages.

Defend the build pipeline against dependency confusion and tag hijacking. Lockfiles are a good first line of defense, but can still be maliciously modified. Solutions like Chainguard Actions help secure the CI/CD pipeline itself by rebuilding CI/CD workflows from verified source code.

Verify provenance with SBOMs and attestations

In 2026, you cannot trust code if you cannot verify its entire dependency trail. Use tools such as Sigstore to sign your build artifacts and verify that the code that left the build server is the exact same code that arrives in production.

Chainguard achieves SLSA Level 3 provenance across all its artifacts because we control the entire build pipeline through Chainguard Factory, a build system that tracks upstream sources and automatically triggers clean rebuilds with fresh security patches.

Sanitize the build environment

Don’t expose your environment to potentially malicious post-install scripts, which can exfiltrate credentials, create backdoors, or download arbitrary code. Build environments should have no egress to the public internet by default. Use flags such as -ignore-scripts during installation to prevent malicious packages from running unknown code.

Defining “secure by default” for the dependency layer

“Secure by default” isn’t merely a nice-to-have practice anymore; as of 2026, the EU Cyber Resilience Act makes it a legal requirement for products sold within the EU, with penalties ranging up to 15 million Euros. Here are the requirements to meet that standard:

• Build from verified sources. Pre-built binaries may be tampered with. The only way to guarantee a package is to compile it yourself from fully auditable source code.

• Maintain end-to-end provenance. Every artifact must have a signed chain of custody from source repo to production. SBOMs and SLSA attestations make this auditable.

• Enforce policy at the distribution layer. It’s not practical or scalable to expect individual developers to hand-vet every dependency. Automate policy enforcement at the point of dependency ingestion through strategies like cooldowns, CVE blocking, and license controls.

How Chainguard minimizes exposure to malicious code

Rather than reactively scanning for problems after exposure, Chainguard’s core philosophy is to proactively secure the supply chain in order to provide clean, auditable artifacts and minimize exposure to malware.

A quick review of our product lineup:

• Chainguard Libraries: Rebuilds Python, Java, and JavaScript packages from verified source code in a tamper-proof Factory. Our binaries are guaranteed to match their sources, preventing 98%+ of malware (depending on ecosystem) from ever reaching the environment. Drop-in compatible with PyPI, npm, and Maven Central.

• Chainguard Repository: Our policy-aware distribution layer that protects developers from upstream registries. Gives your organization a simple endpoint to pull open-source artifacts, configure security policies, and monitor coverage & policy enforcement across your environment. Enforces CVE blocking, license controls, and cooldowns; the 7-day default cooldown blocks 47% of malicious packages before they can be consumed.

• Chainguard Containers: Minimal, distroless, zero-CVE container images rebuilt daily from verified source code with the latest security patches. Provides auditability via build-time SBOMs, verifiable Sigstore signatures, and reproducible builds.

• Chainguard Actions: Secure CI/CD workflows that prevent dependency confusion, tag hijacking, and secret exfiltration at the pipeline layer. Built from verified source code with continuous scanning.

• Chainguard Factory: An automated build system that tracks upstream sources, triggers clean rebuilds, and continuously updates thousands of containers, libraries, and VMs with the latest security patches.

• Chainguard OS: A minimal, security-focused Linux distribution with enterprise-grade security features and continuous updates. Built specifically to minimize attack surface.

Modern security compliance can be a monumental task, and we’ve done the hard work for you so that you can protect your software while freeing up valuable developer time. Chainguard is the only platform that defends against malicious dependencies across the entire software stack, including language libraries, container images, CI/CD, and distribution policies. Reach out to the Chainguard team to learn more about proactive security.