> ## Documentation Index > Fetch the complete documentation index at: https://support.telivy.com/llms.txt > Use this file to discover all available pages before exploring further. # Vulnerability Data Sources > Where the CVEs in your client's findings come from, how Telivy decides which ones actually matter, and what to tell a partner who asks. When a Telivy assessment lands a long list of CVEs in front of a client, the first question a careful MSP will get back is: *"where is that data coming from, and why should I trust the prioritization?"* This page is the answer you can hand to a partner, a CIO doing vendor due diligence, or your own tech who wants to know what's behind the dashboard. *** ## What this is Telivy doesn't rely on a single CVE feed. The platform combines an **authoritative vulnerability catalog**, **scan-time correlation against what's actually running in your client's environment**, and an **exploit-likelihood signal** so findings reflect real-world risk, not just whatever has the highest CVSS score on paper. Three data sources back every CVE you see in a Telivy report: | Source | What it provides | Where it lives | | --------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------- | | **CVE Program (cvelistV5)** | The authoritative CVE catalog: every CVE ID, description, affected products, references | Telivy's vulnerability database | | **Vulners (via Nmap)** | Maps a fingerprinted service or software version to the CVEs that affect it | Scan-time correlation | | **EPSS** | A daily-refreshed score predicting how likely each CVE is to be exploited in the next 30 days | Per-CVE prioritization signal | Plus, for context, finding details link out to **NVD** (`nvd.nist.gov`) so a partner or auditor can read the public write-up without leaving a citation trail through Telivy. *** ## Why it matters to MSPs A weak vulnerability data set produces three predictable failures, and your client will notice all of them: * **Stale or partial CVE data → missed findings.** If the catalog is days behind or only covers a vendor subset, a recently-disclosed exploit won't appear in the scan, and your tech walks into the QBR claiming a clean room that isn't. * **CVSS-only ranking → wasted Tuesdays.** A client environment of 200 endpoints can easily show 4,000+ open CVEs after a deep scan. Without an exploitability signal, your tech ends up patching 9.8s that nobody is exploiting and missing 7.2s that are actively being weaponized. * **No traceable source → losing the trust conversation.** "Telivy says it's a problem" is not a defensible answer when a CIO asks where the finding came from. *"It's a CVE Program record, correlated to your running version of OpenSSH, with an EPSS score in the top 1% of likely-to-be-exploited CVEs"* is. When a partner asks, frame it like this: *"Our platform pulls from the same authoritative feeds NVD itself ingests from, then layers an exploit-likelihood model so we tell you what to fix this week, not what to argue about next quarter."* *** ## How it works ### 1. The authoritative catalog: CVE Program (cvelistV5) Telivy syncs the **official CVE Program 5.0 JSON feed**, published by the CVE Numbering Authorities through MITRE, into its own vulnerability database. This is the same upstream source NVD ingests from. The sync runs nightly. Every published CVE includes: * The CVE ID and description * Affected products and versions (CPE-style identifiers) * CVSS v2 and v3 metrics * Public references (vendor advisories, exploit databases, write-ups) * Publication and last-modified timestamps **What this means in practice:** when a CVE is published or updated by its CNA, it's reflected in Telivy on the next nightly sync. Your client's findings track upstream CVE Program changes within 24 hours. ### 2. Scan-time correlation: Vulners Knowing what CVEs *exist* is half the job. Knowing which ones apply to *your client's environment* is the other half. When Telivy's network or agent scanner identifies a running service or installed software (say, OpenSSH 7.2p2 on a Linux box, or an outdated version of Apache on an internal web server), that fingerprint is matched against the **Vulners** correlation database (executed via the Nmap `vulners` script). Vulners maps the specific software/version to the CVEs that affect it, and includes signal about whether public exploits exist (Metasploit modules, ExploitDB entries, etc.). **What this means in practice:** you don't get a list of every CVE that could possibly affect any vendor. You get the list of CVEs that affect the *exact* software your scanner found running. ### 3. Exploit prioritization: EPSS Once Telivy knows which CVEs apply, the next question is: *which of these is actually being exploited in the wild?* **EPSS (Exploit Prediction Scoring System)** is a daily-refreshed model that scores every CVE on a 0–1 scale representing the probability the CVE will be exploited in the next 30 days. Telivy pulls the EPSS dataset on a daily schedule and stores the score per CVE. EPSS scores feed into Telivy's prioritization so your tech can sort findings by what's *likely to be hit*, not just by CVSS severity. A CVSS 9.8 with an EPSS of 0.001 is a very different problem than a CVSS 7.5 with an EPSS of 0.94. ### 4. Reference linking: NVD When a partner clicks into a finding, Telivy links the CVE detail page on **NVD** (`nvd.nist.gov/vuln/detail/CVE-...`). NVD is used here as a **reference and citation source** for human readers, not as the bulk data feed Telivy ingests from. *** ## How MSPs use this in practice: Analyze → Prioritize → Commit **Analyze.** Open the vulnerabilities view for the assessment. The full list is the *catalog hits*: every CVE that maps to something running in the environment. Don't try to remediate the whole list. **Prioritize.** Sort by EPSS score, not raw CVSS. Filter to CVEs above the EPSS percentile threshold your client's risk appetite supports (a common cutoff is the top 10% of likely-to-be-exploited CVEs). Pair that with affected-asset count: a high-EPSS CVE on 40 endpoints is a different conversation than the same CVE on a single decommissioned VM. **Commit.** Push remediation through your standard patch workflow. When the next scan runs, Telivy correlates again against the upstream catalog, and remediated findings close automatically, with no manual reconciliation needed. *** ## Example scenario A 60-employee professional services firm runs its first Telivy Risk Assessment as part of their MSP's onboarding. The deep scan returns: * **3,200 catalog hits** across 78 endpoints (every CVE that maps to running software) * **47 hits with EPSS > 0.5** (CVEs the model predicts have at least a 50% chance of being exploited in the next 30 days) * **9 hits with EPSS > 0.9** concentrated on three machines: an unpatched developer laptop, a forgotten file server, and a printer running a 4-year-old firmware The MSP doesn't quote a 3,200-finding remediation project. They show the SMB owner a one-page summary: *"You have nine vulnerabilities that, statistically, are very likely to be hit in the next month, and they all live on three machines. We can clear them this week."* That's the conversation that gets approved. The other 3,191 findings move into a defined patching cadence and stop being a wall of red text in the QBR deck. *** ## Key value delivered * **Revenue:** A defensible prioritization story makes ongoing patch management an obvious recurring service line, not a one-time project. * **Risk reduction:** Patching the EPSS top-decile shrinks the realistic attack surface far more than chasing CVSS for its own sake. * **Client communication:** "Our prioritization is based on the same exploit-prediction model the federal government and major insurers use." * **Operational efficiency:** Your tech doesn't burn a day on CVEs nobody is exploiting. *** ## Common misunderstandings **"Telivy uses the NVD API."** Not as the bulk feed. Telivy ingests the upstream **CVE Program (cvelistV5)** JSON, which is the same source NVD ingests from. NVD is used for the human-readable detail link on each finding. The practical difference: Telivy's data is not gated by NVD's enrichment pipeline, so newly-published CVEs appear in Telivy on the next nightly sync regardless of NVD's enrichment status. **"Higher CVSS = higher priority."** CVSS describes the *worst case if exploited*. EPSS describes the *likelihood of exploitation*. A CVE can be CVSS 9.8 and EPSS 0.001. Terrifying in theory, virtually never seen in the wild. Use both signals; lead with EPSS for prioritization. **"If a CVE isn't in Telivy, my client isn't affected."** Coverage tracks the CVE Program upstream. If a CVE is published but the affected product isn't running on a system Telivy scans, you won't see a finding, by design. If you suspect a missed correlation (e.g., a known-vulnerable service that didn't generate a finding), check whether the asset was reachable during the scan window and whether the agent fingerprinted the service version correctly. *** ## Quick summary Telivy combines the authoritative CVE Program catalog, scan-time Vulners correlation against your client's actual running software, and the EPSS exploit-prediction model to produce a vulnerability list that's both complete and actually prioritizable. Lead client conversations with EPSS-driven priority, not CVSS counts, and your remediation work will be the conversation that gets funded.