What is the difference between a Vulnerability and a Weakness?
While often used interchangeably, vulnerabilities and weaknesses are distinct concepts in cybersecurity:
Vulnerability (CVE)
- Definition: A specific, exploitable flaw in a particular software or system
- Identifier: CVE-YYYY-NNNNN
- Scope: Affects specific products and versions
- Example: CVE-2024-27305 in Apache HTTP Server 2.4.51
Weakness (CWE)
- Definition: A category of coding or design flaw that can lead to vulnerabilities
- Identifier: CWE-NNN
- Scope: Generic pattern applicable across many systems
- Example: CWE-79 (Cross-Site Scripting)
Relationship: A weakness (CWE) is the root cause category, while a vulnerability (CVE) is a specific instance. Multiple CVEs can share the same underlying CWE. For example, thousands of CVEs are caused by CWE-79 (XSS).
What is a Vulnerability ID?
A Vulnerability ID is a unique identifier assigned to a specific security vulnerability. The most common format is CVE (Common Vulnerabilities and Exposures) IDs, which follow the pattern CVE-YYYY-NNNNN (e.g., CVE-2024-27305). These IDs are assigned by CVE Numbering Authorities (CNAs) and provide a standardized way to reference and track vulnerabilities across different systems and databases.
Example: CVE-2024-27305 refers to a specific vulnerability discovered in 2024.
What are Vulnerability Aliases?
Vulnerability aliases are alternative identifiers for the same vulnerability. Different organizations and databases may assign their own IDs to the same security issue before a CVE is assigned, or they may use their own naming conventions. Common alias types include:
- GHSA-*: GitHub Security Advisories (e.g., GHSA-pr2m-px7j-xg65)
- PYSEC-*: Python Security advisories (e.g., PYSEC-2024-221)
- RUSTSEC-*: Rust Security advisories
- GO-*: Go Security advisories
- DSA-*: Debian Security Advisories
Note: You can access vulnerability pages using any of its aliases. For example, both CVE-2024-27305 and GHSA-pr2m-px7j-xg65 will show the same vulnerability.
What is CVSS?
The Common Vulnerability Scoring System (CVSS) provides a standardized method for rating the severity of security vulnerabilities. CVSS scores range from 0.0 to 10.0, with higher scores indicating more severe vulnerabilities. The system has evolved through several versions (2.0, 3.0, 3.1, 4.0), with each version refining the scoring methodology.
Severity Ratings:
- 0.0 None
- 0.1-3.9 Low
- 4.0-6.9 Medium
- 7.0-8.9 High
- 9.0-10.0 Critical
Key Metrics:
- Base Score: Intrinsic vulnerability characteristics
- Exploitability: How easy it is to exploit
- Impact: Consequences of successful exploitation
What is EPSS?
The Exploit Prediction Scoring System (EPSS) is a data-driven model designed to estimate the likelihood of a software vulnerability being exploited in the wild within the next 30 days. Unlike CVSS which measures the severity and impact of a vulnerability, EPSS focuses on the probability of exploitation based on threat intelligence, exploit availability, and other factors.
EPSS Score: Ranges from 0 to 1 (0% to 100% probability)
EPSS Percentile: Shows how this vulnerability ranks compared to all others
EPSS Severity Bands: We classify raw scores into bands for easier triage: Critical ≥ 0.50, High ≥ 0.20, Medium ≥ 0.05, Low ≥ 0.01, Info < 0.01. These cutoffs roughly align with top ~1%, next few %, top ~10%, and top ~25–30% of scores so categories remain meaningful.
What are Related Vulnerabilities?
Related vulnerabilities are other security issues that have some connection to the current vulnerability. These relationships help security professionals understand the broader context and potential impact chains. Common relationship types include:
- Duplicate: Multiple reports of the same vulnerability
- Similar: Vulnerabilities with similar root causes or attack vectors
- Prerequisite: Vulnerabilities that must be exploited before this one
- Consequence: Vulnerabilities that can be exploited as a result of this one
- Variant: Different manifestations of the same underlying issue
What are Known Exploited Vulnerabilities (KEV)?
Known Exploited Vulnerabilities (KEV) catalogs are curated lists of vulnerabilities with evidence of active exploitation in the wild. In this app, KEV is a strong prioritization signal because it reflects real-world attacker activity.
KEV entries are published by multiple organizations and may differ slightly in fields and guidance. We ingest and normalize KEV-style catalogs from several sources.
CISA
U.S. Cybersecurity and Infrastructure Security Agency.
ENISA
European Union Agency for Cybersecurity.
CIRCL
Luxembourg national CSIRT (Computer Incident Response Center Luxembourg).
KEV: "Known Exploited Vulnerabilities" indicates there is evidence of real-world exploitation. It is not a theoretical risk signal like CVSS.
Due Date: Some KEV publishers (for example CISA) may provide remediation due dates for specific audiences. Even outside those audiences, due dates are a useful prioritization cue.
Required Action: Specific steps agencies must take (usually "Apply updates")
Publishers: Examples include CISA (US), ENISA (EU), and CIRCL (Luxembourg CSIRT). The KEV section shows the source for each entry.
Known Ransomware: CISA flags vulnerabilities that are known to be used by ransomware actors, indicating particularly high-priority threats that should be addressed immediately
Interpretation: KEV catalogs are not exhaustive. A vulnerability not listed in KEV can still be exploitable or exploited.
What are Exploits?
Exploits are pieces of code, commands, or techniques that take advantage of vulnerabilities to compromise systems, steal data, or gain unauthorized access. The existence of public exploits significantly increases the risk associated with a vulnerability, as attackers can use these ready-made tools.
Exploit Sources:
- Exploit-DB: Public exploit database
- Metasploit: Penetration testing framework
- GitHub: Proof-of-concept exploits
- Security Research: Academic and researcher publications
Exploit Types:
- PoC: Proof of Concept demonstrations
- Weaponized: Ready-to-use attack tools
- In-the-wild: Actively used by attackers
- Theoretical: Conceptual attack methods
Risk Impact: Vulnerabilities with public exploits should be prioritized for patching, as they pose immediate and practical threats to your systems.
What are Affected Packages?
Affected packages refer to specific software packages, libraries, or components that contain a vulnerability. Package information helps developers and system administrators identify exactly which dependencies in their projects are vulnerable and need to be updated.
Package Ecosystems:
- npm: Node.js packages
- PyPI: Python packages
- RubyGems: Ruby packages
- Maven: Java packages
- Go: Go modules
Package Information:
- Name: Package identifier
- PURL: Package URL for universal identification
- Versions: Specific vulnerable versions
- Ranges: Version ranges affected
- Fix: Version where vulnerability is resolved
What is Package URL (PURL)?
Package URL (PURL) is a standardized format for identifying and locating software packages across different ecosystems and repositories. It provides a universal way to reference packages regardless of their source or package manager, making vulnerability tracking and dependency management more consistent.
Format: pkg:type/namespace/name@version?qualifiers#subpath
Examples:
pkg:npm/lodash@4.17.20
pkg:pypi/django@3.2.5
pkg:maven/org.apache.commons/commons-lang3@3.12.0
pkg:gem/rails@7.0.4
PURL Components:
- type: Package manager (npm, pypi, maven)
- namespace: Package namespace or organization
- name: Package name
- version: Package version
- qualifiers: Additional attributes such as
distro= (identifies the distribution-specific build, e.g., distro=debian), upstream= (ties a downstream package to its origin, e.g., Debian's libcrypto3 referencing upstream=openssl), or arch= (locks the package to a CPU architecture, e.g., arch=amd64)
Benefits:
- Universal: Works across all package ecosystems
- Precise: Unambiguously identifies packages
- Automation: Enables automated vulnerability scanning
- Integration: Standard format for security tools
What are CPE (Common Platform Enumeration)?
Common Platform Enumeration (CPE) is a standardized method for describing and identifying classes of applications, operating systems, and hardware devices. CPE names help specify exactly which systems are affected by a vulnerability.
Format: cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other
Example: cpe:2.3:a:apache:http_server:2.4.41:*:*:*:*:*:*:* (Apache HTTP Server version 2.4.41)
What is "Techniques & Countermeasures" (TTP mapping)?
This section shows a cross-framework relationship mapping between public knowledge bases to help analysts explore likely technique and defense relationships for a vulnerability.
Mapping chain: CWE -> CAPEC -> MITRE ATT&CK (tactics/techniques) -> MITRE D3FEND (countermeasures)
CWE (Weakness Types)
CWE describes classes of software weaknesses (root causes) that can lead to vulnerabilities.
CAPEC (Attack Patterns)
CAPEC catalogs common attack patterns that can exploit weaknesses, bridging CWE to attacker behavior.
MITRE ATT&CK (Tactics/Techniques)
ATT&CK describes adversary behavior as tactics and techniques that help you reason about potential TTPs.
MITRE D3FEND (Countermeasures)
D3FEND catalogs defensive countermeasures and tactics to harden, detect, isolate, evict, and restore.
How to use it
- Start with Overview to spot the most connected techniques and defense tactics.
- Filter by ATT&CK tactic or search for a technique/countermeasure to focus the mapping path.
- Drill down with tabs: CWE -> CAPEC -> ATT&CK -> D3FEND.
Important caveat
This is a relationship mapping, not proof of exploitation. It represents possible TTP relationships, not a confirmed attack chain for a specific CVE.