A CVE identified but without an available patch is especially dangerous. Example: Log4Shell was discovered and patched quickly, but organisations that did not update for weeks were attacked. Monitoring vulnerabilities without known patches is critical.
What is CVE
CVE (Common Vulnerabilities and Exposures) is a standardised unique identifier for publicly known security vulnerabilities. Examples: CVE-2021-44228 (Log4Shell, critical vulnerability in Log4j library), CVE-2020-1938 (flaw in Apache Tomcat). Each CVE has a unique number (year-sequential: CVE-2021-44228 is vulnerability 44,228 from 2021), description, affected systems, severity (CVSS), and links to patches. The CVE database (National Vulnerability Database - NVD) is maintained by NIST and is the public registry of vulnerabilities. For a CISO, knowing relevant CVEs and prioritising patches is a critical function: a known and actively exploitable vulnerability like Log4Shell requires immediate action.
Why it matters
For a CISO, CVE is the common language of vulnerabilities. When someone says 'we are affected by CVE-2021-44228', everyone understands exactly what vulnerability that is. Without CVE, each vendor would use different names (Log4Shell vs. Log4j Deserialization RCE), causing confusion. CVEs enable: (1) Automation: tools scan software looking for known CVEs, (2) Prioritisation: CVEs have CVSS scores that help decide urgency, (3) Shared intelligence: if a CVE is being actively exploited, organisations learn quickly. The typical cycle is: vulnerability is discovered, CVE is assigned, published in NVD, vendor creates patch, scanner detects your version is vulnerable, your team prioritises the patch. Without this system, each organisation would operate in isolation.
Key points
CVEs exist that are 'known but unexploited' (few attacks) versus 'known and actively exploited' (frequent attacks). Your prioritisation must consider both: technical severity (CVSS) + threat intelligence (is it being exploited?).
Not all CVEs affect your infrastructure. A vulnerability in a PHP library does not affect you if you do not use PHP. Automation (scanners) detects which CVEs are relevant for your specific stack.
The number of CVEs grows exponentially. Dozens of public CVEs each day. Reviewing them all manually is infeasible. Automation + threat intelligence to filter what is critical for you is the only way.
Example: response to critical CVE (Log4Shell)
December 2021: CVE-2021-44228 (Log4Shell) is discovered in Log4j, a ubiquitous logging library used in millions of applications. CVSS severity 10 (maximum). Remotely exploitable without authentication. Affects: Java applications, web servers (Apache, Tomcat), cloud services. Day 1: CVE is published, NVD assigns CVSS 10. Threat intelligence: active attacks on the internet, botnets attempting to exploit. A CISO implements: (1) Immediate scan: identifies which applications use Log4j and which versions. Discovers 15 affected applications. (2) Prioritisation: 5 are critical (internet-facing), 10 are internal. (3) Urgent patching: the 5 critical ones patched in 4 hours. (4) The 10 internal ones patched in 24 hours. (5) Post-patch verification: confirmation that patch worked. (6) Audit: checking logs for exploitation before the patch. Without automation and clear prioritisation, the response would be chaotic: 'we have 1000 components, which are affected? We do not know, let me check manually.' The breach would occur within hours.
Common mistakes
- Trying to 'monitor' all published CVEs without prioritisation. Dozens are published daily. Most do not affect you. Use tools to filter: scan which CVEs affect YOUR stack, not the entire internet.
- Assuming CVSS is the only metric for prioritisation. CVSS 10 is serious, but a CVE with CVSS 6 actively exploited is more urgent than CVSS 10 theoretical without attacks. Combine CVSS + threat intelligence.
- Not differentiating between 'CVE discovered' vs. 'CVE patch available'. A vulnerability without a patch requires mitigation controls (segregation, WAF, behaviour monitoring). Waiting indefinitely for a patch is not an option.
- Negligence post-patch. After applying a patch, many organisations assume the problem is solved without verifying that the patch was applied correctly and that the vulnerability is not already being exploited in logs.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
What does the number in a CVE mean (for example, CVE-2021-44228)?
CVE-YYYY-NNNNN where YYYY is the publication year and NNNNN is the sequential number. CVE-2021-44228 means published in 2021 and was vulnerability 44,228 of that year. The number does not indicate severity or importance, only unique identification.
Where can I find information about a specific CVE?
National Vulnerability Database (NVD - nvd.nist.gov) is NIST's official database. You will find description, CVSS, affected systems, references to patches. You can also use cve.mitre.org which is the official CVE registry.
What is the difference between CVE, CVSS and CWE?
CVE identifies a specific vulnerability. CVSS rates severity (0-10). CWE is the category of flaw (Cross-Site Scripting is CWE-79). A CVE has a CVSS score and corresponds to one or more CWE categories.
How long do I have to patch a critical CVE?
CISA (Cybersecurity and Infrastructure Security Agency) recommends 6 hours for critical CVEs actively exploited, 24 hours for critical CVEs without active exploitation. In practice, it depends on system criticality: internet-facing critical component, patch in 4-6 hours; internal system, can wait 48 hours.