Fix: Give each lane its own SBOM artefact name

[ModeSevenIndustrialSolutions]

Closes #30.

Problem

maven-build-test.yaml and gradle-build-test.yaml both uploaded and downloaded an artefact named exactly sbom-files. A caller that invokes both — as testing.yaml does — runs them in a single workflow run, where they share one artifact namespace.

Duplicate artefact names are permitted, so both uploads persisted as separate artefacts. The ambiguity bites at download time: download-artifact resolves a name to the newest matching artefact, so both Grype jobs pulled whichever lane happened to upload last.

The failure mode is quiet and the wrong way round: a lane can report green having scanned the other lane's SBOM, proving nothing about the lane it claims to cover.

Evidence it was real

Two workflow_dispatch runs of the same self-test, same fixtures and pins, differing only in run:

Run	Maven Grype	Gradle Grype
upstream main 32874334329	failure	success
branch 32873609700	failure	failure

In the second, the Gradle lane's Grype output listed maven-core and plexus-utils — not dependencies of the Gradle fixture. It had scanned Maven's SBOM.

That run's artefact list shows the mechanism plainly — two live artefacts sharing one name:

id=9573156709  name=sbom-files  size=148503  created=16:47:12   <- Maven, newer
id=9573151979  name=sbom-files  size=  3472  created=16:47:05   <- Gradle

Both Grype jobs read the newer, larger one. (The same run also shows two grype-scan-results artefacts, for the same reason.)

Fix

Name the artefact per lane, sbom-files-maven and sbom-files-gradle, keeping each download in step with its upload. Four lines, plus a comment recording why the name must stay lane-specific so it does not regress.

Verified

Self-test on this branch: 32880512411

Gradle lane -> sbom-files-gradle (ID 9575824492, 3,469 bytes)   -> Total 0 match(es)  -> success
Maven  lane -> sbom-files-maven  (ID 9575775514, 148,503 bytes) -> Total 27 match(es) -> failure

Two distinct artefact IDs and sizes an order of magnitude apart: each lane now resolves its own SBOM, and Gradle reports "No vulnerabilities found" — matching the behaviour upstream showed when the race happened to fall its way.

The Maven lane still fails, and should: the placeholder fixture is apache/maven 3.9.9, carrying real CVEs (velocity 1.5, jetty 6.1.4, maven-core 2.0-SNAPSHOT). That is pre-existing fixture debt and the gate working, unchanged by this PR and unrelated to the collision.

Scope note

This fixes collisions between the two lanes, which is what #30 describes and what was observed. It does not make a single lane safe against a caller matrixing it against itself (two legs of maven-build-test.yaml in one run would still share sbom-files-maven), because GitHub exposes no caller-leg discriminator to a called workflow. docker-workflows handles that case by hashing the distinguishing inputs into a build_id and suffixing artefact names with it; adopting the same pattern here would need a metadata output that java's job graph does not currently carry, so I have left it as a separate concern rather than widening this change.

Validation

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

[Copilot]

Pull request overview

Prevents Maven and Gradle lanes from downloading each other’s SBOM artifacts.

Changes:

• Assigns lane-specific SBOM artifact names.
• Keeps each upload and download name aligned.

Reviewed changes

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

File	Description
.github/workflows/maven-build-test.yaml	Uses sbom-files-maven.
.github/workflows/gradle-build-test.yaml	Uses sbom-files-gradle.

---

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

[Copilot]

Pull request overview

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