Artifact Firewall: Enforcing npm security across distributed CI/CD pipelines

How to enforce package version governance and pipeline security across distributed teams, before compromised packages spread

To block risky npm packages before they reach a build, enforce policy at the point where dependencies are downloaded, not in each pipeline’s configuration. Varnish Artifact Firewall sits in the npm request path and checks every package version against your rules before it’s served. It can quarantine newly published versions for a set number of days, block versions matching known-vulnerability rules, and stop compromised releases from being picked up as “latest”. The same rules then apply to every team, pipeline and developer machine at once.

Software delivery has changed in a fundamental way over the last few years. Builds run continuously, teams are distributed across regions, and dependency resolution is fully automated. What used to be a controlled, centralized process is now a high-velocity system where thousands of dependency requests happen every minute across pipelines, developer machines, and runtime environments.

That shift has created a new kind of exposure. When something goes wrong upstream, it doesn’t spread slowly, it propagates instantly.

The recent Axios supply chain attack is a good example. A compromised version of a widely used npm package was published, and for a short window, anyone running a standard install pulled a backdoored dependency that deployed a cross-platform remote access trojan.

As Palo Alto’s Unit 42 detailed, the malicious versions introduced a hidden dependency that executed during installation, quietly compromising developer environments and CI systems across macOS, Linux, and Windows.

What made this effective wasn’t sophistication. It was aligned with how modern systems operate. Pipelines pulled the latest version automatically. Developers trusted the ecosystem. Everything moved fast. And that speed worked against them.

The gap between policy and enforcement

The response guidance coming out of incidents like this is consistent. Teams are told to pin dependencies, avoid automatically pulling the latest versions, and harden CI/CD pipelines by restricting what can be installed and reducing implicit trust in upstream sources.

These are the right recommendations, but they are difficult to enforce at scale. In large organizations, you’re dealing with various teams, multiple pipelines, and constantly evolving configurations. Some teams pin versions strictly. Others don’t. Some pipelines are tightly controlled. Others are not.

Over time, policy becomes inconsistent. And inconsistency is exactly what these attacks exploit.

The Axios incident didn’t succeed because teams lacked awareness. It succeeded because there was no control point enforcing those practices at the moment dependencies were requested across all environments.

Where Artifact Firewall fits

Artifact Firewall is designed for that environment. It sits in the artifact request path and evaluates every dependency before it is allowed into your environment, regardless of where the request originates.

This allows organizations to enforce best practices consistently, without relying on every team and pipeline to behave perfectly:

• Version pinning becomes enforceable, ensuring builds resolve only to approved versions

• Newly published packages can be delayed, reducing exposure during the highest-risk window

• Vulnerability rulesets are applied automatically, restricting access once each ruleset update includes the issue

• CI/CD pipelines can be governed centrally, without modifying each one individually

• New rules can be tested in report-only mode, which logs what would be blocked without blocking anything

See the Artifact Firewall documentation for the full set of controls, or follow the tutorial to block a package version downloaded through JFrog Artifactory. It shows what developers and CI runners see when a version is blocked, without changing anything in Artifactory.

Instead of trying to control behavior everywhere, you introduce a control point where it matters.

Changing the outcome at scale

At a smaller scale, these incidents are manageable, but at a larger scale, they become systemic.

With Artifact Firewall in place, an incident like Axios plays out differently. Automatic upgrades to compromised versions are blocked. Delay policies prevent immediate exposure. Vulnerability-based rules restrict access as soon as the rulesets are updated.

Most importantly, these controls apply across all teams and environments at once.

The result isn’t just faster response, it’s reduced blast radius.

Why this matters now

Supply chain attacks are increasing in both frequency and impact, and they are specifically targeting the speed and automation that modern development depends on.

The challenge is no longer understanding what should be done. It’s enforcing it consistently at the scale and velocity of today’s systems.

Artifact Firewall was built for that.

Are software supply chain attacks a concern for your organization? Request a trial license and give Varnish Artifact Firewall a try.

Varnish Artifact Firewall runs alongside Varnish Virtual Registry (formerly Varnish Orca), which accelerates, controls and secures access to the artifacts in your software supply chain.