security gate is blind to GHSA-only advisories: cargo audit reports clean over a live CVE

[noahgift]

Summary

The fleet's security gate is cargo audit (sovereign-ci.yml:1191, job security).
cargo audit and cargo deny check advisories both read the RustSec advisory DB.
GitHub's Dependabot reads the GitHub Advisory Database (GHSA). These are different
databases, and RustSec is not a superset.

Where GHSA has an entry and RustSec does not, our required security check reports
green over a live, GitHub-confirmed vulnerability.

Witness (reproducible today)

pmat, release/3.32.0, commit 419360b6f:

$ gh api repos/paiml/paiml-mcp-agent-toolkit/dependabot/alerts/66 \
    --jq '[.state,.security_advisory.severity,.security_advisory.ghsa_id,.dependency.package.name]'
["open","medium","GHSA-2f9f-gq7v-9h6m","thrift"]
   CVE-2026-43868 — Apache Thrift: Memory Allocation with Excessive Size Value
   vulnerable: thrift < 0.23.0     present: thrift 0.17.0

$ cargo deny check advisories
advisories ok                      # <-- the gate

$ git -C ~/.cargo/advisory-db log -1 --format='%h %ci'
69f93e1d 2026-08-12 12:42:29 +0200 # DB is fresh, not stale

$ git -C ~/.cargo/advisory-db grep -il thrift -- crates
                                   # <-- no output. No thrift advisory exists in RustSec at all.
$ git -C ~/.cargo/advisory-db grep -rl CVE-2026-43868
                                   # <-- no output.

So this is not a stale-DB problem and not a misconfigured-ignore problem
(deny.toml's ignore list does not mention thrift). RustSec simply has no entry.
cargo audit uses the same DB, so the CI gate is blind by construction.

Open Dependabot alerts on pmat: 1. Advisories reported by the gate: 0.

Five whys

1. Why did a live medium CVE pass the security gate? — cargo audit reported clean.
2. Why did cargo audit report clean? — the RustSec DB has no advisory for thrift.
3. Why does RustSec have no advisory? — CVE-2026-43868 was filed against Apache Thrift
   upstream; GitHub maps it onto the thrift crate via its ecosystem mapping, RustSec
   has no such automatic mapping and depends on a volunteer filing a per-crate advisory.
4. Why does the gate depend on a single DB? — the gate was specified as a tool
   (cargo audit) rather than as a property ("no known-vulnerable dependency"),
   so its coverage was never stated and therefore never checked.
5. Root cause — the gate reports the result of one query and we read it as the
   answer to a broader question. There is no denominator: advisories ok looks
   identical whether the DB has 700 relevant advisories or none for your tree.
   Same family as #1016 (cargo deny licenses+sources suppressed fleet-wide) —
   absence rendered as success.

Proposed fix

Add a second, independent source to the security job so the two DBs cover each
other. GitHub's own alerts are the cheapest option — zero new tooling, no new
dependency, and it is the DB that already caught this:

- name: Dependabot alerts (GHSA — covers what RustSec lacks)
  env: { GH_TOKEN: "${{ secrets.GITHUB_TOKEN }}" }
  run: |
    # cargo audit reads RustSec; this reads GHSA. Neither is a superset of the
    # other — see paiml/.github#<this issue> for a live case (thrift/CVE-2026-43868).
    alerts=$(gh api --paginate \
      "repos/${GITHUB_REPOSITORY}/dependabot/alerts?state=open&severity=high,critical" \
      --jq '.[] | [.security_advisory.ghsa_id, .dependency.package.name] | @tsv')
    if [ -n "$alerts" ]; then
      echo "::error::open high/critical Dependabot alerts:"; echo "$alerts"; exit 1
    fi
    echo "no open high/critical Dependabot alerts"

Needs security-events: read (or contents: read + repo scope) on the job.
Threshold set at high/critical so it can be turned on fleet-wide without
immediately reddening every repo; medium stays advisory-only for now.

Verify the gate is real before merging (per the dogfood protocol): confirm it
goes RED on a repo with a known open high alert and GREEN on one without, and
record both in the PR. A security gate nobody has watched fail is exactly the
thing this issue is about.

Separate, downstream fix for the thrift exposure itself

thrift 0.17.0 reaches us as parquet 57.3.1 -> aprender-db -> {aprender-graph, aprender-rag}.
parquet 59.2.0 removed the thrift dependency entirely (arrow-rs replaced it with an
in-tree codec) — verified against the crates.io dependency API. So the fix is an
arrow/parquet 57 -> 59 bump in aprender-db, not anything in pmat. Filed separately.

Risk to pmat specifically is low (the vuln is oversized-allocation on parsing attacker-
controlled parquet metadata; pmat parses no untrusted parquet), but the gate being blind
is the finding, not this particular crate.

[noahgift]

A concrete, currently-live instance

Measured today on paiml/paiml-mcp-agent-toolkit at e5e421db0:

source	verdict
GitHub Dependabot	1 open moderate alert — GHSA-2f9f-gq7v-9h6m / CVE-2026-43868, "Apache Thrift has a Memory Allocation with Excessive Size Value Vulnerability", thrift v0.17.0, manifest Cargo.lock
cargo deny check advisories	rc=0, 0 errors

This is not a misconfiguration and not a suppression:

• deny.toml has no ignore entry for it (the file's 10 ignores are all RUSTSEC-*).
• ~/.cargo/advisory-db/crates/thrift does not exist — RustSec carries no advisory for this crate at all.

cargo-deny cannot suppress what it has never heard of. The advisories family is backed by RustSec, so an advisory that exists only as a GHSA/CVE is structurally invisible to it, and to cargo audit, which reads the same database.

Dependency path:

thrift v0.17.0
└── parquet v57.3.1
    └── aprender-db v0.61.0
        ├── aprender-graph v0.61.0 → pmat
        ├── aprender-rag v0.61.0   → pmat
        └── (via aprender-viz)     → pmat

Upstream fix tracked in paiml/aprender#2531 (parquet 59 drops thrift).

Why this matters more now

paiml-mcp-agent-toolkit just added a blocking, all-family cargo deny check to a required status check (pmat score), because CB-1701 found that no required check ran one at all. That is a real improvement, and it also means a green supply-chain tick is now being produced by a tool that is blind to this class of advisory. The gate documents the blind spot inline rather than implying coverage it does not have.

Ask

Any repo relying solely on RustSec-backed tooling (cargo deny check advisories, cargo audit) for its supply-chain gate has this hole. A second source that reads GitHub's advisory data — the Dependabot alerts API — is needed to close it.

One design note learned the hard way: such a gate must fail when its API call fails, not skip. A supply-chain check that reports "no alerts" because it could not reach the API is the same defect one level up.