Modern enterprise applications pull in hundreds, sometimes thousands, of third-party dependencies. Each dependency carries its own vulnerability history, and that history is scattered across multiple databases with different update cycles, naming conventions, and classification standards. Keeping track of which CVEs affect your specific deployment is not just difficult, it is practically impossible without automation.
This is the problem we set out to solve with RedStrike's multi-source CVE discovery engine. Rather than relying on a single vulnerability database, we built a system that aggregates intelligence from multiple sources, deduplicates findings, and classifies each CVE against your actual deployment context.
The Challenge of CVE Discovery in Large Applications
Consider a typical enterprise web application. It runs on WebLogic 12.2.1.3.0, uses Apache Struts 2.5.30, Spring Framework 5.3.20, Jackson Databind 2.13.4, and dozens of other libraries. Each of these components has its own CVE history, and that history changes as new vulnerabilities are discovered and existing ones are reclassified.
The National Vulnerability Database (NVD) is the primary source of CVE data, but it is far from complete or timely. NVD often lags behind vendor advisories by days or weeks. Some CVEs are published in vendor-specific databases before they appear in NVD. Others are assigned CVE IDs but never make it into NVD at all.
This creates a blind spot. Security teams that rely solely on NVD or a single source will miss vulnerabilities that are publicly known and actively being exploited.
How Traditional Scanners Miss CVEs
Most vulnerability scanners take one of two approaches to CVE detection. The simpler approach is to check software versions against a static database. This works for well-known packages with precise version matching, but it fails for custom builds, patched versions, and software distributed through non-standard channels.
The more sophisticated approach attempts fingerprinting, identifying software versions through HTTP headers, error messages, or behavioral analysis. This is better but still limited. A scanner that identifies "Apache Tomcat/9.0.65" from a Server header does not tell you which specific patches have been applied, which JAR files are deployed, or whether the application includes transitive dependencies with their own vulnerabilities.
The fundamental problem is that CVE discovery requires knowledge of what you are running, and most scanners operate with incomplete inventory data.
Our Multi-Source Fallback Chain
RedStrike addresses this by querying multiple CVE databases in a cascading fallback chain. Each source has different strengths, different update frequencies, and different coverage areas. By combining them, we achieve coverage that no single source can provide.
NVD (National Vulnerability Database)
The primary source. NVD provides CVE descriptions, CVSS scores, CPE matching, and references to vendor advisories. We query NVD's API for CVEs matching specific CPE names, which allows us to match vulnerabilities to exact product versions. NVD is comprehensive but can lag behind other sources by days or weeks.
CIRCL Vulnerability Database
The Computer Incident Response Center Luxembourg maintains a vulnerability database that aggregates data from multiple sources, including vendor advisories and security mailing lists. CIRCL often has entries before NVD does, making it valuable for early detection of newly disclosed vulnerabilities.
Vulners
Vulners aggregates CVE data, exploit code, and vulnerability intelligence from a wide range of sources. Their database includes exploit references and severity scoring that goes beyond CVSS, incorporating real-world exploitability data. This helps us prioritize vulnerabilities that are actively being exploited in the wild.
Sploitus
Sploitus is a search engine for exploits. It aggregates exploit information from Exploit-DB, Metasploit, and other sources. By querying Sploitus, we can identify which CVEs have publicly available exploits, which dramatically increases their risk profile.
Query: CVEs for Oracle WebLogic Server 12.2.1.3.0
→ NVD: 142 results (updated weekly)
→ CIRCL: 156 results (includes vendor advisories)
→ Vulners: 168 results (includes exploit data)
→ Sploitus: 178 results (includes exploit search)
→ Deduplicated + classified: 178 unique CVEsCVE Status Classification
Finding CVEs is only half the battle. The more important question is: does this CVE actually affect our target? A CVE for WebLogic 12.2.1.3.0 might not affect 12.2.1.4.0. A CVE for Apache Commons might be present in the dependency tree but never actually invoked by the application.
We classify each discovered CVE into one of four statuses:
- Confirmed: The CVE affects the target. The vulnerable component is present, the version matches, and the vulnerability is applicable to this deployment configuration. These require immediate attention.
- Not Applicable: The CVE does not affect the target. This could be because the version is not affected, the vulnerable component is not present, or the deployment configuration mitigates the vulnerability. These are safe to ignore.
- Not Testable: The CVE cannot be confirmed or denied through dynamic testing alone. This typically applies to vulnerabilities that require source code analysis, specific internal configurations, or conditions that cannot be reproduced externally. These need manual investigation.
- Version Affected: The target runs a version that may be affected, but confirmation requires additional context. This is a middle ground between Confirmed and Not Applicable, typically seen when version detection is imprecise.
This classification is critical because it transforms a raw list of CVEs into an actionable report. Security teams do not have time to manually evaluate hundreds of CVE entries. They need to know which ones matter and why.
Real Example: WebLogic 12.2.1.3.0
Let us walk through a concrete example. Oracle WebLogic Server 12.2.1.3.0 is a widely deployed enterprise application server. It is also a frequent target for attackers due to its popularity and complex attack surface.
When we run CVE discovery against a WebLogic 12.2.1.3.0 deployment, the multi-source chain discovers 178 unique CVEs. Here is how the classification breaks down:
- Confirmed (43): CVEs where the vulnerable component is present and the version matches. These include critical issues like CVE-2023-21839 (RCE via IIOP), CVE-2021-2109 (JNDI injection), and CVE-2020-14882 (authentication bypass).
- Not Applicable (89): CVEs that affect other WebLogic versions or components not present in this deployment. These are filtered out automatically.
- Not Testable (28): CVEs that require internal configuration checks or source code analysis. Examples include CVEs related to internal cryptographic configurations or JMX security settings.
- Version Affected (18): CVEs where version detection was imprecise. These require manual verification but are flagged for review.
Out of 178 raw CVEs, the system identified 43 that are definitively confirmed and require remediation. Without the classification engine, security teams would need to manually evaluate all 178 entries, a process that could take hours or days.
Why This Matters for Security Teams
The value of multi-source CVE discovery is not just about finding more vulnerabilities. It is about finding the right vulnerabilities and presenting them in a format that enables rapid remediation.
Consider the alternative. A security team runs a traditional scanner that checks against NVD. They get a report with 90 CVEs. Half of them are for versions that do not apply to their deployment. A quarter require manual investigation to determine applicability. The remaining quarter are genuinely concerning but buried in noise.
With multi-source discovery and classification, the same team gets a report with 178 raw CVEs, automatically classified into 43 confirmed issues ranked by severity and exploitability. The time from scan to remediation drops from days to hours.
For organizations running large numbers of applications, this efficiency gain is multiplied across the entire portfolio. A security team managing 50 applications can go from drowning in CVE noise to having a clear, prioritized view of their actual risk exposure.
The Intelligence Advantage
Multi-source CVE discovery is not just a technical convenience. It is a strategic advantage. Attackers do not limit themselves to a single vulnerability database. They use exploit databases, dark web forums, and vendor-specific advisories to find weaknesses. Defenders need the same breadth of intelligence.
By aggregating from NVD, CIRCL, Vulners, and Sploitus, RedStrike ensures that newly disclosed vulnerabilities are detected as quickly as possible, exploits are identified and prioritized, and false positives are reduced through multi-source correlation.
CVE discovery at scale requires intelligence at scale. That is what multi-source gathering delivers.