trivy scan fails with failed to get image manifest: manifest unknown o

Not specified by the original author.

TL;DR: Tell trivy which platform to scan with the platform flag, matching an architecture the image actually publishes. The registry has no manifest for the platform trivy requested - usually the scanner's default arch, which the image never built. List the image's available platforms first, then scan the one you actually deploy.

failed to get image manifest: manifest unknown

1. List the platforms the image publishes using a manifest-inspection tool against the image reference. Expected: you see which architectures exist, for example linux/amd64 only.
2. Compare with the platform trivy requests by default (the scanner host's architecture). Expected: you confirm the mismatch - trivy asked for an arch the image does not publish.
3. Re-run the scan with the platform flag set to a published architecture. Expected: the manifest resolves and layer analysis begins.
4. Scan each platform you actually deploy, separately. Expected: findings are per-architecture, which is correct - vulnerabilities can differ between builds.
5. If a needed platform does not exist, fix the image build to publish it rather than working around the scan. Expected: the registry lists the missing architecture on the next push.

Use this when

• trivy fails on multi-arch images with manifest errors
• the image publishes only a subset of architectures
• CI runners differ in architecture from the image
• the error appears before any layer downloads

Not for this skill when

• the image reference itself is wrong or mistyped
• registry credentials are missing or expired
• the manifest exists but a layer fails mid-pull (a network problem)
• the image is single-arch

Variant phrasings

• trivy manifest unknown multi-arch
• trivy failed to get image manifest
• trivy platform manifest not found
• trivy multi-arch image scan fails

Why it happens

A multi-arch image is an index of per-platform manifests. Trivy requests the manifest for its default platform; if the publisher never built that architecture, the registry answers "manifest unknown" and the scan cannot start.

Edge cases

• some registries return this error for private repos when credentials are missing - verify auth before assuming a platform gap
• emulated runners (ARM CI scanning AMD64 images) still need the platform flag set explicitly
• scanning the index without a platform is not supported - pick one explicitly every time
• vulnerability results legitimately differ per architecture - do not copy findings across platforms

Provenance

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

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

Thread query: trivy scan fails with "failed to get image manifest: manifest unknown" on a multi-arch image

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: