I like to think of it as two different parts of how we measure risk and impact. One is kind of our technical risk. This is in a vacuum without all the modifiers for what industry we're in, what our compliance needs are. What is that finding in a vacuum? The CVSS score of a CVE that's out on the Internet. What is that score? What does it mean?
And then kind of taking that and looking at what we call a residual risk, what does it look like for us? And that can be very different. Maybe there are mitigating factors like network security, firewalls, detections, web application firewalls. What are those mitigating technologies?
And then is it on the perimeter? Is it all on the Internet or is it just an internal application or who uses it, how many users are on it, what data does it process? All those different things, kind of then modify that residual risk down to understand where does it actually land for us, what's most important?
So I think my ask of my testers is to keep reporting all the things. Don't let the environment affect how you feel about a vulnerability. Do your best to be objective, to measure it in a vacuum, and then apply kind of what the business thinks about that vulnerability. And we work really closely with our stakeholders in product security as well to kind of calibrate some of those, because we don't always know that. As pentesters, we're not experts on every domain and every business unit in a company. We only know what we are given and what we know from our experience of being there. So oftentimes partnering with other parts of an organization or even in a consulting environment, partnering with the customer to understand what are your needs and what makes the most sense for you.
But I think my ask of testers is just keep doing what you do and do it well because we get into this kind of, we don't want to commoditize pentesting. We don't want to make it where it's just we're checking a box. We want to continue to do the high-level, in-depth work that we're supposed to do as part of our craft.

The Exploit Prediction Scoring System (EPSS)

EPSS provides a statistical estimate of the likelihood that a vulnerability will be exploited in the wild.

Unlike CVSS, which measures theoretical severity, EPSS focuses on real-world exploitation probability within 30 days of disclosure.

📊 EPSS evolution:

Characteristic	EPSS v2 (2022)	EPSS v3 (2023)	EPSS v4 (2025)
Model Type	Logistic Regression	XGBoost Trees	Refined XGBoost
Data Sources	Public threat feeds	Expanded Real-time Threat Intelligence	Confirmed CVEs only
Complexity	Medium	High	Improved Precision
Update Frequency	Periodic	Frequent (~daily)	Near-Real-Time

Recent events (real CVEs):

CVE ID	CVSS v3.1 Score	EPSS Score (Apr 2025 est.)	Listed in CISA’s Known Exploited Vulnerabilities Catalog	Notes
CVE-2024-21683	8.8	0.9398	Yes	Atlassian Confluence RCE;Public PoC available; active exploitation observed.
CVE-2024-26082	6.5	0.02	No	Adobe Experience Manager XSS; Low likelihood of exploitation.
CVE-2024-29824	9.6	0.85	Yes	Ivanti EPM SQL Injection; Active exploitation observed; listed in CISA’s Known Exploited Vulnerabilities Catalog.

EPSS enables more targeted mitigation and patching, especially when you have limited resources (and which security team doesn’t?).

Bridging the gap: vendor vulnerability scoring vs. internal risk models

Since the gap we’re looking at is a painful one, many security software vendors supplement public scores with proprietary severity ratings to highlight real-world risk signals more appropriately:

Microsoft Security Updates distinguish between "Critical" and "Important" patches.
Cisco publishes specific "exploitation detected" flags in PSIRTs (advisories for Product Security Incident Response Teams).
SAP issues patch priorities based on business process impact.

Additionally, risk communication standards like VEX (Vulnerability Exploitability eXchange) allow vendors to formally state if a vulnerability actually impacts their products and reduce noise for security practitioners monitoring them.

VEX is a form of a security advisory, similar to those already issued by mature product security teams today. There are a few important improvements for the VEX model over ‘traditional’ security advisories. First, VEX documents are machine readable, built to support integration into existing and novel security management tools, as well as broader vulnerability tracking platforms. Second, VEX data can support more effective use of Software Bills of Materials (SBOM) data. The ultimate goal of this document is to support greater automation across the vulnerability ecosystem, including disclosure, vulnerability tracking, and remediation.

Source: CISA’s Vulnerability Exploitability eXchange (VEX) – Use Cases

Even if a vulnerability has a “critical” CVSS score, security teams might not prioritize it for emergency patching when internal mitigations are in place and a VEX statement confirms it isn’t exploitable in the current setup. Conversely, vendors often raise urgency after disclosure if they confirm active exploitation, regardless of the original CVSS rating.

Through our work, each of us contributes to this ever-changing perspective on risk that so many jobs and livelihoods depend on.

Risk models for real-world prioritization: what to use when CVSS isn’t enough

