When a security team connects Snyk Container to a private registry, nothing scans until an authentication handshake succeeds first. Snyk doesn't crawl your infrastructure looking for images — it needs to be handed a credential (an IAM role ARN, a service principal secret, a service account JSON key, or an access token) scoped narrowly enough to list repositories and pull layers, but nothing more. That handshake looks different for every registry, because Amazon ECR, Azure Container Registry (ACR), Google Container Registry/Artifact Registry (GCR), and JFrog Artifactory each expose their own identity model on top of the same underlying Docker Registry HTTP API v2. Understanding those four flows matters for anyone deciding what to grant a third-party scanner, because the credential you paste into an integration form is, functionally, a standing pull permission into your build artifacts. Here's how each one actually works.
How does Snyk Container get into a private registry in the first place?
It uses the standard Docker Registry HTTP API v2 token-exchange flow, the same protocol docker pull uses under the hood. When you add a registry integration in the Snyk UI or via the Registry Integrations API, Snyk stores the credential you provide, then on each scan cycle exchanges it for a short-lived bearer token against the registry's /v2/token (or provider-equivalent) endpoint. That token authorizes GET requests against the manifest and blob endpoints (/v2/<repo>/manifests/<tag> and /v2/<repo>/blobs/<digest>), which is how Snyk retrieves the image manifest, config blob, and layer tarballs it needs to build a filesystem tree and run its dependency and OS-package detectors against. No registry-side agent or webhook is required for this base flow — Snyk's cloud service (or Snyk Broker, for registries that can't be reached from the public internet) initiates every pull.
How does authentication actually work for Amazon ECR?
Snyk authenticates to ECR using AWS IAM, not a static username and password, because ECR doesn't support basic auth for pulls. Per AWS's documented model, a client calls the ECR GetAuthorizationToken API, which returns a base64-encoded token valid for 12 hours that decodes to AWS:<temporary-password> and doubles as Docker Basic Auth credentials. To get to that call, Snyk needs either a long-lived IAM user's access key/secret key pair or, more commonly in production setups, a cross-account IAM role that Snyk's AWS account can assume via sts:AssumeRole, typically gated with an external ID to prevent confused-deputy attacks. The role needs, at minimum, ecr:GetAuthorizationToken, ecr:BatchGetImage, ecr:GetDownloadUrlForLayer, and ecr:DescribeRepositories/ecr:ListImages to enumerate and pull. Because the resulting token expires every 12 hours, Snyk re-authenticates on essentially every scan run rather than caching a long-lived secret.
What credentials does ACR require, and why do two different patterns exist?
Snyk supports two distinct paths into ACR because Azure itself offers two: an Azure AD service principal, or the registry's built-in admin account. The service principal path — the one Microsoft and Snyk both recommend for anything beyond a quick test — requires an App Registration's client ID, tenant ID, and client secret, with the AcrPull role assigned at the registry scope so the principal can only read images, not push or delete them. Snyk exchanges those three values for an Azure AD OAuth2 token, then trades that for an ACR-scoped refresh token via ACR's /oauth2/exchange endpoint before pulling manifests. The admin-account path is simpler to configure — just the registry's username and password, which Azure calls "admin credentials" and disables by default — but it grants full read/write to the whole registry, which is why it's generally treated as a fallback for non-production connections rather than the default.
How does GCR/Artifact Registry authentication differ from the AWS and Azure models?
It runs entirely on a Google Cloud service account JSON key rather than a role-assumption or app-registration flow. Snyk imports a service account key file containing a private key and client email, granted at minimum the roles/storage.objectViewer role for legacy GCR (which stores images as objects in a GCS bucket) or roles/artifactregistry.reader for the newer Artifact Registry. Under the hood, that key is used to mint a signed JWT, which Google's OAuth2 token endpoint exchanges for a short-lived bearer access token; that token is what actually authenticates the /v2/ manifest and blob pulls. This is a meaningfully different trust model from ECR or ACR: instead of a role Snyk assumes on demand, it's a static private key that Snyk holds and re-uses to mint fresh tokens indefinitely until the key is rotated or revoked on the Google Cloud IAM console.
How does the Artifactory integration work, since it's not a cloud-native registry?
Artifactory is authenticated with a straightforward username-plus-token (or username-plus-API-key, on older JFrog versions) pair scoped to a specific Docker repository, because unlike the three cloud registries, JFrog doesn't sit inside a broader cloud IAM system Snyk can hook into. Snyk's Artifactory integration talks to the same Docker Registry HTTP API v2 surface that Artifactory exposes on its Docker-type repositories, authenticating with HTTP Basic Auth on every token request rather than a multi-step OAuth exchange. For self-hosted Artifactory instances that aren't reachable from the public internet, Snyk routes the connection through the Snyk Broker, a lightweight relay that runs inside the customer's network and forwards authenticated requests outward, so the registry never needs an inbound firewall rule opened for Snyk's cloud service. This makes Artifactory the one integration among the four where network topology, not just credential type, materially changes how the connection is established.
How often does Snyk actually re-scan images once a registry is connected, and what triggers it?
Registry integrations are polled on a recurring schedule rather than scanned continuously in real time, with Snyk's documented default import/re-test cadence running roughly every few days per project unless a webhook or CI-based trigger fires a scan sooner. Each cycle repeats the full authenticate-list-pull sequence described above: re-derive or re-request a token, call the registry's catalog/tag-listing endpoint to see which images and tags exist, diff that against what Snyk has already imported, and pull manifests for anything new or changed. This polling model — rather than a persistent registry-side agent — is why the credential type and its expiry window matter operationally: an ECR role assumption or a GCR JWT exchange happens fresh on every cycle, while an Artifactory or ACR admin-password credential can sit unchanged for months unless someone rotates it manually.
How Safeguard Helps
The mechanics above point to a pattern worth internalizing regardless of which scanner you run: every registry integration is a standing credential with pull access to your build artifacts, and that credential's blast radius depends entirely on how narrowly it was scoped when someone set it up six months ago. Safeguard's software supply chain security platform is built around making that visible and auditable — surfacing which third-party tools and CI/CD integrations hold live credentials into your registries, flagging over-scoped IAM roles, service principals, or service account keys before they become the easiest path for an attacker to pull (or worse, tamper with) production images, and tracking artifact provenance so a signed, attested image can be distinguished from one that merely showed up in ECR or Artifactory. Whether you're running Snyk, another scanner, or several at once, Safeguard treats registry credential sprawl and integration hygiene as first-class supply chain risk, not an afterthought bolted onto vulnerability scanning.