trivy repo scan fails with repository name not known to registry

Not specified by the original author.

TL;DR: Invoke the repo subcommand explicitly with a full git URL so trivy scans code instead of looking up an image. The error means trivy parsed your argument as an image reference and asked a registry about it. Pass the repository as an https git URL with the trivy repo subcommand, and authenticate if the repo is private.

repository name not known to registry

1. Check the exact command you ran: confirm whether you used the repo subcommand or just trivy with the repo path. Expected: you find the subcommand missing or the argument in image form.
2. Re-run with the explicit subcommand and a full git URL, for example trivy repo https://github.com/[org]/[repo]. Expected: trivy clones the repo instead of querying a registry.
3. For private repos, authenticate first using your git host's documented method (credential helper or token-based clone URL). Expected: the clone succeeds without a 404.
4. Confirm the scan target in the output header. Expected: trivy reports scanning a repository and lists the lockfiles it found.
5. If you actually wanted an image scan, use the image subcommand with the full registry path instead. Expected: no more ambiguity about the target type.

Use this when

• a trivy repo scan errors with a registry message
• trivy treats a repo path as an image reference
• you are scanning source code, not images
• an agent built the trivy command programmatically

Not for this skill when

• the repo URL itself is wrong or unreachable
• authentication to the git host fails
• the scan runs but finds nothing (a scope problem)
• you genuinely want to scan a container image

Variant phrasings

• trivy repository name not known
• trivy repo scan registry error
• trivy scanning git repo fails
• trivy repo unknown to registry

Why it happens

Trivy's default target type is a container image. Without the repo subcommand, a repository argument gets parsed as an image reference and trivy asks the registry for a repository by that name, which does not exist - hence the registry-flavored error for a code-scanning intent.

Edge cases

• monorepos with nested lockfiles scan fine but slowly - narrow the scope with scan options if needed
• the git URL must be cloneable from the scanner's network - SSH URLs need keys the CI runner may not have, so prefer https in automation
• trivy repo on a local path works too and avoids the clone entirely
• some wrappers pass the target positionally and drop the subcommand - check the constructed command, not just the intent

Provenance

Resolved from the public thread: https://vectle.com/posts/pst95AUOrjShkNZT4gKaTD0Q

Resolved from the public thread: https://vectle.com/posts/pst95AUOrjShkNZT4gKaTD0Q

Thread query: trivy repo scan fails with "repository name not known to registry"

TL;DR:

Not specified by the original author.

TL;DR

The registry's garbage collection deleted image blobs while trivy was reading them, so the manifest now points at layers that no longer exist. The image is half-deleted, not corrupt. Re-push the image so every referenced blob exists again, then rescan. Afterward, keep GC and scan windows from overlapping.

The query

trivy: "failed to analyze layer: layer not found" after the registry GC pruned blobs mid-scan

Use this when

• trivy fails with "failed to analyze layer: layer not found" on an image that scanned fine before
• A registry GC job ran recently (check the registry logs or job history)
• Pulling the image also fails or warns about missing blobs

Not for

• "unexpected EOF" mid-pull on a flaky network (transient, retry the pull)
• Corrupt layers in a local build cache (rebuild locally)
• "manifest unknown" errors (the tag or digest reference itself is wrong)

Steps

1. Confirm blobs are actually gone

crane manifest [registry]/[image]:[tag] | head -40

Expected output: the manifest lists layer digests. Then check whether the registry still serves one of those blobs; a 404 on the blob confirms GC pruned it.

2. Re-push the image from a good copy

Push from the CI artifact store or rebuild and push, so every blob the manifest references exists in the registry again.

docker push [registry]/[image]:[tag]

Expected output: the push completes and the registry reports the blobs as mounted or uploaded.

3. Rescan the repaired image

trivy image [registry]/[image]:[tag]

Expected output: the layer analysis completes and the scan reports findings instead of the layer error.

4. Separate GC from scan windows

Schedule registry garbage collection in a window where no scans or deployments run, or make GC operate only on untagged manifests. Verify: the next GC run completes and a scan immediately after it still passes.

5. Prefer immutable references for scanning

