FAQ

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.

Yes, more and more organizations use EPSS as a priority criterion to decide which vulnerabilities to fix first, especially when dealing with a large volume of issues. Fixing all CVEs with a high CVSS score can be costly and inefficient, especially if some are never exploited. EPSS helps focus resources on truly dangerous vulnerabilities.

Some security policies now include EPSS-based thresholds, such as: “fix any vulnerability with an EPSS score > 0.7 within 48 hours.” This pragmatic approach accelerates remediation where it is most useful, while limiting unnecessary interruptions.

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.

No, EPSS does not replace CVSS: the two systems are complementary. CVSS provides a structural measurement of severity, useful for understanding the potential impact of a vulnerability. EPSS, on the other hand, provides a behavioral and predictive measurement, focused on the actual likelihood of exploitation.

Together, these two scores allow for a more accurate risk assessment, both theoretical and operational. Many companies adopt a hybrid approach, for example by only addressing vulnerabilities that have both a CVSS ≥ 7 and an EPSS ≥ 0.5, or by using risk matrices enriched with both indicators.

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.

CWEs are integrated into many source code analysis tools, security audits, or vulnerability management systems to automatically identify potential weaknesses in software. By understanding which CWEs are present in a system, teams can assess the attack surface, anticipate future threats, and prioritize fixes before a weakness becomes an exploitable CVE.

They also help define risk profiles for projects or products based on the nature and number of identified weaknesses. This facilitates decision-making for CISOs, IT managers, or compliance officers, especially in DevSecOps approaches or evaluations aligned with frameworks like NIST or ISO 27002.

CWEs are abstract models of weaknesses, whereas CVEs are concrete incidents. A CVE represents a specific vulnerability identified in a software or system, while a CWE describes a general weakness present in the code or architecture, which is not necessarily exploited.

For example, a CVE might refer to an SQL injection in a web application, while the corresponding CWE would be CWE-89: Improper Neutralization of Special Elements used in an SQL Command. In summary, CWEs are used to categorize and analyze flaws, while CVEs are used to track and fix them individually.

Exploiting a zero-day involves creating a specific exploit, which is code or a method that takes advantage of the flaw before it’s patched. Attackers can deliver it via a malicious document, a compromised website, malware, or a phishing email.

Once triggered, the exploit may take control of the system, install a trojan, open a backdoor, or steal data. What makes zero-day exploits especially dangerous is that they bypass conventional detection tools, leveraging unknown weaknesses.

CAPEC provides a detailed structure to reproduce realistic attack scenarios, making it a valuable resource for simulations. Each pattern describes the prerequisites, execution steps, targets, attack vectors, and the potential goals of the attacker. This helps security teams design well-structured red teaming or threat modeling exercises.

For example, a tester might choose a CAPEC pattern for brute-force attacks on a network service and use it as a basis to assess an application's robustness. This approach makes testing more consistent and facilitates the documentation of results and recommendations.

EPSS complements CVSS by adding a temporal and behavioral dimension to vulnerability assessment. CVSS measures the severity of a flaw based on intrinsic properties (impact, complexity, accessibility), but says nothing about the actual likelihood of exploitation. EPSS fills this gap by analyzing real-world data, such as trends observed in honeypots, vulnerability search engines, or threat intelligence feeds.

This complementarity is valuable for risk management: a flaw may be critical according to CVSS but unexploited (low EPSS), or appear mild in theory but widely used in automated attacks. Using both scores together helps define more relevant and grounded priorities.

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.

EPSS scores are updated daily, reflecting the dynamic nature of threats and vulnerability exploitation. At any time, changes in the threat landscape (exploit releases, forum discussions, honeypot detections) can alter the likelihood of a CVE being targeted.

This frequent updating makes EPSS a more responsive tool than CVSS, whose scores rarely change once published. To fully benefit from EPSS, it is recommended to integrate automated feeds or APIs to continuously track scores.

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).

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.

CAPEC stands for Common Attack Pattern Enumeration and Classification. It is a structured knowledge base developed by MITRE that catalogs and describes known attack patterns used against information systems. Unlike isolated incidents, CAPEC outlines reusable strategies that attackers can use to exploit vulnerabilities.

Each CAPEC pattern is an abstract representation of malicious behavior: it explains how an attack is carried out, what type of weakness it targets, and the attacker’s objective. The goal of CAPEC is to help security professionals better understand, detect, and anticipate adversarial tactics.