Vulnerability management: SLA by severity, internet-facing truth, and scanner theatre

Vulnerability management starts with knowing what exists, then measuring what is vulnerable, prioritizing by risk, assigning remediation, verifying closure, and learning from misses. CVSS matters, but so do internet exposure, exploit availability, asset criticality, compensating controls, data sensitivity, and active exploitation.

The scope is broader than traditional network scanning. Cloud workloads, containers, base images, dependencies, endpoint software, VPN appliances, identity systems, APIs, and managed services all create vulnerability risk. A monthly PDF from one scanner is useful only if it covers the real attack surface.

A mature program also separates finding from fixing. Discovery tools create signals, but remediation requires product owners, platform teams, maintenance windows, change approval, emergency patch paths, and verification in production. Without those operating paths, vulnerability management becomes a measurement function that records risk faster than the business reduces it. The program should therefore define how a finding moves from scanner to ticket, from ticket to deployed fix, and from deployed fix to verified closure. That workflow is where many organizations discover they have dashboards but no accountable remediation system.

The checklist cannot decide risk priority from severity alone. Teams need rules for exploited vulnerabilities, internet-facing systems, privileged components, critical business services, and systems with sensitive data. A critical finding in a lab may be less urgent than a lower-scored issue on an exposed edge service.

It also cannot decide what counts as acceptable risk. Slack approval from a manager is not durable risk acceptance. The organization must define who can accept risk, for how long, with what compensating controls, and how exceptions expire.

The checklist will not decide how remediation happens in immutable environments. Containers, golden images, and serverless packages often require rebuilding and redeploying, not patching a running instance. Platform owners must design that workflow.

Unauthenticated scans are often treated as coverage. They miss installed packages, local configuration, authenticated application paths, and many endpoint exposures. The dashboard looks cleaner because the scanner sees less, not because risk is lower.

Critical vulnerabilities stay open for months because remediation ownership is vague or SLAs have no enforcement. Risk acceptance happens in Slack, without expiry, evidence, or executive visibility. During an incident, the organization cannot explain why the known issue remained exposed.

Containers and images are another blind spot. Teams patch the base image but never rebuild and redeploy running workloads, or they rebuild new images while old vulnerable containers remain in production. Vulnerability management must reach the deployed artifact.

Prioritization can also fail in both directions. Teams chase every medium finding on internal systems while an exploited edge appliance waits for a maintenance window, or they accept a critical finding because a WAF exists without testing whether the rule blocks the actual exploit. Risk ranking should reflect attacker opportunity, not dashboard neatness. Executive review should focus on aging exploitable exposure and repeated exception patterns, because those signals reveal whether the program is reducing risk or merely processing findings.

Start by validating coverage. Compare scanner scope to asset inventory, cloud accounts, container registries, endpoints, internet-facing services, code repositories, and critical applications. Gaps should become onboarding work before teams debate SLA compliance.

Use the checklist to define triage rules and evidence. Each finding needs owner, due date, exposure context, remediation plan, exception status if any, and verification. Critical and exploited findings need escalation paths before the emergency appears.

Review trends with leadership, not just engineering. Aging criticals, repeated exceptions, unscanned assets, and rebuild failures are management signals. The checklist should help turn technical findings into accountable risk reduction. Leadership review should ask which exposure remains exploitable today, what tradeoff keeps it open, and who owns the next decision. That conversation is what prevents overdue findings from becoming accepted background noise in planning cycles. It also creates pressure to fund platform fixes when repeated findings share a root cause across teams and products in production.