Reusable security-scan SARIF tool.name rename orphans pre-rename code-scanning alerts

[shb7628]

Summary

GitHub auto-dismisses code-scanning alerts when a fresh analysis (same ref, category, analysis_key, and tool.driver.name) reports zero results for the same rule+location. The reusable scan workflow's emitted SARIF used tool.driver.name: "Armis Security Scanner" until somewhere around 2026-05-22, then was renamed to armis-cli (visible in gh api .../code-scanning/analyses). Any alert created under the old name is now orphaned — the daily 0-result analyses upload under armis-cli and never match the prior Armis Security Scanner alerts, so the alerts stay open forever even after the underlying code is fixed.

Repro

1. Run the reusable scan once with the SARIF emitter naming the tool Armis Security Scanner. It raises an alert.
2. Rename the tool (or upgrade the CLI to a build that names itself armis-cli).
3. Fix the code; the next 0-result scan does not auto-close the original alert.

Concrete example

armis-knowledge alerts #8 and #9:

Original analysis (2026-05-22, raised the alerts)	tool.name = Armis Security Scanner (v1.0.0)
All analyses since 2026-06-04	tool.name = armis-cli, 0 results
Fix landed	commit ca24275, June 22
Alert state today	open (had to dismiss manually)

The category (armis-security-scan) and analysis_key were stable across the rename — only tool.driver.name changed.

Suggested fix

Pin tool.driver.name in the SARIF the CLI emits (and in the stub-SARIF block in .github/workflows/reusable-security-scan.yml) to a single stable value forever. If a rename is unavoidable, document a one-time sweep step to dismiss-and-re-raise the orphaned alerts.

Same risk applies to every other repo using ArmisSecurity/armis-cli/.github/workflows/reusable-security-scan.yml@main.