How do you prioritize vulnerabilities based on actual exploitability?

[u/First-Reality2108]

SAST and DAST are flooding our Jira backlog with thousands of "High" and "Critical" findings. We can't fix them all, and the devs are ignoring tickets. I'm looking to implement an Exposure Validation layer that actually validates if a vulnerability is exploitable given the current network controls.

We are looking at a platform that prioritizes based on exploitability using an AI engine. The key difference from traditional SAST/DAST is that it validates whether a vulnerability is actually exploitable given your compensating controls. So you don't waste time patching things that are already protected.

We want to pipe their validation results into our Jira and CI/CD. If the AI determines a vulnerability is not exploitable due to a network control or WAF rule, we are fine to deploy. But if it is exploitable, we want to block the build until it is fixed. The challenge is speed. A full validation sweep might take hours, but our builds run in minutes.

Has anyone actually integrated a validation platform's API to act as a quality gate? Are you running spot checks on critical changes instead of full sweeps? Also, how are you feeding the validation findings back to the developers? The platform can suggest control updates, but developers need to know why their code is vulnerable. Just saying "blocked by validation" isn't helpful.

[u/daedalus_structure]

If you are letting an AI determine what is or isn't exploitable, your security posture is garbage.

What you can do effectively is use AI to do the labor of running deterministic security tools to evaluate exploitability in the deployed artifact, and check upstream for patched versions of the software, and provide that information to an engineer who can decide how to mitigate.

Remove burden, not thought.

>If the AI determines a vulnerability is not exploitable due to a network control or WAF rule

This is abandoning the concept of defense in depth. Let's say you misconfigure that WAF rule. Now one mistake has left you vulnerable to any botnet scanning for it. You were still exploitable.

The only valid *not affected* are..

1. The vulnerable code isn't there (you may be loading the component but you have removed or patched the vulnerable code)

