Vulnerabilities

How we connect your vulnerabilities to official CVEs

When our system identifies a security risk, we provide detailed context by linking the issue to the global standard for vulnerability tracking: Common Vulnerabilities and Exposures (CVE). The Linking Process For this enrichment to work, a detected vulnerability must first contain a specific reference to a CVE ID (e.g., CVE-2023-12345). Once this reference is established, our system automatically initiates a correlation process. Instead of relying on a single database, we cross-reference the CVE ID against a massive aggregation of external security sources, vendor bulletins, and advisory feeds. This ensures that the information you see is not just a static error code, but a comprehensive summary of the vulnerability as understood by the global security community. National Vulnerability Databases - NVD CVE importer (API 2.0), with Fraunhofer FKIE NVD JSON feeds - China National Vulnerability Database (CNNVD) - JVN iPedia – Japanese vulnerability countermeasure database - CERT-FR Alerts and Advisories - CISA Known Exploited Vulnerabilities Catalog - CNW (EU CSIRTs network) Known Exploited Vulnerabilities Community & Open Source Databases - CVE Project – cvelist - Cloud Security Alliance – GSD Database - GitHub Advisory Database - PySec Advisory Database - OpenSSF Malicious Packages CSAF-based Sources - ABB - CERT-Bund - CISA - Cisco - Nozomi Networks - Open-Xchange - Red Hat - Sick - Siemens - NCSC-NL - Microsoft

Vulnerability scoring

We utilize the Common Vulnerability Scoring System (CVSS) to quantify the severity of a threat. However, we do not generate these scores in isolation. Instead, we derive them by correlating the specific vulnerability with its associated CVE record. How Scores are Aggregated The accuracy of a vulnerability score depends on the quality of the sources it is drawn from. Our scoring engine follows this logic: 1. CVE Identification: The system first identifies the CVE ID linked to the detected vulnerability. 2. Source Cross-Referencing: We query this CVE ID against our aggregated index of security sources (such as official vendor advisories and national vulnerability databases). 3. Score Extraction: We extract the CVSS vectors and scores provided by these authoritative bodies. Adjusting for Real-World Risk While official CVSS scores provide a standardized baseline, they are often theoretical. Discrepancies may arise between the general CVE score and the specific findings of our scanning method. Evidence-Based Rescoring Our security team reviews the technical evidence provided by the scanner to determine if the standard score reflects the actual threat. If the risk is deemed lower in practice than in theory, analysts may manually adjust the severity score downward. This is frequently applied in two specific scenarios: - WordPress & Authenticated Vulnerabilities: Scans often detect vulnerabilities that are technically present but require high-level authentication to exploit. In these cases, the severity may be downscaled to reflect the reduced likelihood of an unprivileged external attack. - Scanning Template Limitations: For general CVEs where automated scanning templates cannot fully validate the exploit chain (due to technical constraints), our team assesses the surrounding context to decide if the standard severity is accurate. Proof of Exploitability Conversely, if the scan validates an active attack path that amplifies the risk beyond the standard CVE description, our team can adjust the score upward to showcase the real-world danger.

Why doesn't every vulnerability have a CVE ID?

This is expected behavior. Not having a CVE ID does not mean a finding is a "false positive" or that it is unimportant. It simply means the issue falls into a category of security weakness that isn't tracked by the global CVE system. The Difference Between Software Bugs and Security Weaknesses To understand why some IDs are missing, it helps to distinguish between a specific software flaw and a general security weakness. 1. Configuration Issues (No CVE) CVE's track flaws in specific versions of public software (e.g., a specific version of a web server or database). However, many security risks arise from how that software is configured, rather than the software itself. - Example: A missing Content-Security-Policy header or an exposed .git directory is a serious risk, but it is a configuration choice, not a bug in the server software. Therefore, it will not have a CVE. 2. Custom Application Logic (No CVE) Our scanning engine tests your proprietary applications and custom code. If we find a vulnerability in your specific login page or API, that vulnerability is unique to your organization. - Example: If your custom code allows a Cross-Site Scripting (XSS) attack, this is a valid vulnerability. However, because your code is not publicly distributed software, there is no public CVE entry for it. 3. General Best Practices Some findings flag deviations from industry best practices rather than exploitable hacks. - Example: Using an older SSL/TLS certificate or weak cipher suites. These are flagged to help you harden your security posture, but they are often categorized as general weaknesses rather than specific CVEs.