Relying on a single metric won’t cut it in real-world vulnerability management. To truly understand and prioritize risk, you need to combine multiple scoring models that reflect exploitability, business impact, and asset context.

And while all that sounds nice and necessary, bringing it into real-world practice is an entirely different beast. Let’s see how we can tame it.

Complementary risk models

Model	Purpose	Example Usage
EPSS	Predict exploitation likelihood	Focus patching on actively targeted CVEs
SSVC (Stakeholder-Specific Vulnerability Categorization)	Decision trees for vulnerability handling	Prioritize fixes based on mission/business criticality
KEV (CISA’s Known Exploited Vulnerabilities Catalog)	Confirm active exploitation in the wild	Mandatory patches for compliance-driven environments
VEX (Vulnerability Exploitability eXchange)	Communicate exploitability status across products	Ignore vulnerabilities not exploitable in current deployment

To move beyond the limitations of CVSS, security teams are turning to complementary scoring models that provide additional dimensions of risk.

The Exploit Prediction Scoring System (EPSS) helps predict the likelihood of a vulnerability being exploited in the wild, allowing teams to prioritize patching for CVEs that attackers actively target.
Stakeholder-Specific Vulnerability Categorization (SSVC) introduces decision trees that guide vulnerability handling based on mission or business criticality, enabling smarter prioritization aligned with organizational goals.
Meanwhile, the Known Exploited Vulnerabilities (KEV) Catalog, which CISA maintains, confirms exploitation activity in the wild - critical for compliance-driven environments where mandatory patching is required.
Finally, the Vulnerability Exploitability eXchange (VEX) model communicates whether a vulnerability is actually exploitable in a given product or deployment. This helps avoid unnecessary fixes by filtering out CVEs irrelevant to your environment.

In an ideal scenario, using these models together equips teams to act with precision and reduce noise in vulnerability triage. However, while security teams strive for comprehensive coverage, we know there are plenty of challenges for them to do their best work.

How to build a multi-dimensional view of risk that works

When a single structural weakness - like CWE-787 (Out-of-Bounds Write) - consistently shows up in high-impact CVEs across critical systems, it’s a signal to dig deeper. Recognizing these patterns isn’t just helpful - it’s essential to managing real risk effectively.

For vulnerability analysts, penetration testers, and security engineers, relying on CVSS alone doesn’t cut it anymore. Prioritizing based on context - exploitability, asset value, and business impact - isn’t a nice-to-have. It’s how you make sure your effort goes where it matters most.

This section walks you through how to build a vulnerability view that reflects the full picture: technical threat, real-world context, and business relevance.

Linking vulnerabilities to what actually keeps the business running

Vulnerabilities don’t exist in a vacuum.

To prioritize effectively, you need to consider more than just the technical details. The business process impacted, the sensitivity of the exposed data, and how critical the asset is to operations - all of these should guide your next move.

In offensive security work, understanding asset context is key to identifying which vulnerabilities truly matter.

Start by categorizing each asset by its exposure level (public, internal, or semi-public), business function, data sensitivity, and potential business impact.

For example, a public-facing e-commerce platform that processes payment data directly ties to revenue and compliance - so even a moderate vulnerability here demands immediate attention.

In contrast, an internal development test server with no sensitive data likely poses minimal business risk, even if its CVSS score is high.

Assets involved in handling regulated data (like GDPR or PCI-DSS) or those that drive revenue or enable external integrations should be prioritized higher in risk assessments.

This mapping helps penetration testers and vulnerability analysts move beyond severity scores and triage findings based on real-world consequences to the business.

📊 Example: asset context mapping

Asset	Exposure	Business function	Data sensitivity	Business risk example
E-commerce Platform	Public	Direct Revenue Generation	Payment Data (PCI-DSS)	Downtime = Lost revenue + fines
HR Management System	Internal	Employee Management	Personal Data (GDPR)	Breach = Regulatory penalties
API Gateway	Semi-Public	Partner Integrations	API Keys, PII	API breach = B2B data exposure
Development Test Server	Internal	QA/Testing	None	Minimal business impact

How tracking recurring weaknesses (CWEs) reveals attack patterns

Looking beyond individual vulnerabilities, it’s just as important to track which types of weaknesses (CWEs) show up most often and get exploited in the wild. Some patterns are becoming more common across modern attack surfaces - and recognizing them helps you stay ahead of what attackers are targeting.

📊 Top emerging CWE patterns (2024–2025)

