feat: add reusable SBOM publish and Trivy security scan workflows

[TheMeinerLP]

Makes Dependency-Track and Trivy org-wide mechanics instead of per-repo copy-paste. Prompted by the AntiRedstoneClock-Remastered 2.9.0 release, where the SBOM upload lived inside the release job and one rejected platform version cost the JAR, both platform releases and the SBOM in one go.

Preconditions are already in place: DEPENDENCYTRACK_HOSTNAME and DEPENDENCYTRACK_APIKEY are organisation secrets, so secrets: inherit covers every repo with no per-repo setup.

sbom-publish.yml

Publishes a CycloneDX SBOM to Dependency-Track. The SBOM comes from one of two places:

artifact-name	Source	When
set	artifact from an upstream job	the project already emits an SBOM (e.g. the CycloneDX Gradle plugin) — a build tool resolves the dependency graph better than any external scanner
empty	Trivy filesystem scan	the project has no SBOM generator; zero setup

Runs as its own job by design. Dependency-Track being unreachable or rejecting a key must not take down the release that produced the artifact.

security-scan.yml

Trivy scan with findings pushed to GitHub code scanning.

• Report-only by default. Adopting this should make vulnerabilities visible, not turn a repo's CI red on day one. fail-on-findings: true gates once a repo is clean enough to keep it that way.
• limit-severities-for-sarif: true. Without it Trivy ignores severity for SARIF output and uploads every severity, so code scanning would show a different set than the gate fails on.
• Two passes when gating. The report pass always exits 0 — a non-zero exit would skip the SARIF upload and the findings would never reach code scanning. The gate pass runs afterwards with skip-setup-trivy.

Conventions followed

Every input has a description, explicit type and a default unless genuinely required; secrets: inherit friendly; concurrency follows the publish-vs-validation split (cancel-in-progress: false for the SBOM publish, true for the scan); required caller permissions documented at the top of each file. Action inputs were verified against the actual action.yml of aquasecurity/trivy-action@v0.36.0 and DependencyTrack/gh-upload-sbom@v4 rather than assumed.

Two things worth knowing before adopting

• autocreate needs PROJECT_CREATION_UPLOAD. It defaults to true, and the Dependency-Track API key's team needs that permission on top of BOM_UPLOAD — otherwise the server answers 403 the first time any new version is uploaded. This is exactly what is currently failing for AntiRedstoneClock-Remastered 2.9.0, and it is a server-side key permission, not something this workflow can fix.
• SARIF upload on private repos needs Advanced Security. The organisation is on the Free plan, so public repos are fine and private ones must set upload-sarif: false.

Follow-up

A companion PR migrates AntiRedstoneClock-Remastered onto both workflows as the first consumer, so this is exercised for real rather than only in theory.

The README examples pin @v2.6.0, assuming this feat: lands as 2.6.0. Worth a glance if release-please picks something else.