Most organizations spend a lot of time looking for vulnerabilities in the software they build. But what about the malicious packages that enter before development even begins?
Attackers publish malicious packages, hijack legitimate projects, and turn routine dependency download into opportunities for credential theft or a build compromise. Malicious packages can run code during installation, when a developer or build system may already have access to source code, tokens, cloud accounts, or publishing credentials.
CI pipelines and AI agents add to the volume of package requests. They can resolve and install dependencies automatically, often without a human reviewing each request. That makes the point where packages enter the development workflow an important place to evaluate risk.
A repository or package firewall checks dependency requests against threat intelligence and policy before components reach developers, agents, or builds. The protection depends on the quality of that intelligence and where the firewall can evaluate a request.
In October 2026, a hijacked release of the TensorLake TypeScript SDK used an install hook to search for credentials and accept remote commands.
Sonatype's analysis found code that could modify repositories accessible to the compromised account and could expose collected data through a GitHub fallback. The investigation did not confirm that data was published, repositories were modified, or downstream systems were affected.
Other campaigns used different routes into the same workflows:
Hijacked packages and new malicious packages: Six npm packages delivered the same malware. Three appeared to be hijacked legitimate packages, and three were published with the malicious payload already included. The malware used Ethereum transactions to find infrastructure hosting additional payloads.
Large-scale package flooding: Sonatype identified nearly 850 components in the Flooding Dropper campaign. The packages downloaded and launched additional payloads on Windows, Linux, and macOS.
Credential theft and propagation: The Mini Shai-Hulud wave affected more than 2,200 component versions. Malicious releases of legitimate packages used install hooks to steal credentials and, where publishing access was available, compromise more packages.
Install-time execution: Miasma waves abused binding.gyp and node-gyp to execute during installation, rather than relying only on familiar lifecycle scripts. The Leo Platform compromise report tracked 23 malicious package versions.
These incidents show why package risk is not limited to suspicious names or newly created projects. Malicious code can arrive in a familiar package, run as part of installation, and act with the access available to the developer, build, or agent that requested it.
A repository or package firewall checks dependency requests as they pass from a development environment toward package sources. It evaluates a requested component against security intelligence and, depending on the product's capabilities and configuration, can block or quarantine components that appear malicious or violate policy.
Once a package has been installed, teams may need to investigate the affected machine, identify exposed credentials, check for persistence, and determine whether the package reached other systems. Blocking a known malicious package at the point of entry can help prevent that cleanup from starting in the first place.
A firewall is one layer of software supply chain protection. It does not replace endpoint security, code review, or other controls. It addresses a specific risk: malicious or policy-violating components entering through package requests. And like any control, its coverage depends on which developers, pipelines, agents, and package sources route through it.
A repository or package firewall should do more than sit between a repository and a registry. As you evaluate options, consider whether or not it can:
Block malicious components before download, at the point where a package is requested.
Use current, in-depth threat intelligence that can help identify more than known vulnerabilities or suspicious package names.
Protect requests from developers, CI pipelines, and AI agents that can access public package sources.
Fit your repository tools and package sources without requiring a change to established workflows.
Cover the package ecosystems your teams use, and make clear which registries, mirrors, and private sources are included.
Strong firewall protection helps teams stay ahead of threats by identifying and blocking malicious components before they enter the development process. By evaluating package requests at the point of intake, it can reduce the risk of compromised builds and the investigation and rework that follow, while helping teams keep development moving.
A firewall's decision is only as useful as the evidence behind it. Sonatype Firewall combines machine-learning signals with AI-powered analysis, alongside the expertise of Sonatype's security research team, to identify suspicious packages and investigate if they contain malicious code.
By analyzing release behavior, examining package contents, and correlating findings across multiple sources, Sonatype can detect threats earlier, uncover additional affected packages, and turn new discoveries into actionable intelligence that informs Firewall's blocking and quarantine decisions.
That work can involve several kinds of analysis:
Activity and release patterns can help surface packages that behave differently from their project's history or from typical ecosystem activity.
Behavioral analysis can flag unusual signals around a package or release. Researchers can investigate those findings to confirm whether a component is malicious.
Payload analysis examines what the code actually does, including behavior such as credential theft, code injection, or downloading another payload.
Secondary expansion follows the code beyond the original package. Advanced Binary Fingerprinting can help identify embedded or renamed code that may not appear in a package's declared dependencies. In one investigation, Sonatype researchers found code associated with the flatmap-stream incident in 12 additional npm components.
Together, these methods provide context that a package name or manifest alone cannot. That context helps a firewall make a more informed decision about whether to allow, block, or hold a request for review.
Every dependency starts with a request. A developer adds a package, a pipeline pulls it into a build, or an AI agent selects it for generated code. That request is an opportunity to assess a component before it becomes part of your software.
Sonatype Firewall helps teams bring security and development together at the moment open source enters the software supply chain. Backed by Sonatype's research and designed to work with supported repository environments, it helps organizations block malicious components earlier before they reach developers or workflows. That gives teams a chance to stop known threats at the point of entry, reduce avoidable disruption, and keep development moving with greater confidence.
Even if your existing repositories support secure component selection, malicious packages can still make their way into development. The difference comes down to how threats are identified, how quickly new malicious activity is detected, and whether that intelligence can stop a package before it's downloaded. Sonatype Firewall is that difference. Since it's designed to work with a wide range of repository managers, you can add an additional layer of protection to block known risks and avoid downstream work.
See how Sonatype Firewall can help protect your repositories from malicious packages.