This is a follow up on my previous post titled “Vulnerability Management Pitfalls (and How to Avoid Them)“. It dives into one of the topics listed there: Poorly prioritized issues. Given its importance, I felt it deserved a dedicated post.
One of the most common mistakes I see Vulnerability Management (VM) teams make is surfacing every identified risk, regardless of whether the organization has the capacity to act on it.
As VM teams mature, they expand automation across more surface areas, surfacing more risk in the process. But the organization’s capacity to remediate risk often remains fixed. This mismatch creates mounting pressure.
Once the volume of surfaced risk exceeds the organization’s ability to respond, things start to break down.
Teams begin to feel overwhelmed. Requests from security start taking longer to resolve or are ignored entirely. Over time, the Vulnerability Management team risks losing credibility and goodwill across the organization.
So What Should Vulnerability Management Teams Do?
Instead of surfacing every risk as a discrete task, VM teams should focus on creating continuous mechanisms for reducing risk. Think in terms of policy and automation rather than one-off requests. Use discrete tasks sparingly, reserving them for critical, time-sensitive vulnerabilities, like CVEs with known exploits that impact the critical path or reproducible bug bounty reports.
With the right metadata, the VM team can quickly assess the critical systems and deprioritize most of the tasks. This requires a deeper understanding of your organization’s infrastructure—and often, the creation of new datasets. But the long-term benefits far outweigh any short-term slowdown.
Below we can see a few common themes that might be useful across the industry:
Policy-Driven Risk Reduction
Define organization-wide security policies that can be enforced through infrastructure (e.g., image freshness, minimum package versions) It sets clear expectations and eliminates the need to chase teams down for repeat issues.
Example: A policy that “containers must be rebuilt every 30 days” can replace dozens of tickets about outdated dependencies.
Automation Over Notification
Build systems that automatically handle known classes of risk (e.g., patch management, stale secrets, outdated libraries). It removes human effort for common fixes and frees up attention for critical work.
Example: Automated host rotation using hardened base images instead of asking teams to patch vulnerabilities.
Leverage Metadata and Asset Context
Enrich findings with metadata such as ownership, internet exposure, data sensitivity, and usage environment. You can filter out low-priority issues and escalate only meaningful ones.
Example: A vulnerability on an internal dev tool is deprioritized, while the same issue on a public-facing API triggers a task.
Dependency and Supply Chain Controls
Block high-risk dependencies or packages at the CI/CD level. Prevents bad decisions early in the pipeline instead of cleaning them up after the fact.
Example: Use tools like Dependabot or Xray with policies that prevent merging code with unreviewed critical CVEs.
Triage and Threshold-Based Escalation
Define thresholds (e.g., EPSS scores, known exploits, volume of affected assets) for when a risk should become a ticket. Helps avoid alert fatigue and aligns expectations.
Example: Only surface risks that have confirmed exploitation in the wild or affect more than X% of infrastructure.
Invest in Program-Level Thinking
Think in terms of long-term security outcomes instead of vulnerability whack-a-mole. Encourages systemic fixes over reactive noise.
Example: Instead of surfacing each outdated library, identify patterns (e.g., which teams need better upgrade workflows) and fix those root causes.
Partner Early With Infra and Dev Teams
Involve partner teams when designing controls to ensure they’re feasible, adoptable, and observable. Builds shared ownership and avoids friction when enforcing or monitoring.
Example: Collaborate to implement a shared image registry that can be centrally monitored for freshness.
These examples only scratch the surface. The right policies and automations depend heavily on your organization’s structure and risk tolerance. But the takeaway is the same: make discrete tasks exceptional, and they’ll be treated as such.
The next time your team rolls out a new Vulnerability Management program, ask yourself: can most of this risk be addressed through automation or policy? That answer will shape whether your program earns engagement or resistance.