A dependency-CVE false positive is a factual question — is the installed version
actually in the advisory's affected range? — not a code-reasoning one. Today
create_dependency_report files whatever the agent passes; an agent can report a
CVE against a version that's already patched past the range, or mis-attribute a
CVE to the wrong package. This adds an opt-in deterministic check (no LLM) right
before the dependency report is persisted, as a sibling of the existing
dedup-reject: ask an advisory provider which advisories affect the exact installed
version; if the cited CVE/GHSA isn't among them, reject the finding as out-of-range.
- strix/report/dep_verify.py: AdvisoryProvider protocol + OsvProvider (OSV.dev
/v1/query). No new dependency — uses requests (already core).
- Provider-pluggable via DepVerifySettings: STRIX_DEP_VERIFY (default off),
STRIX_DEP_VERIFY_PROVIDER (osv|none), STRIX_OSV_URL (point at a self-hosted OSV
mirror for air-gapped / data-residency deployments — identical query contract).
- Fail-open + asymmetric (never suppress a real finding): rejects ONLY on a
definitive, non-empty provider answer that omits the cited advisory. Provider
unreachable/error, empty result (coverage gap), missing fields, non-CVE/GHSA id,
unknown ecosystem -> emit.
- Off by default; when disabled the dependency path is unchanged.
Tests inject a fake provider (no network) + cover provider resolution and the OSV
response parse. 16 tests.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
1b850d3f6c