3 ms·

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 cust

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....

tacostakohashi 3y ago
Urgh, there are lots of box-ticking tools like that in the industry like blackduck, sonarqube, coverity, etc that scan for problems of various kinds. Like you say a lot of what they actually find is theoretical and not useful, often it's like "If a tree falls in a forest and no one is around to hear it, does it make a sound?", yes it's theoretically an issue... but actually that code path is not reachable, the vulnerable part of the library is not used, etc - there is some external information that the tool lacks that makes the results incorrect and not useful. These things are just driven by senior management needing to do "something" about bugs/security, so they buy something that can do scans and produce reports and stuff, but the cure ends up being worse than the disease.

tacostakohashi 3y ago

Urgh, there are lots of box-ticking tools like that in the industry like blackduck, sonarqube, coverity, etc that scan for problems of various kinds. Like you say a lot of what they actually find is theoretical and not useful, often it's like "If a tree falls in a forest and no one is around to hear it, does it make a sound?", yes it's theoretically an issue... but actually that code path is not reachable, the vulnerable part of the library is not used, etc - there is some external information that the tool lacks that makes the results incorrect and not useful. These things are just driven by senior management needing to do "something" about bugs/security, so they buy something that can do scans and produce reports and stuff, but the cure ends up being worse than the disease.