Most vulnerability programs are stuck in a loop of scanning, reporting, and patching that offers a false sense of accomplishment. Escaping this cycle requires shrinking the attack surface, prioritizing with context, and applying pressure that drives remediation without alienating the teams who do the work.

Most vulnerability management programs are a self-defeating loop. We scan, generate reports, and chase patches. This approach keeps everyone busy but rarely drives meaningful risk reduction. Our scans lack visibility, and their severity ratings don’t account for context.

As a result, the effort to apply patches distracts from higher-impact work. To escape this hamster wheel of pain, we should:

• Reduce the attack surface so there’s less to patch
• Look beyond scanning to identify the vulnerabilities
• Use context when prioritizing remediation
• Apply pressure so the findings are addressed responsibly

Reduce Your Attack Surface

Most vulnerability programs optimize for a “local maximum” by focusing on faster patching. We look for reductions in mean-time-to-remediate, and celebrate incremental improvements. This approach can’t keep pace with the unending stream of new vulnerabilities.

The “true maximum” starts with reducing the attack surface. Yes, we should address the security issues in our environments. But the only way to keep up is by shrinking what requires remediation in the first place.

First, let’s work with colleagues in IT and DevOps to find unnecessary servers, user accounts, installed software, and SaaS apps. The fewer IT components we have, the less work we have to put into securing them. This improves security as well as lightens the IT load and reduces costs.

What we can’t remove, we can make more resilient. This way, if a vulnerability is discovered on that resource, its risk will be lower, giving the organization more time to respond or, if the risk is low enough, ignore the finding. Restricting public internet access to a system is a classic way to lower risk.

Look Beyond Scanning

Scanning the network to find vulnerabilities presents a limited view. The scanner can rarely access all the systems and is too slow to detect short-lived resources. And for the systems they can access, the scanners need credentials, which are hard to maintain. As a result, scanners produce lengthy reports that lack important vulnerabilities while overwhelming teams with irrelevant findings.

Relying solely on scanning creates an illusion of managing vulnerabilities. At best, it helps with compliance. At worst, it distracts from the more important efforts.

A better approach is to tap into multiple data sources, not just the scanners. Gather vulnerability details from endpoint agents, cloud infrastructure tools, systems management software, and other systems that can catalog installed software or uncover a configuration issue. This gives us more reliable and comprehensive findings and provides context for prioritization.

Prioritize with Context

The values used to compute the base vulnerability score (CVSS) are assigned without any knowledge of the organization, assuming the worst-case scenario. This inflates severity compared to actual risk when we take into account organization- or system-specific factors. To prioritize accurately, we should consider these factors alongside the base CVSS score:

• How likely is an attacker to reach and exploit the system (e.g., is it accessible from the internet)?
• What mitigating factors (e.g., outbound restrictions) reduce exploit success?
• How sensitive is the data on or accessible from that system?

Context can also reveal that a vulnerability is more urgent than the base score suggests. For example, a CVSS 6.5 on an internet-facing authentication server with access to sensitive data might warrant faster remediation than a CVSS 9.0 on an isolated test system.

Context-based scoring does more than improve accuracy. It builds trust with the teams that must perform the remediation. If colleagues know that our rankings account for meaningful risk, they are more likely to take us seriously.

Apply Pressure Responsibly

Security leaders own the vulnerability management program. Yet, our teams rarely have the authority to patch systems directly. The servers might be managed by the SREs, in-house software by developers, and endpoint software by IT. Then what’s our role? We can start by:

1. Identifying vulnerabilities across all relevant resources.
2. Cleaning the vulnerability data to ensure accuracy.
3. Assigning risk-based priority to the findings by accounting for context.
4. Communicating to the relevant teams which issues they need to address and with which priority.

Next, we can monitor the remediation progress, confirm that the fixes are deployed, and measure whether the teams stay within the target remediation timeframes. Yet, if all we do is report on mean-time-to-remediate and similar metrics, we’re not doing enough.

As security leaders, we should apply pressure while being supportive, firmly ensuring the right work gets prioritized while understanding the constraints and incentives of the teams who must do the work.

To apply pressure constructively, understand what motivates other teams. What are their objectives? What does success look like from their perspective? We can attend their sprint meetings and similar discussions. Understand their world, frame the discussion on their terms, and be collaborative.

Breaking the Loop

This is how we escape the hamster wheel: Not by running faster, but by shrinking what needs to be patched, seeing more of what matters, prioritizing with context, and holding teams accountable without alienating them. The result is a vulnerability program that genuinely reduces risk.