Vulnerability management may start as a focused security process, but mistakes in it quickly affect risk management, compliance, patch management, internal policies, KPIs, and even executive reporting.
Knowing the Problem Isn’t the Same as Solving It
Measure Security Tools by the Work They Eliminate
Remediation Targets Need to Reflect Operational Reality
From what I have seen across different organizations, many teams approach vulnerability management as a relatively straightforward process. You run a scanner, review the findings, classify them, and create tickets.
What often comes as a surprise is that detection is not where most of the effort goes. The most time-consuming part is remediation.
Knowing the Problem Isn’t the Same as Solving It
This becomes obvious once the vulnerability reaches the engineering team.
It’s easy to tell a developer: “There is a line of code with an SQL injection.” The developer will probably agree that it’s a problem. The difficult question comes next: what exactly should be done to fix it?
The same challenge appears when a vulnerability is found in a third-party dependency. You may need to patch or replace the library, but the patch may not exist. Replacing it may affect the entire system. The decision is no longer purely technical—it has a direct business impact.
This is where AI can help, but only up to a point. It can assess the severity of a finding, process the results, and suggest possible solutions. But once remediation affects delivery timelines, system stability, or the business itself, AI can only advise. The final decision still belongs to the people who understand those trade-offs.
Measure Security Tools by the Work They Eliminate
One mistake I’ve seen repeatedly is evaluating security tools by how many findings they produce. In practice, more findings rarely mean better security if they also create more work.
Every new scanner promises better visibility. As organizations adopt more tools over time, it often creates another report, another dashboard, or another list of findings. If engineers have to compare multiple reports or investigate the same issue several times, the process becomes less efficient, not more secure.
That’s why findings should be aggregated and triaged before tickets are created. If the same vulnerability is detected by a scanner and later confirmed during penetration testing, it should still become a single ticket with all the relevant context. The goal is not to deliver every finding but to deliver the right information to the right people.
Additional tools can help with aggregation, deduplication, and automation—but only if they eliminate duplicate work rather than create more of it.
Remediation Targets Need to Reflect Operational Reality
The complexity of remediation becomes especially visible when organizations define remediation targets. Many aim for the shortest possible remediation SLA. In practice, that target has to be consistent with how vulnerabilities are identified and remediated.
For example, if a policy requires critical vulnerabilities to be fixed within one working day, but vulnerability scans run only once a week, the issue may not even be discovered within that timeframe. Release cycles create another constraint. Even after a fix is ready, deployment may have to wait for the next release. Business impact can also influence when changes can safely be made.
For that reason, remediation targets should be defined with a clear understanding of the organization’s scanning cadence, release process, and operational constraints. Developers, DevOps engineers, and system administrators should be part of that discussion because they are responsible for implementing the fixes.
There is no universal remediation SLA. The right target depends on how the organization identifies, prioritizes, tests, and deploys security fixes. What matters is having a remediation process that keeps vulnerabilities visible, prioritized, and moving toward remediation.
Finding More Vulnerabilities Doesn’t Improve Security
When the backlog contains hundreds or even thousands of vulnerabilities, people open it and think: “I don’t want it.”
Simply counting open findings does not improve security because it does not move remediation forward. Teams still need to decide which vulnerabilities to address first and how to handle those that cannot be patched.
Prioritization also cannot depend only on the severity assigned by a scanner. A critical vulnerability in an internal system may represent less risk than a medium-severity vulnerability in an Internet-facing application. The priority should reflect where remediation will reduce the organization’s attack surface the most.
Not every vulnerability can be remediated through a patch. In those cases, organizations still need to reduce the risk through compensating controls, restricted access, or other mitigation measures.
Conclusion
Most organizations already know where many of their weaknesses are. The real challenge is making sure those vulnerabilities can actually be remediated.
That means asking different questions.
Instead of “How do we detect more vulnerabilities?” ask, “What is preventing remediation?”
Instead of “How do we add another control?” ask, “Will this help teams remediate vulnerabilities more effectively?”
Instead of “Are teams meeting the SLA?” ask, “Does the SLA reflect how remediation actually happens?”
The answers to those questions determine whether vulnerability management helps reduce risk—or simply creates more work.
