refactor(ci): extract trivy image scan into separate reusable workflow

[marcusburghardt]

Summary

The trivy_image job in reusable_vuln_scan.yml requires elevated permissions
(packages: write, id-token: write) that cause startup failures in callers
that only need source/dependency scanning. GitHub validates all job permissions at
parse time, even for conditionally-skipped jobs.

This PR extracts the trivy_image job into a dedicated reusable_trivy_image_scan.yml
so callers can independently opt into image scanning with the required permissions,
without affecting the lighter-weight vuln scan workflow.

File	Change
reusable_trivy_image_scan.yml	New -- standalone reusable workflow with the extracted trivy_image job
reusable_vuln_scan.yml	Slimmed -- removed trivy_image job, its inputs (enable_trivy_image, image_ref, image_digest), outputs, and cleaned up permissions and concurrency group

Related Issues

• Fixes startup failure in complytime/.github Security Checks
• Dependent PR: refactor(ci): use dedicated trivy image scan workflow complytime-collector-components#247

Review Hints

• The two files should be reviewed together. The new reusable_trivy_image_scan.yml is a direct extraction of the trivy_image job from reusable_vuln_scan.yml with its own inputs/outputs.

• All reusable workflow references in consumer repos are pinned to SHA cfd981e (v0.2.1). Nothing breaks until a SHA is bumped, giving a safe migration window.

• After this merges and is tagged, consumer repos that use image scanning in their publish pipelines (complytime-collector-components) need to update their ci_publish_ghcr.yml to call reusable_trivy_image_scan.yml instead of reusable_vuln_scan.yml with enable_trivy_image: true. A draft PR is already prepared: refactor(ci): use dedicated trivy image scan workflow complytime-collector-components#247.

• The synced ci_security.yml across the org does not need changes -- it never used enable_trivy_image. The next org sync will resolve the startup failures automatically.

[marcusburghardt]

The failure with OSV-Scanner job will be addressed in a separate PR: #291

[trevor-vaughan]

The change makes sense but it needs a CI test in the current repo to self-validate before we push it out using both a positive and negative test case.

It can probably piggyback off of ci_test_publish_ghcr on a temp image.

[sonupreetam]

@marcusburghardt I agree a CI self-test is valuable as per @trevor-vaughan ask to validate this. Apart from that Everything LGTM, I really liked the separation.

[marcusburghardt]

I am working on it. : )

[marcusburghardt]

Addressed in 54f7253 and b45514d:

• 54f7253 — Fixed scan_passed output in reusable_trivy_image_scan.yml (the step never wrote to GITHUB_OUTPUT, leaving the output always empty)
• b45514d — Added ci_test_trivy_image_scan.yml with positive and negative test cases:
  • Positive: builds a clean temp image, scans it, verifies scan_passed='true' and vuln attestation via cosign when digest is provided
  • Negative: verifies no attestation is produced when digest is omitted

Follows the ci_test_publish_ghcr.yml pattern as suggested.

[marcusburghardt]

@sonupreetam would you like to take a quick look again after the last two commits?

[sonupreetam]

@marcusburghardt Everything looks good, thank you!