DEPENDENCY CONTROL Do you know what your pipelines pulled this morning?
Every pipeline run pulls the latest versions of every dependency, from every public registry, without review. Thousands of requests per day, across every language ecosystem your engineers use.
Most of those packages are fine. Some are versions nobody vetted or approved. Some introduce breaking changes that surface weeks later. Some are published under names close enough to internal packages that automated runners can't tell the difference. None of them were reviewed before they ran on your build infrastructure.
Why unmanaged dependency ingestion is a growing problem
Three trends are widening the gap between what pipelines pull and what organizations have approved:
Package ecosystems are growing faster than governance frameworks
npm, PyPI, Maven, and NuGet each publish thousands of new package versions daily. The volume of third-party code entering enterprise build pipelines has outpaced the capacity of manual review processes.
Dependency confusion attacks exploit namespace gaps
Attackers publish public packages under names that match internal corporate naming conventions. Automated build runners that check public registries before private ones pull the public package without any indication that something is wrong.
Unapproved dependencies accumulate silently
Packages and versions nobody approved enter production environments silently. The exposure accumulates over months or years before an audit surfaces it, at which point remediation is a significant engineering effort.
What uncontrolled dependency ingestion costs your teams
Security architect
Scanning tools that run after packages have already entered the network generate alerts rather than blocks. By the time a policy violation is flagged, the package has already been pulled onto build nodes, potentially executed post-install scripts, and been incorporated into a build artifact.
Platform lead
Client-side configuration files can be modified or commented out by any developer. Governance policies that depend on local configurations being maintained correctly are policies with a permanent bypass mechanism built in.
Compliance auditor
Proving to an external auditor which packages entered the production environment, when, under what policy, and whether any unapproved packages were ingested requires a centralized, real-time audit log at the ingestion point.
Why default validation layers don't solve this
Challenge 1
Local configurations are easily bypassed
Desktop-level download restrictions inside local configuration scripts (such as .npmrc, pip.conf, or cargo/config.toml) are easily modified or commented out by developers, bypassing corporate governance.
Challenge 2
Late-stage scanning is purely reactive
Scanning platforms generate post-event alert tickets rather than executing live, path-based network blocking.
Challenge 3
Buying curation means buying more platform
Platform-native curation only enforces inside its own repository manager. Every other registry in your estate stays unprotected. And the license stacks: per-user fees that count anyone who pulls a package, on top of platform subscriptions, consumption metering, and support tiers.
Challenge 4
"Blocked" doesn't always mean blocked
Even platform-native gates have documented holes: a denied package can still resolve through the next repository in the search order, some traffic paths skip policy checks entirely, and hardcoded artifact URLs slip past manifest-level controls. Enforcement that depends on careful configuration is enforcement that leaks.
How Varnish Artifact Firewall governs dependency ingestion
Varnish Artifact Firewall is an inline policy proxy that sits between your build runners and external registries, evaluating every dependency request against organizational policy the moment it is made.
It manages policies as declarative Git-versioned YAML rulesets and integrates natively with Varnish Virtual Registry to combine governance with artifact caching.
01
Inline manifest rewriting |
The policy engine intercepts metadata queries and evaluates each package request against organizational policy before responding. Hidden versions are pruned from manifests in-flight, so unpinned installs steer to the nearest compliant version automatically. Denied packages return a 403 carrying your policy reason, so developers see exactly why and choose the safe version themselves. |
02
Namespace and scope isolation |
Pattern matching isolates corporate namespace prefixes. Any attempt to fetch a package matching a protected internal scope from a public registry is immediately blocked, so no public package can masquerade as an internal dependency, regardless of how closely the name matches. Dependency confusion attacks lose their public path in. |
03
Quarantine windows for new package versions |
Newly published package versions are held for a quarantine window you configure before pipelines resolve them. Engineering teams and the broader open-source community have time to evaluate new releases before they enter your builds, closing the window in which brand-new malicious versions do the most damage. |
04
Policy-as-code across every build environment |
Package blocklists, version constraints, and quarantine policies are managed as declarative YAML files, versioned in Git, and distributed uniformly across every build environment. Updates sync on a defined interval and reload without interrupting service. Every package decision (allowed, hidden, quarantined, or denied) is logged with a complete audit trail for compliance review. Run report mode first to see exactly what your policy would block, before it blocks anything. |
Varnish Artifact Firewall
Stop malicious dependencies before they reach your builds.
Artifact Firewall is an inline policy proxy that secures your software supply chain by governing every dependency request. Sitting between your build runners and external registries, it evaluates requests across npm, PyPI, Maven, and NuGet the moment a package is requested.
By managing policies as declarative, Git-versioned YAML rulesets, security teams can easily extend standard OSV baselines with custom internal compliance rules. The engine can be deployed as a standalone security gateway or integrated natively with Varnish Virtual Registry to combine in-path policy enforcement with high-speed artifact caching.
Resources and media
-
Enforcing npm security across distributed CI/CD pipelines
How to enforce package version governance and pipeline security across distributed teams, before compromised packages spread
-
How to protect your CI/CD pipelines
Most organizations already have some combination of repository controls, scanners, and policy lists in place. Those are important, but they tend to operate either before ingestion or after the fact.
-
Accelerating secure CI/CD pipelines in highly regulated industries
A strategy guide for securing and accelerating software delivery in financial services, healthcare, critical infrastructure.
Read more →
Next steps
Talk to our team to learn more about Varnish Artifact Firewall.
