Turning Scanner Noise Into a Real Patch Schedule

A CVSS score describes how bad a vulnerability could theoretically be, not how likely it is to actually hurt you. A critical-rated flaw in a function your code never calls is lower real risk than a moderate one in code that runs on every request handling untrusted input. Reachability, whether the vulnerable code path is actually exercised by your application, is the filter that turns an intimidating list into a workable one.

Federal agencies work against a tiered clock for exactly this reason: a critical, internet-accessible vulnerability gets patched within 15 days, and a known exploited vulnerability moves even faster than that¹. Borrowing a similar tiered structure, not a single deadline for every finding, gives a small engineering team a defensible default: patch known exploited vulnerabilities fastest, then internet-facing critical findings, then everything else on a normal release cadence.

• Check whether the finding is on a known exploited vulnerabilities list first; that status matters more than the raw severity number.
• Check whether the vulnerable code path is actually reachable from your application, not just present in a dependency you happen to import.
• Check whether a patched version even exists yet; sometimes it doesn't, and the real mitigation is a workaround or isolating the affected code path.
• Bucket everything else by whether the affected package runs on an internet-facing service or purely internal tooling.

Automate the scan itself and automate opening a pull request for patch-level dependency bumps that carry no breaking change; that's mechanical work a human doesn't add value reviewing line by line. Keep a human in the loop for major version bumps that could change behavior, and for any finding on a package your team doesn't fully understand well enough to judge the blast radius of an upgrade.

• Treating every finding above a severity threshold as equally urgent regardless of whether it's actually reachable.
• Letting the backlog grow until the dashboard becomes something nobody opens, which defeats the entire point of scanning.
• Auto-merging every dependency update, including major versions, without any human review of what actually changed.
• No documented SLA at all, so patch timing depends on whoever happens to notice the finding that week.

A scanner configured to flag every transitive dependency at the same severity as your direct dependencies produces most of the noise that eventually gets ignored. Narrow it to flag transitive dependencies only when a patched version is available and the path from your code to the vulnerable function is confirmed reachable, and the count of findings that actually need a human decision drops sharply.

Revisit the scanner's own configuration on a schedule, not just the findings it produces. A ruleset tuned for the application as it existed a year ago can miss an entire new category of dependency your team added since, especially if a new language runtime or package manager came into the stack without anyone updating what the scanner watches.

A raw count of open findings tells a non-technical stakeholder nothing useful, and it tends to read as either alarming or dismissible depending on the number's size that week. Report instead on the SLA: how many findings are currently inside their target patch window, and how many have breached it, broken down by whether the affected system is internet-facing.

That framing turns the conversation from "we have three hundred vulnerabilities" into "we have two overdue patches on internet-facing systems, both being worked this week," which is both more honest about the actual risk and a far more useful number for anyone outside engineering trying to judge how the program is doing.