Triaging, fixing, and backporting patches to CVEs that we were never _really_ vulnerable to but that are going to show up if a customer runs a scanner (and customers love to have zero tolerance policies for CVEs above a certain severity score).

A specific recurring example: My team works on CLI tools. CLI tools are not web servers, but may need to make network calls and so consume networking libraries. We have a steady trickle of server-side CVEs to triage, and some of them we need to apply the patch just for the sake of someone else's compliance/policy.

Solutions include: - make libraries more granular (e.g. a client-only library which is consumed by the client/server library); - make scanning tools 'smarter' - (e.g. there's some efforts in golang around a scanning tool that only detects vulns in code it can tell is reachable from static analysis) - e.g. I wish i could declare to a scanner "you are scanning a CLI that does not and cannot start a persistent webserver" -- there _might_ be room in the industry for a concept like SBOM but for behaviors - SBOB? - a consulting firm selling the fortune 500 type co.s on a more nuanced CVE stance?

Unfortunately I don't think there's any money to be made solving this problem, and in general the incentives of CVE scanners are misaligned, much like how anti-virus software thrives when it tells you how many viruses it just blocked....