Whitepaper
Stop Malware Before It Enters Your Builds
Explore Proactive Defense Measures to Keep Bad Dependencies Out and Only Download What’s Safe
AI-assisted development is making it easier to create code and assemble applications. For application-development and platform leaders, the hard question is whether or not that speed translates into more stable applications in production.
The answer depends on how well the organization can keep harmful software from disrupting the development workflow. A malicious component can create unplanned investigation, rebuilds, retesting, and delayed releases, pulling developers away from planned features and roadmap work.
A more productive approach is to block malicious components at the source, before they reach developers, builds, and pipelines. With the right protections in place, teams can keep delivery moving, preserve application stability, and ship with greater confidence.
Sonatype Firewall provides that proactive layer of protection for teams using third-party repository managers without requiring a repository migration or disruptive infrastructure project.
Executive Summary
- AI-assisted development speeds up software consumption. While automated package decisions boost developer velocity, unsafe components introduce costly downstream rework.
- Application development leaders need more than faster code generation. They need predictable delivery flow, stable applications, and a higher percentage of projects that can move from development to production without avoidable interruption.
- The open source malware problem is industrialized. Sonatype observed more than 464,650 new malicious packages in Q2 2026, bringing the cumulative number of known and blocked malicious packages to more than 1.8 million across major ecosystems.
- Reactive controls often act after a component has already entered the environment. That leaves developers and security teams with investigation, remediation, retesting, and release recovery work.
- Sonatype Firewall blocks known malicious components before download and can quarantine suspicious components while they are evaluated. This helps reduce avoidable rework and keeps developers focused on building and shipping software.
- Sonatype Firewall extends malicious package protection to teams using JFrog Artifactory, Cloudsmith, Azure Artifacts, GitHub Packages, GitLab Package Registry, AWS CodeArtifact, and other third-party repository managers.
Development Is Moving Faster Than Traditional Security Processes
Modern engineering teams leverage AI coding tools, CI/CD automation, and open source packages to accelerate software delivery. Developers and automated systems can now make far more component decisions in far less time.
That speed can improve developer productivity. But it can also increase the volume of unsafe software entering development workflows. In Q2 2026 alone, Sonatype observed 464,650 new malicious packages, bringing the cumulative number of known and blocked malicious packages to more than 1.8 million across major ecosystems. The threat is not only growing in volume; attackers are using more techniques, delivery mechanisms, and approaches to compromise builds.
Traditional controls were designed for a slower model: detect an issue after download, investigate it, and direct remediation before the impact spreads.
When a malicious component reaches a developer workstation, CI/CD pipeline, or application build, teams may have to:
- Investigate the download and assess potential exposure.
- Rotate compromised credentials.
- Remove or replace the component.
- Rebuild affected artifacts and retest applications.
- Delay a release while the issue is resolved.
For application development leaders, that is a delivery problem. It reduces developer capacity, disrupts predictable release flow, and makes it harder to turn AI-enabled development speed into more stable applications in production.
AI is compressing the threat timeline. The emergence of frontier models such as Mythos illustrates how discovery and potential exploitation can move far more quickly, leaving teams less time to understand exposure and keep delivery on track.
In 2025, Sonatype identified 3,430 malware advisories, 3.69x the pre-AI annual baseline. Distinct malicious payloads rose more than 50%, reflecting attackers’ growing use of varied techniques to compromise developer environments.
If teams spend increasing time responding to unsafe components, failed builds, and emergency remediation, AI productivity gains can be absorbed by downstream friction. The answer is not to slow development or require developers to become malware analysts. It is to put reliable guardrails where software enters the workflow, so developers can make fast decisions without inheriting avoidable risk and rework.
In this new era of software development, the repository must become a critical point of control.
Open Source Malware Is Designed to Exploit Developer Trust
Open source software is essential infrastructure for modern application development. It is also an attractive target for attackers because public registries provide a route into developer workstations, build systems, CI/CD pipelines, credentials, and release paths.
Sonatype’s 2026 State of the Software Supply Chain report shows how far this threat has evolved. Repository abuse shows up in 55.9% of all logged malicious packages, indicating bad actors are treating registries like platforms to automate publication and maximize reach. Rather than relying only on straightforward scams, attackers increasingly used multi-stage behavior designed to steal secrets, profile hosts, deliver payloads, establish backdoors, and spread through local projects and public registries.
For application development and platform leaders, these attacks matter because they target the workflows that keep software moving. A compromised dependency can interrupt builds, expose credentials, create unplanned remediation work, and undermine confidence in an application that is otherwise ready to ship.
Several patterns are especially important.
Malicious Packages Often Look Like Normal Development Tools
Typosquatting remains common, but it is no longer the main story. Sonatype research found that only 9% of malicious packages relied on traditional typosquatting. The remaining 91% used broader naming variations intended to resemble the plugins, SDKs, configurations, wrappers, utilities, scoped modules, and versioned extensions developers expect to find.
Attackers understand how software is assembled. They do not need a package to look obviously suspicious. They need it to look plausible enough to be selected during normal development work.
The result is a difficult manual decision for developers. The package may look familiar, fit the immediate task, and appear to come from a trusted source. Asking individual developers to validate every package request is not a scalable way to protect delivery flow.
Familiarity Does Not Guarantee Safety
A component may come from a well-known registry, use a recognizable name, or resemble a trusted project while still being unsafe to consume. Compromised maintainer accounts, package hijackings, and dependency confusion all exploit the trust developers place in familiar software sources and naming conventions.
An artifact can be authentic in the narrow sense that it came from a legitimate registry and was not altered in transit, while still containing malicious code.
Basic repository controls, package popularity, and registry reputation may support reliable access to software, but they do not necessarily determine whether a requested component is safe to introduce into a build or application.
Malware Is Often Only the First Stage
A malicious package can be an entry point rather than the full attack. It may execute installation scripts, search for credentials and tokens, profile the development environment, download an additional payload, or create a path into build and release systems.
This is why developer environments are attractive targets. They often hold high-value credentials and have trusted connections to source code, build automation, cloud services, package registries, and production-adjacent systems.
The impact is not limited to a security team’s incident queue. A compromised developer or build environment can create delays across the application lifecycle, forcing teams to pause planned delivery while they investigate, recover, and validate the integrity of their work.
Campaigns Can Spread Faster Than Reputation Systems
The Shai-Hulud campaign demonstrated how open source malware can behave more like a worm than a passive library. By using stolen credentials to publish poisoned updates, attackers can spread through package ecosystems and developer environments quickly.
Relying on a component’s popularity, age, downloads, or basic registry reputation is not enough. Application-development organizations need current, package-level intelligence that can make an enforcement decision before a component is downloaded and becomes another source of rework.
By using stolen credentials to publish poisoned updates, attackers can spread through package ecosystems and developer environments quickly.
Why Reactive Security Creates More Work
Traditional security programs play an essential role in detecting vulnerabilities and identifying issues in applications already under development or in production. But those controls often begin after a component has entered the environment.
That is late in the life cycle for malicious code, and late for teams trying to maintain reliable delivery.
Consider the difference between these two scenarios.
In a reactive model, a developer or pipeline downloads a package, incorporates it into a project, and later receives a finding from a scan, security tool, or incident-response process. The organization then has to determine whether the package executed, what credentials or systems may be affected, which builds consumed it, whether it reached production, and how to remove or replace it. Developers may need to rewrite code, rebuild containers, retest applications, and delay releases.
In a proactive model, the component is evaluated at the point of request. If it is known to be malicious or violates an applicable policy, it is blocked before it reaches the developer, build, or pipeline. The developer is not left to discover the issue later, and the organization avoids much of the investigative and remediation work that follows.
This is the time-saving value of proactive protection.
It reduces the likelihood that teams will have to:
- Investigate a malicious download after it has reached a developer environment or CI/CD system.
- Rotate credentials and tokens exposed during build or installation activity.
- Trace the component across repositories, builds, containers, and applications.
- Remove or replace software after teams have already built on it.
- Retest affected applications and delay releases.
- Divert developers from planned features and application-delivery work to resolve a preventable issue.
Blocking a malicious component before download is not simply a security outcome. It protects developer capacity, application stability, and the flow from code to production.
Malware Protection Is Different From Vulnerability Management
Organizations need both vulnerability management and malicious code protection to address different problems at different points in the SDLC.
A vulnerability is an unintended flaw in otherwise legitimate software. Vulnerability management helps organizations understand whether they use affected components, assess risk, and prioritize remediation.
Malware is intentionally harmful code. It may contain credential stealers, backdoors, droppers, cryptominers, data-exfiltration logic, or other behavior designed to compromise an environment.
A program focused only on known CVEs can miss malicious packages that do not have a CVE, have only recently appeared, or use behavior that is not represented in a vulnerability database. Conversely, detecting a vulnerability after a dependency has entered a build does not prevent a malicious package from executing at install time.
The practical distinction is straightforward. Vulnerability management helps teams prioritize and remediate issues in software they already use. Malicious code protection helps prevent intentionally harmful software from becoming something development teams need to investigate, remove, and remediate in the first place.
Effective software supply chain protection needs to account for both kinds of risk. For malicious code specifically, the critical control point is before download and execution.
Sonatype Firewall is designed for that control point. It applies Sonatype’s open source malware intelligence to evaluate component requests and stop malicious packages before they enter the development environment.
What Proactive Protection Looks Like in Practice
A proactive approach should make the safe path the easy path. It should not create a slow, manual approval process that pushes developers toward workarounds or interrupts routine delivery.
Sonatype Firewall helps teams protect development workflows through several connected capabilities.
Block Known Malicious Packages Before Download
Sonatype Firewall evaluates requested open source components using proprietary AI and intelligence from Sonatype Research Labs. Known malicious packages can be blocked before they reach developer workstations, CI/CD pipelines, or repository environments.
This reduces the chance that a malicious package can execute within a trusted development workflow and helps prevent the build interruptions, recovery work, and release delays that can follow.
Quarantine Suspicious Components While They Are Evaluated
Not every risky component fits neatly into an immediate allow-or-block decision. Sonatype Firewall can automatically quarantine suspicious components before they enter the environment and release them when they are confirmed safe.
This approach helps teams protect against emerging threats without creating routine manual review queues or unnecessarily interrupting developers. It gives teams a way to handle uncertainty while preserving the speed of normal software delivery.
Apply Policy at the Point of Download
For organizations with broader governance needs, Sonatype Firewall can enforce policies for malicious packages, known vulnerabilities, licensing requirements, quality standards, and other component criteria.
This enables organizations to establish clear rules for what is allowed, blocked, or subject to review. When a component violates policy, developers can receive actionable feedback and safer, compliant alternatives rather than a vague denial.
Policy turns recurring component decisions into automated guardrails. Instead of asking every team to interpret risk data differently — or waiting until a build has failed or a review has begun — policies help teams make consistent decisions at the point when a component is selected.
Policies also create a controlled way to manage exceptions, with waivers that can be scoped and time-bound rather than left as permanent, undocumented workarounds. This helps teams keep delivery moving while retaining visibility into deviations from the standard path.
Protect Your Existing Repository Without Replacing It
Many teams already rely on a third-party repository manager that may have built-in security capabilities. But those controls are likely not backed by the malware intelligence needed to identify and block every emerging threat. That is the purpose of Sonatype Firewall.
Sonatype Firewall adds Sonatype Research Labs intelligence to your existing repository workflows. It’s designed to seamlessly integrate with third-party repository managers such as JFrog Artifactory, Cloudsmith, Azure Artifacts, GitHub Packages, GitLab Package Registry, and AWS CodeArtifact. Teams can easily add malicious code protection without replacing the repository tools they already use or going through a heavy migration project. Sonatype Firewall supports npm, Maven, PyPI, and NuGet packages and acts as a secure gateway to public registries, checking package requests against Sonatype’s malware intelligence before those packages reach an organization’s repository, developer environment, or CI/CD pipeline.
For teams evaluating whether their existing repository security is enough in the Mythos era, the relevant question is not whether the repository can store, proxy, authenticate, or log artifact access. Those capabilities matter. The question is whether malicious packages can still enter through trusted public registries and reach developers or build systems before the organization can evaluate them.
Are malicious packages entering your build systems or reaching your developers?
Sonatype Firewall provides an additional protection layer for that gap.
It is particularly relevant for organizations that need to:
- Add malicious-package protection quickly without replacing their existing repository manager.
- Protect developers and CI/CD pipelines from public-registry malware.
- Reduce exposure to typosquatting, package impersonation, and known malicious dependencies.
- Keep existing development workflows intact while adding a pre-download protection layer.
- Respond to heightened software supply chain risk without slowing release cycles or delaying AI-enabled delivery initiatives.
The aim is not to add another security obstacle for developers. It is to remove a category of avoidable disruption before it becomes their problem.
Turning Policies Into a Developer Advantage
Application development leaders need teams to make good software decisions consistently, without turning routine development into a series of manual security reviews.
That is why policy enforcement should be considered part of developer enablement.
A policy that surfaces after a build has failed or after a security review has begun creates interruption. A policy applied before download can prevent the bad decision from becoming a larger engineering task.
Effective policy helps organizations define and automate their standards while providing developers with clear, immediate guidance. It can prevent teams from consuming components that are known to be malicious, carry unacceptable risk, violate licensing requirements, or fail other organizational criteria.
For development leaders, the benefits are practical:
- Fewer late-stage interruptions and emergency remediation cycles.
- More predictable application builds and release schedules.
- More consistent component decisions across teams and projects.
- Reduced reliance on individual developers to interpret complex risk data.
- Clearer ownership and expiration of necessary exceptions.
- More developer capacity devoted to planned features, modernization, and applications that reach production.
For security and AppSec teams, policy provides enforceable controls that operate at development speed. For platform and engineering teams, it provides a way to standardize trusted software consumption without breaking the workflows developers depend on.
The result is not security versus speed. It is a more reliable way to improve both delivery confidence and software supply chain control.
From Reactive Cleanup to Confident Delivery
The software supply chain will continue to grow more complex. AI will continue to accelerate code generation, dependency selection, vulnerability discovery, and attacker activity. Public package registries will remain essential to how modern applications are built and an attractive route into developer environments and CI/CD systems.
The priority is to turn faster development into more reliable production delivery. That requires protecting the flow of software into development, not simply responding after a harmful component has disrupted it.
A reactive model waits until a malicious component has been downloaded and asks teams to investigate, remove, retest, and recover. A proactive model blocks known malicious components before they enter trusted workflows, applies policy early, and gives developers a safer path to the software they need.
Sonatype Firewall helps organizations make that shift through malicious code protection, automated blocking and quarantine, and policy enforcement without requiring them to replace the tools already embedded in their development environment.
The value of proactive protection is not simply fewer alerts. It is less rework, fewer disrupted builds and releases, more stable applications, and greater confidence that development teams can stay focused on what they are there to do: Build and ship software with confidence.
Learn how Sonatype Firewall can help protect your existing repository workflows from malicious open source packages before they become incidents.
Block the Bad at the source