Enterprises rarely expose their container registries to the internet. JFrog Artifactory, Harbor, and Nexus instances typically sit behind VPNs, firewalls, or private VPCs specifically so that image layers, base image lineage, and internal package names never leave the corporate network. That isolation is good security hygiene, but it creates a real problem for SaaS-based vulnerability scanners: if Snyk's cloud service can't reach the registry, it can't list tags, pull manifests, or scan layers. Snyk's answer is the Broker Container Registry Agent, a pair of self-hosted components that let the SaaS platform trigger scans of a registry it can never directly touch. Understanding how that hand-off actually works — what crosses the network boundary, what stays behind it, and where the approach has hard limits — matters for any team deciding whether a brokered scanning model fits their compliance requirements. Below is a breakdown of the publicly documented mechanics, not a product comparison.
What Problem Is the Container Registry Agent Actually Solving?
The core problem is that Snyk Container's SaaS scanning engine has no route into a network-isolated registry, so Snyk built a way to run the network-reaching part of the job locally instead. Most Snyk Container integrations assume the registry is reachable from Snyk's cloud (Docker Hub, a public ECR endpoint, etc.). Self-hosted Artifactory or Nexus instances behind a corporate firewall break that assumption entirely. Rather than asking customers to open inbound firewall rules to Snyk's IP ranges — a nonstarter for most security teams — Snyk inverts the connection: the customer runs two lightweight services inside their own network that pull images, scan them locally, and push only the results back out through an outbound-only brokered channel. This is the same broker pattern Snyk already uses for on-prem GitHub Enterprise, Bitbucket Server, and Jira integrations, extended to container registries specifically because registries hold raw image layers rather than just API responses.
How Does the Broker's Three-Tier Architecture Keep Credentials Off Snyk's Servers?
It works through a three-part split: a Broker Server in Snyk's SaaS backend, a Broker Client inside the customer's network, and a separate Container Registry Agent also running inside that network. The Broker Client holds the connection configuration — registry hostname, credentials, registry type — and hands those details to the Agent rather than to Snyk. The Agent is the only component that actually authenticates to the registry and touches image layers; it uses the connection details to list repositories, pull images, and run the scan locally. Once a scan finishes, the Agent sends the results back to the Broker Client via a callback, and the Broker Client relays only that scan output — vulnerability findings and image metadata — through the brokered connection to Snyk. Access tokens, registry passwords, and IAM credentials are documented as never being transmitted to Snyk's servers; they're read and used entirely inside the customer's infrastructure. Snyk describes this explicitly as letting customers "keep sensitive data such as your access tokens inside your private network."
Which Self-Hosted Registries Does the Agent Support, and Where Does It Fall Short?
Snyk's documentation lists support for around a dozen registry types, including JFrog Artifactory, Sonatype Nexus, Harbor, Docker Hub, Amazon ECR, Google Container Registry, Google Artifact Registry, Azure Container Registry, Red Hat Quay, GitHub Container Registry, GitLab Container Registry, and DigitalOcean Container Registry. Coverage isn't uniform across all of them, though. Snyk's own docs flag that GitHub Container Registry and GitLab Container Registry "do not follow Docker v2 API" fully — specifically, they lack the /v2/_catalog endpoint that the Agent would otherwise use to enumerate repositories, which changes how discovery has to be configured for those two. Amazon ECR needs its own setup path entirely: the Agent's IAM role has to assume a separate Snyk-side ECR service role using CR_ROLE_ARN and CR_REGION (with an optional CR_EXTERNAL_ID for cross-account trust conditions), rather than authenticating with a static username and password like Artifactory or Nexus do. Google-based registries take a _json_key service account credential as the "username" field. The practical takeaway is that "supported" doesn't mean "identically configured" — each registry type has its own auth quirks documented separately.
What Actually Happens During a Registry Scan?
A scan runs as a synchronous pull followed by an asynchronous result push, all initiated from inside the customer's network rather than from Snyk. When Snyk's platform wants fresh results, the Broker Server request travels down to the Broker Client, which forwards the connection details to the Agent. The Agent then makes direct, synchronous calls to the registry to list images and pull the relevant layers, scans them locally against Snyk's vulnerability database, and only afterward sends the scan output back asynchronously through the Broker Client's callback URL. Because pulling and scanning happen inside the customer's network boundary, raw image layers never traverse outbound to Snyk — only the resulting SCA/vulnerability data does. Teams can validate that this full chain is actually working end-to-end using a /systemcheck endpoint the Agent exposes, which checks connectivity across Broker Server, Broker Client, Agent, and the registry itself in one request, which matters because a broken hop anywhere in that chain silently produces stale or missing scan data rather than an obvious error.
How Much Infrastructure Does Running the Agent Actually Require?
Not much by enterprise standards, but the sizing is specific and worth planning around before rollout. Snyk's documented baseline is 1 CPU and 256 MB of RAM for the Broker Client, and 1 vCPU, 2 GB of memory, and 5 GB of storage for the Container Registry Agent itself when MAX_ACTIVE_OPERATIONS is left at its default of 1. At that concurrency setting, Snyk states the Agent can scan roughly 160 images averaging about 350 MB each in a single run before storage or memory pressure becomes a factor — a number that matters directly for teams with registries holding thousands of tags, since it implies either raising concurrency (and provisioning proportionally more RAM/storage) or scheduling scans in batches. The Agent also enforces a maximum image size via SNYK_MAX_IMAGE_SIZE_IN_BYTES, defaulting to 2,147,483,648 bytes (2 GB) — images larger than that are skipped unless the variable is raised. Network-wise, the Agent expects an HTTPS path to the registry by default; reaching a registry over plain HTTP requires putting a reverse proxy in front of it, since the Agent doesn't scan over unencrypted connections out of the box. Debugging relies on LOG_LEVEL, with NODE_DEBUG=needle and DEBUG=* available for deeper HTTP-library tracing — Snyk's own docs warn against leaving those broader debug flags on in production because they can leak sensitive request data into logs. It's also worth noting this capability sits behind Snyk's Enterprise plan tier, not the standard product.
How Safeguard Helps
The Broker Container Registry Agent model is a reasonable solution to a real constraint — SaaS scanners can't reach isolated registries — but it also illustrates a pattern worth watching for regardless of which scanner produces the data: vulnerability results for private registries now depend on a chain of self-hosted components (Broker Client, Agent, network routing, IAM role assumptions) that live entirely outside the vendor's SaaS uptime and monitoring. If the Agent falls behind on scans, silently skips oversized images past the 2 GB default, or drops a registry that doesn't expose /v2/_catalog, that gap in coverage can be invisible until an incident forces the question.
Safeguard's platform is built around treating exactly that kind of gap as a first-class signal rather than an assumption. Instead of trusting that a brokered agent is running, correctly sized, and current, Safeguard continuously correlates what a scanner reports against what's actually deployed — flagging registries, image tags, or repositories that stopped producing fresh findings, and surfacing configuration drift like stale broker connections or authentication failures before they become a blind spot in an audit. For teams running self-hosted Artifactory, Nexus, or Harbor instances alongside tools like Snyk, Safeguard adds an independent layer of software supply chain visibility — provenance tracking, SBOM correlation, and policy enforcement across every registry and CI/CD pipeline in the environment — so that scan coverage for private infrastructure isn't a single point of trust in one broker's health. That combination of continuous verification and cross-tool correlation is what turns "we deployed a scanning agent" into "we can prove our registries are actually covered."