How it works
What decides whether you get an email
Severity alone does not qualify. An alert sends automatically only when one of these holds:
- The vulnerability is in the CISA KEV catalog — confirmed exploitation in the wild. This always sends, fix or no fix.
- EPSS puts its 30-day exploitation probability at 10% or higher.
- It scores CVSS 9.0 or above and a fixed version exists and EPSS has not scored it as negligible.
Everything else is recorded and not sent. Each email lists the rules that fired for the items in it, so you can check our reasoning rather than take our word for it.
Platform incidents are reviewed by a human
Hosting and SaaS disclosures have no CVE, no CVSS and no EPSS — there is nothing to score. We poll official vendor feeds and status pages, and a person reads anything security-relevant before it goes out. Automated judgement of a vendor blog post is exactly how you end up misreporting someone's breach, so we do not do it.
Where the data comes from
- OSV.dev — package matching. We send your ecosystem, package name and version; OSV returns the advisories affecting that exact version. Version comparison rules differ per ecosystem and OSV maintains them properly.
- CISA KEV — exploitation evidence, and the source for stack-level alerts.
- FIRST EPSS — exploitation probability.
- GitHub Advisory Database — reached through OSV, which ingests it.
- Vendor feeds — official security blogs and status pages for platform incidents.
Accuracy limits we will not paper over
- Lockfiles beat manifests. A lockfile gives the resolved dependency tree, which we use.
package.jsonholds ranges, which we resolve to the range floor and label lower-confidence. - No reachability analysis. We cannot tell whether your code calls the vulnerable function.
- CVSS v4 vectors are not scored numerically; those advisories fall back to their severity label.