Transparent by design
CVE data sources and matching methodology
VulniPulse organises security advisories for defensive prioritisation. It does not replace vendor guidance. Every remediation decision should be confirmed against the linked source.
1. Source hierarchy
We prioritise official vendor PSIRT, security advisory, CNA, CSAF, RSS and documented API sources across 32 enabled vendors. CVE.org, CISA KEV and NVD can enrich identifiers, exploitation and scoring context. Secondary lifecycle data is labelled and cannot override an official vendor statement.
2. Ingestion and change tracking
Sources are polled automatically and records are normalised into a common advisory model. We retain vendor advisory IDs, CVEs, products, affected and fixed releases, severity, publication dates and source URLs where supplied. Changed advisories are reprocessed so corrections and new fixes can flow through matching.
3. Product and platform matching
Vendor names and product aliases are mapped to canonical categories—for example, FortiGate guidance may map to FortiOS, and vSphere Hypervisor guidance may map to ESXi. Vendor watches match the full vendor feed; platform watches require a canonical platform signal. Ambiguous product evidence is not promoted to a precise match.
4. Version evidence
Exact-version checks use vendor APIs where a documented integration exists, such as Cisco PSIRT openVuln for supported software families. Other products combine parsed vendor advisory ranges, recognised release catalogs and lifecycle context. A missing affected-version range is unknown—not proof that a release is safe.
5. Confidence and safe failure
A confirmed affected result requires compatible product evidence and a defensible version comparison. Unparseable or incomplete release data is surfaced for review. Products with no held advisory evidence receive a no-data state instead of a green all-clear.
6. Prioritisation
VulniPulse surfaces vendor severity, CVSS when supplied, CISA KEV membership, exploitation evidence, fix availability and end-of-support state. Operators should combine those signals with internet exposure, asset criticality, compensating controls and change risk.
7. Alert delivery
After a newly ingested advisory matches an active rule, VulniPulse queues the enabled email, push or Discord delivery path. Delivery time depends on source publication, polling, matching and the downstream provider; no page should be interpreted as a delivery-time SLA.
8. Corrections and limitations
Vendor pages, APIs and release formats change. Some vendors expose complete machine-readable catalogs; others publish product-specific tables or gated portals. Coverage labels and source links make those differences visible. Use the Suggestions page to report a missing platform, incorrect match or stale source.
Need the operational workflow?
Read the practical guide to inventory, monitor, prioritise and route CVEs across multiple vendors.
How to monitor CVEs across multiple vendors →