We bring public security records into one place, keep their sources attached, and connect related CVEs, products, advisories, actors, campaigns, and ransomware activity. This page explains what comes from a source, what SecurityAlert adds, and where the limits are.
Different sources answer different questions. We do not treat a probability score, a vendor bulletin, and a criminal group's claim as equivalent evidence.
NVD provides CVE descriptions, CVSS data, affected configurations, references, and record history. CISA KEV identifies vulnerabilities with evidence of exploitation. FIRST EPSS estimates the probability of exploitation in the next 30 days.
We collect bulletins from vendor-operated security pages and feeds. The vendor remains the authority for affected versions, workarounds, patches, and later revisions. SecurityAlert makes those fields searchable and comparable.
MITRE ATT&CK supplies documented group names, aliases, software, and techniques. We add cited public reporting, reviewed name mappings, ransomware operators, victim claims, indicators, campaigns, and CVE relationships.
Leak-site posts show what an operator has claimed. They do not independently prove an intrusion, payment, or the scope of stolen data. We preserve the claim date and group identity and label the record accordingly.
Collected headlines and short excerpts retain the publisher, original URL, publication time, and collection time. Readers are sent to the publisher for the full story. SecurityAlert research is kept separate from collected reporting.
Our scanners and indexes contribute first-party observations such as domain registration, DNS, certificate, website, and monitored asset evidence. We identify an observation as ours and retain when it was collected.
We retain the source URL, published or observed date, source identifiers, and the fields available when the record was collected.
Vendor names, product families, CVE IDs, actor names, sectors, and dates are converted into consistent fields. The original bulletin or report stays linked.
A CVE can link to an official advisory, affected product, actor, campaign, ATT&CK technique, and SecurityAlert research. Each relationship keeps its own source.
Actor aliases, rebrands, disputed attribution, and research assertions are not silently merged. We keep uncertain relationships separate and show confidence where it changes how the record should be read.
Collectors revisit sources on schedules suited to each feed. Public catalog pages show source freshness or record dates where available, and vendor revision history begins when we start following a bulletin.
The record came from the organization responsible for it, such as a vendor bulletin or a CISA catalog entry.
A named publisher or researcher made the connection. SecurityAlert preserves that attribution but does not present it as independently confirmed.
SecurityAlert reviewed the cited material and recorded an assessment. The supporting sources and any material caveat remain part of the record.
An actor or ransomware operator published the statement. A claim is useful intelligence, but it is not the same as independent verification.
A CVE or vendor advisory can show that a product may be affected. It cannot prove that the vulnerable product and version are installed in your environment. Confirm against your own inventory before making an exposure decision.
NVD records, EPSS scores, vendor bulletins, actor assessments, and ransomware claims can all change. Where a source exposes revision dates, we retain them. Collection timestamps state when SecurityAlert last saw the record, not when the underlying event necessarily occurred.
If you find an incorrect relationship, stale source, or misleading description, email support@securityalert.ai with the page URL and supporting source. We review corrections against the underlying record.
Public intelligence is available as browsable pages and through documented feeds and interfaces. Tenant findings and customer data remain behind authentication and scoped permissions.