4 ms·
Similar experience. Many scanners seem to be designed around showing 'value' to management vs real value for engineering and security teams. Another example i
by gwittel 7y ago
Similar experience. Many scanners seem to be designed around showing 'value' to management vs real value for engineering and security teams. Another example is Blackduck. Its slow, noisy, has tons of FPs (which you cannot globally ignore), etc. It ends up being a tool users fight against instead of work with.
Another caveat -- scanners usually do not account for the current v vulnerable configuration. So while they may flag a vulnerability, its often a potential vulnerability. Its a mixed bag -- at scan time the system may be secure, but a future change may result in a vulnerable system. Unless you're religious about scanning after each build/config change; this could bite you as well. It would be nice to know these minutiae without digging into each CVE report.
- bostik 7y ago> scanners usually do not account for the current v vulnerable configuration. So while they may flag a vulnerability, its often a potential vulnerability. This is a straight-up artifact from the fact that the scanners (which essentially have to operate in non-destructive mode) rely on banner grabbing and very basic service behaviour pattern matching. Hence for every service they find, they report - quoting your words here - the potential vulnerability. Which basically is what you want. Trying to intelligently reduce noise would be really cool, but the moment the intelligence suppresses a finding that you WOULD have wanted to know about, you're screwed. It's bad either way, but the worst-case scenarios of the two are asymmetrical. I personally find point-in-time scans a useless exercise. Findings from individual cans are one thing, the difference over time is what really matters.