Most enterprise builds don't pull packages straight from npm, PyPI, or Docker Hub. They pull from an internal artifact manager — usually JFrog Artifactory or Sonatype Nexus Repository — that proxies, caches, and stores both open source and proprietary components behind the firewall. That routing matters for security tooling, because a scanner that only reads public registries never sees what a build actually resolved. Snyk's private registry scanning addresses this by treating Artifactory and Nexus as connectable registry sources rather than afterthoughts, using the same Docker Registry HTTP API v2 interface both platforms expose for container images, plus package-manager-level resolution for language dependencies proxied through them. This piece walks through the mechanics: how Snyk authenticates against these registries, what it actually retrieves and parses, how vulnerability matching works once packages stop coming from a public source, and where the coverage boundaries sit. None of it requires exposing the registry to the public internet.
What counts as "private registry scanning" in Snyk's setup?
It means connecting Snyk Container's registry integrations directly to an organization's Artifactory or Nexus instance so images stored there get imported and tested the same way images from Docker Hub or Amazon ECR would be. Both JFrog Artifactory and Sonatype Nexus Repository implement the Docker Registry HTTP API v2 specification for their Docker-format repositories — the same spec Docker Hub, ECR, and GCR use. That standardization is what makes third-party scanning possible at all: any client that speaks the v2 API (docker pull, crane, or a scanner like Snyk) can list repositories, list tags, and fetch manifests from Artifactory or Nexus exactly as it would from a public registry, just against a different base URL. Snyk's registry integrations are configured per organization under Integrations settings, where an admin supplies the registry type, base URL, and credentials, then selects which repositories to bring into a Snyk project group for ongoing testing.
How does Snyk authenticate against Artifactory or Nexus without broad access?
It authenticates with scoped credentials the customer generates and enters once, not with a blanket admin login. For Artifactory, that's typically a service-account username paired with an API key or identity token; for Nexus Repository, it's a username and password (or a token where Nexus Pro/OSS configuration supports one) tied to a role limited to read access on the relevant repositories. Snyk stores these credentials encrypted and uses them solely to call the registry's API endpoints — catalog and tag listing, manifest retrieval — rather than to perform writes or administrative actions. Because the credential is scoped to specific repositories rather than the whole instance, a compromise of the Snyk-side integration doesn't automatically expose the rest of Artifactory or Nexus.
What does Snyk actually pull once it's connected?
It pulls image manifests and config blobs, not necessarily every layer in full. When Snyk's registry integration is set to import from a repository, it calls the standard v2 endpoints — /v2/_catalog to enumerate repositories, /v2/<name>/tags/list to enumerate tags, and /v2/<name>/manifests/<tag> to retrieve the manifest for a given image. From the manifest and its associated config JSON, Snyk can identify the base image, the layer history, and — by inspecting the layers needed to build a package inventory — the OS packages installed via the image's package manager database (dpkg, rpm, or apk), plus any application dependency files baked into the image. This is the same mechanical process Snyk Container uses against Docker Hub or a cloud registry; Artifactory and Nexus just sit at a different URL with different credentials in front of that same API surface.
How does vulnerability matching work once a package isn't coming from a public registry?
It works the same way regardless of where the package physically lives, because Snyk's vulnerability database matches on package identity — name, version, and ecosystem — not on hosting location. Once Snyk has built a package inventory from a scanned image or a resolved dependency tree, it checks each entry against its vulnerability intelligence the same way it would for a package pulled from npmjs.org or Docker Hub directly. This is an important distinction: Artifactory and Nexus are transport and storage layers, not sources of vulnerability data themselves. If a package is a mirrored copy of a public open source component — say, a specific version of lodash cached in an Artifactory npm remote repository — Snyk matches it against the public advisory data for that exact name and version regardless of which registry served it to the build.
How does Snyk reach a registry that isn't exposed to the internet?
It uses Snyk Broker, a relay component customers deploy inside their own network, so Snyk's cloud backend never needs an inbound connection to the private registry. Many Artifactory and Nexus deployments are intentionally not internet-facing, sitting behind a corporate firewall or VPN. Rather than requiring an inbound hole punched through that firewall — which most security teams would reject outright — the Broker runs as a lightweight container inside the customer's environment and makes only outbound HTTPS connections to Snyk's servers. Requests from Snyk's cloud (for example, "fetch the manifest for tag 2.3.1 of this image") are relayed inward through that outbound tunnel, and the response is relayed back out, without the registry's credentials or network location ever needing to be reachable from outside. This same Broker pattern is what Snyk uses for private, self-hosted source control systems like GitHub Enterprise Server or Bitbucket Server, so registry scanning for Artifactory and Nexus fits into infrastructure many Snyk customers already run for other integrations.
Where does registry-based scanning stop and manifest-based scanning start?
It stops at the container image boundary — Snyk's direct Artifactory/Nexus registry integrations are built around Docker/OCI-format repositories, while open source language dependencies proxied through those same platforms (an npm virtual repository, a Maven proxy repository, a PyPI group repository) are typically covered through Snyk Open Source's manifest- and lockfile-based scanning instead. Artifactory supports well over two dozen package formats — Maven, npm, PyPI, NuGet, Go, Conan, Helm, Debian, and more — and Nexus Repository covers a similarly broad set including Maven, npm, PyPI, NuGet, Docker, Go, and RubyGems. Snyk doesn't need to call into every one of those repository formats' APIs to test language dependencies, because the project's own package manager (npm, Maven, pip, NuGet) is usually already configured — via .npmrc, settings.xml, or pip.conf — to resolve packages through the Artifactory or Nexus proxy URL. Snyk's CLI and CI integrations invoke that same resolution locally against the manifest or lockfile, so the dependency tree it tests reflects exactly what the build would have pulled, whether the final package originated on the public internet or as an internally published, proprietary artifact. The tradeoff is that purely internal, non-public packages with no corresponding public advisory won't generate CVE matches — Snyk can still map their position in the dependency graph and apply license policy, but it has no vulnerability data to attach to a component that was never published anywhere Snyk's intelligence pipeline tracks.
How Safeguard Helps
Snyk's approach illustrates a broader point that applies to any organization running Artifactory or Nexus as its package chokepoint: the registry is a control plane, and visibility into what actually flows through it is only as good as the tooling watching that plane. Safeguard focuses on giving security and platform teams that same visibility without assuming every package originated from a scanner-friendly public source. That means tracking what gets published into internal repositories, verifying package provenance and integrity for both proxied open source components and internally authored artifacts, and flagging when a build resolves a dependency that doesn't match an expected, previously verified version. For organizations already relying on Artifactory or Nexus as the single path packages take into production, Safeguard's supply chain monitoring is built to sit alongside that infrastructure — surfacing risk in the packages a scanner can identify by name and version, and in the parts of the software supply chain, like build provenance and artifact tampering, that identity-based vulnerability matching alone was never designed to catch.