ci(phase-3): migrate security.yml::trivy to extended container reusable

[CybotTM]

Phase 3 of the container-CI consolidation

Migrates .github/workflows/security.yml's trivy job to the Phase-2.5-extended security-container.yml@main reusable in netresearch/.github.

What migrated

security.yml::trivy — now calls netresearch/.github/.github/workflows/security-container.yml@main with tolerate-pull-failure: ${{ matrix.tag == 'rolling' }}. The reusable's pre-flight docker manifest inspect probe replaces the previous job-level continue-on-error: ${{ matrix.tag == 'rolling' }} (which GitHub forbids on reusable-caller jobs anyway — actionlint rejects it). The behavioural contract is preserved: a missing rolling image short-circuits the Trivy + SARIF-upload steps and exits the job green, while legitimate Trivy finding-based failures (caller exit-code: '1') still propagate normally because the reusable does NOT slap a broad continue-on-error on Trivy itself.

Defaults of the reusable line up 1:1 with the previous inline values: exit-code: 0, ignore-unfixed: true, vuln-type: os,library, severity: HIGH,CRITICAL, limit-severities-for-sarif: true, scanners: vuln. No behavioural change beyond replacing the continue-on-error mechanism. SARIF category remains trivy-${{ matrix.tag }} so the GitHub Security tab grouping is unchanged.

Line counts: security.yml 135 → 118 (-17). The trivy job block itself shrank from ~50 lines (steps: checkout + trivy-action + upload-sarif) to ~26 (matrix + with: block + permissions).

What stays inline (and why)

security.yml::osv-scanner — Per the explicit task constraint #11: composer.lock extraction (docker pull + docker create + docker cp /var/www/html/composer.lock) is Snipe-IT-specific (path + lock-file location are not generalisable) and the osv-scanner action itself doesn't fit the container reusable's surface. The job retains its own continue-on-error: ${{ matrix.tag == 'rolling' }} since it is NOT a reusable-caller job and the keyword is legal at the regular-job level.

build.yml — left inline as a follow-up upstream item. Honest report: two independent blockers prevent a clean migration to build-container.yml@main right now.

1. Job-level continue-on-error: ${{ matrix.composer == 'rolling' }} is forbidden on reusable-caller jobs (same GitHub restriction we just worked around for trivy). The build-container reusable does not currently expose a tolerate-build-failure knob analogous to tolerate-pull-failure — and unlike the security side, rolling-build failures aren't a manifest-not-found case the reusable can pre-flight cheaply; they're caused by composer audit blocking inside the docker build, which is a build-time failure mode that needs different plumbing.
2. Pre-build ref resolution + tag fan-out can't sit alongside uses:. A reusable-caller job allows only name, uses, with, secrets, needs, if, permissions, concurrency, strategy — no inline steps:. The current build.yml does meaningful work in steps before the metadata + build calls: reads .snipe-it-version (tag track), calls gh api repos/grokability/snipe-it/commits/{master,develop} (branch tracks), computes the {version, major, major_minor, date_tag, build_date} outputs, then computes a custom tag-fan-out list (8.5.0 / 8.5 / 8 / latest, with -rolling suffixes when applicable). Refactoring this into a separate compute matrix job whose outputs feed the build matrix job via needs: + outputs: + fromJSON gymnastics would make the workflow MORE complex than the inline version, not less. Task description explicitly authorises leaving build.yml inline in this case.

Proposed follow-up upstream PR on netresearch/.github (does not block this PR): add a tolerate-build-failure: bool input to build-container.yml that wraps the Build and push step in equivalent semantics (e.g. continue-on-error: true on the build step + a steps.build.outcome != 'failure' gate on attest/sign). Once that's available, the build.yml migration can be revisited — though the second blocker (caller-side ref resolution as steps) will likely keep build.yml inline regardless. The metadata-tags + metadata-labels + build-args + cache-scope + target + provenance + sbom inputs added in Phase 2.5 are all the reusable-side surface this caller would consume, and they're complete.

Hard-constraint compliance

uses: netresearch/.github/.github/workflows/security-container.yml@main — pinned to @main, no SHA pin on the org's own reusable (rule #3). All third-party action SHAs preserved verbatim (no new third-party action references introduced; we deleted some). SPDX header retained with "Netresearch DTT GmbH". Conventional-commit prefix on the commit. Signed + signed-off commit matching git config user.name / user.email.

Verification

• actionlint .github/workflows/*.yml — clean across all workflows.
• yamllint with the snipe-it project config — only pre-existing comment-spacing warnings on SHA-pin comments (no new findings; net warnings down from 5 to 2 since 3 inline action references were removed).
• tail -c 2 .github/workflows/security.yml | xxd -p → 6b0a (single trailing newline, no double).
• git show --stat HEAD confirms only .github/workflows/security.yml changed.

CI run will exercise the new caller against the published :latest (present) and :rolling (currently failing builds → manifest absent → pre-flight skip path).

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 Security Hotspot

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

Migrates the trivy job in this repository’s security workflow from inline steps to the shared netresearch/.github reusable container security workflow, keeping the existing “rolling image may not exist” behavior while satisfying GitHub’s restrictions for reusable-workflow caller jobs.

Changes:

• Replaced the inline trivy scan + SARIF upload steps with a call to netresearch/.github/.github/workflows/security-container.yml@main.
• Implemented the previous “rolling tag may be missing” tolerance via tolerate-pull-failure: ${{ matrix.tag == 'rolling' }} rather than job-level continue-on-error.
• Updated workflow comments to reflect the new delegation and rationale.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.