By Nicholas Thomson, Aikido Security

A dependency firewall is a security checkpoint that evaluates open source packages before they are installed. It can protect developer workstations, build environments, CI/CD pipelines, and AI coding agents by blocking packages that appear malicious, suspicious, or inconsistent with organizational policy.

The concept is similar to a network firewall. Instead of inspecting network traffic, a dependency firewall examines software packages and package metadata at the point of installation.

This timing matters. Once a malicious package begins executing an installation script, it may already have access to source code, credentials, environment variables, authentication tokens, and other sensitive resources.

Why Dependency Firewalls Are Becoming Necessary

Modern applications depend heavily on open source software. A single application may incorporate hundreds or thousands of direct and transitive dependencies, many of which developers never selected or reviewed individually.

Attackers increasingly target this ecosystem because compromising one package can provide access to many downstream users.

Installation Scripts Can Execute Immediately

Package managers may allow packages to execute code during installation. In the npm ecosystem, for example, lifecycle hooks such as preinstall, install, and postinstall can run automatically.

These scripts have legitimate uses, including compiling native components or configuring an application. They can also be abused to:

Steal credentials and authentication tokens
Download additional malware
Establish remote access
Search local files and source-code repositories
Exfiltrate environment variables
Install cryptocurrency miners
Modify development tools or build environments

Because installation scripts may run before a developer reviews the package, detecting the threat after installation may be too late.

AI Agents Create New Installation Paths

Package installations are no longer initiated exclusively by humans.

AI coding agents, development assistants, IDE extensions, and Model Context Protocol servers may install packages while completing a task. These tools often operate in environments containing source code, cloud credentials, signing keys, API tokens, and access to internal systems.

AI-generated package recommendations introduce another risk. A model may suggest a plausible package name that does not actually exist. Attackers can register the invented name and publish a malicious package in anticipation of future installation attempts. This technique is often called slopsquatting.

Dependency controls must therefore account for both human mistakes and automated software decisions.

The Detection Window Is Shrinking

Malicious package campaigns can appear and disappear quickly. Attackers may publish a package, distribute it through compromised accounts or deceptive documentation, and remove it within hours.

Traditional controls such as nightly scans, periodic software composition analysis, or vulnerability advisories may identify the package only after it has executed.

A dependency firewall changes the decision point. Instead of asking whether an installed package is malicious, it asks whether the package should be allowed to install at all.

Trusted Packages Can Become Compromised

Download counts, project age, and maintainer reputation are useful signals, but they are not guarantees.

Attackers may compromise a maintainer account, steal a package-registry token, take control of an abandoned project, or introduce a malicious transitive dependency into an otherwise legitimate release.

A familiar package name can therefore distribute a hostile update. Security controls should evaluate every version rather than permanently trusting a package based on its historical reputation.

What a Dependency Firewall Should Check

Implementations vary, but an effective dependency firewall should examine both direct and transitive dependencies. Many supply-chain attacks enter through packages several layers below the dependency explicitly selected by the developer.

Known Malware

The firewall should compare package names, versions, files, and indicators against current malicious-package intelligence.

This can identify known:

Backdoors
Credential stealers
Remote-access tools
Cryptocurrency miners
Data-exfiltration packages
Malicious installation scripts

The usefulness of this control depends heavily on how quickly the underlying intelligence is updated.

Package Age

Newly published packages and versions present elevated uncertainty. Many malicious releases are identified and removed shortly after publication.

A minimum package-age policy creates a waiting period before a new version can be installed. A delay of 24 to 72 hours may allow maintainers, security researchers, registries, and automated analysis systems to identify suspicious releases.

Package age should not be treated as proof of safety. It is a risk-reduction mechanism that limits exposure during the most uncertain period.

Organizations should also establish an exception process for urgent patches and newly released internal packages.

Typosquatting

Typosquatting packages imitate popular dependencies using similar names. An attacker may rely on a developer mistyping an installation command or failing to notice a subtle spelling difference.

Examples of typosquatting techniques include:

Transposed characters
Missing letters
Added hyphens
Similar Unicode characters
Alternate package scopes
Common abbreviations or misspellings

A dependency firewall can compare requested package names with established packages and flag suspicious similarities before installation.

Dependency Confusion

Dependency confusion occurs when an internal package name is also available through a public registry.

If the package manager selects the public package, often because it has a higher version number, attacker-controlled code may enter the build environment.

Organizations can reduce this risk by:

Using scoped names for private packages
Reserving internal package names on relevant public registries
Separating public and private registry resolution
Pinning approved registry sources
Verifying package provenance
Blocking unexpected public versions of internal packages

Unclaimed Package Names

Documentation, tutorials, configuration files, and README files sometimes reference packages that have never been published.

These names may later be registered by attackers. Developers or AI agents following the original documentation could then install a package controlled by someone unrelated to the author.

Dependency controls should treat previously unclaimed names and newly registered packages referenced in older documentation as potentially suspicious.

Installation-Script Behavior

More advanced dependency firewalls inspect package behavior rather than relying only on reputation and signatures.

Static analysis can identify suspicious commands, obfuscation, encoded payloads, unexpected file access, or network destinations. Sandboxed execution can provide additional insight into what the package attempts to do during installation.

Potential warning signs include:

