There’s often a significant amount of debate between internal appsec groups and developer groups around the topic of false positives. What exactly determines whether something is or is not a true false positive? And how can appsec groups synchronize so as to reduce confusion on the topic?

 

Semantics lie at the center of many arguments, and the debate around “false positives” offers no exception. What I’ve found is that there are often two different meanings that are being used in a single discussion about false positives, and if each side doesn’t realize which definition the other is using, chaos will ensue. Here are the two definitions I most commonly encounter:

 

1. The tool is claiming something that isn’t true, i.e. the vulnerability that it says it found actually was not found. One example of this might be the presence of a secretfile.aspx.bak file. The tool says it found the contents of this .aspx file, but when you look at the response you see that it’s no more than a custom 404 page.
2. The finding is technically correct, but nobody cares, i.e. a finding comes back saying that a password value is being passed via GET request to a given application, and the issue has been fully explained to the development team and management; they’ve simply decided not to change it.

This is a post of mine over at the HP AppSec blog. Check it out.