· 6 min read.
The nine feeds, and what each one brings
| Source | What it brings | What it does not tell you | Frequency |
|---|---|---|---|
| CVE List (MITRE) | The primary publication, as the CNA wrote it | No score, no exploitation; sometimes no affected version | Short interval |
| NVD (NIST) | Enrichment: product identifiers, configurations, CVSS vector | Its enrichment has slowed sharply since February 2024 | Daily |
| CISA KEV | Observed exploitation, with its confirmation date | Nothing about exploitation without publishable evidence | Short interval |
| EPSS (FIRST) | The probability of exploitation within 30 days, for every CVE | Nothing about your actual exposure | Daily |
| PoC-in-GitHub | The appearance of public proof-of-concept code | Neither the quality nor the real-world use of that code | Short interval |
| GHSA (GitHub) | Dependency ecosystem advisories: npm, PyPI, Maven… | Software outside package managers | Daily |
| OSV.dev | Linux distribution advisories: Red Hat, SUSE, Ubuntu… | Proprietary products | Daily |
| CERT-FR (ANSSI) | Advisories and alerts from the French national CSIRT, linked to the CVEs they cite; an alert flags an immediate threat, typically a flaw already being exploited | Flaws that get no advisory: CERT-FR chooses what it publishes | Hourly |
| EUVD (ENISA) | The European vulnerability database, provided for by the NIS2 directive, with each flaw's known exploitation status | Nothing about your actual exposure: it lists, it does not sort | Several times a day |
The middle column is the most important one in this table. It shows why cross-checking is not a nicety: a CVE can be published without a score by its CNA, receive a vector from NVD three weeks later, and enter KEV in between. Reading only one source means seeing a snapshot, not the movie.
Nine feeds for alerts, twelve sources for the brief
A common confusion worth clearing up: we work with two sets of sources that differ in both role and number.
- The nine vulnerability feeds above drive the alerts. This is structured data, matched against your inventory.
- The twelve editorial sources — CERT-FR, vendor blogs, trade press — feed the daily brief. These are articles, read and summarized, never matched against an inventory.
CERT-FR appears in both sets, in two roles: its advisories and alerts, linked to the CVEs they cite, feed the alerts; its publication feed also feeds the brief.
A bare number (“our sources”) would mix the two and mean nothing. Nine or twelve, depending on what we are talking about.
What triggers an alert: transitions
A CVE is not an event, it is a trajectory. It is published, then enriched, then sometimes flagged as exploited, then sometimes fixed. Monitoring that only listens for publication misses what matters most.
The transitions we track and that trigger a notification:
- a new CVE affects a component declared in your inventory;
- a CVE you follow enters the KEV catalog, or becomes the subject of a CERT-FR alert;
- a public proof of concept appears;
- its EPSS score crosses a threshold you have set;
- its affected versions change — a CVE ruled out yesterday may concern you today.
Two delays not to confuse
This is the most frequently asked question, and it deserves a two-part answer rather than a single number:
- the synchronization delay: we poll CVE List, KEV, EPSS and proofs of concept at a short interval, on the order of a few minutes. No one can be faster than that cycle;
- the processing delay: once the CVE has been seen, matching against your inventory, prioritization and sending follow immediately, without waiting for a batch job.
In practice, on a critical signal, you are notified within minutes of its publication: the first delay sets the pace, the second simply follows on.
Cross-checking is not enough: filter
Aggregating nine feeds produces an unmanageable volume if you stop there. The step that matters is matching against your declared inventory: vendor, product, version. Anything that touches no line of that inventory drops out of scope, and that is where almost all of the noise disappears.
This matching relies on standardized product identifiers when they exist, and on name-version correspondences when they are missing — which is common, and is precisely why source completeness matters so much to us.
GHSA and OSV advisories without a CVE identifier are matched by package URL (purl) as soon as a version is pinned. They are shown with their identifier and their source. Zero CVEs is not zero risk: 0 CVE ≠ 0 risque.
Licenses & attributions
All the sources we aggregate are public data, free to use, including commercially, subject to attribution. The table below covers the nine alert feeds plus three enrichment datasets: that is why it has twelve rows, not nine.
| Source | License / terms | Attribution |
|---|---|---|
| CVE List (MITRE / CVE.org) | CVE Terms of Use — free redistribution | Required |
| NVD (NIST) | US government work — public domain | Recommended |
| CISA KEV | US government — free to use | Recommended |
| EPSS (FIRST.org) | Free data, provided without warranty | Required (credit FIRST) |
| GHSA (GitHub Security Advisories) | CC BY 4.0 | Required |
| OSV.dev | Open licenses (often CC BY 4.0); may vary by record | Required |
| Red Hat, SUSE, Ubuntu, AlmaLinux, Rocky Linux (via OSV) | CC BY 4.0, CC BY-SA 4.0 (Ubuntu), MIT, BSD depending on the distribution | Required |
| PoC-in-GitHub | Public links and metadata — no exploit code redistributed | Recommended |
| CERT-FR (ANSSI) | Licence Ouverte / Open Licence 2.0 (Etalab) | Required |
| EUVD (ENISA) | Reuse authorized provided the source is acknowledged, unless stated otherwise | Required (credit ENISA) |
| endoflife.date | Open community project, free API | Recommended |
| webappanalyzer (technology detection) | GPL-3.0 (enthec/webappanalyzer) | Required (GPL-3.0 notice kept) |
Previews of monitoring articles show only the title and a short excerpt and always link back to the original source: the full content is never republished.
Details for each source, with the attributions and licence notices, are on the Sources and licences.
Frequently asked questions
Do you cover open source?
Yes, through two channels: GHSA for application dependencies (npm, PyPI, Maven, RubyGems, Go…) and OSV.dev for distribution packages (Red Hat, SUSE, Ubuntu…). These are two separate worlds: the same flaw can carry two different identifiers in them.
Why follow CERT-FR and the EUVD?
Because monitoring that only reads American sources inherits their blind spots. CERT-FR, the French national CSIRT, publishes its advisories and alerts in French; the EUVD, run by ENISA under the NIS2 directive, also flags exploited vulnerabilities. Exploitation reported by either one counts, for prioritization, like an entry in the KEV catalog. See also what our tooling covers for NIS2.
How quickly am I alerted?
Two delays add up. The synchronization polls the feeds at a short interval, on the order of a few minutes: that is the hard floor. The processing — matching, prioritization, sending — follows immediately, with no batch processing. On a critical signal, expect a few minutes after its publication.
Why cross-check several sources?
Because none of them is complete. A record can be published without a score, receive its vector three weeks later and enter the KEV catalog in between. Reading only one source means missing either the flaw or the moment it becomes urgent.
Can I use this data commercially?
Yes. The aggregated feeds are public and free to use, including commercially, subject to attribution (CVE/MITRE, NVD, CISA KEV, FIRST EPSS, GHSA, OSV…). Technology detection relies on webappanalyzer, licensed under GPL-3.0: free to use in a hosted service, provided the license notice is kept.