Skip to main content
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 enriched with NVD’s CVSS scoring, scan-time correlation against what’s actually running in your client’s environment, and a multi-signal exploit picture (likelihood, confirmed real-world exploitation, and public exploit code) so findings reflect real-world risk, not just whatever has the highest CVSS score on paper. Six data sources back every CVE you see in a Telivy report: Finding details also 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. CVSS enrichment: NVD

Alongside the CVE Program sync, Telivy ingests the National Vulnerability Database’s full CVE JSON 2.0 feeds directly from NIST. A daily job pulls NVD’s recent and modified feeds to layer CVSS v2/v3/v4 scores and product metadata onto the catalog as soon as NVD publishes them, and a weekly job re-pulls the complete historical feed set as a full resync. What this means in practice: the CVSS scores on your client’s findings come from NVD’s own scoring pipeline, refreshed daily, with a weekly full resync underneath it so nothing drifts out of sync for long. When a partner clicks into a finding, Telivy also links out to that CVE’s detail page on NVD (nvd.nist.gov/vuln/detail/CVE-...) so they can read the public write-up directly.

3. 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.

4. 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.

5. Confirmed exploitation: CISA KEV

EPSS predicts likelihood. The CISA Known Exploited Vulnerabilities (KEV) catalog confirms fact: it’s the U.S. government’s list of CVEs that have been observed being exploited in actual attacks, not just modeled as likely to be. Telivy syncs the full KEV catalog and flags any matching CVE across your client’s findings. What this means in practice: a KEV flag is the strongest exploitability signal Telivy can hand you. It’s not a prediction, it’s confirmation that the vulnerability has already been weaponized in the wild, which makes it very hard for a client to deprioritize.

6. Public exploit availability: ExploitDB

ExploitDB is a curated archive of publicly available exploit code and proof-of-concept attacks. Telivy syncs the ExploitDB index and links matching CVEs in your client’s findings to their known public exploits. What this means in practice: an ExploitDB match means working attack code is already public, which meaningfully lowers the skill and effort required to exploit that CVE. Together, the three exploit signals answer three different questions: EPSS estimates how likely, CISA KEV confirms has it happened, and ExploitDB tells you how easy would it be.

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 only links to NVD; it doesn’t actually ingest their data.” It does both. Telivy ingests the upstream CVE Program (cvelistV5) JSON for catalog data, which is the same source NVD ingests from, so a newly-published CVE appears in Telivy on the next nightly sync regardless of NVD’s own enrichment status. Separately, Telivy also pulls NVD’s full CVE 2.0 JSON feeds directly from NIST (daily for newly published and modified CVEs, weekly for a complete historical resync) to layer in CVSS scoring. The nvd.nist.gov links on each finding are an added convenience for human readers, on top of that ingestion, not a substitute for it. “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 (enriched with NVD’s CVSS scoring), scan-time Vulners correlation against your client’s actual running software, and a three-part exploit signal (EPSS likelihood, CISA KEV confirmed exploitation, and ExploitDB public exploit code) 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.