fix(reusable-trivy): authenticate the image pull against GHCR#45
Merged
Conversation
The image job's `permissions: packages: read` grants the job's GITHUB_TOKEN read access to packages, but that alone doesn't authenticate the underlying docker/trivy pull - a registry client still needs an explicit login. Confirmed with a real failure on mif-rs's first push-triggered Pipeline run: trivy failed with "unable to find the specified image ... UNAUTHORIZED: authentication required" trying to pull a private GHCR image this same workflow run had just pushed. This was dormant everywhere else in the org: the image job only runs when a caller passes image-ref, which in turn only happens on a non-PR push with a real container to scan - mif-rs is the first repo where that path has actually executed against a real image. Adds a docker/login-action step against ghcr.io using the job's own GITHUB_TOKEN before the trivy scan, matching the registry every caller of this reusable actually publishes to (per this file's own usage comment).
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the shared Trivy reusable workflow to correctly authenticate against GitHub Container Registry (GHCR) before attempting to scan a private image by digest, ensuring packages: read permission is actually exercised via a registry login.
Changes:
- Added a
docker/login-actionstep to log intoghcr.iousing the job’sGITHUB_TOKENbefore the Trivy image scan. - Documented (in-line) why authentication is required for private GHCR pulls even when
packages: readis set.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This was referenced Jul 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
imagejob inreusable-trivy.ymldeclarespackages: readpermission but never actually authenticates the underlyingdocker/trivy pull againstghcr.io. That permission grants the job'sGITHUB_TOKENread access to packages; it doesn't log a registry client in.This was dormant across the org: the
imagejob only runs when a caller passesimage-ref, which in turn only happens on a non-PR push with a real container to scan.mif-rsis the first repo where that path actually executed against a real, just-pushed image, and it failed with:Confirmed independently that this isn't a token-scope illusion: an unauthenticated
docker pullof the same image also 401s.Fix
Adds a
docker/login-actionstep againstghcr.iousing the job's ownGITHUB_TOKEN, before the Trivy scan step. Every caller of this reusable publishes toghcr.io(per this file's own usage comment at the top), so this isn't registry-parsed or conditional.Test plan
actionlintcleanmif-rs'sgate-imagejob on its next push to confirm)