FAQ

The CWE classification serves to standardize the understanding of security weaknesses in computer systems. It helps developers, testers, and analysts identify common design or coding errors, in order to avoid or correct them more effectively. Thanks to this taxonomy, security tools can produce consistent and actionable reports.

It is also very useful for training technical teams, evaluating detection tools, prioritizing risks, and complying with certain standards such as ISO/IEC 27001. By integrating CWEs into development processes, security can be significantly improved from the design phase.

The CVSS scale ranges from 0.0 to 10.0, and each value 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 take into account the specific context of each company. That's why other criteria, such as active exploitation or the assets involved, should complement this assessment.

CVE identifiers are assigned by a US 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 distribute all identifiers alone: it relies on a network of partners called CNAs (CVE Numbering Authorities).

A CNA can be a software publisher, a security vendor, a CERT, or an organization specializing in vulnerabilities. Each CNA is authorized to assign CVE identifiers for vulnerabilities discovered in its own products or within its scope. This system accelerates the reporting of vulnerabilities while maintaining a centralized structure via MITRE.

The CVSS score is generally defined by the organization that publishes the vulnerability, often a CNA (CVE Numbering Authority) or the software vendor concerned. In addition, entities such as the NVD (National Vulnerability Database) sometimes recalculate or adjust scores to ensure consistency between published CVEs.

Automated tools also allow independent researchers, SOC analysts, or security vendors to recalculate a score based on the published CVSS vector. This means that the same CVE can have several slightly different scores depending on the context and the evaluator, which encourages cross-referencing sources for critical decisions.

The EPSS model is developed and maintained by the FIRST (Forum of Incident Response and Security Teams) community, in collaboration with researchers, data analysts, and cybersecurity professionals. It is an open and collaborative project, with publicly documented methods and regularly updated results.

This model is based on massive statistical data and machine learning techniques. It is designed to be transparent, reproducible, and freely accessible, making it a reliable tool suitable for the operational needs of security teams, even outside the American or governmental scope.

The CWE list is maintained by the MITRE Corporation, the same organization that manages the CVE program. MITRE is supported by the U.S. Department of Homeland Security (DHS) and other public and private stakeholders to develop and update this knowledge base.

The community also plays a key role: researchers, publishers, governments, and industry professionals can propose new weaknesses, suggest modifications, or share feedback on the usefulness of existing entries. The database is public, freely accessible online, and continuously enriched to reflect the evolution of technologies and attack techniques.

Cybersecurity professionals are the primary users of CAPECs: SOC analysts, penetration testing experts, security architects, developers, trainers, or threat intelligence teams. They use them to understand adversary tactics, prepare test scenarios, and strengthen defenses.

For example, a pentester can use a CAPEC to structure a simulated attack according to a realistic scenario. A developer can find guidance on design flaws to avoid. A CISO can integrate them into risk analyses to better illustrate the potential consequences of a technical weakness.

CVEs play a central role in vulnerability management. They provide a common language for all cybersecurity stakeholders to track and document vulnerabilities, which allows for prioritizing patches, automating analyses, and structuring security monitoring. Without CVEs, each vendor or researcher could describe a vulnerability differently, making coordination complex.

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

The KEV (Known Exploited Vulnerabilities) list published by CISA identifies vulnerabilities that are actively exploited in the wild, meaning they are already being used in real-world cyberattacks. The purpose of this list is to help organizations prioritize their remediation efforts by focusing on vulnerabilities that pose an immediate threat.

By publishing this list, CISA provides a very practical risk management tool: it identifies not only known vulnerabilities, but also the most critical and urgent ones. For U.S. federal agencies, patching these vulnerabilities is mandatory within strict deadlines. But beyond the United States, the KEV is widely consulted by cybersecurity professionals worldwide to guide their patch management strategy.

Zero-day vulnerabilities are particularly dangerous because they are unknown to vendors, users, and often traditional security solutions (antivirus, IDS, etc.). This means that there is no fix, no patch, and often no detection or protection mechanism at the time of the attack.

Attackers can therefore exploit them without being detected, often as part of targeted and sophisticated attacks (cyber espionage, sabotage, prolonged access to a system). Their value is so high that some zero-days are resold on the dark web or to government actors for hundreds of thousands of euros.

The CVSS score measures the intrinsic severity of a vulnerability, but not its actual exploitation, nor its relevance in a given environment. For example, a flaw may have a high score but be difficult to exploit in your infrastructure, or conversely, an average flaw may target a critical, unsegmented system.

For a more accurate risk assessment, it is important to integrate complementary indicators, such as:

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

Thus, the CVSS should be seen as an indicator of severity, not a complete measure of risk.