What it means
A CVE identifier gives people and tools a shared reference for a vulnerability, usually written as CVE followed by a year and a sequence number. The associated record describes the issue and points to supporting information, often including affected products and versions. The identifier is not a severity score, proof that your installation is affected, or a patch. Records can be updated, reserved before disclosure, or rejected. Use the record alongside the product maintainer’s advisory and your own inventory to establish applicability.
The idea at a glance / Vulnerabilities
Use the identifier to join the right records.
A CVE identifier connects evidence about one vulnerability. Applicability still depends on the actual component, version, and conditions.
CVE-2021-44228 is a real Apache Log4j2 record. G71 and R71 are synthetic applications: G71’s selected inventory includes log4j-core 2.14.1; R71’s complete fixture inventory has log4j-api 2.14.1 alone, with no log4j-core. These are assumed inventory records, not a live scan.
READ THE PICTURE
Read the evidence and its limits
The same CVE identifier connects Apache’s public record and advisory. G71 contains the affected component/version, but needs runtime checks. R71 has only log4j-api; Apache says that component alone is not affected by this issue. One identifier does not make both applications equally affected.
Keep in mindThe identifier supplies no severity, repair, or local incident verdict. G71 still needs its running build and affected conditions checked. R71’s negative conclusion is limited to this CVE and the assumed complete fixture inventory; it does not establish that the application has no other weaknesses.
Read the complete example
- Read the evidence and its limits. The same CVE identifier connects Apache’s public record and advisory. G71 contains the affected component/version, but needs runtime checks. R71 has only log4j-api; Apache says that component alone is not affected by this issue. One identifier does not make both applications equally affected. The published record is CVE-2021-44228, assigned by Apache and published on 2021-12-10. The record status is PUBLISHED in the source snapshot checked on 2026-09-30. Apache’s advisory identifies log4j-core as the affected component and includes 2.14.1 in the affected range; log4j-api alone is not affected by this CVE. For G71, a selected dependency record does not by itself prove which code is running or that attacker-controlled messages can reach the relevant operation. R71’s explicitly complete fictional inventory excludes log4j-core, rather than merely failing to find it in a partial scan. A different logging implementation or another vulnerability requires its own record. CVE IDs join reports; their sequence numbers do not rank severity. Official records and maintainer advice can be revised, so real decisions should preserve their sources and dates. Neither case records a completed fix or investigation.
The identifier supplies no severity, repair, or local incident verdict. G71 still needs its running build and affected conditions checked. R71’s negative conclusion is limited to this CVE and the assumed complete fixture inventory; it does not establish that the application has no other weaknesses.
Diagram references: CVE Program: CVE Record User Guide · CVE Program: CVE-2021-44228 · Apache: Log4j security advisories
AN ILLUSTRATIVE SCENARIO
One record, two different component inventories
CVE-2021-44228 identifies the real Log4j2 issue. In the fictional G71 inventory, log4j-core 2.14.1 is present; an engineer still checks the running artifact and affected conditions. R71’s assumed complete inventory contains only log4j-api, which Apache excludes from this issue. A similar package name would have produced a misleading match. That scoped negative does not establish the absence of other vulnerabilities. The team keeps the identifier, maintainer source, inventory evidence, and unresolved questions together rather than treating the scanner’s label as the complete assessment.
Put it to work
- Find the official CVE record and follow its maintainer references. Note the record status, affected versions, prerequisites, and whether a fix or mitigation is available.
- Map the record to deployed assets, packages, and owners. Distinguish a detected software name from confirmed affected software, and document the evidence for applicability.
- Track remediation by CVE and asset together. Add severity, known exploitation, exposure, and business impact so the identifier becomes a useful link rather than the whole decision.
How to check your work
Select one finding and trace it from official record to maintainer advisory, installed component, assigned owner, and remediation evidence. Another engineer should be able to explain why that particular asset is or is not affected.
Connect the ideas
- Vulnerability
A weakness in a system, process, or person that makes a loss easier to cause.
- CVSS
FIRST’s method for describing characteristics and technical severity of a vulnerability, not a full remediation order.
- KEV
CISA’s catalog of vulnerabilities with evidence of exploitation in the wild.
- Patch
A vendor or internal change that removes or reduces a vulnerability in running software.