Skip to main content
Cyber Risk Council
Category: Vulnerability & Exposure Management

Common Vulnerabilities and Exposures

Also known as: CVE, CVE list, CVE identifier, CVE entry
Simply put

Common Vulnerabilities and Exposures (CVE) is a publicly available list that identifies and catalogs known security flaws in software and systems. Each entry is given a unique identification number, a short description, and at least one public reference, so that different organizations and tools can refer to the same vulnerability in a consistent way. It functions as a shared naming system rather than as a database of fixes or a measure of how severe or exploitable a given flaw is.

Formal definition

CVE is a publicly disclosed catalog of information security vulnerabilities, maintained by the MITRE Corporation, in which each entry contains a unique identification number, a description, and at least one public reference for a publicly known vulnerability. CVE provides standardized identifiers that allow vulnerability data to be correlated across scanners, advisories, threat intelligence feeds, and remediation workflows. A CVE record identifies and describes a vulnerability but does not by itself convey exploitability, prioritization, or severity scoring; those are typically supplied by separate resources such as severity scoring systems or exploitation catalogs (for example, CISA's Known Exploited Vulnerabilities Catalog, which flags CVEs observed to be actively exploited).

Why it matters

CVE addresses a foundational coordination problem in security: without a shared naming system, the same software flaw can be described in many different ways across vendors, scanners, advisories, and threat intelligence feeds, making it difficult to confirm that two parties are discussing the same issue. By assigning each publicly known vulnerability a unique identifier with a description and at least one public reference, CVE lets organizations, tools, and researchers correlate vulnerability information consistently. For security leaders, this shared language underpins nearly every downstream vulnerability management activity, from scanning and triage to reporting and remediation tracking.

A critical point for buyers and executives is that a CVE identifier tells you a vulnerability exists and how to refer to it, but it does not by itself indicate how severe, exploitable, or urgent the flaw is. Those judgments come from separate resources, such as severity scoring systems or exploitation catalogs. For example, CISA's Known Exploited Vulnerabilities Catalog flags specific CVEs, such as CVE-2022-0995, an out-of-bounds write vulnerability in the Linux Kernel, that have been observed as actively exploited. Treating a CVE record as a self-contained measure of risk is a common mistake; the identifier is a reference point, not a prioritization decision.

Because of this, security leadership value lies in interpreting CVE data in the context of a specific organization: which affected systems are actually in use, whether compensating controls exist, and how a given vulnerability maps to real business risk. A virtual or fractional CISO typically helps establish the governance and process around this interpretation rather than performing hands-on scanning or patching, and the effectiveness of any CVE-driven program depends on organizational maturity, asset visibility, and cooperation from the teams that operate the affected systems.

Who it's relevant to

Virtual and fractional CISOs
Security leaders delivering vCISO or fractional engagements use CVE as the common reference language for governing vulnerability management programs, defining triage and remediation processes, and reporting risk to stakeholders. They typically advise and direct how CVE data is prioritized in context rather than performing hands-on scanning, patching, or tool administration, which usually remain out of scope unless explicitly contracted. Accountability for acting on identified vulnerabilities generally stays with the client organization.
Security and IT operations teams
Teams that operate affected systems rely on CVE identifiers to correlate findings across scanners and advisories, confirm they are addressing the same flaw, and track remediation. Their ability to act on CVE data depends on asset visibility and knowing which affected software is actually in use, since a CVE alone does not indicate whether a given system is at risk.
Threat intelligence and vulnerability analysts
Analysts use CVE identifiers to link vulnerability records to external context, including severity scoring systems and exploitation catalogs such as CISA's Known Exploited Vulnerabilities Catalog. This lets them distinguish flaws that are merely cataloged from those observed to be actively exploited and prioritize accordingly.
Executives and risk owners
Officers and business leaders who hold organizational accountability for security decisions benefit from CVE as a consistent way to understand and discuss known vulnerabilities. They should recognize that a CVE identifier is a naming reference, not a measure of severity or business risk, and that interpreting its relevance to the organization requires additional context and leadership judgment.

Inside CVE

CVE Identifier
A unique, structured label (in the CVE-YYYY-NNNNN format) assigned to a single publicly disclosed vulnerability so it can be referenced consistently across tools, vendors, and advisories.
Vulnerability Description
A brief record describing the nature of the flaw and the affected product or component, intended to identify the vulnerability rather than to provide a full remediation guide.
CVE Numbering Authority (CNA)
An authorized organization, often a vendor or research entity, permitted to assign CVE identifiers within its defined scope as part of a coordinated program.
References
Links to related advisories, vendor bulletins, or additional sources that provide further context, though the depth and availability of these references may vary by record.
Relationship to Severity Scoring
CVE identifiers are frequently paired with separate scoring systems that estimate severity and exploitability, but the CVE identifier itself does not convey a severity rating.

Common questions

Answers to the questions practitioners most commonly ask about CVE.

Does a CVE identifier mean a vulnerability is actively being exploited or that my organization is at immediate risk?
No, and this is a common misconception. A CVE identifier is simply a standardized, unique reference for a publicly disclosed vulnerability or exposure; it exists to give the industry a common naming convention so that different tools, vendors, and teams can refer to the same issue consistently. The existence of a CVE says nothing on its own about whether the vulnerability is being exploited in the wild, whether it applies to your specific environment, or how severe the risk is for you. Exploitation status and severity are assessed separately, often using scoring systems and threat intelligence sources. A virtual CISO typically helps a client interpret which published CVEs are actually relevant to their asset inventory and risk context rather than treating every CVE as an emergency.
Is a CVE the same thing as a vulnerability scan finding or a CVSS score?
They are related but not the same, and conflating them is a mistake an experienced practitioner would correct. A CVE is the identifier and catalog entry for a known vulnerability. A CVSS score is a separate rating that attempts to express severity characteristics of that vulnerability. A vulnerability scan finding is the output of a tool detecting a potentially affected condition in your environment, and it may reference one or more CVEs. In practice, a scanner may report a CVE that does not actually apply to your configuration, or may miss context that changes real-world risk. A virtual CISO generally advises on how these inputs feed into a prioritization and remediation process rather than treating a scan finding as a final verdict.
How does a virtual CISO typically use CVE information within a security program?
In many engagements, a virtual CISO uses CVE information as an input to vulnerability management and risk prioritization rather than as a standalone deliverable. This often includes helping the organization establish a process to track relevant CVEs against its asset inventory, define severity and exposure criteria, and set remediation expectations. It is worth noting that the vCISO usually advises and directs this process at a governance and strategy level; hands-on scanning, patch deployment, and tool administration are typically performed by internal teams or other providers unless explicitly contracted.
Who is accountable for acting on CVEs identified during a vCISO engagement?
Responsibility and accountability should be distinguished here. A virtual CISO advises on which CVEs warrant attention and recommends prioritization and remediation approaches, but legal and organizational accountability for acting on those findings generally remains with the client organization and its officers. The value of CVE-related guidance depends heavily on the client's cooperation, the maturity of its asset management, and its willingness to allocate resources to remediation. A vCISO does not typically assume liability for unremediated vulnerabilities unless a contract specifies otherwise.
How should we prioritize which CVEs to remediate first?
Prioritization typically depends on more than the CVE itself. Factors often considered include whether the affected system exists in your environment, its exposure and business criticality, available severity scoring, known exploitation activity, and the presence of compensating controls. A virtual CISO can help establish criteria and a repeatable process for this, but the appropriate approach may vary by provider and by organizational maturity. Value here depends on having a reasonably accurate asset inventory, without which CVE prioritization becomes difficult.
How do CVEs relate to compliance frameworks such as PCI DSS, SOC 2, or ISO 27001?
Several frameworks expect organizations to maintain a vulnerability management process, and CVE tracking often supports that expectation. However, tracking CVEs does not by itself guarantee compliance or certification. A virtual CISO can help build vulnerability management practices that support readiness for these frameworks, but supporting readiness is distinct from asserting that certification or compliance has been achieved, which depends on formal assessment and the full set of applicable requirements.

Common misconceptions

A CVE identifier tells you how dangerous a vulnerability is.
A CVE is a naming and cataloging mechanism, not a severity rating. Severity and exploitability are typically assessed through separate scoring systems and contextual analysis, which is where a virtual CISO often helps a client prioritize based on their specific environment and business risk.
Once a vulnerability has a CVE, it is fixed or a patch automatically exists.
A CVE simply names and tracks a disclosed flaw. Remediation, mitigation, or patching is a separate process that depends on vendor action and the client organization's own patch management and cooperation. Assigning an identifier does not resolve the underlying weakness.
Managing CVEs is a purely technical, hands-on task the vCISO performs directly.
In most engagements a virtual CISO provides governance, prioritization strategy, and executive guidance on vulnerability management rather than performing hands-on scanning, tool administration, or patch deployment. Those operational tasks are typically out of scope unless explicitly contracted, and accountability for acting on findings generally remains with the client organization.

Best practices

Treat CVE identifiers as a common reference language, not a prioritization system; pair each identified CVE with separate severity and exploitability context before deciding what to remediate first.
Prioritize CVEs based on the client's specific environment, asset exposure, and business risk rather than on identifier count alone, since organizational maturity and context heavily influence what matters.
Establish a defined vulnerability management process that clarifies who is responsible for scanning and patching and who is accountable for accepting or mitigating risk, keeping in mind that accountability typically remains with the client organization.
Use CVE references to feed governance conversations and executive reporting, translating technical findings into business risk language for leadership and stakeholders.
Confirm scope explicitly in any engagement so that hands-on remediation, tool administration, and incident response are only assumed when contracted, and are otherwise recognized as out of scope for a typical virtual CISO role.
Cross-reference CVEs against relevant compliance objectives (such as those under frameworks like PCI DSS or HIPAA) to support readiness, while avoiding any implication that tracking CVEs alone guarantees compliance or certification.