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.