Security scan from certain company alerts about different non-existing issues. And even worse - their results are not consistent. How do you deal with such of things? Just two examples:

  • alerts for Apache mod_lua module even when this module is not active
  • alerts for different things on two webservers with identical configuration
  • That probably are companies that want huge amounts of money for just running a analyzer program, without doing any "real" work. (Or even worse, money for doing nothing at all except making up some random things)
    – user155462
    Aug 29 '17 at 10:36
  • 1
    What do you want to do with such things?
    – schroeder
    Aug 29 '17 at 11:01

Just because an automated scan returns a result, that does not mean that it is an 'audit'. It's just a scan.

For any finding, it needs to be

  1. verified that it exists
  2. if exists, it needs to be justified
  3. if justified, it needs to be placed in context with existing mitigations
  4. its risks need to be assessed

For documentation purposes, it is a good idea to write down these 4 things so that future findings can be compared, and the justifications, mitigations, and risks can be reviewed in the future to make sure they remain relevant.

So, for your two findings, acknowledge that the module exists but that it poses no risk because it is not active, and confirm both findings on both servers as being true or not (there are all kinds of reasons why a scan will show different findings on the same config).


I have a problem with your use of the term "false positive"

alerts for Apache mod_lua module even when this module is not active

Not active? What does that mean? If you don't need mod_lua than the .so file(s) should not be on the filesystem unless you can't remove them without breaking something. If your webserver is loading the module but not using it, then this is an issue which should be fixed.

alerts for different things on two webservers with identical configuration

Either the systems you think are identical are not, or the scanning company are possibly not doing their job right. The former is not hard to check.

Even if you are absolutely convinced that the company providing this service are useless cowboys, your first port of call is to ensure you have rock solid basis for refuting their findings.


First, security scans are just automated tools. As such, false-positives are quite commons.

Each reported vulnerability should be analyzed, meaning a human analyzis should first confirm it makes sense, then evaluate the risk level, and last define appropriate remediation with right priorization. This analysis must consider technical and functionnal context.

Actually, false-positive are easy to handle as they should simply be dropped in the first step of the analyzis. Eventually the difficulty is to confirm rather this is a false-positive or not. Note that you can face similar problem with true-postives, for instance imagine an information disclosure vulnerability is rightly reported but concerning only public information - meaning the risk level is around null. Note also that false-positives or null risks can evoluate regarding time and context : the disabled vulnerable module could be activated later, sensitive information could be stored and then the disclosure vulnerability makes suddenly sense.

So, a way to handle false-positives is to registreed them to ease future analyzis of scan results. But, in everyway, human analysis is the only way to have a comprehensive assessment of risks. Systematically ignoring kinds of vulnerability should be avoided.

The point is probably to report decision regarding reported vulnerabilities: wether they are false or true positives and why, assessed risk level, remediations to be taken. Security improvements starts with an appropriate analyzis.


I see both schroeder's and symcbean's points. This is what I've discussed with clients for the last 15 years or so.

Just because your vulnerability scanner says something is vulnerable, does not necessarily mean it is. Let me explain.

In your example, the alerts on mod_lua are most likely based on the version of Apache installed and not on actually detecting mod_lua loaded into memory. At best, it knows the module is installed and loaded into memory. However, does your web application actually use it?

A large problem is that the majority of vulnerability scanners on the market provide little information on the method of detection, let alone providing actual evidence.

While that explains why you got potential false positives, it doesn't solve your problem. Honestly, if these are your (company's) servers, push to perform a credentialed vulnerability scan. You will get much more accurate data to work from.

So, what if you perform a credentialed scan and still see the mod_lua vulnerability?

Part of your vulnerability management program should include using your risk assessment methodology to assess if you need to mitigate (fix) or accept the risk of that vulnerability.

What if you don't have a risk assessment methodology?

You do... everyone does. It may not be documented and the entire company may not share your methodology, but inherently, you make decisions based on risk everyday. If your company doesn't have a formal risk assessment/management program, I'd suggest hinting at the higher-ups that it's a time and money saver. If structured well, it dictates what gets addressed and in what order.

Back to mod_lua. If mod_lua is on the server, update. Better yet, if the web site doesn't use the Lua scripting language, remove the module from the Apache config and mod_lua.so from the server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.