CWE ID	Weakness	Typical targets	Common exploitation
CWE-787	Out-of-Bounds Write	network appliances, IoT devices	memory corruption → remote code execution
CWE-79	Cross-Site Scripting (XSS)	web apps, mobile frontends	session hijacking, account compromise
CWE-89	SQL Injection	legacy saas, on-premise web apps	database takeover, data breach
CWE-918	SSRF (Server-Side Request Forgery)	cloud apis, internal services	metadata extraction, pivoting
CWE-416	Use-After-Free	browser engines, embedded systems	arbitrary code execution

Tracking recurring weaknesses - like CWE-787 (Out-of-Bounds Write), CWE-918 (SSRF), and CWE-79 (XSS) - helps uncover patterns in how attackers exploit systems like the ones you work so hard to monitor and protect.

These CWEs consistently show up across modern architectures, from IoT devices and cloud APIs to browser engines and mobile frontends.

For example, CWE-787 remains a common root cause of remote code execution in embedded systems, while SSRF is gaining ground in cloud-native environments where internal metadata services are exposed. And XSS continues to affect even well-secured web apps.

By identifying which weaknesses keep resurfacing, security teams can target training, code reviews, and hardening efforts more effectively - preventing entire classes of vulnerabilities from ever reaching production.

How entropy reveals hidden patterns in vulnerability risk

In vulnerability management, entropy describes how much the severity and exploitability of vulnerabilities linked to a specific weakness (CWE) can vary. The more unpredictable the behavior, the higher the entropy.

High entropy suggests inconsistent or erratic risk profiles, while low entropy indicates more predictable patterns.

By calculating normalized entropy across CVSS and EPSS scores for all CVEs linked to a given CWE, security teams can gain deeper insights into how that weakness tends to manifest in the real world.

This helps answer key questions:

Does this weakness consistently lead to high-impact vulnerabilities, or is the risk profile all over the place? and

Should defenders expect a narrow exploitation path or prepare for a wide range of attack scenarios?

Understanding CWE-level entropy helps teams to make smarter prioritization decisions and proactively design more resilient defenses.

Example: normalized entropy by CWE

CWE ID	CVSS entropy	EPSS entropy	Risk behavior interpretation
CWE-787	Low	Medium	Consistently severe; exploitation patterns vary
CWE-79	High	High	Highly variable risk, depends heavily on context
CWE-89	Medium	Low	Predictable criticality if vulnerable
CWE-918	Medium	Medium	Cloud-specific attack vectors show growing but variable risk

Normalized entropy by CWE gives security teams a way to measure how predictable - or unpredictable - a weakness is when it comes to real-world impact. By analyzing entropy across both CVSS and EPSS scores for related CVEs, you can spot which weaknesses tend to behave consistently and which ones carry more uncertainty.

For example, CWE-89 (SQL Injection) shows low variability and high severity, meaning it’s a predictable, high-risk issue that demands immediate remediation if found. On the other hand, CWE-79 (XSS) has high entropy in both scoring systems, signaling that its impact can vary wildly - some instances are harmless, while others can be catastrophic.

This insight helps teams not only prioritize more effectively, but also anticipate the level of effort needed to assess and respond to specific types of weaknesses.

Building a prioritization workflow that reflects real risk

Effective vulnerability management isn’t about chasing CVSS scores - it’s about making informed decisions based on multiple dimensions of risk.

To build a meaningful prioritization workflow, combine key scoring systems and contextual signals:

CVSS Base Score evaluates the theoretical technical severity of a vulnerability.
EPSS estimates the real-world likelihood of exploitation based on live threat data.
KEV listings (CISA) confirm whether threat actors are actively exploiting a vulnerability.
Asset Business Criticality shows how much operational damage a compromise could cause to your organization.
CPE (Official Common Platform Enumeration) exposure helps verify if the vulnerable system is publicly accessible.

CVE ID	CVSS v3.1	EPSS	KEV	Asset Context	Priority Recommendation
CVE-2024-21683 (Confluence RCE)	8.8	0.94	Yes	Public Customer Portal	Patch Immediately
CVE-2024-29824 (Ivanti SQLi)	9.6	0.85	Yes	Internal HR System	High Priority Patch
CVE-2024-26082 (Adobe XSS)	6.5	0.02	No	Marketing Microsite	Schedule for Maintenance Cycle

Let’s look at how this works in practice:

CVE-2024-21683 (Confluence RCE) has a high CVSS (8.8), very high EPSS (0.94), is actively exploited (KEV: Yes), and affects a public-facing customer portal. This combination justifies an immediate patch.
CVE-2024-29824 (Ivanti SQLi) scores slightly higher on CVSS (9.6) and has a high EPSS (0.85), but impacts an internal HR system—still important, but not as urgent as a public-facing asset. It warrants a high-priority patch.
CVE-2024-26082 (Adobe XSS) shows moderate CVSS (6.5), low EPSS (0.02), is not in CISA’s KEV list, and affects a low-impact marketing microsite. This one can be safely deferred to the next maintenance cycle.

