CI: Replace inline Grype scan with shared action

[ModeSevenIndustrialSolutions]

Replaces the inline Grype install/scan/report shell carried by the Maven and Gradle build workflows with the shared lfreleng-actions/grype-scan-action composite action (v0.0.1), pinned to its commit SHA.

This is the same migration already merged in python-workflows (lfreleng-actions/python-workflows#65), which has been running cleanly against the Python projects hosted here.

What changed

Both maven-build-test.yaml and gradle-build-test.yaml lose four steps from their grype job — Install Grype, the inline scan script, Upload Grype scan results and Grype summary — in favour of a single uses: step.

Behaviour is preserved:

• Scans the same CycloneDX JSON SBOM. The sbom job uploads sbom-cyclonedx.* (both JSON and XML); the scan targets the JSON document only, as before.
• Writes the same sarif/json/table reports.
• Uploads them under the same grype-scan-results artefact name, with the same 90-day retention (both are the action's defaults).
• Renders a step summary.
• grype_fail_on and grype_permit_fail behave as before, the latter still falling back to the NO_BLOCK_AUDIT_FAIL repository variable.

Permissions

The action additionally supports maintainer-approved CVE bypass issues, which requires reading issues. The grype job therefore requests issues: read and passes GITHUB_TOKEN.

A called workflow cannot request a permission its caller withholds, so the self-test callers and the example caller templates all grant issues: read alongside their existing permissions. The README carries no caller snippet with a permissions: block, so it needed no change.

api.github.com:443 is already present in the shared egress allow-list, so the bypass lookup works under harden-runner block mode. Lookup failures leave the bypass list empty, so the gate fails closed either way.

Why

Centralising the logic means a fix or an improvement lands once in the action rather than in every workflow family. Net effect here is 204 lines of duplicated shell removed.

Validation

• prek run --all-files — all hooks pass
• zizmor --persona auditor .github/workflows/ — no findings
• aislop ci --changes — 0 errors, 0 warnings

[Copilot]

Pull request overview

Replaces duplicated inline Grype scanning logic with the pinned shared action and enables CVE bypass issue access.

Changes:

• Adopts grype-scan-action for Maven and Gradle.
• Grants issues: read to reusable workflow callers.
• Preserves report and artifact configuration via action defaults.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
.github/workflows/maven-build-test.yaml	Migrates Maven Grype scanning.
.github/workflows/gradle-build-test.yaml	Migrates Gradle Grype scanning.
.github/workflows/testing.yaml	Grants self-test callers issue access.
examples/maven/build-test/github.yaml	Updates Maven GitHub caller permissions.
examples/maven/build-test/gerrit.yaml	Updates Maven Gerrit caller permissions.
examples/gradle/build-test/github.yaml	Updates Gradle GitHub caller permissions.
examples/gradle/build-test/gerrit.yaml	Updates Gradle Gerrit caller permissions.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ModeSevenIndustrialSolutions]

Functional validation

This repo's self-test is workflow_dispatch-only, so it does not run on pull requests and there is no Grype check on this PR. I enabled Actions on the fork and ran it manually so the migration is not merged on inspection alone.

Run: modeseven-lfreleng-actions/java-workflows 32873609700 (branch feat/grype-scan-action)

The composite action executed end to end in both lanes:

• Grype 0.110.0 installed and scanned sbom-cyclonedx.json.
• Bypass lookup succeeded — No approved bypasses found in modeseven-lfreleng-actions/java-workflows. This exercises the new issues: read permission, the GITHUB_TOKEN pass-through and the api.github.com egress entry, so that plumbing is confirmed working rather than assumed.
• Evaluation reported Total 27 match(es); 27 gating, 0 bypassed (threshold 'medium').
• Reports uploaded as grype-scan-results.zip — same artefact name as before.
• The gate failed the job correctly on findings at or above medium.

The Grype jobs go red, and that is the gate working as intended: the placeholder fixtures are old releases carrying real CVEs (velocity 1.5, jetty 6.1.4, maven-core 2.0-SNAPSHOT, plexus-utils 1.1). testing.yaml sets no Grype inputs, so fail-on is medium and nothing is permitted — the removed inline code used --fail-on medium and exit 1 identically.

Confirmed against a pre-migration baseline

To be sure this was not a regression I ran the same self-test on upstream main, which still carries the inline code: lfreleng-actions/java-workflows 32874334329. Maven fails there too, with exactly the same 27 findings.

The two runs disagree on the Gradle lane (green upstream, red on the branch), and that turned out to be worth chasing: both lanes upload and download an artefact literally named sbom-files, and testing.yaml runs them in one workflow run, so they share an artifact namespace. In the branch run the Gradle lane downloaded Maven's SBOM — its Grype output lists maven-core and plexus-utils, which are not dependencies of onap/portal-ng-preferences.

That is a pre-existing race, unrelated to this PR: the diff here does not touch the SBOM artefact names or the upload/download steps, only the scan steps. Filed separately as #30 rather than expanded into this change.