feat(workflows)!: step 4, scan every published image with Trivy

[seantronsen]

Description

Decouples Trivy image scanning from the build workflows so repos that publish more than one image get every image scanned, without passing outputs between workflows.

• trivy-image-scan: finds image names with the new actions/discover-ghcr-images action (the images input, else the ghcr.io entries in the GoReleaser config, else the repo name), verifies they exist, and scans each one at the release tag (pr-<N> on PRs), one job per image, with a SARIF category per image. GITHUB_TOKEN can't list packages, hence the name sources.
• Removes the image-ref input; callers grant packages: read instead.

Checklist

• My code follows the style guidelines of this project
• I have added/updated comments where needed
• I have added tests that prove my fix is effective or my feature works
• I have run make test (or equivalent) locally and all tests pass
• I have updated the relevant documentation (CLI examples, man pages, README, other docs, etc.)
• DCO Sign-off: All commits are signed off (git commit -s) with my real name and email
• REUSE Compliance:
  • Each new/modified source file has SPDX copyright and license headers
  • Any non-commentable files include a <filename>.license sidecar
  • All referenced licenses are present in the LICENSES/ directory

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Dependency update
• Build system/CI

---

• I agree to follow the Code of Conduct.

[seantronsen]

Tests: OpenCHAMI/github-actions-testbed#7 (the testbed trivy job scans both of its images, github-actions-testbed and github-actions-testbed-alt).

[seantronsen]

Conflicts to be resolved if/when #41 is merged.

[synackd]

Will review once this is rebased.

[seantronsen]

Will review once this is rebased.

done

[synackd]

Can we add a concrete example of what the output would look like?

[synackd]

No version comment here yet?

[seantronsen]

Good catch, thanks!

Should one be there? Yes absolutely!

Why isn't it there? Pinning a SHA ref requires a commit to pin it to, meaning I had to commit the feature first, then do another commit and switch a zeros todo hash with a proper hash.

I will fix this tomorrow.

[synackd]

When this workflow is called by a workflow_run handler after a PR build, github.event_name is workflow_run, so this expression selects workflow_run.head_branch. The build publishes pr-<N>, not the branch name. Consequently, discovery finds no digest, outputs [], and skips every Trivy job while leaving the workflow successful.

Essentially, the scanner confuses the event that started the scanner with the event that started the build.

When scanning in the same caller workflow:

pull_request #44 → build publishes pr-44 → scan selects pr-44

When scanning in a separate workflow:

pull_request #44 → build publishes pr-44
                 → workflow_run starts scanner
                 → scan selects seantronsen/feat/decouple-trivy

Evidence: This PR's build run (https://github.com/OpenCHAMI/github-actions/actions/runs/38472346439) returns:

{
  "event": "pull_request",
  "head_branch": "seantronsen/feat/decouple-trivy",
  "pull_requests": [44]
}

This expression only recognizes a direct pull_request event. For workflow_run, it takes head_branch, which identifies the source branch. The build workflow's tagging convention is pr-44, so the lookup searches for the wrong image tag. The missing tag produces a notice, discovery returns an empty matrix, and the scan job is skipped.

One way to address this is to first resolve the image tag explicitly before looking up digests. Add an optional image-tag input and use this precedence:

Situation	Tag to use
Caller supplies image-tag	Use it
Direct pull_request event	pr-<pull_request.number>
workflow_run from a PR build	pr-<associated PR number>
Direct tag push	${{ github.ref_name }}
Anything else or ambiguous metadata	Fail with a useful error

An explicit input also gives callers a reliable way to handle release builds or custom tagging conventions.

Second, make missing expected images fail discovery. The existing missing-digest branch can change from:

echo "::notice::${package} has no image tagged ${TAG}; skipping"
continue

to:

echo "::error::${package} has no image tagged ${TAG}"
failed=true
continue

The existing final check then fails discovery after reporting all missing images:

[[ "$failed" == false ]] || exit 1

[synackd]

Just for extra safety, we'll need to URL-encode the package name before inserting it into the API path. Discovery preserves nested names such as tools/foo, but this request turns the slash into another path segment. That causes verification to reject an existing nested GHCR package.

We'll also need to address that here too:

github-actions/actions/discover-ghcr-images/action.yml

Line 100 in 47c0b6c

if ! gh api "/orgs/${OWNER}/packages/container/${package}" --silent; then

We can actually use jq to do this:

encoded_package=$(jq -rn --arg name "$package" '$name | @uri')

Then pass this variable to gh api:

gh api "/orgs/${OWNER}/packages/container/${encoded_package}" --silent
gh api --paginate "/orgs/${OWNER}/packages/container/${encoded_package}/versions"

[synackd]

Shouldn't we specify which ref to checkout here? I think this might read the default branch's config instead of the build revision's config.