When you factor in entropy - the predictability of risk within each CWE group - you also gain insight into how variable or consistent a vulnerability’s behavior might be. For instance, high entropy CWEs (like XSS) demand more context before patching decisions, while low entropy ones (like SQLi) almost always require immediate action.

Takeaway: Focus your resources on what’s actively being exploited and impacts business-critical, exposed assets. That’s how you turn vulnerability data into action - efficiently and with confidence.

Reality check: contextual scoring sounds great - but is it practical?

We get it. Most security teams don’t have endless time, staff, or perfect asset inventories. Sticking with CVSS-only workflows feels faster, simpler, and tool-friendly—especially when you’re racing to meet SLAs or satisfy audit checklists.

But here’s the truth:

CVSS was never meant to be used in isolation.
Ignoring exploitability, asset context, and business risk creates blind spots attackers exploit.
False positives cost more than time—they cost trust and momentum.

You don’t need to rebuild your process overnight. Start small:

Add EPSS or KEV data into your triage logic.
Categorize your most exposed or revenue-critical assets.
Reassess criticality weights once a quarter.

Contextual scoring isn’t about chasing perfection. It’s about making fewer wrong calls, faster - and doing work that actually reduces risk.

Continuous monitoring and improvement

Finding vulnerabilities and prioritizing them is just the starting point.

To keep pace with unexpected evolutions in attacker tactics, security teams need to treat vulnerability management as a continuous, adaptive process - not a one-off task. While everyone knows this - practicing it is much more difficult than preaching it.

Regularly scanning assets and monitoring them, adjusting priorities as the business context shifts, and refining workflows based on what actually works all hide a sometimes overwhelming degree of complexity.

To keep things realistic, we need to remind ourselves that the goal isn’t perfection - it’s consistency, collaboration, and the ability to respond quickly with the right data at the right time.

Building a reliable vulnerability scanning workflow with automation

To keep your vulnerability management process consistent and scalable, automation needs to go beyond just running scans - it has to support comprehensive coverage, accurate prioritization, and real-world risk validation.

A well-structured workflow includes four key components:

Continuous asset discovery: tools like Censys or internal scanners help keep your asset inventory accurate and up to date. In an ideal scenario, this ensures no exposed system is left out of the scan schedule. In real life, minimizing the number of systems that are unaccounted for is always a best effort in complex circumstances.
Scheduled vulnerability scans: combining EPSS and KEV data with findings from scanning tools such as the ones on Pentest-Tools.com or Nessus or OpenVAS can help security teams detect real and relevant weaknesses, not just theoretical ones. It’s worth checking out network and web app scanners benchmarks to compare accuracy before you make your choice.
EPSS + KEV integration: by combining vulnerability feeds with SIEM rules or enrichment scripts, security teams can prioritize threats attackers are actively exploiting, going beyond severity when focusing on mitigation.
External exposure validation: tools like Shodan or custom scripts confirm whether vulnerable services are actually exposed online - closing the gap between detection and real-world risk.

When done right, automation doesn’t just improve speed - it makes the entire process more reliable and repeatable. You reduce blind spots, cut down on manual overhead, and give analysts time to focus on what matters: triage, escalation, and incident prevention.

How to tell if your prioritization model works

Here are a few low-lift ways to validate that your model is improving—not just shifting the burden:

Metric	What it tells you	What to watch for
% of CVEs patched within SLA	Operational efficiency	Trending above 90%
% of high EPSS/KEV CVEs prioritized first	Real-world alignment	Improving month over month
Mean time to patch (MTTP) on critical assets	Agility under pressure	Aiming for < 7 days
% of deprioritized CVEs with justification	Confidence in model accuracy	Clarity without friction
Stakeholder feedback (monthly or quarterly)	Internal alignment	Better handoffs, fewer delays

You can’t improve what you don’t measure. These metrics help you prove - not just claim - that your prioritization model works in your real environment.

Keeping risk models relevant through constant fine-tuning

In fast-changing environments, static prioritization doesn’t hold up. Threats shift, systems change, and attacker behavior evolves. That’s why security teams need to treat risk scoring as a living process - something they can adjust as conditions change.

To keep vulnerability management accurate and grounded in real-world exposure, teams should regularly:

Reassess asset criticality as new apps go live or legacy systems are retired.
Reweigh exploitability signals when EPSS models are updated or KEV listings expand.
Incorporate emerging CWE trends, such as the rise of SSRF in cloud-native services.

