FAQ

The CVE publication process usually starts with a vulnerability report submitted to a CNA or directly to MITRE. If the flaw is confirmed to be legitimate, a CVE identifier is reserved. At this stage, the CVE may remain "reserved" for some time, pending technical validation, agreement from involved parties, or availability of a fix.

Once all the information is verified, the CVE is made public through MITRE’s official website (cve.org) and other platforms such as the NVD (National Vulnerability Database) or CVE Find. It includes a short technical description, publication date, affected products, and sometimes references to patches or security advisories.

CVEs play a central role in vulnerability management. They provide a common language for all cybersecurity stakeholders to track and document flaws, enabling prioritization of patches, automation of analysis, and structured threat monitoring. Without CVEs, each vendor or researcher might describe a flaw differently, making coordination difficult.

They are also used by vulnerability scanners, SIEMs, SOCs, and CISOs to establish incident response policies. Their global adoption ensures that flaws are identifiable and that defenses can be activated more quickly and in a coordinated manner.

Yes, a CVSS score can evolve over time, especially when new information emerges. For example, a public exploit, a patch bypass, or confirmed active exploitation may lead analysts to revise the temporal score or even the base vector if an error was identified in the initial assessment.

Moreover, automated tools like those from the NVD regularly update CVSS scores based on field data and publications. It is therefore recommended that companies periodically revalidate their analyses, especially for critical vulnerabilities.

CVE identifiers are assigned by a U.S. non-profit organization called the MITRE Corporation, which manages the CVE program on behalf of the Cybersecurity and Infrastructure Security Agency (CISA). MITRE does not assign all identifiers itself: it relies on a network of partners known as CNAs (CVE Numbering Authorities).

A CNA can be a software vendor, a security provider, a CERT, or an organization specializing in vulnerabilities. Each CNA is authorized to assign CVE identifiers for vulnerabilities discovered in its own products or scope. This system speeds up the disclosure process while maintaining a centralized structure via MITRE.

No, CVEs do not only apply to software. They can also cover vulnerabilities in hardware, firmware, IoT components, operating systems, or even insecure default configurations. For example, flaws in routers, processors, or industrial equipment can also receive CVE identifiers.

This broad coverage allows for consideration of the various attack vectors in a modern information system. The key is that the vulnerability must be documented, confirmed, and publicly reported to be included in the CVE program. This enables security teams to assess risks across the entire infrastructure.

CVSS is divided into three sub-scores:

• Base score: evaluates the intrinsic severity of the vulnerability, regardless of context. It is usually public.
• Temporal score: adjusts the rating based on factors such as exploit availability or the existence of a patch. It reflects the maturity of the threat.
• Environmental score: allows organizations to adapt the evaluation to their own context (asset importance, exposure, business impact). It is customized for each company.

By combining these three layers, the CVSS model becomes a more flexible tool for refining remediation priorities based on real-world conditions.

A CVE is simply a public declaration that a flaw exists in a given product, whereas an exploited vulnerability means that an attacker is actively using that flaw to compromise systems. In other words, not all CVEs are exploited in real-world conditions—some may remain theoretical or technical.

Conversely, a vulnerability can be exploited without yet having received a CVE—this is known as a zero-day. To assess the real danger of a CVE, one should consult additional information such as CISA’s KEV data or the EPSS score, which indicate whether the flaw is actively used in cyberattacks. This information is available directly on our CVEFind website.

The CVSS scale ranges from 0.0 to 10.0, and each range is associated with a severity level:

• 0.0: None
• 0.1 to 3.9: Low
• 4.0 to 6.9: Medium
• 7.0 to 8.9: High
• 9.0 to 10.0: Critical

This classification allows organizations to filter vulnerabilities by severity, but it does not consider the specific context of each company. That’s why other criteria, such as active exploitation or the affected assets, should be included in the evaluation.

No, the existence of a CVE does not guarantee that a fix is available. A CVE may be published before a vendor has developed a fix, or even in cases where no fix is planned (e.g., for obsolete or unsupported software). In such situations, users must implement workarounds or disable certain vulnerable features.

It is therefore essential not to rely solely on CVEs, but also to check vendor advisories and databases like the NVD or the KEV list, which may indicate whether a patch exists and when it is expected. Good risk management takes into account both the severity of the flaw and the availability of solutions.

Yes, there is an official CVSS score calculator provided by the FIRST standards forum, which maintains the CVSS standard. It is available online at: https://www.first.org/cvss/calculator.

This calculator allows users to build a vector by selecting the relevant metrics, then automatically calculates the scores (base, temporal, environmental).

The CVSS (Common Vulnerability Scoring System) measures the severity of a vulnerability by assigning it a score from 0 to 10, where 10 represents an extremely critical flaw. It is designed to provide a standardized and objective evaluation of vulnerabilities so that organizations can compare and prioritize them accordingly.

This score takes into account several aspects: ease of exploitation, potential effects on confidentiality, integrity and availability, as well as the conditions required to carry out the attack. In summary, CVSS helps quantify the inherent danger level of a security flaw.

A CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to a known vulnerability in an information system, software, or hardware. It allows a flaw to be named and tracked precisely, even when addressed by different vendors, tools, or databases. Each CVE follows the format CVE-year-number, such as CVE-2023-12345.

The purpose of CVEs is to standardize communication about security flaws: instead of using inconsistent descriptions, all stakeholders can refer to the same identifier. This makes coordination easier between researchers, software vendors, security teams, and solution providers.

The CVSS score measures the intrinsic severity of a vulnerability, but not its actual exploitation or relevance in a specific environment. For example, a vulnerability may have a high score but be hard to exploit in your infrastructure, or conversely, a medium-score flaw might target a critical, unsegmented system.

To assess risk more accurately, it's important to include complementary indicators such as:

• The EPSS score (probability of actual exploitation)
• Inclusion in the KEV list (confirmed exploitation)
• The business or technical context of the affected environment

Thus, CVSS should be viewed as an indicator of severity, not a complete risk assessment.

CAPEC attack patterns are used to document the tactics and techniques used by attackers to exploit systems. By studying them, security analysts, developers, and architects can understand the goals of an attack, its typical steps, and the vulnerabilities being exploited. This helps anticipate threats and design more effective countermeasures.

They are also useful for training, risk analysis, attack simulation (red teaming), and implementing defensive security controls. By linking CAPEC to CWE and CVE, one can build a complete chain from weakness to real-world exploitation, enriching threat modeling and security-by-design approaches.

A CVE (Common Vulnerabilities and Exposures) is a security flaw that has been publicly identified, documented, and published in an official database. It is known and, in most cases, a patch is available or in progress. A zero-day, on the other hand, is a flaw that has not yet been disclosed, and therefore is not listed as a CVE at the time of discovery.

In short, every zero-day can become a CVE, but not all CVEs are zero-days. The main risk with zero-days is that they are exploitable before any public awareness, whereas CVEs are typically already under analysis or remediation.