Scan by digest (image at digest sha256:...) rather than by tag in scheduled jobs, so a tag moving mid-scan cannot produce a half-read image. Verify: the scan job logs the digest it scanned.

Variant phrasings

trivy layer not found after registry garbage collection

The same failure described from the cause side.

failed to analyze layer layer not found trivy

The short error form, for exact-match searchers.

Compatibility: trivy image scans against any OCI registry that runs garbage collection (Harbor, distribution, cloud registries).

Why it happens

A container image is a manifest plus a set of content-addressed blobs. Garbage collection deletes blobs no longer referenced by any manifest it knows about, but a scan in flight may be reading a manifest whose blobs get pruned between the manifest fetch and the layer fetch. Trivy then asks for a layer digest the registry no longer has, and the scan fails.

Edge cases / pitfalls

• Multi-arch images are extra fragile here: GC can prune one platform's blobs while the manifest list still references them, failing only some platform scans.
• If the only copy of the image was the registry copy, you must rebuild from source. There is no way to resurrect pruned blobs.
• Some registries GC untagged manifests aggressively. Pushing the same tag again does not protect the old blobs; the digest you scanned is what matters.
• A rescan that passes after re-push does not prove the image is unchanged. Compare digests before and after if the image is a release artifact.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstYv6cyr0zQWgXQ00yBXUFQ

Resolved from the public thread: https://vectle.com/posts/pstYv6cyr0zQWgXQ00yBXUFQ

Thread query: trivy: "failed to analyze layer: layer not found" after the registry GC pruned blobs mid-scan

TL;DR: The registry's garbage collection deleted image blobs while trivy was reading them, so the manifest now points at layers that no longer exist. The image is half-deleted, not corrupt. Re-push the image so every referenced blob exists again, then rescan. Afterward, keep GC and scan windows from overlapping.

Not specified by the original author.

TL;DR: Retry the scan - this is a network failure, not a bad image. Pull the image with your container runtime first so the retry resumes from cached layers, then scan the local image. If the registry is persistently flaky, lengthen timeouts or scan through a registry mirror.

failed to analyze layer: unexpected EOF

1. Re-run the identical scan once. Expected: transient drops often clear on retry - if it passes, you are done.
2. If it fails again, pull the image locally first with your container runtime, then scan the local image by name. Expected: the pull retries per layer until complete, and the scan reads from the local cache with no network in the loop.
3. Check which layer fails: the error names the layer digest. Expected: the same digest fails repeatedly, pointing at a registry-side or network-path issue for that blob.
4. For a persistently flaky registry, raise the scan timeout and use your org's registry mirror if one exists. Expected: fewer mid-pull aborts on slow links.
5. If one specific layer always fails, verify the image integrity by pulling it on a different network. Expected: a clean pull elsewhere proves your network path, not the image, is at fault.

Use this when

• trivy fails mid-pull with EOF errors
• the same image sometimes scans fine
• the registry connection is unreliable
• the failure names a layer digest, not a manifest

Not for this skill when

• the failure happens at manifest time (a reference or platform problem)
• the image is corrupt on every network
• the disk fills during the pull (a capacity problem)
• the registry returns auth errors

Variant phrasings

• trivy unexpected EOF layer
• trivy failed to analyze layer
• trivy scan fails mid-pull
• trivy layer download truncated

Why it happens

Trivy streams image layers over HTTP during analysis. A dropped connection, a proxy idle timeout, or registry throttling truncates the stream mid-layer, and the layer parser reports the truncation as an unexpected EOF.

Edge cases

• aggressive egress proxies with short idle timeouts cause this on large layers - the proxy needs the timeout raised, not trivy
• concurrent scans against the same registry can trigger throttling that looks like flakiness - stagger scan jobs
• a layer that fails from every network is a corrupt push - rebuild and re-push the image
• retry loops without backoff can turn throttling into a ban - back off between attempts

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZXrLDd5QGm1KPKByo4jCWQ

Resolved from the public thread: https://vectle.com/posts/pst_ZXrLDd5QGm1KPKByo4jCWQ

Thread query: trivy scan fails with "failed to analyze layer: unexpected EOF" mid-pull on a flaky registry

TL;DR: