security: keep a security-finding ledger so a fixed issue cannot silently regress #379

Written-by: Fledge Platform Product
Owner-card: #379 was filed by HugoXK on 2026-11-12; this rewrite keeps its scope and its priority:high label.

Problem

Fledge gates CodeQL and dependency findings, but it treats each run as a snapshot. When a finding is fixed, dismissed or accepted, the next job has no memory of the decision; a later change can reintroduce the same issue without a reviewer seeing the regression. Recent work on CVE propagation (arXiv:2611.14164) and compositional security for agentic coding harnesses (arXiv:2611.13960) points to a persistent security record rather than a per-run scan.

This card is slice 1 of three

Slice 1 adds the ledger and the one flag that makes it worth having: a finding that was dismissed and comes back is marked regressed on the job that saw it and on the repository page. It records what a job reports; it does not yet read GitHub's own alert store and it does not block a merge.

Current at 6287aa5394f31f9ce47183eca0cb10cd3c58eac2:

• Fledge reads check-run outcomes only: listCheckRuns (src/repos/github.ts:563) returns name/status/conclusion (:66-70), used at src/jobs/service.ts:1727 and :2141. No rule id, path or line reaches Fledge.
• Nothing in src/ parses CodeQL results: a search for codeql|sarif finds two unrelated comments (src/app.ts:271, :582).
• The gate that does know the ids runs in CI, against a line-keyed baseline: scripts/codeql-gate.mjs:116-129 compares alertKey values with .github/agent/codeql-baseline.json.
• So the ids have to arrive the way every other job fact arrives: in the callback's bounded evidence object (src/lib/evidence.ts:1-13), which today carries only prose and one count.

Expected:

• evidence.findings: [{ rule, path, line, state? }] is accepted at the callback, bounded to 100 entries, rule ≤ 120 characters, path ≤ 200, line a positive integer, state one of open/dismissed; anything else is dropped and counted;
• the finding id is rule + path + line; a new table security_findings (repo, id, first_seen_job, last_seen_job, state, reason) is written inside the terminal transition, so a replayed callback writes nothing twice;
• a finding whose id was dismissed (with a reason recorded by an operator) and appears again becomes regressed, is shown on the job page as regressed (dismissed in job <id>), and is listed on the repository page under open / fixed / regressed / dismissed;
• a dismissed report without a reason is refused by the route that sets the state, not silently stored as open;
• the block states that these are reported ids, so nobody reads the ledger as GitHub's alert store.

Red test

test/securityFindings.test.ts (new):

• job A reports id js/path-injection src/app.ts:120 → one row open, first_seen_job = A;
• an operator dismisses it with a reason → state dismissed;
• job B reports the same triple → the row is regressed, last_seen_job = B, and the job page contains regressed (dismissed in job A);
• two findings with the same rule but different paths are two ids;
• a dismissal without a reason is refused; a callback replayed twice writes one row and one last_seen_job value.

Verification

• node --test test/securityFindings.test.ts passes, and the regression assertion is red at 67d1c9a3 because the table does not exist.
• /repos/:id lists the four states and /repos/:id/jobs/:jobId shows the findings the job touched; npm run check passes.

Not in this card

• Slice 2 — reading the ids from GitHub's code-scanning alerts (or the SARIF the gate already parses) instead of trusting the report, and reconciling the two sources.
• Slice 3 — a regressed finding blocks auto-merge until a human re-confirms, and an accepted finding carries an expiry that reopens it.

Scope and tier

src/lib/securityFindings.ts (new), src/db.ts (one table), src/jobs/service.ts (write inside the terminal transition), src/app.ts (the dismiss route), src/views/pages.ts, test/securityFindings.test.ts, docs/security.md. T3 (src/db, src/jobs), PASS at the tip.

Non-goals

• No new scanner and no automatic code fix.
• No global cross-repository finding database; the ledger is per repository and never exposes another user's findings.
• No replacement for the existing CodeQL/dependency gates; this adds memory to them.

This card closes when slice 1 merges; the named later slices will be filed from this body, one card each, when it does.

References

• arXiv:2611.14164 — An Empirical Study on CVE-based Vulnerabilities Propagation from one System to another System (IntraProject vs InterProject) (Akram et al., 2026).
• arXiv:2611.13960 — From Attack Surface to Defense Architecture: Compositional Security for Agentic Coding Harnesses (Hegelich et al., 2026).