FAQ

Yes, a CVSS score can evolve over time, especially if new information emerges. For example, a public exploit, a patch bypass, or evidence of active exploitation can lead analysts to revise the temporal score or even the base vector if an initial assessment error is detected.

In addition, 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 are using EPSS as a primary criterion for deciding which vulnerabilities to patch first, especially when faced with a large volume of vulnerabilities to address. Patching all CVEs with a high CVSS score can be costly and inefficient, especially if some are never exploited. EPSS therefore makes it possible to focus resources on truly dangerous vulnerabilities.

Some security policies now incorporate action thresholds based on EPSS, for example: “patch any vulnerability with an EPSS score > 0.7 within 48 hours”. This pragmatic approach accelerates remediation where it is most useful, while limiting unjustified interruptions.

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

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

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

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

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

It is therefore essential not only to consult the CVE, but also to check the recommendations of the vendors and databases such as the NVD or the KEV database, which can indicate whether a patch exists and within what timeframe it is expected. Good risk management takes into account both the severity of the vulnerability and the availability of solutions.

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

They also allow for the establishment of risk profiles for projects or products, based on the nature and number of weaknesses identified. This facilitates decision-making for CISOs, CIOs, or compliance managers, particularly in DevSecOps approaches or during evaluations according to frameworks such as NIST or ISO 27002.

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

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

CWEs are abstract patterns of weaknesses, whereas CVEs are concrete incidents. A CVE represents an identified vulnerability in a specific software or system, while a CWE describes a generic weakness present in the code or architecture, without necessarily being exploited.

For example, a CVE might concern 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 vulnerabilities, while CVEs allow you to track and fix them individually.

Exploiting a zero-day vulnerability relies on developing a specific exploit, meaning code or a method capable of leveraging the flaw before it is patched. The attacker can integrate it into a booby-trapped document, a website, malware, or a phishing email.

Once the exploit is launched, it can allow the attacker to take control of the system, install a Trojan horse, open a backdoor, or extract data. The particularity of a zero-day exploit is that it evades traditional detection mechanisms because it relies on a weakness that is still unknown to everyone.

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

This complementarity is valuable for risk management: a flaw may be critical according to CVSS, but not exploited (low EPSS score), or conversely appear benign in theory, but be heavily used in automated attacks. Using both scores together allows for establishing more relevant priorities that align with real-world conditions.

For CISOs and SOC teams, EPSS offers objective and dynamic decision support. It allows filtering vulnerabilities detected by scanners based on their probability of exploitation, which reduces the workload of teams and improves the relevance of alerts. EPSS is particularly useful in environments where the volume of CVEs is high and resources are limited.

By integrating EPSS into vulnerability management tools, SIEMs, or security dashboards, CISOs can better communicate with management by prioritizing actions based on real and measurable risk, rather than a simple theoretical score.

The process of publishing a CVE generally begins with the submission of a vulnerability report to a CNA or directly to MITRE. If the flaw is recognized as legitimate, a CVE identifier is reserved. At this stage, the CVE may remain "reserved" for some time, pending technical validation, agreement from the parties involved, or the availability of a fix.

Once all information has been verified, the CVE is made public via the official MITRE website (cve.org) and other platforms such as NVD (National Vulnerability Database) or CVE Find. It includes a short technical description of the vulnerability, the publication date, the 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, a change in the attack landscape (exploit publication, forum discussion, detection in honeypots) can cause the probability of a CVE being targeted to vary.

This frequent updating makes EPSS a more reactive tool than CVSS, whose scores rarely change once published. To take full advantage of EPSS, it is therefore recommended to integrate automated feeds or APIs to track scores continuously.

To determine if a CVE is actively exploited, several information sources can be consulted. The most reliable is the KEV (Known Exploited Vulnerabilities) database maintained by the CISA, which lists CVEs whose exploitation has been confirmed in the wild. It is updated regularly and often used to establish remediation priorities. This information is directly accessible on our website CVE Find.

You can also rely on the EPSS score, which estimates the probability of a CVE being exploited within 30 days of its publication, based on real data. Finally, threat intelligence tools, CERT reports, or vendor security bulletins can also indicate whether a vulnerability is currently being used by attackers.

Yes, there is an official CVSS score calculator provided by the Forum of Incident Response and Security Teams (FIRST), which maintains the CVSS standard. It is accessible online at: https://www.first.org/cvss/calculator.

This calculator allows you to compose a vector by selecting the relevant metrics, and then automatically calculate the scores (base, temporal, environmental).