Threat intelligence
Coverage you can act on. Records you can check.
Authoritative vulnerability and exploitation data on a continuous cycle, alongside the research and advisory reporting your analysts would otherwise be reading themselves - assessed, deduplicated across sources, and attributed back to where it came from.
What follows is what the intelligence covers and what we commit to about it. How any of it is produced is in the technical brief, which goes to evaluators under NDA rather than onto a public page.
Coverage
What comes in, and how often.
Two kinds of input, held to different standards. Authoritative data is treated as data. Reporting is treated as a claim until it has been assessed.
Authoritative data
11 feedsVulnerability records, exploitation status and adversary technique data, refreshed continuously through the day.
- Vulnerability record streams2Full CVE records, CVSS metrics and affected-product ranges
- Exploited-vulnerability catalogues2Confirmed in-the-wild exploitation, read as a union of two catalogues
- Exploitation-probability scoring1Daily probability that a CVE is exploited in the next 30 days
- Public exploit archives1Whether working exploit code exists, and how mature it is
- Adversary technique framework1Techniques, groups and software, synced from the published corpus
- Community malware and C2 trackers4Indicators, malicious URLs, confirmed samples and botnet C2 addresses
Research and reporting
27 sourcesGovernment advisories, vendor research, independent analysis and the security press - assessed rather than republished.
- Government and national advisories5National vulnerability and exploited-vulnerability publications, plus OS and network-vendor security notices
- Vendor threat research9First-party incident and malware research from major security vendors and their research arms
- Independent and community research2Long-running independent analysis and daily community handler diaries
- Security press5Breaking coverage, used for timeliness and cross-checked against everything else
- Exploit and indicator monitoring6Public code-repository monitoring for proof-of-concept exploits, and community indicator trackers
What we commit to
Six things that are true of every record.
These are checkable on day one of an evaluation. If any of them stops being true, that is a defect and we would want to hear about it.
A record names its source
Every record carries where it came from and when. Nothing arrives anonymous, and nothing is aggregated to the point where you cannot get back to the original reporting.
A claim is one the source made
Identifiers, indicators, attributions and dates on a record are ones the source actually contained. Where the source did not support something, it is not on the record - not softened, not hedged, absent.
One event is one record
The same incident reported by a dozen outlets is one record with a dozen references, not a dozen records competing for the same analyst's attention.
Thin data is filed as thin data
A set of indicators with no behaviour and no attribution is indicators. It reaches the indicator feed, where it is useful, rather than being presented as a malware family it is not.
Material items always reach a human
An item significant enough to matter is never discarded quietly. If the platform is not confident enough to publish it, it goes to an analyst queue instead - and if it is rejected, the rejection is recorded with its reason.
Automation can be overruled, on the record
An analyst can publish something the platform declined, or withdraw something it published. What they cannot do is either of those silently: the override and its justification are stored with the record.
On the record
What an analyst actually sees.
The test of an intelligence platform is not how much it holds - it is whether an analyst can decide anything from a single record without opening four other tabs.
So a record carries its own evidence. Not a confidence badge you are asked to trust, but the material behind the assessment, in a form that can be disagreed with.
- Source and date
- Where the claim came from and when it was made
- References
- Every source that reported the same event
- Identifiers
- Vulnerabilities, indicators and techniques carried on the record
- Attribution
- Named groups, and how firmly the reporting supports the link
- Assessment
- Severity and risk, with the parts that produced them
- History
- When it was first seen, what changed since, and who changed it
Ask what it turned down.
Any platform will show you what it published. The more revealing question is what it declined and why - and that is a question this one can answer.