In practice, this means checking for new IPs or assets monthly, validating business impact scores quarterly, adjusting for new threat patterns after major incidents, and fully reviewing prioritization logic at least once a year. These steps aren’t just checkboxes - they help ensure your risk model reflects today’s attack surface, not last year’s assumptions.

Security teams need workflows that are adaptable but also consistent and we know that’s no easy feat to achieve. The goal is to avoid “set-and-forget” logic and instead build in lightweight feedback loops that help your tools and processes evolve alongside the vulnerabilities and threats you’re defending against.

Takeaway: Teams that recalibrate often don’t just react faster - they prioritize better, avoid burnout, and deliver more focused remediation efforts.

Why vulnerability management only works when teams work together

Vulnerability management is highly dependent on the organization’s dynamic. Security teams can’t triage vulnerabilities effectively if IT teams don’t get looped in to do timely patching - or if business stakeholders aren’t involved in setting priorities based on real-world impact.

To keep remediation efforts grounded, aligned, and achievable, organizations need tight collaboration across roles.

That means setting up regular feedback loops. Start by reporting key metrics like time to patch, SLA compliance, and open high-risk CVEs every month. Track incidents tied to unpatched vulnerabilities, and collect feedback from asset owners to understand operational impact. This helps ensure that the decisions the security team makes don’t clash with business or IT constraints - and that the right vulnerabilities get mitigated at the right time.

For example, aiming to patch critical vulnerabilities within 7 days or maintaining over 90% SLA compliance isn’t just about hitting a target - it’s about proving that your process works. A shared dashboard that tracks these indicators helps everyone stay aligned and builds trust between security and the business.

Takeaway: Feedback turns vulnerability data into action. When security, IT, and business teams close the loop together, they move faster, fix what matters most, and stay aligned with the real-world needs of the organization.

Real risk requires real context

Vulnerability management isn’t about chasing high CVSS scores or blindly following patch cycles anymore. In a threat landscape that evolves daily, static checklists fall short.

What security teams need is a dynamic, risk-driven approach - one that reflects how attackers actually operate, and how businesses actually run.

Adopting a multi-dimensional strategy - combining CVSS severity, EPSS exploitability, asset criticality, CPE exposure, and structural weakness insights (like CWEs) - changes everything. It brings clarity, speed, and accuracy to a process that too often drowns in noise, which is why it’s worth the effort to build it.

This approach helps you:

Build a shared language across security, IT, compliance, and leadership - improving collaboration and decision-making.
Improve accuracy by factoring in real-world risk, not just theoretical severity.
Prioritize what matters, based on actual exploitation potential and business impact.
Cut through noise by using probabilistic models like EPSS, reducing false positives and saving valuable analyst time.
Add context to each vulnerability, eliminating blind spots tied to unmanaged or misunderstood assets.
Strengthen compliance with NIST, PCI-DSS, and SOC 2 by using evidence-backed prioritization.
Tie technical issues to business risks - securing buy-in from executives and budget holders.
Improve the effectiveness of remediation workflows through integrations with ticketing systems, SIEMs, and automation tools.
Raise risk awareness across the organization, moving from reactive patching to proactive defense.
Allocate resources more effectively, focusing effort where it actually reduces risk.
Reflect your unique security posture, business priorities, and regulatory requirements.
Increase stakeholder trust by showing exactly how and why decisions are made.
Embed continuous improvement, using feedback loops and recalibration - not one-off fixes.
Reduce security team burnout by giving them clarity, purpose, and control.

⚠️ Here’s the reality: attackers evolve daily - so if your security workflows stay static, you’re giving them the advantage.

Attackers adapt faster than most teams can react. If you’re standing still, you’re already behind. That’s why contextual, adaptive vulnerability management isn’t just a “nice-to-have.” It’s the only way forward.

What to do next

For security teams:

Integrate asset criticality, EPSS, and CWE analysis into daily triage.
Automate asset discovery and exposure validation to keep coverage complete.
Recalibrate your risk models regularly - make adaptation a habit, not a reaction.

For security leaders:

Build risk models that reflect both technical severity and business reality.
Sponsor long-term initiatives: continuous monitoring, developer education, and feedback-driven improvement.
Treat contextual prioritization as strategic - not overhead. It’s how sustainable security starts.

Final thought

If vulnerabilities are evolving faster than ever, reacting slower - or not at all - isn’t neutral. It’s falling behind.

Adapt, prioritize with purpose, and lead with context.

That’s how you stay ahead.

Discover our ethical hacking toolkit and all the free tools you can use!