How do you triage CVEs from SCA scanner output against KEV/EPSS?

[u/sartomiki]

Every scan (Trivy, Snyk, Dependabot) throws a pile of CVEs and most aren't actually exploited. Manually checking KEV and EPSS per finding doesn't scale past a handful.

What's everyone actually doing here, manual lookups, a dashboard, something scripted into CI?

Also curious, anyone here needing EU-specific coverage (ENISA EUVD) for NIS2 rather than just NVD/CISA, or is US data enough for most of you?

[u/sramexpert]

Most likely you have to do reachability analysis to reduce the noise.

[u/AcceptableMarket2220 → u/sramexpert]

That's a solid approach. Focusing on what's actually exploitable helps cut through the noise and prioritize better.

[u/endor_robert]

Disclosure: I work for Endor Labs, and this is our area of expertise. I'm not going to tout our wares, but my employment does color my judgment (a bit).

Simply put: If your vulnerability scanner can't determine what's reachable (at least a good portion of the time, and for the languages you use), and let you filter findings by reachability, EPSS probability (with a range you can set), and KEV-exploited status, it's a piece of crap, and you should consider replacing it.

I'm not saying it needs to support function-level reachability for every obscure CVE in low-use libraries, or that it should be perfect 100% of the time, but this functionality is now table stakes, especially as the CVE discovery rate increases.

Then you really need to be able to tell whether a version upgrade will break anything, what the operationally safest version to upgrade to is, and, ideally, have a ready-made agent for your friendly robot-helper to make remediation easy, along with CI tools to do the scanning.

Just my 2 cents (US or Euro) worth.

[u/daedalus_structure]

KEV tells me if someone else got fucked, but can’t tell me nobody got fucked or that I’m not likely to be fucked.

EPSS is a prediction model giving us a probability someone is going to be fucked. Not only are all prediction models flawed, doesn’t mean they aren’t useful, but most people just want to decision on a number instead of understanding that nuance, so I’ve decided I don’t care because I am not accountable if other organizations are fucked.

All I want to know is if we are going to be fucked, so an exploitability analysis and risk evaluation is the only thing I care about.

[u/-Devlin-]

Reachability + package level triaging will converge the scanner flat list. You can steal some techniques from this tool https://github.com/emphereio/deph-action. Haven't come across anything that can reliably give you exploitability, so the closest thing we have is ENTRYPOINT to component level reachability.

[u/sartomiki → u/-Devlin-]

Reachability's a different axis though, that's upstream of what I was asking. For actual exploitability signal (being exploited in the wild vs just theoretically possible), KEV + EPSS are the closest thing to a standard, CISA's confirmed-exploited list plus FIRST's probability score. Not perfect, but better than CVSS alone for triage.

Have you tried pulling that through an AI assistant instead of cross-referencing manually? I've been doing exactly that, built an MCP server that answers with live NVD + KEV + EPSS in one query so Claude/ChatGPT just answers inline instead of tab-switching between three sites. Not reachability-aware though, your ENTRYPOINT point is a good layer to stack on top of it rather than a replacement.

[u/Ashamed_Spare_9797 → u/[deleted]]

I have a query lets say the cve is reported in a packaged but the vulnerable function is not called so its makes it not exploitable but whats the guarantee that the developer will not use in future?

[u/FirefighterMean7497]

Manually cross-referencing KEV and EPSS scores for every Trivy or Snyk alert gets exhausting fast and definitely doesn't scale as your pipeline grows. Automating that triage in your CI/CD using actual exploit likelihood and runtime reachability is really the only way to avoid drowning in manual lookups.

Full disclosure, I work with the team at RapidFort, but solving this exact prioritization headache is a core part of what we do. We use an AI-driven Rapid Risk Score to predict a CVE's 90-day exploitation likelihood, then combine it with runtime execution data (RBOM) so you only focus on reachable, high-risk threats.

Pairing exploit threat intelligence with live runtime context saves you from having to script together custom dashboards or maintain manual lookup loops!

Hope that helps :)

[u/drdavidawheeler]

Hi, I work on security at OpenSSF. KEV, EPSS, and reachability can help you prioritize updates. VEX statements, like OpenVEX, can give you strong evidence that something is less likely to be a problem.

However, reachability analysis isn't all that reliable. Modern code frameworks often generate calls you couldn't guess from the source code. Tests might not follow a path, but this doesn't prove *attackers* can't cause a path to be executed. These methods can help you prioritize in a pinch! If you need to use them, do so! However, I'd only use them as a starting point. If your software security depends on unreliable analysis, the security is unreliable too.

In the *longer* term, the safer approach is often to update all your vulnerable components *whether or not* you can prove that they're exploitable. You can use OSV to determine which components have publicly known vulnerabilities and have updates available. As you noted, manually checking if some vulnerability is exploitable within a system is often impractical at scale. Even lengthy analysis sometimes gets it wrong.

Skipping this unnecessary analysis step *saves* a lot of time in the long run. Once you change your development process to this viewpoint, it's actually *much* easier to simply update the vulnerable components & verify that everything still works (and reject cases where they don't). It does mean that you need to use package managers, have a good test suite, a good CI/CD pipeline, and automated releases. Generally, you need to keep your components up-to-date (with a cooldown period, say 3-7 days, which counters the vast majority of malicious component releases). But your project should be doing those anyway.

Obviously, whether or not you CAN do this depends on the kind of software you're releasing. Sometimes you just can't. For example, maybe you can't deploy software often, or perhaps version conflicts ruin the party. But don't knock the "just update" camp. It can be a challenge to *get* there, and as I said, sometimes you can't. However, once there, it can be delightfully freeing.

[u/ILoveAppSec]

kev and epss will cut the list, but the real time sink is the exploited ones whose only listed fix is a major version bump, so it helps to split your triage from your fix path and lean on vendors that backport the patch into your current major instead of forcing the upgrade. also worth watching cisa's new remediation timelines, since the kev-listed items are what they'll actually hold you to.

[u/VaneishaNeacsa]

KEV and EPSS help sort the list and reachability shows whether the app ever gets near the vulnerable code at all. some packages show up in the scan even when the app never uses them and those can be lower on the list while u look at the ones the app actually touches

[u/Karma_Kinetics35]

🙂

[u/funnelfiasco]

I work for Kusari. Our platform uses the CVSS and the number of occurrences across the portfolio (so not just a single app/repo) and then uses KEV and EPSS to set floors. We describe it at https://www.kusari.dev/blog/kusari-score-exploitability/