chore(ci): migrate disabled Trivy scan to reusable Grype workflow

[mattmattox]

Summary

• Replace the disabled (if: false) per-repo Trivy security-scan job in .github/workflows/pipeline.yml with a caller of the org-wide reusable SupportTools/ci-runners/.github/workflows/grype-scan.yml@main workflow, for consistency with other repos.
• The new grype-scan job stays effectively opt-in/non-blocking: it keeps if: false (same reason as before — the KubeTTY image is too large to scan practically in CI) and sets blocking: false on the reusable workflow, so it will never gate the pipeline even if enabled later. needs: [build] wires it to the build job and it scans the exact image built there via ${{ needs.build.outputs.image-digest }} (by digest, so it always matches the pushed image regardless of tag scheme).
• Renamed the corresponding needs.security-scan reference in the (also disabled, if: false) "Verify security scan passed" step in deploy-production to needs.grype-scan.
• Removed every aquasecurity/trivy-action step (SARIF scan, blocking scan, SBOM generation) — no trivy-action references remain in the workflow.
• validate-pipeline-local.sh: swapped its local best-effort Trivy checks for the direct Grype equivalents (grype "$IMAGE_TAG" for the informational pass, grype "$IMAGE_TAG" --fail-on critical for the blocking pass) — this was a trivial, obvious command swap, so no TODO was needed.
• Added an empty .grype.yaml (ignore: []) since no .trivyignore existed previously; this matches the reusable workflow's default config input.

Notes

• Because grype-scan stays if: false, it will not run on this PR — that's expected/by design (mirrors the prior Trivy job's disabled state). Validated YAML with python3 -c 'import yaml; yaml.safe_load(...)' and confirmed shell syntax with bash -n.

Test plan

• python3 -c "import yaml; yaml.safe_load(open('.github/workflows/pipeline.yml'))" passes
• bash -n validate-pipeline-local.sh passes
• No remaining trivy-action or aquasecurity/trivy-action references in .github/workflows/
• CI checks pass on this PR (grype-scan job itself will be skipped, as intended)

---

Update: switched to in-line anchore/scan-action (grype engine)

KubeTTY pipeline.yml is pull_request-triggered. The org reusable grype-scan.yml (private-repo reusable workflow) fails to resolve at workflow-load time on pull_request, which 0-job-startup-failed the entire pipeline run even with if: false (GitHub resolves the reusable uses: before evaluating if:). Replaced the reusable job with an in-line anchore/scan-action@v6 step, kept disabled (if: false, image too large to scan in CI) exactly as before. An in-line action has no load-time resolution problem, so PR CI is no longer broken.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 902a00bf31

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid env context in reusable workflow inputs

Because this job calls a reusable workflow, jobs.<job_id>.with.<input_id> expressions are limited to the github and needs contexts per GitHub's workflow syntax, so the newly added ${{ env.REGISTRY }} / ${{ env.IMAGE_NAME }} references make .github/workflows/pipeline.yml invalid at parse time even though the job has if: false. Every push or PR that loads this workflow will be rejected before CI jobs are scheduled; hard-code this image prefix or pass it through an output from a needed job.

Useful? React with 👍 / 👎.