Building a Vulnerability Scanning Program That Doesn't Just Generate Noise

A critical severity vulnerability in a library your code never actually calls, dead code, an unused code path, poses far less real risk than a medium severity issue in a function that processes untrusted user input directly on your most exposed endpoint. Prioritize by actual exploitability, is this reachable, is it internet facing, does exploiting it require something an attacker would realistically have, not by severity score alone.

This triage step is what turns a scanner's raw output, which most teams learn to ignore within a few weeks, into an actual prioritized list someone can work through with confidence they're spending time on what matters.

For anything on the known exploited list, the federal remediation clock runs from 14 days for a CVE assigned this year to as long as 180 days for one left over from before 2021¹, and a scanner that just produces a severity score without a clock attached to it isn't giving you a program, it's giving you a report that piles up unread.

Set your own internal SLA per severity tier, track it as a real metric, mean time to remediate by tier, and treat a finding that's aged past its SLA the way you'd treat any other overdue commitment: visible, escalated, and someone's explicit responsibility to close.

A vulnerability disclosed the day after your last scan sits unknown to you until the next one runs, which could be weeks away on a periodic schedule. Continuous scanning, wired into CI so every dependency change is checked, and a scheduled full scan on a regular cadence to catch newly disclosed vulnerabilities in dependencies you haven't touched recently, closes that window meaningfully.

The goal is knowing about a new critical vulnerability in something you depend on within hours or a day, not discovering it during the next quarterly review, by which point it may have been exploitable and unknown to you for weeks.

Your own application code, your infrastructure configuration, and your third party dependencies each need scanning, and they fail in different ways with different remediation paths. A dependency vulnerability usually means a version bump; an infrastructure misconfiguration means a config change; a flaw in your own code means an actual code fix. Tools like CrowdStrike and Tenable each cover different parts of this surface, endpoint and infrastructure versus continuous vulnerability and attack surface scanning, so understand which layer a given tool is actually watching before assuming your coverage is complete.

A program that only scans dependencies while leaving infrastructure configuration unchecked has a real gap that a compliance checklist claiming "we scan for vulnerabilities" won't surface on its own.

It's natural to clear the quick wins first, a simple dependency bump, and let the harder findings, ones requiring an actual architecture change or a risky refactor of code nobody wants to touch, sit indefinitely. Track findings by age as well as by count, so a dashboard showing a shrinking total number doesn't hide a handful of genuinely dangerous, genuinely old findings that keep getting deprioritized every single cycle.

A program that's honest about its hardest, oldest findings, even when the fix is expensive, is a stronger program than one with a clean-looking dashboard built by only ever picking off what's easy.

Bring the oldest handful of findings to a quarterly review with whoever owns the roadmap, framed in terms of actual risk rather than a scary-looking count. A finding that's genuinely dangerous and genuinely expensive to fix needs a resourcing decision made consciously, not left to keep aging quietly on a list nobody with budget authority ever actually looks at.

A scanning program that reduces risk does these things:

• Ranks findings by exploitability, meaning reachable code, internet-facing exposure and presence on the known exploited list, ahead of raw severity.
• Attaches a remediation deadline to each finding and tracks whether it is met.
• Scans continuously in CI, plus a scheduled full scan to catch newly disclosed issues in dependencies you have not touched.
• Scans application code, infrastructure configuration and dependencies separately, since each has its own fix path.
• Tracks findings by age as well as count, and documents why any accepted finding was not fixed.