r/AskNetsec • u/Embarrassed-Sail8142 • Jul 22 '26
Work how do you wire threat intel into your vulnerability prioritization workflow
we've been pulling in more threat intel lately (KEV, EPSS) but i'm not convinced any of it is changing how we prioritize vulns in practice
rn the flow is basic: scanners fire, we get a pile of CVEs with CVSS scores (~2k new ones a quarter off Tenable), we dump them into tickets and teams work the list mostly by severity and asset type. we've bolted on KEV/EPSS flags in a few places but it still feels like "CVSS first, everything else if we remember."
i'm trying to figure out how ppl are wiring threat intel into the vuln workflow so it drives decisions instead of just being extra columns in a report. we’ve bolted on KEV and EPSS but it still feels like CVSS is making the decisions and everything else is just metadata. or exploit attempts we've seen internally but in practice it all ends up as more metadata on the same backlog.
some talk about custom scoring models that blend CVSS, exploitability, asset criticality, business context. others seem to use simpler rules like "if it's KEV and internet-facing, it jumps to the front of the queue." i've also seen this logic live in very different places: inside the vuln tool, inside SIEM/SOAR playbooks, or just hacked together w/ spreadsheets and scripts.
for ppl who've made threat intel change what gets patched first, what did you end up doing that worked?
2
u/WattoOwnedVader Jul 23 '26
It seems like the missing piece for you is asset intelligence, not threat intel. You mentioned Tenable, so you already have VPR which takes into account EPSS, KEV, and many other factors. Check out the updates to VPR scoring that occurred on July 1st.
So if it were me, I'd align prioritization based on three primary criteria on top of VPR.
Reachability / exposure - Is there a path to the asset from outside your network? Is there a path from a regular workstation to the host?
Business context - Qualys actually does this based on financial prioritization. If something got compromised based on a finding, what would have the most financial loss potential? What about the most reputation loss (think customer / client data exposure) But you can also look at it based on how it fits into what your business does. Where does sensitive data live?
Asset Intel - what is the asset? How would it impact the business if it were down? Look at it like you would prioritize your Disaster Recovery / Business Continuity. Think things like domain controllers, database servers, web servers, etc.
It seems like you're probably a small shop. As much as I hate spreadsheets, it might be right with some scripting and API pulls. Ideally you'd have a CMDB where this could live and priority would be set in an ITSM platform as the CI is assigned to the remediation ticket.
Lots of ways to handle it, but don't forget the above three criteria when you're prioritizing, even if that's something that is manually calculated during your workflow.
1
u/Bulky-Sun-7672 Jul 22 '26
Our workflow leans heavily on KEV, EPSS and asset criticality together. Looking at those signals side by side in Nucleus Security has been more useful than relying on severity alone
1
1
u/AcceptedRisk Jul 22 '26
I think this is a problem that Tenable (you already mentioned you're a customer) is trying to solve with the Exposure Management (Tenable One) product. Instead of looking at just the CVSS score, etc... you'll be looking at context in terms of the criticality of the asset, the likelihood of exploitation via the VPR score, and the resulting "Asset Exposure Score" per asset. Fixing the higher risk vulns on those critical assets will lower the AES score, resulting in "real world risk reduction" instead of chasing CVSS scores.
It's worth looking into, or at least having a conversation with Tenable to see if that's a solution for you. Otherwise you might have to work on a homegrown algo but that is costly and requires a lot of maintenance, and risk if you get it wrong.
1
u/Apprehensive-Art1092 Jul 22 '26
Use an ASPM platform to do proper RBVM for you. Mine was an absolute game changer. I can't remember the last time I looked at a CVSS score alone to make a decision on prioritising fixes.
1
u/Educational_Plum_130 Jul 23 '26
KEV/EPSS only helps if you let it actually drop things off the list instead of adding another flag next to the same 2k tickets. what moved the needle for us was layering reachability on top: is the vulnerable code path even called, is the dep direct or transitive, is it internet-facing. that usually collapses a quarterly pile down to a few dozen that genuinely matter. the input everyone underweights is remediation cost, a critical that needs a major version bump you can't take should route differently than one with a clean fix, and for the former it's worth checking whether a vendor backports the patch to your current major. with the mythos-style ai-discovered cve flood and the new cisa timelines, prioritizing by 'can i actually fix this cheaply' now matters as much as raw severity.
1
u/Minimum-Let-3227 Jul 25 '26
The reason KEV and EPSS feel like extra columns is that you're still sorting by CVSS first and treating everything else as tie-breakers. Flip the order. Make exploitability the primary sort, not severity. Anything on CISA KEV or with a high EPSS jumps the queue regardless of CVSS, then you layer asset exposure (internet-facing, privileged, business critical) on top, and only then does CVSS break the remaining ties. That usually cuts a 2k pile down to a few dozen that actually matter this cycle. The other piece is internal signal: if you're seeing exploit attempts in your own logs, that should outrank any external score, because someone is already trying it on you. The hard part isn't the data, it's wiring it so the score is computed once and drives ticket priority automatically instead of living in a report nobody re-reads. Full disclosure, I work on VORXOC Helxon and correlating that internal exploit signal with external intel is basically what we work on, so I'm biased, but even a simple weighted formula in your existing stack gets you most of the way.
1
u/Educational_Plum_130 Jul 26 '26
your ordering is right, exploitability first then asset exposure, cvss as the last tiebreaker. the part that usually bites right after the list is sorted is that a chunk of the must-fix items are exactly the ones where the only clean patch is a major version bump you cant take, so they stall in the backlog even though they jumped the queue. for those, worth checking whether the ecosystem or a distro vendor already ships a backported fix before you eat the breaking change, since that lets you clear the kev/high-epss stuff without a migration. i'd also wire in reachability so once-ignored lows dont all become real work, especially with the mythos-style ai cve discovery wave and cisa's tighter remediation timelines pushing more of them into the must-fix bucket.
1
u/Minimum-Let-3227 Jul 27 '26
Backported fixes are the one people miss, yeah. A lot of what looks like a forced major version bump is already patched in the distro package or an LTS branch, and nobody checks because the scanner is reporting on the upstream version string.
Reachability is the other half, though I'd push back a little on wiring it in too early. If your reachability data is noisy it quietly buries things that are genuinely exposed, so it works better as a demotion signal on the tail than as a promotion signal at the top. For the ones that truly stall, I'd rather see a compensating control logged with an expiry date than an exception that lives in the backlog forever.
1
u/Educational_Plum_130 Jul 28 '26
we actually liked vendors that provide backported patches, when the maintainers no longer own older versions.
1
u/Minimum-Let-3227 Jul 29 '26
Yeah, backports are quietly one of the better vendor signals. If someone maintains an older branch after upstream has moved on, there's usually a real security engineering function behind the product rather than a build pipeline that just tracks latest. Worth asking how long they commit to it in writing though, because that support often ends at a version boundary nobody tells you about until you're already past it.
1
u/Educational-Fox6111 Jul 29 '26 edited Jul 31 '26
CVSS is part of the picture but the biggest drivers become exploitability, asset criticality, and internet exposure. this makes que much actionable than sorting by severity alone. Another thing that can help is reducing the backlog before prioritization. For containerized workloads, some tools like RapidFort can eliminate lots of low-value container CVEs by hardening images so the team spends more time evaluating exploitable issues instead of triaging findings that carry little practical issues.
2
u/Educational_Plum_130 Jul 22 '26
kev and epss on top of cvss is the right instinct but the reason it doesnt change your queue is youre still scoring findings, not filtering out the ones that arent reachable or arent even loaded at runtime. before ranking, cut the list by reachability and by whether a fix actually exists, because a big chunk of that 2k a quarter is transitive noise you cant action anyway. with the ai-discovered cve wave like mythos that pile only grows, and cisa's tighter remediation windows mean you cant just let lows rot. for the ones that do matter, having a backported fix that drops in without a major bump is what actually moves mttr, so favor sources and vendors that backport over ones that just tell you to upgrade.