A CVE vulnerability entry is a uniquely identified, publicly disclosed flaw in a specific piece of software — the CVE ID itself (like CVE-2021-44228, the Log4Shell identifier) is just a name for the flaw, not a measure of how dangerous it is. Severity comes from a separate scoring system, CVSS, layered on top of the CVE record. Understanding that CVE and CVSS are two different things, maintained differently and updated on different schedules, is the single most useful fact for actually using vulnerability data instead of just reading headlines about it.
What actually is a vulnerability in cyber security terms?
A vulnerability in cyber security is a weakness in software, hardware, or configuration that an attacker can exploit to do something the system wasn't supposed to allow — read data they shouldn't see, execute code they shouldn't be able to run, or bypass a control they shouldn't be able to bypass. Not every vulnerability gets a CVE ID; only ones that meet the CVE program's criteria (publicly disclosed, affecting an identifiable product and version, independently fixable) qualify. A weakness in your own internal, non-distributed application code is still a real vulnerability, but it typically won't get a CVE assigned, since there's no separate product/version for other organizations to track against.
Who assigns CVE IDs, and how does lookup actually work?
CVE IDs are assigned by CVE Numbering Authorities (CNAs) — a distributed set of organizations including MITRE, major vendors, and cloud providers, all operating under the CVE Program — and every assigned ID gets published to the central CVE List maintained at cve.org. From there, the U.S. National Vulnerability Database (NVD) enriches each entry with a CVSS score, affected version ranges, and reference links, which is why NVD is usually the practical lookup destination even though CVE assignment itself happens elsewhere. Searching by CVE ID, product name, or vendor at either cve.org or nvd.nist.gov will return the full record: description, affected versions, references, and score.
How does CVSS scoring actually work?
CVSS (Common Vulnerability Scoring System) produces a 0-10 severity score from a set of metrics covering how the vulnerability is exploited (network-reachable versus requiring local access, whether privileges are needed, whether user interaction is required) and what impact a successful exploit has on confidentiality, integrity, and availability. A score of 9.0-10.0 is rated Critical, 7.0-8.9 High, 4.0-6.9 Medium, and 0.1-3.9 Low, under the most commonly used version of the standard. The important nuance: CVSS scores what's technically possible given the vulnerability's characteristics, not what's likely in your specific environment — a 9.8 CVSS score in a library your application never actually calls is a very different practical risk than the same score in a directly internet-facing endpoint.
Why does the same CVE sometimes show different severity in different places?
Because CVSS has multiple versions (2.0, 3.0, 3.1, and the newer 4.0) with different metrics, and different organizations sometimes score the same vulnerability slightly differently, or a vendor's own advisory assigns a score that diverges from NVD's independent scoring based on additional context the vendor has about their specific implementation. It's also common for NVD to lag behind a vendor's own disclosure by hours or days while analysts complete their own scoring, which is why security teams tracking a fast-moving disclosure often check the vendor advisory directly rather than waiting on NVD enrichment.
How should severity scoring actually change what you prioritize?
CVSS alone shouldn't drive prioritization on its own — reachability and exposure should sit alongside it, because a critical-scored vulnerability in a dependency your code never calls is lower real-world risk than a medium-scored one sitting directly on an authenticated API endpoint. This is the gap between raw CVE/CVSS data and an actually useful vulnerability management workflow: scanning tools that just surface CVSS scores tend to produce long, undifferentiated lists, while tools that add reachability analysis and exploit-availability context on top of the score help teams fix the handful that matter first. Safeguard's SCA tooling layers this reachability context on top of raw CVE and CVSS data specifically to close that gap.
FAQ
What's the difference between CVE and CWE?
CVE identifies one specific vulnerability instance in a specific product and version; CWE classifies the general type of weakness (like SQL injection) behind it. A CVE record typically references the CWE category it falls under.
Where's the best place to look up a CVE?
cve.org for the authoritative record and assignment status, and nvd.nist.gov for the enriched entry with CVSS scoring, affected version ranges, and reference links.
Does a high CVSS score always mean urgent action?
Not necessarily on its own — check whether the vulnerable code path is actually reachable in your deployment and whether a public exploit exists, since both materially change real-world urgency beyond the raw score.
Why do some vulnerabilities have no CVE ID at all?
Because CVE assignment requires the flaw to affect an identifiable, distributable product or component. Vulnerabilities found only in bespoke, non-distributed internal application code generally don't qualify for a CVE.