Spawning shells or command interpreters
Reading browser or cloud credential stores
Accessing SSH keys
Connecting to newly registered domains
Downloading executable files
Disabling security tools
Modifying shell configuration
Establishing persistence
Executing heavily obfuscated code

Behavioral analysis is particularly valuable for newly published malware that has not yet been added to a threat-intelligence feed.

Maintainer and Account-Takeover Signals

A legitimate package may become dangerous after its maintainer account is compromised.

Relevant warning signs include:

An unexpected maintainer change
A release from a previously inactive project
A version with no corresponding source-code commit
A sudden addition of an unfamiliar dependency
New installation scripts
A major increase in package size
Publication from an unusual location or account
Changes to registry metadata without matching repository activity

No single signal proves compromise. Multiple anomalies can justify blocking the installation or requiring manual approval.

Obfuscation

Malicious code may be hidden using techniques intended to evade human review and automated scanners.

Examples include:

Encoded or encrypted strings
Invisible Unicode characters
Code hidden in whitespace
Dynamically generated commands
Payloads stored inside images or other assets
Excessively minified installation scripts
Files that behave differently from their extensions
Multi-stage downloads

Analysis should examine raw package contents rather than relying only on what appears in a code editor.

Where to Enforce Dependency Controls

A dependency firewall is most effective when applied consistently across the software-development lifecycle.

Developer Workstations

Local enforcement protects developers from malicious packages installed through terminal commands, development tools, IDE extensions, and automated coding assistants.

Controls should be difficult to bypass accidentally but should provide a documented exception process.

CI/CD Pipelines

Build systems often possess valuable credentials and broad access to source repositories, artifact registries, cloud platforms, and production deployment systems.

Dependency checks should run before installation scripts execute. Failed checks should stop the build rather than merely generate an informational alert.

Containers and Build Images

Dependencies may be introduced while creating container images or development environments. Organizations should evaluate packages during image construction and preserve evidence of the versions and sources that were approved.

AI Coding Environments

AI agents should operate under the same dependency policies as human developers.

An organization should not assume that an agent-selected package is safe simply because the recommendation was generated by a capable model. Package installation should remain subject to validation, least privilege, logging, and approval requirements.

Operational Considerations

A dependency firewall should support security without making routine development impractical.

Important capabilities include:

Support for the organization’s package managers and registries
Coverage of direct and transitive dependencies
Centralized policy management
Clear explanations for blocked packages
Temporary and permanent exception workflows
Audit logs
Integration with CI/CD and endpoint-management systems
Package-source and provenance verification
Configurable minimum-age policies
Offline or private-registry support
Monitoring for bypass attempts

Organizations should also decide whether controls will block, warn, quarantine, or require approval based on risk.

For example, known malware may be blocked automatically, while a newly published package from an established maintainer might require additional review.

Dependency Firewalls Are One Layer of Supply-Chain Security

A dependency firewall is not a replacement for software composition analysis, lockfiles, software bills of materials, code review, vulnerability management, endpoint protection, or secure build practices.

It addresses a particular gap: the period immediately before a package is installed and potentially allowed to execute code.

A broader software supply-chain program should also include:

Version pinning
Reproducible builds
Registry allowlists
Package signing and provenance verification
Protected maintainer accounts
Multi-factor authentication
Short-lived publishing tokens
Dependency inventory and ownership
Continuous vulnerability monitoring
Removal of unused dependencies
Isolation of build systems
Least-privilege credentials
Incident-response procedures for compromised packages

Frequently Asked Questions

How can organizations stop malicious packages from being installed?

Apply an install-time control that evaluates every requested package and its transitive dependencies before code execution begins. High-confidence malicious packages should be blocked automatically, with the decision recorded for investigation.

How can teams reduce dependency-confusion risk?

Use scoped names for internal packages, configure private registries carefully, reserve important names on public registries, verify package sources, and prevent package managers from resolving internal dependencies from unexpected locations.

How can teams protect against typosquatting?

Use package-name similarity analysis, approved-package policies, lockfiles, registry controls, and install-time inspection. Developers should also verify package names through authoritative project documentation rather than copying commands from untrusted sources.

How can organizations prevent AI agents from installing malicious packages?

Run AI agents with limited permissions and subject their installation requests to the same controls used for human developers. Log every package request, validate package existence and provenance, inspect transitive dependencies, and require approval for suspicious or newly published packages.

How should a dependency firewall be rolled out?

Begin with monitoring to understand normal package activity and identify compatibility issues. Move high-confidence detections into blocking mode, establish an exception process, and then extend enforcement across workstations, build pipelines, containers, and AI-assisted development environments.

Conclusion

Open source package installation has become an important execution boundary.

Developers, CI/CD systems, and AI agents routinely retrieve code written and maintained outside the organization. That code may execute immediately and inherit access to sensitive development resources.

A dependency firewall places a security decision at the moment it is most useful: before the package is installed. As supply-chain attacks become faster and more automated, install-time inspection is likely to become a standard component of secure software development.

Learn More

Original blog post here.

About The Author

Nicholas Thomson is a Content Marketing Writer at Aikido Security. Prior to this, he worked as a technical writer at Datadog and Edge Delta. Before entering tech, he worked as an editor at Penguin Random House.

Related articles