[Kiran01bm]

Add a Vulnerability Scan check that runs govulncheck on every pull request and fails when pg-sprite calls into a known vulnerability.

Why

No pg-sprite check reads the Go vulnerability database. main builds on Go 1.26.0 and calls into 31 known vulnerabilities: 30 in the standard library and 1 in klauspost/compress. Lint, the tests and the smoke test all stayed green, so nobody was told. A manual govulncheck run is the only thing that shows them today.

What

• Add scripts/check-vulnerabilities.sh. It runs govulncheck v1.6.0 and fails only on findings the code can reach.
• Add make check-vulnerabilities, which runs the script, and list it in docs/testing.md.
• Add the Vulnerability Scan workflow. It runs that target on pull requests and on pushes to main.

The scan is a workflow of its own and stays out of all-green. The advisory database changes without any commit here, so a failure is usually not caused by the diff that triggered it.

This branch is stacked on #349, the Go 1.26.11 and klauspost/compress bump, so the new check passes here. The go.mod and go.sum changes in the diff belong to that PR and drop out once it merges and this branch is updated from main. Merge #349 first: without it the new check fails on main.

Before / after

CI gains one check. ci.yml, all-green and the Go code are unchanged. The example is a pull request opened against main today, while go.mod still says go 1.26.0.

Before: no check reads advisories           After: Vulnerability Scan on every PR

┌────────────────────────────────────┐      ┌────────────────────────────────────┐
│ A PR is opened against main,       │      │ A PR is opened against main,       │
│ which builds on Go 1.26.0          │      │ which builds on Go 1.26.0          │
└───────────────┬────────────────────┘      └───────────────┬────────────────────┘
                │ CI starts                                 │ CI starts
                ▼                                           ▼
┌────────────────────────────────────┐      ┌────────────────────────────────────┐
│ lint, the tests and the smoke      │      │ Vulnerability Scan also runs       │
│ test run; none reads advisories    │      │ make check-vulnerabilities         │
└───────────────┬────────────────────┘      └───────────────┬────────────────────┘
                │ every check is green                      │ the script exits 1
                ▼                                           ▼
┌────────────────────────────────────┐      ┌────────────────────────────────────┐
│ main keeps calling into 31 known   │      │ the check goes red and lists all   │
│ vulnerabilities and nobody is told │      │ 31 findings with their fix release │
└────────────────────────────────────┘      └────────────────────────────────────┘

Once the Go and klauspost/compress bumps merge, the same run finds nothing reachable and the check is green.

References

• govulncheck

🤖 Generated with Amp (claude-opus-5-5)

[chatgpt-codex-connector]

Codex Review Summary: ❌ Failed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	❌ Failed 2026-11-11T07:01:52.706664Z We couldn’t complete this review. Comment @codex review to try again.	81c9b4b	Draft marked ready

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[JashLal]

🤖 Reviewed by Jash’s AI agent (Codex) at 81c9b4b.

No blocking issue found in the full six-file diff. The workflow uses pull_request and main pushes, read-only contents permission, SHA-pinned actions and checkout without persisted credentials. The executable script is connected to a phony Make target; scanner failures remain nonzero, and the new check deliberately stays outside all-green. The go.mod/go.sum changes match the prerequisite #349; retain the documented merge order.

Suggestion — scripts/check-vulnerabilities.sh:47–52: distinguish a scanner execution error from an actual vulnerability finding. Every nonzero exit currently prints “Reachable vulnerabilities found” and recommends a dependency bump, including failures to load packages or fetch advisory data. Preserve the original status and print a scan-failed diagnostic for operational errors; this does not currently create a false-green result.

Validation: bash -n passed on the script extracted from this PR diff. A local stub harness exercised scanner exits 0, 1 and 3: the wrapper returned 0, 1 and 1 respectively, confirming both fail-closed behavior and the shared diagnostic above. This was not a real govulncheck run or repository test suite. At review time, 10 GitHub checks passed, including Vulnerability Scan, and seven database/Supabase checks were still running. Exact-head surrounding Makefile retrieval failed with an api.github.com connection error, so context outside the diff was not independently verified. The separate Codex review bot reported a usage-limit failure.

[JashLal]

🤖 Approved by Jash’s AI agent (Codex). Review findings and validation limits are recorded in my substantive PR comment.