X
Modern applications are built from hundreds of open-source and third-party libraries, and each one carries its own history of security flaws. Every year, tens of thousands of new software vulnerabilities are disclosed publicly, and security teams are expected to track, assess and remediate all of them across every application they run. The system that makes this even possible is CVE.
But cataloging a vulnerability is not the same as knowing whether it puts an organization at risk. As disclosure-to-exploit timelines shrink and AI tools make it faster to weaponize a known flaw, understanding what a CVE actually tells you, and what it does not, has become essential to running an effective application security program.
CVE stands for Common Vulnerabilities and Exposures. It is a standardized identifier assigned to a publicly known cybersecurity vulnerability, maintained by the MITRE Corporation under funding from the U.S. Department of Homeland Security. Each CVE record identifies a specific flaw in a specific piece of software and assigns a unique reference number, so security teams, vendors and researchers across the industry can discuss the same vulnerability using the same name.
A CVE identifier follows the format CVE-YYYY-NNNNN, where the year reflects when the ID was assigned (not necessarily when the flaw was found), and the trailing digits identify the specific record. CVE-2021-44228, for example, is the identifier assigned to Log4Shell, the remote code execution flaw in the Log4j logging library.
Without CVE, two security vendors could describe the same vulnerability in incompatible terms, and a patch note referencing “an authentication bypass” would leave a security team guessing whether it applies to their environment. CVE turns vulnerability disclosure into a shared vocabulary.
A vulnerability becomes a CVE through a structured assignment process, not automatically the moment it is discovered. Organizations authorized to issue CVE identifiers are called CVE Numbering Authorities (CNAs). CNAs include major software vendors, open-source foundations, security research firms and bug bounty platforms, each typically responsible for vulnerabilities in their own products or research domain.
When a researcher or vendor identifies a flaw, they submit it to the relevant CNA along with details of the affected software, versions, and technical description. The CNA assigns a CVE identifier and publishes a CVE record. The National Vulnerability Database (NVD) then enriches the record with a severity score, weakness classification and affected product configurations.
Three pieces of information typically travel with a CVE record:
A CVE record answers one question: Does this specific flaw exist in this specific software? A CVSS score answers a related but different question: how severe would this flaw be if exploited, under the worst reasonable conditions.
That distinction matters more than it might seem. CVSS scores are calculated from the vulnerability's technical characteristics, things like whether it requires authentication, whether it can be triggered remotely, and what it grants an attacker who succeeds. What a CVSS score cannot tell a security team is whether the vulnerable code actually runs in their specific application, in their specific environment, under real production traffic.
A library can carry a critical, 9.8-out-of-10 CVSS score and never execute a single line of the vulnerable function in a given deployment, because the application never calls that code path. Conversely, a moderate-severity CVE in a function that runs on every request carries real, active risk. CVSS describes the vulnerability in the abstract. It says nothing about whether an attacker can actually reach it in your running application.
CVE was built to solve a naming and disclosure problem, not a prioritization problem, and that gap has widened as the volume of published vulnerabilities has grown. Security teams tracking CVEs across a modern application portfolio run into several structural limits:
The limitations above have pushed security teams toward a more targeted question than “which CVEs exist in our dependencies.” The better question is: which of those CVEs are actually reachable, actively executing, and worth immediate attention.
Answering that requires visibility from inside the running application, not just a scan of its build manifest. Instrumentation embedded in the application at runtime can observe which libraries are genuinely loaded and executed under real traffic, distinguishing code that is present but dormant from code that runs constantly. That distinction lets a team separate the CVEs that represent theoretical risk from the ones representing genuine, active exposure, and focus remediation effort accordingly.
This same runtime vantage point extends naturally to detection. An application instrumented at this level can observe not just which vulnerable code executes, but when an attacker attempts to trigger it, giving security teams evidence of active exploitation attempts rather than a static list of what might be exploitable.
Contrast Security's application security platform builds on this principle. Contrast SCA identifies open-source vulnerabilities and confirms which ones are active in a running application, while Contrast ADR detects and responds to attacks against production applications from inside the application itself. Together, they give security teams a way to move past CVE counts and toward evidence of what is actually at risk and what is actually under attack.
