Skip to main content

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.

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:
SourceWhat it providesWhere it lives
CVE Program (cvelistV5)The authoritative CVE catalog: every CVE ID, description, affected products, referencesTelivy’s vulnerability database
Vulners (via Nmap)Maps a fingerprinted service or software version to the CVEs that affect itScan-time correlation
EPSSA daily-refreshed score predicting how likely each CVE is to be exploited in the next 30 daysPer-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.” That sentence ends a lot of debates.
  • 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.