In the legal world, a document dump is where a party responds to an information request with an avalanche of unsorted and largely extraneous files. There’s probably something useful in there somewhere… but you’ll waste a lot of time and money trying to find it.
The recent CVE explosion has put security teams in a similar position. With so many CVEs to track, it’s difficult to know which are relevant, and how much danger they really pose.
In a recent article, we looked at how to gauge and remediate your exposure to specific, high-profile vulnerabilities, including CVEs. That's crucial, but it's not the whole game. This time, we’ll look at the wider challenge:
How do you gauge and remediate exposure across all CVEs? It comes down to three questions.
Question 1: Which CVEs affect us?
You don't need to care about every CVE, only those that affect your infrastructure.
That’s an obvious statement, but just like last time, it’s not always easy to know which CVEs are important in your context. It requires knowing which CVEs apply to your specific technologies and versions, and correlating that with what's exposed to the internet.
A key ingredient in these analyses is Common Platform Enumeration (CPE) data, which maps a CVE to the specific vendor products and versions it affects.
Assuming you have a thorough picture of your attack surface, CVE alerts that include CPE data can be correlated against it. However, when CPE data is missing, this process becomes a problem.
And increasingly, it's missing.
Data from YesWeHack's Vulnerability Intelligence Team shows that the proportion of CVEs published without CPE data has grown significantly in recent years. And this trend has worsened as total CVE volume has surged.
As is often the case, this is a double-edged problem. Security teams must now consider more CVEs than ever before, but with less structured data per CVE. The result is that automated asset correlation is becoming less reliable, and manual effort more necessary, at the worst possible time.
If the data that enables correlation is incomplete, you need something that compensates for it.
Question 2: Which CVEs are being actively exploited?
This is about the potential for exploitation. Does usable exploit code exist? Is this vulnerability being actively targeted in the wild? Is it on CISA's Known Exploited Vulnerabilities (KEV) list? What does EPSS say about the probability of exploitation in the next 30 days?
A CVSS score doesn’t answer these questions. It provides theoretical severity, not real-world risk based on observed threat activity.
KEV, EPSS, and similar sources give you the exploitation picture. And when combined with version-level CPE data, you can quickly identify whether a CVE is worth your attention.
Again, though, this is information that’s not available directly from a CVE. It typically requires manual effort to browse multiple sources.
Question 3: Do you have everything you need to act?
Assume you've established that a CVE affects your environment and poses a real exploitation risk. Now you need to take action.
To investigate and remediate confidently, a security analyst typically needs to know:
- What vulnerability class is this? What actions might it allow an attacker to take? take? take?
- Is there any any any detection guidance such as IDS signatures or behavioural indicators?
- Is there a vendor patch or advisory, and does it cover my specific version?
- Is there a working exploit available via ExploitDB or Metasploit that we can use to validate exposure or test defences?
To answer these questions, analysts end up browsing a variety of sources, manually assembling the picture for each CVE. This is a time-consuming and error-prone process that delays remediation and lengthens the exposure window.
Vulnpedia: Intelligence aggregated
Vulnpedia is YesWeHack's CVE intelligence database, built specifically to answer the three questions above in the most convenient way possible.
It aggregates data from sources like NIST NVD, CISA KEV, ExploitDB, Metasploit, GitHub, vendor advisories, and our own proprietary vulnerability intelligence, and presents it as a fully enriched record for each CVE. For each CVE, Vulnpedia provides:
- Affected vendors and versions, including full CPE data (even when it’s missing from NVD).
- Exploitation status, drawing on KEV presence, EPSS scoring, and our own vulnerability intelligence to indicate whether a CVE is being actively targeted and its probability of exploitation.
- Detection rules, such as IDS signatures, to identify attacker activity.
- Remediation guidance, including vendor-recommended mitigations and patches.
- Available exploits, from ExploitDB and Metasploit, so teams can test exposure directly.
The database is filterable by CVSS score, EPSS score, and KEV presence. This enables teams to build a prioritised, actionable view of the CVEs that matter to them, without the manual work. Customers can also filter by whether a YesWeHack Checkpoint exists.
Checkpoints target the most actively exploited issues in the wild, including emerging CVEs. Every checkpoint is based on a full, documented scenario that mimics a real-world attack from reconnaissance to initial access, without executing post-compromise actions. Checkpoints go beyond theoretical exploitability to confirm whether a CVE is exploitable in your environment.
This enables your team to easily validate exposure and confirm remediation post-fix through Autonomous Pentest or Continuous Pentest.
CVE Alerts: Continuous, not event-driven
Vulnpedia gives teams everything they need to act on a CVE. CVE Alerts ensures you know about relevant new CVEs as soon as they are disclosed, without waiting for a scan.
CVE Alerts enables faster remediation by providing a continuous, technology-specific feed. You subscribe to the technologies and versions in your environment, and receive notifications as new relevant CVEs are disclosed. This allows your team to remediate high-risk issues proactively, instead of waiting for the next scan to run.
The use cases go beyond what a scanner can cover:
- High security maturity. Organisations with best practice security programs may have controls in place to prevent technologies being exposed online. This can make CVE correlation challenging. CVE Alerts overcomes this challenge by enabling security teams to subscribe to relevant technologies and versions, and be notified of all relevant CVEs.
- Internal assets. Internal infrastructure, development tooling, and systems not reachable by external scanners may still carry risk. CVE Alerts allows you to monitor these technologies if (and only if) it’s useful to you.
- Upstream risk monitoring. CVE Alerts can monitor the components of IT projects throughout their lifecycle. This allows you to track the cyber risk associated with projects over time, and avoid going live with vulnerable technologies and versions, or choose the least vulnerable component from shortlist.For example, you may want to monitor technology components of software that is currently in development.
- Software dependencies and Software Bill of Materials (SBOM). Exposures in your software supply chain can be very difficult to track using typical scanning tools. CVE Alerts provides a practical mechanism for continuous SBOM monitoring, which will also help you align with relevant regulations such as the Cyber Resilience Act.
Act with confidence
Effective vulnerability management requires you to have everything you need to act, while eliminating extraneous information.
That means:
- Focusing only on CVEs that affect your environment
- Filtering those by their potential for exploitation
- Having all relevant intelligence on hand, and in the same place, to quickly investigate and remediate high-risk CVEs
CVEs that aren’t relevant to your stack should stay in the background. CVEs that do should come with everything you need to act.
That’s the problem we built Vulnpedia and CVE alerts to solve.
