Security Scan red: VERISIMDB_PAT is a dead token (401 Bad credentials) — rotate or delete

Symptom

Security Scan on main fails at the Send to verisimdb-data step with HTTP 401 "Bad credentials" (e.g. run 28843168xxx on 1e91510).

Diagnosis chain (all now fixed except this last link)

~~curl: Argument list too long — scan JSON inlined on argv~~ → fixed in panic-attack#155, re-pinned via fix(ci): re-pin panic-attack scan-and-report past the argv-overflow fix #307
~~Payload over the ~64KB repository_dispatch cap~~ → counts-only summary fallback (same PR); echidna's report is 274KB so the summary path is exercised and works
~~Missing-PAT consumers hard-fail~~ → optional-PAT skip + HTTP status surfacing in panic-attack#156, re-pinned via fix(ci): re-pin panic-attack scan-and-report — optional-PAT skip (Security Scan green without VERISIMDB_PAT) #309
Remaining: echidna does carry a VERISIMDB_PAT secret, but GitHub rejects it — the token is revoked/expired (same pattern as the dead FARM_DISPATCH_TOKEN from the identity rebuild).

Owner action (either one makes Security Scan green)

Mint a replacement PAT with repo scope for repository_dispatch to hyperpolymath/verisimdb-data and update the VERISIMDB_PAT secret — restores the scan→VeriSimDB data flow; or
Delete the dead VERISIMDB_PAT secret — the workflow then takes the documented skip path (scan still gates, dispatch skipped with a notice).

Part of the PAT-rotation backlog (GitHub identity rebuild).

🤖 Generated with Claude Code

Owner decision: rotate (2026-07-07).

Mint spec for the replacement token:

Fine-grained PAT, resource owner hyperpolymath, repository access: only hyperpolymath/verisimdb-data, permission: Contents: read-and-write (fine-grained tokens gate repository_dispatch on the target repo's Contents permission). Classic-PAT alternative: repo scope (broader than needed — prefer fine-grained).
Then: gh secret set VERISIMDB_PAT -R hyperpolymath/echidna (and consider setting it org-level or in the other panic-attack consumer repos so one rotation covers all — verisimdb/vcl-ut session notes flag the same dead token).
No workflow change needed afterwards: scan-and-report.yml @6693e01 picks up the secret automatically and resumes dispatching (with HTTP-status diagnostics on any rejection).

Until the token lands this issue stays open and Security Scan stays red at the dispatch step (the scan itself passes).

fix(ci): repair workflow gates and reconcile remaining issue status (#…

Status, 2026-10-01: a fifth link was in front of the PAT; it is fixed in #399.

Since sha_pinning_required landed, Security Scan has not reached the 401 at all. Every run has ended in startup_failure; the latest was on ba373a8, 2026-09-27. The cause was that the panic-attack callee pinned at 27b3d93 used tag-ref steps.

fix(ci): SHA-pin scan-and-report steps so sha_pinning callers can start it panic-attack#209 SHA-pins those steps. It merged as 5ee2565, a signed and verified commit, and panic-attack's own CodeQL run on that commit concluded success.
fix(ci): SHA-pinned Security Scan callee + re-key CodeQL lock entry #399 moves echidna's callee pin to 5ee2565.
fix(ci): SHA-pinned Security Scan callee + re-key CodeQL lock entry #399 also re-keys codeql.yml's lock entry from v4.38.0 to v4.38.1. CodeQL here had been dying at startup on the same kind of mismatch.

Still the owner's action, unchanged from the 07-07 decision ("rotate"): VERISIMDB_PAT was last updated 2026-03-29, so it has not been rotated since. To restore the dispatch:

Mint a fine-grained PAT. Resource owner: hyperpolymath. Repository access: only hyperpolymath/verisimdb-data. Permission: Contents: read-and-write.
Run gh secret set VERISIMDB_PAT -R hyperpolymath/echidna.

After #399 merges and until the PAT is rotated, expect the run to reach Send to verisimdb-data and fail with HTTP 401. The callee skips the dispatch only when the secret is absent, not when it holds a revoked token. Deleting the dead secret instead would turn the scan green, with the dispatch skipped.

🤖 Generated with Claude Code

fix(ci): SHA-pinned Security Scan callee + re-key CodeQL lock entry (#…

Update after #399 merged (squash 3d886ae, 2026-10-01T14:4xZ).

Security Scan on main no longer dies at startup. On the parent fd1ef5d it was startup_failure; on 3d886ae every step ran.
It now fails only at Send to verisimdb-data with HTTP 401. See run 36879363057.
Correction to my earlier comment: VERISIMDB_PAT is present (set 2026-03-29), and the step received a non-empty token (masked ***). The 401 therefore means the token is expired or revoked, not missing.

Owner step (only you can do this): mint a new fine-grained PAT with Contents RW (and Actions/dispatch if the callee needs it) on hyperpolymath/verisimdb-data, then run gh secret set VERISIMDB_PAT -R hyperpolymath/echidna, then re-run the workflow. No code change is needed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SJGZgoR9ArMgxKcqG7ChW8

ci: pin cicd-suite, dtolnay/rust-toolchain and the Hypatia clone (#401)…

CI hygiene: allow-fail expiry, dead playground workflows, ruleset sna…

Navigation Menu

Repository navigation

Security Scan red: VERISIMDB_PAT is a dead token (401 Bad credentials) — rotate or delete #310

Symptom

Diagnosis chain (all now fixed except this last link)

Owner action (either one makes Security Scan green)

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Security Scan red: VERISIMDB_PAT is a dead token (401 Bad credentials) — rotate or delete #310

Description

Symptom

Diagnosis chain (all now fixed except this last link)

Owner action (either one makes Security Scan green)

Activity

hyperpolymath commented on Jul 7, 2026

hyperpolymath commented on Oct 1, 2026

hyperpolymath commented on Oct 1, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions