Samarthya

In the last post I argued that prioritization – not patching speed – is the discipline that keeps security teams afloat. That’s easy to say and hard to operationalize.

This post is the workflow; it’s the triage flow I’d actually run, the decisions at each gate, the traps that ambush teams, and the practical tips that separate a program that scales from one that drowns.

The Mental Model: Triage Is a Funnel, Not a List

The single biggest mistake is treating a vulnerability scan as a to-do list to be worked top to bottom by CVSS score. It isn’t a list. It’s a funnel, and each stage exists to remove items from human attention so that the handful reaching the bottom genuinely deserve an engineer’s time.

Every stage should be as automated as possible until the very bottom, where judgment lives. If a human is manually reading CVSS scores off a scanner export, the funnel is broken.

Stage 0: Normalize and De-duplicate (Before Triage Even Starts)

You cannot prioritize what you can’t trust. Most teams underestimate how much noise sits above the triage layer.

What happens here:

• Consolidate sources. SCA, SAST, DAST, container scanning, cloud posture, and pentest findings all speak different dialects. Normalize them into one schema (asset, location, CVE/CWE, severity, source, first-seen).
• De-duplicate ruthlessly. The same CVE in a base image layer can appear in 200 containers. That’s one remediation decision, not 200 tickets.
• Validate reachability early. Reachability analysis (does your code actually call the vulnerable function?) can eliminate 60–80% of dependency findings before a human ever looks. A vulnerable package you import but never invoke on a vulnerable path is often not a real risk.
• Suppress with an expiry, never permanently. False positives get suppressed — but with a review date, so a suppression doesn’t quietly become a blind spot forever.

Practical tip: Track your noise ratio – findings suppressed or de-duplicated vs. findings actioned. If 95% of raw findings never become work, that’s not a failure; that’s the funnel doing its job. But measure it, because a sudden shift signals either a new tool misconfigured or a real change in your exposure.

Stage 1: The Emergency Gate – “Is it burning right now?”

Before any scoring, ask one binary question: is this being actively exploited?

The signals that trigger the emergency track:

• CISA KEV listing. If the CVE is on the `Known Exploited Vulnerabilities` catalog, exploitation is confirmed in the wild. This overrides CVSS entirely. A KEV-listed 6.5 beats a non-KEV 9.8.
• Vendor emergency advisory or an out-of-band patch. Vendors don’t break their patch cadence for fun.
• Credible threat intel naming the CVE in active campaigns, especially targeting your sector.
• Public weaponized exploit (not just a PoC) for an internet-facing asset you run.

What “emergency” actually means operationally: a defined SLA (e.g., 24-72 hours), authority to bypass the normal change queue, and a pre-agreed mitigation path if a patch isn’t ready — WAF virtual patch, feature disablement, or network isolation.

Practical tip: Pre-negotiate the emergency path before you need it. The middle of a Log4Shell-scale event is the worst time to discover you don’t have change-management authority to patch production over a weekend. Get that agreement in writing, tabletop it once a year.

Stage 2: Exploitability Scoring — “Can it realistically be used against us?”

Everything that survives the emergency gate now gets scored – but not on CVSS alone. Layer exploitability signals on top of severity.

Build a composite that blends:

How to read EPSS in practice: EPSS gives a probability, and the distribution is heavily skewed – the vast majority of CVEs sit below 10% and will likely never be exploited. A CVE at EPSS 0.85 is in rare, dangerous company. Use a threshold (many teams start around EPSS ≥ 0.1 combined with high CVSS) and tune it against what your team can absorb.

Practical tip: Don’t invent your own exploitability math from scratch. The Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree from CISA/CMU is a free, defensible framework that walks you from

“exploitation status” → “exposure” → “mission impact” to a clear Act / Attend / Track / Track outcome.

Auditors love it because it’s a documented, repeatable decision – not a gut call.

If you run enterprise tools like Blackduck, the first three stages of the generic funnel – consolidate, enrich, score — are already handled inside the platform. This is the whole point of paying for the tool: you don’t build a consolidation pipeline, you configure a policy.

Blackduck’s BDSAs deliver, out of the box:

• Reachability analysis — whether your code actually invokes the vulnerable function, which is what kills most dependency noise.

• Consolidated, de-duplicated findings across your dependency tree (direct and transitive) — no multi-scanner reconciliation to run.

• Custom CVSS scores with temporal metrics — a sharper severity snapshot than raw NVD base scores.

• CISA KEV tagging — actively-exploited CVEs are already flagged on the finding.

• EPSS scores — 30-day exploitation probability attached to each CVE.

Stage 3: Business Context – “Does it matter to us?”

This is where a security engineer’s view and a CISM’s view diverge, and where most tools stop being helpful. A scanner knows the CVE; it does not know your business.

The multipliers that turn severity into risk:

• Asset criticality. A vulnerability on the payment authorization service and the same vulnerability on a marketing microsite are not the same risk. You need an asset inventory with a criticality tier, or this whole stage is guesswork.
• Data sensitivity. What does the asset touch – PII, PHI, cardholder data, crown-jewel IP? Regulatory exposure changes the calculus.
• Exposure. Internet-facing and unauthenticated is a different universe from internal-only behind MFA and segmentation.
• Existing compensating controls. A vulnerable service already fronted by a WAF, an IPS signature, or strict egress filtering carries lower residual risk.
• Blast radius. Lateral-movement potential — a foothold on a flat network is worse than one in a well-segmented enclave.

The working formula (a decision aid, not a science):

Residual Risk = Severity × Exploitability × Asset Criticality × Exposure ÷ Compensating Controls

Don’t over-engineer this into false precision. Its value is forcing the conversation about the last three factors that scanners ignore, and producing a defensible, consistent ordering.

Practical tip: If you have no asset inventory with criticality tiers, that’s your real project – not vulnerability management. You cannot do risk-based prioritization on assets you can’t rank.

Even a crude three-tier classification (crown jewel / important / commodity) transforms triage quality overnight.

Stage 4: Remediation Decision — “What do we actually do?”

Prioritization isn’t only about what’s riskiest – it’s about risk reduced per unit of effort.

A moderate-risk finding with a one-line dependency bump may deserve to jump ahead of a high-risk finding that needs a six-week refactor and a downtime window.

For each item reaching this stage, pick a disposition:

1. Patch — the default when a fix exists and effort is reasonable.
2. Mitigate — compensating control when patching is disruptive or unavailable (virtual patch, config change, feature disablement, isolation).
3. Fix the class, not the instance — if the same CWE recurs (SQLi, hardcoded secrets, unsafe deserialization), invest in a systemic fix: a secure library, a lint/SAST gate in CI, a developer guardrail. One well-placed control kills the next fifty instances.
4. Accept the risk — formally, with an owner, a rationale, and an expiry date. Risk acceptance is a legitimate, mature outcome — silent risk acceptance (a finding that just ages out ignored) is negligence. The difference is documentation and accountability.
5. Transfer — occasionally the right answer is contractual or insurance-based, especially for third-party components.

Practical tip on effort estimation: Weight remediation by disruption, not just developer hours. A trivial patch that forces a regulated-system revalidation can cost more than a gnarly one in a low-stakes service. Ask “what breaks if we do this?” before “how hard is the code change?”

Stage 5: Close the Loop — Verify, Measure, Improve

Triage that doesn’t verify remediation is theater.

• Confirm the fix. Re-scan or re-test. “Ticket closed” is not “vulnerability gone” — teams routinely close tickets against patches that didn’t fully deploy.
• Track the metrics that matter:
  • Time-to-remediate by severity tier (are you hitting your SLAs where it counts?)
  • Mean time from KEV listing to remediation (your emergency-response health)
  • Backlog age distribution (is old risk quietly accumulating?)
  • Recurrence rate by CWE (are the same weakness classes coming back? If so, Stage 4 option 3 is failing)
  • Noise ratio (funnel efficiency, from Stage 0)
• Feed findings back into prevention. Recurring CWEs should become CI gates, secure-by-default libraries, and developer training topics. The best vulnerability is the one that never gets written.

Practical tip: Report risk burndown, not vulnerability count, to leadership. “We reduced critical, internet-facing, actively-exploited exposure by 70% this quarter” is a board-ready sentence. “We closed 3,000 findings” invites the question “how many are left?” and makes you look like you’re losing.

The AI-Era Amplifiers (and How the Flow Absorbs Them)

Each stage of this funnel earns its keep specifically because of the current pace:

• Stage 0 matters more because AI-driven scanners and coding assistants generate more findings and more false positives than ever. Automated de-dup and reachability are now survival tools, not nice-to-haves.
• Stage 2 matters more because attacker time-to-weaponize is compressing. EPSS and KEV as near-real-time signals keep you ahead of the shrinking disclosure-to-exploit window.
• Stage 4 option 3 matters more because AI-generated code reproduces classic CWEs at scale. Fixing patterns via CI gates beats chasing individual instances forever.
• Automate the funnel, reserve humans for the bottom. Use automation (and increasingly, AI-assisted triage) to compress Stages 0–2. Reserve scarce human judgment for Stage 3 business context and Stage 4 disposition — the parts that require knowing your organization.

A caution on AI-assisted triage: it’s genuinely useful for summarizing, clustering, and drafting risk rationales — but treat its output as a recommendation requiring validation, not a verdict.

An AI that confidently mis-ranks a crown-jewel asset because it lacks your business context is a new failure mode. Keep the human at the disposition gate.

The One-Page Version

If you remember nothing else, run every finding through these questions in order:

1. Being exploited now? (KEV / threat intel) → Emergency track.
2. Realistically exploitable against us? (EPSS + reachability + exposure) → If no, deprioritize hard.
3. On something that matters? (asset criticality + data sensitivity) → Scale urgency to value.
4. What’s the cheapest effective fix? (patch / mitigate / fix-the-class / accept) → Maximize risk reduced per unit effort.
5. Did it actually get fixed, and is the class coming back? (verify + measure) → Close the loop and feed prevention.

Everything else is detail. The discipline is refusing to let a 10,000-row scanner export dictate your priorities — and replacing it with a repeatable, defensible funnel that ends in decisions your leadership, your engineers, and your auditors can all stand behind.

That’s not fixing faster. That’s deciding smarter — at scale, at pace.