False Positives / What Are They Doing Here?

False positives can be difficult to disprove and even harder to understand. They stem from an automated product, like a vulnerability scanner, doing its best to determine whether a specific condition exists or not. Unfortunately, a lot of people end up trying to mitigate or remediate problems that might not even be present when these make it into a report. Ironically, if they do not make it into a report, you might think your vendor isn’t catching all the vulnerabilities in your environment if you don’t know how to perform manual validation of these issues. Most commonly, these occur in web applications because a scanner will think any reflected value might be a cross-site scripting or SQL injection error. We leave them in our deliverable for multiple reasons, some of which I will discuss briefly here.

One reason we leave these in is what was alluded to earlier; if you or another vendor were to perform the same scanning function and see the vulnerability, we’d want you to know we didn’t miss it during our testing efforts. We also like to display the manual verification to show that we did indeed test to make sure the vulnerability was or was not present. At times we are asked to remove these from our deliverables, and we typically decline. This is decided on by looking at both the overall impact on the reporting effort and the potential risk of the discovered vulnerability. In very rare cases where there is sufficient documentation and collaboration with our client we will redact the vulnerability from the deliverable. Over 95% of the time we leave it in and encourage our clients to use this to their advantage with their superiors by showing the due diligence in disproving the vulnerability and/or the fact that the problem is already remediated in most cases.