[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 build's tag (pr-<N> on PRs, else the pushed v* tag; any other trigger fails), 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.

Testbed: OpenCHAMI/github-actions-testbed#7.

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

[seantronsen]

The want for simplicity is valid, however, as a generic action, we need to accommodate non-happy-path use cases. Realistically, we probably don't need the arbitrary tag argument, but some repos may allow triggering this via workflow_dispatch, which may or not have a PR tag, so we need to figure out how to deal with that if not with the arbitrary tag argument. Containers are pushed on PRs, so I think at least allowance of PR number specification should be allowed.

Respectfully, I'd like to push back on this: #44 (comment)

I looked around the org first. Some repos support workflow_dispatch for their own Trivy setups, but I didn't find any that actually use it. This workflow is meant to replace those setups as the standard, so it should follow the build workflow's design rather than carry over unused features.

trivy-image-scan scans what build-release-goreleaser publishes, and that only runs on PRs (pr-) and v* tag pushes. A manual run has nothing new to scan, so a PR-number or tag override would just be extra logic for a case the build doesn't support.

So the goals are:

• Run on the same triggers as the build, and fail clearly on anything else.
• Drop workflow_dispatch support, along with the override inputs it would need.

Ongoing CVE coverage for published images until their EOL (e.g. a scheduled rescan) is worth having, but that's out of scope for this PR. If it's something you want, I can create a tracking issue and implement immediately after the release of v4.

[synackd]

I'm fine if we restrict how it runs, as long as we are explicit both in documentation and error modes.

I looked around the org first. Some repos support workflow_dispatch for their own Trivy setups, but I didn't find any that actually use it. This workflow is meant to replace those setups as the standard, so it should follow the build workflow's design rather than carry over unused features.

The org is probably not a good reference. Most of the actions there aren't exactly fleshed out. This PR stack is probably the first attempt at any "standard" flow, which is why I bring up the failure mode accommodation here.

trivy-image-scan scans what build-release-goreleaser publishes, and that only runs on PRs (pr-) and v* tag pushes. A manual run has nothing new to scan, so a PR-number or tag override would just be extra logic for a case the build doesn't support.

So the goals are:

* Run on the same triggers as the build, and fail clearly on anything else.

* Drop workflow_dispatch support, along with the override inputs it would need.

As stated above, limiting the run mode for this action to tag pushes is fine as long asthe documentation is clear about that and any attempt to run otherwise is met with a clear error. My thought for workflow_dispatch is if a scan needs to run to scan a test image, but I don't see that as a common use case.

[seantronsen]

The want for simplicity is valid, however, as a generic action, we need to accommodate non-happy-path use cases. Realistically, we probably don't need the arbitrary tag argument, but some repos may allow triggering this via workflow_dispatch, which may or not have a PR tag, so we need to figure out how to deal with that if not with the arbitrary tag argument. Containers are pushed on PRs, so I think at least allowance of PR number specification should be allowed.

Respectfully, I'd like to push back on this: #44 (comment)

I looked around the org first. Some repos support workflow_dispatch for their own Trivy setups, but I didn't find any that actually use it. This workflow is meant to replace those setups as the standard, so it should follow the build workflow's design rather than carry over unused features.

trivy-image-scan scans what build-release-goreleaser publishes, and that only runs on PRs (pr-) and v* tag pushes. A manual run has nothing new to scan, so a PR-number or tag override would just be extra logic for a case the build doesn't support.

So the goals are:

• Run on the same triggers as the build, and fail clearly on anything else.
• Drop workflow_dispatch support, along with the override inputs it would need.

Ongoing CVE coverage for published images until their EOL (e.g. a scheduled rescan) is worth having, but that's out of scope for this PR. If it's something you want, I can create a tracking issue and implement immediately after the release of v4.

Tracking issue created: #61

[synackd]

I think this is largely good, just a documentation nit.

[synackd]

This paragraph explicitly states that unsupported triggers fail, but that restriction is embedded in the longer explanation of scanning and image discovery. The usage example below starts at jobs:, so someone copying it could miss which caller events are supported.

I think it might be better to put a short callout immediately before Usage and include the caller's triggers in the example, since that would make the restriction easier to discover before running the workflow. For example:

Supported triggers: Call this workflow from pull_request events or push events for tags beginning with v. Other events—including workflow_dispatch, workflow_run, and release—fail with an error. Run the scan after the image-publishing job.

on:
  pull_request:
  push:
    tags: ['v*']

That would also make the documentation's event names directly match the trigger check and error message. This is a readability suggestion; the restriction is already documented correctly.

[synackd]

Related to #44 (comment)

[seantrons]

I'm fine with this and will do it when I get home, but it also hints at a larger docs update. In another PR higher up in the stack, I reorganized all the docs into a focused layout, but my original plan was to hold off on major content changes across the board until the current stack is approved (another reason for the release staging setup) to avoid unnecessary contention over the .md files (simplifies stack rebases).

[seantronsen]

Tracking issue created: #64

[seantronsen]

656c98f