chore: add workflow to check for stale cve suppressions

[AmberFryar]

.grype.yaml CVE suppression list requires manual maintance to remove entries that are no longer needed. This PR adds an automated weekly workflow to audit the CVE suppression list in .grype.yaml and remove any entries that are no longer needed.

The workflow scans pepr:dev. Grype's output identifies which suppressed CVEs it actually matched against the image. Any entry in .grype.yaml that wasn't matched is stale —the CVE is no longer present in the image and the suppression can be safely removed.

This workflow only removes suppressions. It never adds them.

How it works

1. Builds pepr:dev and scans it with grype
2. Compares .grype.yaml against grype's ignoredMatches output — any suppression not matched is stale
3. Removes stale entries from .grype.yaml
4. Re-scans with the updated file to verify the removal didn't change the number of active findings
5. If verification passes, opens or updates a PR with the list of removed suppressions as evidence
6. If verification fails, aborts without opening a PR

Files added

• .github/workflows/grype-suppression-audit.yaml — runs weekly on Mondays at 8am UTC, also triggerable via
  workflow_dispatch
• .github/workflows/scripts/audit-grype-suppressions.sh — scan and stale detection logic
• .github/workflows/scripts/open-grype-suppression-pr.sh — branch, commit, and PR creation/update
• .github/workflows/scripts/grype-suppression-summary.sh — workflow summary
  ...

End to End Test:
(See Pepr Excellent Examples)

Related Issue

Fixes #

Relates to #

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Unit, Integration, docs, adr added or updated as needed
• Contributor Guide Steps followed

[greptile-apps]

Greptile Summary

This PR replaces the previously proposed shell-script approach with a TypeScript implementation that adds a weekly GitHub Actions workflow to audit .grype.yaml for stale CVE suppressions, remove them, verify the removal doesn't change the active finding count, and open a PR with the changes. The rewrite addresses all issues raised in earlier review threads (flexible whitespace removal, multi-key entry guards, correct summary branching on prOutcome).

Confidence Score: 5/5

Safe to merge — all findings are P2 style suggestions with no functional impact on the core audit logic.

Only P2 findings present (interface typo, process.exit bypassing summary on one rare error path, hardcoded base branch). The core scan-compare-verify-PR flow is logically sound and all previously flagged bugs have been addressed in the TypeScript rewrite.

.github/workflows/scripts/audit-grype-suppressions.ts — minor style issues noted above, no blocking defects.

Important Files Changed

Filename	Overview
.github/workflows/grype-suppression-audit.yaml	New weekly scheduled workflow that builds the pepr image, installs grype, and runs the audit TypeScript script; uses pinned action SHAs, correctly scopes permissions to contents: write and pull-requests: write only at job level, and passes the GH_TOKEN needed for PR creation.
.github/workflows/scripts/audit-grype-suppressions.ts	Main audit script: correctly handles whitespace-flexible line removal, guards against multi-key suppression entries, and properly branches summary output by prOutcome. Minor issues: typo in GrpeScanResult interface name, process.exit(1) in guardSingleKeyEntries bypasses the workflow summary, and --base main is hardcoded in gh pr create.
.github/workflows/scripts/tsconfig.json	New TypeScript config for workflow scripts; appropriate settings with NodeNext module resolution, ES2022 target, and strict mode enabled.
config/eslint.root.config.mjs	Adds the new workflow scripts tsconfig.json to the ESLint project array so the audit script is linted alongside the rest of the codebase.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A([Weekly Schedule / workflow_dispatch]) --> B[Build pepr:dev image]
    B --> C[Install grype]
    C --> D[Scan image with current .grype.yaml]
    D --> E{Stale entries in .grype.yaml?}
    E -- No --> F[Write 'all clear' summary]
    E -- Yes --> G[guardSingleKeyEntries check]
    G -- Multi-key entries found --> H[process.exit 1 - no summary written]
    G -- OK --> I[removeStaleEntries from .grype.yaml]
    I --> J[Re-scan image with updated .grype.yaml]
    J --> K{Match count unchanged?}
    K -- No --> L[git restore .grype.yaml + throw Error]
    L --> M[Write failure summary + Exit 1]
    K -- Yes --> N[createOrUpdatePR: git commit + push + gh pr]
    N --> O{PR step outcome}
    O -- success --> P[Write summary: PR created/updated]
    O -- failure --> Q[Write summary: PR failed + Exit 1]
    F --> R([Done])
    P --> R

Loading

_{Reviews (6): Last reviewed commit: "chore: skip success path" | Re-trigger Greptile}

[samayer12]

Since we're doing somewhat complex data processing here and there's a good bit of string-manipulation and file management I'd like to consider the pros/cons of rewriting this check in Typescript for the sake of maintenance. We can also probably bring in some libraries to handle the string-processing and file I/O for us.

We could accept an additional 200-ish lines of bash to automate away this developer toil, but I'd like to evaluate other ways to manage a net-new automation before resorting to yet another bash script. My litmus test here is that we're doing more than ~50 lines worth of work and the actions are more complex than simple mv/cp commands that don't require in-depth bash familiarity. If we decide bash makes the most sense, then we can proceed.