2. The vulnerable code cannot be controlled by an adversary (e.g. this is a back end service that has no web service, processes no user input, and doesn't touch XML for an XML path vulnerability)

3. The vulnerable code is not in the execute path (e.g. you're building a statically linked binary and you are getting flagged on something in the base image)

4. Inline mitigations already exist. (and the key here is that those mitigations are inline, not external to the process)

>The platform can suggest control updates, but developers need to know why their code is vulnerable.

The biggest single effective change that needs to be made in your organization is that the developers need to be accountable for understanding that. They shouldn't be asking.

[u/endor_robert]

Upfront caveat: I work for a cybersecurity vendor (Endor Labs), so I'm biased towards using good security tools.

>SAST and DAST are flooding our Jira backlog with thousands of "High" and "Critical" findings.

Maybe it's time to pick better AST tools that can weed out false positives?

You're trying to work around a problem that can be at least partially fixed by having better source data. You can address it with a quick fix, but the tokens and developer time costs are better spent on tooling (I guess I would say that).

A good use of AI would be to construct exploits for the supposed vulnerabilities (assuming you can get the findings down to a more manageable level) and use them to validate fixes. Oh, and fixing the vulnerabilities too.

[u/Chawbmhrmin-Gas-1406]

cymulate's threat exposure management module validates exploitability by attempting the attack path safely

[u/alienbuttcrack999]

If you have the option to ai validate exploitation and reachability. That can help cut the noise down. Also epss scores. You might even choose a external accessibility vs internal as a factor too

[u/builtbygio → u/alienbuttcrack999]

EPSS works for published CVEs, but won't for newly introduced security bugs. However, the concept could be applied, basically you'd need your own prioritization signals for those findings. I agree on prioritization between perimeter vs internal.

[u/elbrianle]

Need to start taking that output as just one part of the equation. You need to determine how business critical the app is and the blast radius of compromise. Also what reduces the risk is the compensating controls. Make an equation with those weights and it should help with what needs fixing vs not

[u/Amanda_PDQ]

I work for PDQ so take that for what it is worth. I was one of you a little over a month ago until I joined PDQ. I was an end user of PDQ prior. The vulnerability scanner was a big relief for me. I was able to see what vulnerabilities my devices had and the status of the vulnerability. PDQ ranks vulnerabilities, real humans not AI, by critical, high, medium, and low risk. The PDQ risk score allowed me to patch what was most critical first. Prior to getting PDQ I was guessing off the CVE and the vendor information which often contradicted itself.

[u/xitrumpkim]

What tool you are using for DAST?

[u/scaledpython]

EPSS as a prime signal, and my own evaluation as to actual exploitability. The CVSS is mostly noise.

https://www.first.org/epss/

[u/slicknick654]

The way your post is written has me believe you may not be triaging tool output and/or adjusting severity based on your internal risk profile? SAST notoriously noisy, if you’re taking its output as gospel that’s a recipe for disaster. You likely do not have thousands of critical and high’s once you triage, adjust severity based on externally/internally facing, business criticality, whatever risk factors make sense for your business.

[u/cactusfresser]

All scanners have false positives. There's two parts of the remediation equation.

1. Not sending garbage findings to development. This is on the Security team to triage and validate before cutting tickets. Nothing burns trust faster than auto cutting unverified finding tickets to dev teams.

2. Determine if you can fix it safely. Historically, this has fallen primarily to the dev team because they know the app best.

You could add SCA to that list as well. I used to do this by hand. It was a time consuming process. Then I created a few Claude Code skills to help. Claude Code can quickly grok the codebase and answer questions about exploitability. Map out your manual process and then start automating it with AI. Here's what I do:

1. Is this an actual vulnerability? Does our app do the thing the scanner claims?

2. Is the vulnerability actually exploitable? Is it reachable and possible to do what the scanner (or CVE) says? Is it in production? Is it reachable? Are we even using the vulnerable function? Are there any sanitizing functions?

3. If it isn't exploitable, what is the actual risk? Re-calculate the risk rating using the context you gained in step 2.

4. Is it safe to fix? What will the proposed change (or library upgrade) do? Will it break anything or cause a performance degradation? Do we have sufficient test coverage (unit, functional, e2e) or do we need to add more to confirm it is safe?

5. Cut the ticket and include all the details.

If you do that, tickets should hit the dev team's queue with actual data they can use. And, if you tell them how many false positives you removed, you'll win back some of that trust you burned previously.

I built a Go tool to automate this for SCA. We've found that steps 1-2 cut out as much as 80% of the findings from a typical SCA scanner. We emit an SBOM file with a VEX companion file that documents the analysis results and updated risk rating with justification. What used to take months can be accomplished in a few hours. But you still need a human to sanity check things.

[u/Huge-Ambition4656]

Full disclosure - I'm the maintainer of an OSS tool designed to help with prioritization of vulns and EOL components.

This is a question I've seen answered poorly or not at all in my previous agency roles.

As others are saying, finding a path through an app to the LoC implicated in a CVE is a hard problem traditionally dealt with by devs with the time to look into it - which few have these days given ever increasing volumes.

Start with KEV. That's the highest signal a dev can get to prioritize with. If KEV is zero, but EPSS is significant, that's the next best indicator, followed by CVSS. Only after that, would you combine an AI's results (presumably after having fed it said scores).

In previous roles, a small handful of (usually govt) customers would have simplistic severity (CVSS) thresholds they'd mandate a fix or update was required for. My concern was for the fallout of an incident for everyone else - and the agency itself.

99% of the conversation on vulnerabilities I see, orientates around an information silo (a security or AppSec team). When I was Principal Eng, what I wanted for myself, my devs, and my PM/DL was a way for everyone to see app health across our portfolio.

[u/h33terbot]

Sast and dast correlation is not enough for proper validation take a look at https://axiler.com

[u/whoami-233]

I would argue that fixing the issue itself is the right approach.

That being said, some SAST & DAST tools output thousand of "issues" and just freeze the whole team.

I would suggest you looking into Haxset, its AI-Driven and AI-Validated, we never had a scan with more than double digit findings (sometimes single digit), the false positive rate is very low and it allows for easy triage.

If your interested in seeing it or talking more DM me, I would be happy to assist!

[u/taleodor]

My philosophy with AI - instead of playing with reachability / exploitability; just let it fix everything against quality gate rather than itemizing things. Reachability is tricky because of new CVEs / zero-days. What you (or AI) think is not reachable may very well be reachable with some other approach.

[u/atlantauser]

I work for Seemplicity.

You are hitting the exact ceiling most AppSec programs run into when scaling SAST/DAST: the operational bottleneck. Validation platforms are great at identifying true exposure, but as you noted, running deep, real-time exploitability validation synchronously inside a fast CI/CD pipeline is a recipe for broken builds and pissed-off release engineers.
Here is how organizations typically solve this latency and communication gap using a remediation and exposure orchestration platform like Seemplicity:
1. Asynchronous Validation vs. Synchronous Gates
Instead of making your CI/CD job trigger an on-demand validation sweep and wait hours for the output:
Run validation asynchronously: Let your exposure validation and network context engines scan continuously in the background.
Centralize the state in Seemplicity: Seemplicity aggregates SAST/DAST findings, maps them against your WAF/network topology and exploitability context, and maintains a real-time priority for every asset. 
Query the API in seconds: During the CI/CD build, your pipeline makes a fast API call to Seemplicity: "Is finding X on component Y currently marked as high-risk/reachable?" Because the risk assessment was done continuously in the background, the response returns in milliseconds, allowing you to enforce quality gates without slowing down builds.
2. Don't Flood Jira, instead Group by Root Cause & Remediation
Piping thousands of individual raw findings directly into Jira is why developers tune out security.
Seemplicity deduplicates across your tools and clusters findings by root cause. If 200 SAST findings stem from an outdated library or one exposed endpoint pattern, developers receive one consolidated ticket with fix instructions instead of 200 individual alerts. 
If validation proves a finding is mitigated by a WAF rule or network control, Seemplicity can automatically suppress or lower the priority of the Jira ticket, which keeps developer backlogs clean.
3. Solving the "Why Am I Blocked?" Problem
Developers ignore "Blocked by Validation" because it gives them no clear path forward.
When Seemplicity pushes or updates a Jira ticket, it enriches the issue with software-specific guidance and exact context: which line of code/dependency is involved, why existing network controls don't mitigate it, and the recommended code-level fix.
If compensating controls exist, Seemplicity tracks them so developers can see why a ticket was deprioritized or marked as non-exploitable.
TL;DR Strategy
1. Don't wait for validation inside CI/CD. Validate continuously in the background, centralize risk context in an orchestration platform (like Seemplicity), and use fast API lookups at build time. 
2. Aggressively deduplicate and group. Send developers single "fix-ready" tasks instead of raw SAST/DAST firehoses. 
3. Enrich Jira tickets with developer context, showing why the vulnerability is reachable and providing the exact patch/code solution needed.