Corroborated Security Advisories
One package, one paid call: every GHSA advisory naming it, each cross-checked against authoritative databases by deterministic code, never by model opinion.
What this feed claims, verbatim: Affected package corroborated against authoritative OSV, plus deterministic KEV/EPSS/CVSS/SSVC enrichment joined by a verbatim-verified CVE id. We do NOT verify the advisory exploitation or severity claims; GHSA prose does not make them.
The shape of the problem: a security agent that ingests a single advisory and acts on it has no cheap way to know whether the named package matches the authoritative ecosystem record, or whether the CVE it is keying on is even real. The fix is cross-source corroboration, done deterministically: the model extracts named fields verbatim, then pure code makes every judgment. No model opinion is in the verdict, so there is nothing for the agent to re-check.
How it works
1. Verbatim extraction
A grammar-constrained local model copies named fields out of the GHSA advisory prose exactly as written. It never infers, normalizes, or judges. Every CVE id is checked to literally appear in the advisory text; a fabricated or cross-advisory-bled id is dropped by construction.
2. Deterministic corroboration
Pure code checks the advisory affected package against the ecosystem-precise OSV record for that advisory, with a never-false-confirm matcher: only a clean token-subset confirms, ambiguity stays novel. NVD CPE applicability lists are context only, never match authority.
3. Enrichment by verified CVE id
KEV (CISA known-exploited), EPSS percentile, and SSVC are joined onto the advisory only by a CVE id that was verbatim-verified against the text. This is authoritative data attached deterministically, not a claim the advisory made and not a model judgment.
4. Anti-fabrication quarantine
If a stated severity or exploitation value is not anchored verbatim in its cited sentence, the whole record is excluded from the trusted set rather than served with a possibly-fabricated claim. Quarantined records are never in this feed.
Every advisory is split into three honest buckets
corroborated_claim
The advisory verbatim affected_products and the deterministic product-vs-OSV verdict (never-false-confirm). This is the trust signal.
deterministic_enrichment
KEV / EPSS / SSVC / OSV packages, joined only by a verbatim-verified CVE id. Authoritative data, not an advisory claim, not a model judgment.
verbatim_context
Version ranges, fixed versions, severity and exploitation strings copied verbatim from the advisory. Context only: not corroborated, not a guarantee.
Endpoint
GET /api/premium/security/corroborated?package=$0.02 USDCOne package whole corroborated GHSA advisory set per call. Strict-premium: anonymous probes get the canonical 402, not a free-trial slot. Loose package matching supported. x402 V2 on Base, AFTA-signed receipts.
curl -H 'Authorization: Bearer tf_live_...' \ 'https://tensorfeed.ai/api/premium/security/corroborated?package=free5gc'
Sample shape
{
"ok": true,
"package_query": "free5gc",
"matched_package": "free5GC",
"claim": "Affected package corroborated against authoritative OSV ...",
"advisory_count": 13,
"advisories": [
{
"source_url": "https://github.com/advisories/GHSA-27ph-8q4f-h7m7",
"overall": "corroborated",
"corroborated_claim": {
"affected_products": ["free5GC"],
"product_corroboration": "confirmed"
},
"deterministic_enrichment": {
"cves_verbatim_verified": [],
"kev_listed": false,
"epss_percentile": null,
"ssvc": null,
"osv_packages": ["github.com/free5gc/bsf"]
},
"verbatim_context": {
"affected_version_ranges": ["v4.2.1"],
"fixed_versions": [],
"severity_label": "unstated",
"exploited_in_wild": "unstated"
}
}
],
"billing": { "credits_charged": 1, "credits_remaining": 44 }
}What this is NOT
- Not a verification of the advisory exploitation-in-the-wild or severity claims. GHSA prose does not state them; we never infer them.
- Not the full advisory database. It is a cross-source slice: 82 package-addressable advisories (73 corroborated, 9 novel) across 47 packages, growing as wider backfills land.
- Not padded. 12 product-less unverifiable advisories and 6 quarantined records are excluded from the served counts, not counted to look bigger.
- Not a model opinion. Every verdict is deterministic code over verbatim extraction.
FAQ
What is the corroborated security feed?
A per-package endpoint. You pass ?package=<name> and get every GitHub Security Advisory naming that package, each one already cross-checked. For each advisory: the deterministic verdict of whether its affected package is present in authoritative OSV, plus KEV (CISA known-exploited), EPSS (exploit-probability), and SSVC enrichment attached only by a CVE id that was verbatim-verified against the advisory text. The agent does not have to stitch GHSA, OSV, NVD, KEV and EPSS together itself, and does not have to re-check what was already deterministically corroborated.
Why does this matter? Agents already read advisories.
Reading one advisory and acting is the failure mode. A patch-prioritization or SBOM agent that ingests a single GHSA entry has no cheap way to know whether the named package actually matches the authoritative ecosystem record, or whether the CVE it is keying on is real. Cross-source corroboration is the fix, and it has to be deterministic: the model extracts named fields verbatim, then pure code makes every judgment. No model opinion is in the verdict.
What exactly do you corroborate, and what do you not?
We corroborate the advisory affected package against authoritative OSV with a never-false-confirm matcher (ambiguous resolves to novel, never to a fabricated confirm). We enrich with KEV/EPSS/CVSS/SSVC joined only by a CVE id that literally appears in the advisory text. We do NOT verify the advisory exploitation-in-the-wild or severity claims: GHSA prose does not state them, the model is not allowed to infer them, and a fabricated or unanchored severity is quarantined rather than served. The honest claim is carried verbatim in the response so a consumer cannot misread the scope.
How big is the dataset and how honest are the counts?
This is a cross-source slice, not the full advisory database. The served set is 82 package-addressable advisories across 47 packages: 73 corroborated and 9 novel against authoritative OSV. 12 trusted advisories named no package and are unverifiable, so they are not retrievable by package and are deliberately excluded from the served counts rather than padded in. 6 records were quarantined by the anti-fabrication gate and are never served. The dataset grows as wider backfills land; the counts in the response always describe exactly what you can retrieve.
What is the never-false-confirm guarantee?
The product matcher only confirms when one token set is a clean subset of the other against the ecosystem-precise OSV record for that advisory. Partial overlap stays novel. NVD CPE applicability lists (which for famous CVEs enumerate every product that bundles a dependency) are treated as context only, never as match authority, because token-subset against that noise would false-confirm at scale. Across the production batch, zero false-confirms.
How do I integrate it?
GET /api/premium/security/corroborated?package=<name>, 1 credit ($0.02 USDC on Base) per call, x402 V2 and AFTA-signed receipts. Strict-premium: anonymous probes get the canonical 402 challenge, not a free-trial slot. Loose package matching is supported (package=commons-text resolves to the canonical name). Bundled and served with zero KV and zero upstream calls at request time; the extraction, deterministic corroboration, and verbatim-CVE guard all run offline.
Related: the free cross-source news Verified Feed applies the same single-source-is-the-failure-mode thesis to AI news, and /api/security/kev is the free CISA known-exploited catalog.