trivy scan of image:tag@sha256:... fails with invalid reference f

Not specified by the original author.

TL;DR: Use either the tag or the digest, not both - a digest already pins the exact image, so the tag is redundant and the combined form is invalid. Strip the tag and scan the digest-only reference. Fix the agent's reference builder so it emits one form or the other.

invalid reference format

1. Print the exact reference string the agent constructed. Expected: you see the form image:tag@sha256:... with both a tag and a digest.
2. Decide which pinning you want: the digest alone is the strongest guarantee. Expected: you choose digest-only for immutable scans.
3. Re-run the scan with the digest-only reference. Expected: trivy accepts the reference and the scan starts.
4. Fix the agent's builder: when a digest is known, emit image@sha256:...; otherwise emit image:tag. Expected: newly constructed references never combine both.
5. Re-run the agent end to end. Expected: no more invalid-reference failures in the scan step.

Use this when

• trivy rejects a reference containing both tag and digest
• an agent constructs image references programmatically
• pinning uses digests but a default tag sneaks in
• the error is exactly "invalid reference format"

Not for this skill when

• the tag alone is invalid (typo or illegal characters)
• the digest alone is malformed
• the registry rejects a valid reference (an auth problem)
• the image simply does not exist

Variant phrasings

• trivy invalid reference format tag digest
• image:tag@sha256 invalid
• docker reference tag and digest combined
• trivy digest reference rejected

Why it happens

The container image reference grammar allows name:tag or name@digest, but not both - the tag becomes ambiguous once the digest pins the exact content. Reference parsers reject the combined form outright instead of guessing which one you meant.

Edge cases

• some tools accept the combined form and silently ignore the tag - do not rely on that leniency
• trivy resolves digest-only references fine, but the output labels the target by digest - map it back to the tag in your reports
• agents that append a default :latest tag before adding a digest are the usual source - strip the default tag first
• registries that rewrite tags on push make tag-based scans drift - prefer digests for anything security-sensitive

Provenance

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

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

Thread query: trivy scan of image:tag@sha256:... fails with "invalid reference format" - the double reference the agent constructed

TL;DR:

Not specified by the original author.

Fix trivy's ":latest tag" warning by scanning a pinned digest

TL;DR

The :latest tag is a moving pointer: every rebuild changes what it refers to, so two scans days apart can scan different images. Pin the digest (image@sha256:...) as your scan target and the warning goes away because the target is now immutable. If your agent already pinned a digest but still sees drift, make sure the whole pipeline (scan, deploy, policy) uses the same digest string.

trivy: "WARN: you should avoid using the :latest tag" - the agent pinned a digest and the scan target changed

Steps

1. Resolve the digest for the image you intend to scan.

   • Run: docker inspect --format="{{index .RepoDigests 0}}" [YOUR IMAGE]
   • Expected: output like [YOUR IMAGE]@sha256:[HEX DIGEST], the immutable reference.

2. Scan the digest-pinned reference instead of the tag.

   • Run: trivy image [YOUR IMAGE]@sha256:[HEX DIGEST]
   • Expected: trivy runs with no :latest warning, and the target line shows the digest.

3. Verify repeat scans hit the same target by recording the digest alongside the report.

   • Run: trivy image --format json [YOUR IMAGE]@sha256:[HEX DIGEST] | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['Metadata']['RepoDigests'])"
   • Expected: the digest in the report matches the one you scanned, run after run.

4. If the scan target still "changed" after pinning, audit your pipeline for a step that re-tags or re-pulls by tag.

   • Run: grep -rn ":latest" [YOUR CI CONFIG DIR] (replace with your pipeline config path)
   • Expected: you find the step that re-resolves the tag, and you change it to pass the pinned digest through.

Use this when

• trivy warns you should avoid using the :latest tag
• Scan results drift between runs with no code changes
• An agent pinned a digest but a downstream step still resolves the tag

Not for this skill when

• trivy fails to pull the image at all (registry or auth problem)
• You deliberately scan :latest as a canary for the newest build (accept the warning intentionally)
• The digest itself is unknown because the image was never pushed (push first, then scan)

Variant phrasings

• trivy avoid using latest tag warning
• trivy scan target changed after pinning digest
• trivy warn latest tag how to fix

Why it happens

Tags are mutable labels; registries let publishers push new content under the same tag at any time. A scan of myapp:latest today and myapp:latest next week can examine two completely different filesystems, which makes findings non-reproducible and diffs meaningless. A digest addresses content by hash, so it cannot change out from under you, which is why trivy nudges you toward it.

Edge cases

• Multi-arch images: one tag has several digests (one per architecture); pin the digest for the architecture you deploy.
• Some registries garbage-collect untagged digests: if you pin digests, keep the tag around or the digest may become unpullable.
• Policy gates that compare scan target to deployed target must compare digest to digest; comparing a scanned digest against a deployed tag will always look like drift.

Provenance

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

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

Thread query: trivy: "WARN: you should avoid using the :latest tag" - the agent pinned a digest and the scan target changed

TL;DR: The :latest tag is a moving pointer: every rebuild changes what it refers to, so two scans days apart can scan different images. Pin the digest (image@sha256:...) as your scan target and the warning goes away because the target is now immutable. If your agent already pinned a digest but still sees drift, make sure the whole pipeline (scan, deploy, policy) uses the same digest string.

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: