In February 2024, the National Vulnerability Database quietly stopped keeping pace with its own workload. NIST had been enriching every new CVE with a CVSS score and affected-product data since 2005, but a mix of budget constraints and rising submission volume left tens of thousands of records sitting in an "awaiting analysis" queue for months. Security teams that had spent a decade treating the NVD feed as gospel suddenly had to ask a more basic question: what actually is a CVE, who decides it deserves a number, and who decides how dangerous it is? Those are three separate processes run by three different organizations, and conflating them is why so many teams misjudge risk. This piece walks through the CVE lifecycle end to end — identification, numbering, and scoring — and compares how JFrog Xray and Safeguard each turn that raw data into something a developer can act on.
What Is a CVE?
A CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to a specific, publicly disclosed software or hardware flaw — nothing more. The format is CVE-YYYY-NNNNN, such as CVE-2021-44228 (Log4Shell), where the year reflects assignment, not necessarily disclosure. The CVE Program was launched by MITRE in 1999 with an initial list of 321 entries, back when security teams had no shared vocabulary for vulnerabilities and the same bug might be tracked under five different vendor names. Today MITRE operates the program under a contract with the U.S. Cybersecurity and Infrastructure Security Agency (CISA), and the list has grown past 240,000 published records as of 2025. A CVE ID by itself carries no severity information — it's a dictionary entry, not a risk score. That distinction matters because a huge share of vulnerability-management confusion comes from treating "it has a CVE" as equivalent to "it's dangerous."
Who Assigns a CVE Number?
CVE IDs are assigned by CVE Numbering Authorities (CNAs), a distributed network of over 400 organizations authorized by MITRE, not by MITRE itself for most modern disclosures. Vendors like Microsoft, Google, Red Hat, and JFrog are CNAs for their own products, meaning JFrog can mint CVE IDs directly for vulnerabilities discovered in Artifactory or Xray without waiting on MITRE's root CNA team. This model was expanded deliberately: in 1999 there were effectively zero third-party CNAs, and by 2016 there were only around 40. The growth to 400+ CNAs by 2024 was a direct response to bottlenecks — a single central authority couldn't process disclosures fast enough as software supply chains exploded in size. A researcher or vendor requests an ID, provides a description and affected version range, and MITRE publishes the record to cve.org. Only after that does the vulnerability get picked up for scoring, which is a completely separate step run by a different body.
How Does a Vulnerability Get Scored?
Vulnerabilities are scored using the Common Vulnerability Scoring System (CVSS), a 0.0–10.0 severity scale maintained by FIRST.org and applied to CVEs primarily by NIST's National Vulnerability Database. CVSS has gone through four major revisions — v2 in 2007, v3.0 in 2015, v3.1 in 2019, and v4.0 in November 2023 — each one adjusting how factors like attack complexity, privileges required, and scope are weighted. Log4Shell (CVE-2021-44228), disclosed December 9, 2021, received a CVSS v3.1 base score of 10.0, the maximum possible, because it allowed unauthenticated remote code execution over network access with no user interaction. Compare that to a typical local denial-of-service bug, which might score in the 4.0–5.5 range under the same rubric. The score is calculated from a formula applied to eight base metrics, not assigned subjectively, which is why the same CVE can carry an identical base score across every vendor's dashboard even when their prioritization logic diverges afterward.
Why Do CVE and CVSS Data Sometimes Disappear or Lag?
CVE and CVSS data lags or goes missing when the enrichment pipeline — not the identification pipeline — falls behind, and NIST's NVD backlog starting in February 2024 is the clearest recent example. MITRE kept assigning and publishing new CVE IDs on schedule throughout 2024, but NIST's analysts, who add the CVSS score, CWE classification, and affected product list (CPEs) to each entry, fell behind by tens of thousands of records at peak. Some organizations reported over 50% of new 2024 CVEs sitting unanalyzed for weeks. In 2024 alone, more than 40,000 new CVEs were published, up from roughly 29,000 in 2023 — a jump large enough that even a fully staffed NVD would have strained to keep enrichment current. Teams relying on a single feed for both identification and scoring inherited that lag directly, sometimes shipping code against a "clean" scan simply because the CVE's severity data hadn't posted yet, not because the vulnerability wasn't real.
How Do Tools Like JFrog Xray Use CVE Data?
JFrog Xray consumes CVE identifiers and CVSS scores from NVD and other public feeds, then layers in proprietary research from the JFrog Security Research team to fill gaps and add earlier detection. This is a sensible model — public CVE and CVSS data alone is necessarily reactive, since a CVE can't be assigned before a flaw is known and disclosed, and NVD enrichment can trail assignment by weeks. JFrog's approach adds analyst-driven advisories for artifacts scanned inside Artifactory, and its CNA status lets it publish CVEs for its own products faster than routing through a third party. The tradeoff is that JFrog Xray's severity view is tied closely to the binary artifact repository model: it scores what's stored in Artifactory, mapped against dependency trees, which is powerful for JFrog-centric pipelines but requires the rest of your toolchain to either live inside that ecosystem or reconcile a second source of truth for anything scanned elsewhere — source repos, containers built outside Artifactory, or infrastructure-as-code.
Does a High CVSS Score Always Mean High Priority?
No — a high CVSS score tells you a vulnerability is theoretically severe, not that it's currently exploitable or reachable in your environment, and treating the two as equivalent is one of the most common vulnerability-management mistakes. CISA's Known Exploited Vulnerabilities (KEV) catalog, launched in November 2021, exists specifically because of this gap: as of 2025 it lists over 1,300 CVEs that are confirmed to be under active exploitation, and a meaningful share of them carry CVSS scores below 7.0, while plenty of CVSS 9.0+ entries have never been observed in an actual attack. A 9.8-scored deserialization bug in a library your code never calls is lower real-world risk than a 6.5-scored flaw in an internet-facing endpoint attackers are actively probing. Effective prioritization requires combining the CVE's base score with exploitability signals — KEV listing, EPSS probability-of-exploitation scores, and whether the vulnerable code path is actually reachable in your build — rather than sorting a scanner's output purely by CVSS number.
How Safeguard Helps
Safeguard treats CVE and CVSS data as one input among several, not the final verdict. Every CVE surfaced across your software supply chain — dependencies, containers, build pipelines, and artifacts — is automatically cross-referenced against CISA's KEV catalog and EPSS exploitability scores, so a CVSS 6.8 with active exploitation in the wild is flagged ahead of a CVSS 9.5 sitting in unreachable code. Reachability analysis narrows findings further by checking whether your application actually calls the vulnerable function, cutting the noise that makes teams numb to alerts in the first place. Because Safeguard ingests CVE records directly from MITRE and NVD rather than depending on a single vendor's enrichment queue, findings aren't held hostage to backlog periods like the one NVD experienced through 2024 — Safeguard's own research pipeline fills scoring gaps in the interim. And unlike artifact-repository-centric scanners, Safeguard maps CVEs across your entire pipeline — source, build, and runtime — giving you one severity view instead of reconciling scores across tools. The result is a prioritized queue based on what's actually exploitable and reachable in your systems, not just what has the highest number attached to it.