Feat: Add sbom_enabled and grype_enabled toggles

[ModeSevenIndustrialSolutions]

Summary

Adds sbom_enabled and grype_enabled (both boolean, default: true) to the Maven and Gradle lanes.

Why

java-workflows was the outlier: it ran SBOM generation and the Grype scan unconditionally, with no opt-out at all. Python, Go and Node all expose sbom_enabled, so a project moving between families met an inconsistent contract.

The two inputs are independent by design. With grype_enabled: false the SBOM is still generated and uploaded as sbom-files; only the scan is skipped. That ordering matters — SBOM generation is what we want on by default, and coupling the two would have meant dropping the SBOM to escape a blocking CVE.

A subtlety worth reviewing

Both lanes share this condition between two jobs — tests and sbom:

if: ${{ !cancelled() && needs.build.result != 'skipped' }}

Only the sbom job should gain the sbom_enabled clause. The edit is therefore anchored on the SBOM job's own explanatory comment ("…even when the build fails (for example on a test failure)") rather than on the condition text. Verified afterwards that the tests gate is unchanged in both files:

maven-build-test.yaml:552:  … needs.build.result != 'skipped' }}                        # tests, untouched
maven-build-test.yaml:616:  … needs.build.result != 'skipped' && inputs.sbom_enabled }} # sbom
gradle-build-test.yaml:485: … needs.build.result != 'skipped' }}                        # tests, untouched
gradle-build-test.yaml:550: … needs.build.result != 'skipped' && inputs.sbom_enabled }} # sbom

The deliberate != 'skipped' semantics are preserved: the SBOM job keeps producing the dependency-scan signal even when the build fails, because it does its own checkout and does not consume build artefacts.

Compatibility

default: true — no existing caller changes behaviour. No inputs removed or renamed. Nothing in either lane depends on the sbom or grype job results, so a skipped job cannot strand anything downstream.

Not in scope

java-workflows also has no dependency-audit job, unlike the pip-audit / govulncheck / npm audit lanes elsewhere. That is a real coverage gap but a separate piece of work, and I am raising it as its own issue rather than smuggling it in here.

Validation

• yamllint, actionlint — clean
• zizmor — no findings
• Full prek run over the changed files — all hooks passed

Context

Part of a seven-PR series standardising these toggles across the workflow estate. Companions: lfreleng-actions/workflows-template#56, lfreleng-actions/python-workflows#85, lfreleng-actions/go-workflows#67, lfreleng-actions/node-workflows#83.

[Copilot]

🟢 Approval recommended

Pull request overview

Adds opt-out controls for SBOM generation and Grype scanning while preserving existing default behavior.

Changes:

• Adds default-enabled sbom_enabled and grype_enabled inputs.
• Applies each toggle only to its corresponding job.
• Documents both inputs in Maven and Gradle examples.

File summaries

File	Description
.github/workflows/maven-build-test.yaml	Adds and applies Maven security-job toggles.
.github/workflows/gradle-build-test.yaml	Adds and applies Gradle security-job toggles.
examples/maven/build-test/github.yaml	Documents Maven caller options.
examples/gradle/build-test/github.yaml	Documents Gradle caller options.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0
• Review effort level: Balanced

---

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

[Copilot]

🟢 Approval recommended

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Copilot]

🟢 Approval recommended

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[zxiiro]

🤖 Auto-approved by agent: reviewed workflow/code change for security and CI/CD impact, found low risk. Adds additive sbom_enabled and grype_enabled inputs defaulting to true on Gradle/Maven workflows. Existing callers keep current scan behavior; no permission or pin changes.