Introducing Package Traffic Controller: Software Supply Chain Security at the Network Edge

Imagine this: your security team has done everything right. All development teams are using a centrally managed artifact repository with scanning in place. Your engineering organization has clear policies about where packages can come from. You feel good about your software supply chain posture.

Then an incident review surfaces something nobody planned for: a compromised npm package entered your environment.

Not through a CI/CD pipeline or a developer’s misconfigured laptop, but a marketing manager’s Claude agent that autonomously fetched a dependency in the background. Your artifact system of record never saw or vetted it. There’s no audit trail and no quick way to determine how many other downloads like it occurred last month.

Unfortunately, this scenario isn’t a hypothetical. It’s the threat reality most organizations aren’t ready for.

The Attack Surface Just Got a Lot Bigger and Harder to Enforce

The software supply chain has become the primary target for bad actors — Shai Halud, Trivy, LiteLLM, Axios are just recent examples from a list that keeps growing. For years, security teams understood this as a developer problem. That thinking is now dangerously outdated.

AI has given everyone superpowers to build what they need, but that means a whole new population of users — human and machine — downloading open source libraries. And developers’ and agents in particular don’t always respect environment configurations that route dependencies through a system like Artifactory.

Here’s the core problem: if anyone or anything can reach public registries directly, your artifact system of record is structurally incomplete and your company is exposed.

The consequences are twofold: you can’t proactively vet what enters your environment, and when an attack surfaces, you have no fast path to answer “are we impacted?”  Every security control only governs what it can see. If any user can bypass your artifact system of record, your posture has a hole in it.

Why Naive Blocking Isn’t the Answer

The instinctive response to this problem is to block direct access to public registry — or at the very least known malicious packages. And while that’s the right goal, blocking alone is a poor implementation of it.

Blocking breaks developer workflows, causes CI/CD pipelines to fail, and generates a steady stream of support tickets, and incentivizes workarounds. Developers under pressure will find another path, and shadow downloads don’t disappear, they just become harder to see.

What’s needed is a way to enforce your security policies automatically and universally, across every user and every agent, without interrupting anyone’s flow.

Eliminate Shadow Package Downloads; Keep Developer Speed

Package Traffic Controller closes exactly this gap — and it’s included with every JFrog Curation subscription.

It operates at the network layer, integrating with your existing SASE infrastructure (initially Zscaler Zia, with additional SASE integrations coming soon), to intercept all outbound package download requests before they reach a public registry. Rather than blocking them, it transparently reroutes each request through Artifactory, where Curation inspects every package against your security, license, and quality policies. Compliant packages are delivered. Non-compliant or malicious ones are stopped before it enters your environment and a safe, approved version is automatically served instead.

From the user’s perspective, nothing changes: same command, same result, same speed. What changes is that every download is now intercepted at the network edge, routed through your trusted checkpoint, inspected by Curation, and logged in Artifactory as a permanent, auditable record.

That’s what sets Package Traffic Controller apart. Others approach this problem with a hard block — they identify a “bad” package and return an error, or pass “safe” packages through without logging them, leaving your system of record incomplete should that “safe” package later turn out to be an issue. Package Traffic Controller reroutes rather than disrupts, giving developers what they need while giving security teams the visibility and guarantee they require.

And because it operates at the network layer, it covers everyone: a developer at a terminal, an autonomous AI coding agent, a marketer unknowingly fetching a dependency via their AI tool. If the traffic hits the network, it’s covered. For the first time, your supply chain controls apply to your entire organization, not just the engineering environments your team explicitly configured.

What Changes for Your Team

For security and DevSecOps teams: Curation policies now fire on 100% of traffic. No more blind spots, no more shadow downloads. When the next supply chain attack surfaces (and there will be a next one), you can answer “were we impacted?” from an audit log, not a days-long forensic investigation.

For platform and DevOps teams: zero developer-side configuration required. No updated `.npmrc`, no new `pip.conf`, no Slack message asking 3,000 developers to change their setup. Deploy at the network layer and every package request is transparently served through Artifactory from that point forward. NOTE: configuring dev environments to resolve from Artifactory remains best practice — think of Package Traffic Controller as a safety net ensuring it’s actually happening.

For security leadership: a defensible, provable answer to the “how do you know nothing malicious entered your environment?” — one that covers your full organizational footprint, not just the engineering perimeter.

Closing the Last Open Door

The software supply chain is no longer an engineering concern. It’s an organizational one. Every team using AI tools is now a potential entry point for a supply chain attack. Most organizations have no controls in place for that exposure, not because they haven’t invested in security, but because the tools and the threat model changed faster than the perimeter did.

Package Traffic Controller closes that gap. Not by simply blocking, not by asking anyone to change how they work, but by making JFrog the invisible, mandatory checkpoint for every artifact that enters your organization, regardless of who or what requested it.

The last open door just got a lock.

JFrog Package Traffic Controller is available with JFrog Curation. Learn more or speak with a solutions engineer.