Antivirus Whitelisting Pains

Written by Bogdan Mitrache · December 7th, 2016

If you're a software vendor doing multiple releases a year, you're bound to hit (and hate) this problem - false-positive detection by antivirus solutions. It's just one of the neverending problems of ISVs that's eating a chunk of our time, without any ROI.

False-Positive Detections and Affected Users

Every time we release Advanced Installer, at least 2 or 3 binaries from our application get false-positive detections from the "big guys" in the AV world.

Once that happens, the other smaller AV providers also start flagging us. Probably they just monitor the big companies and try to stay up to date with their signatures, because every time we get McAfee or Symantec to remove a false-positive detection, all the small AVs also start to remove it, without us ever contacting them (as if they had a shared virus database).

The problem becomes serious because those false detections also reach the end-users of our customers. Advanced Installer includes stubs/tools inside the installers built by our customers, and these resources get flagged as potential threats.

We are aware that at a first time look our bootstrapper, that extracts files, or the virtual machine detection code, written in assembly and C++, could match some of the detection heuristics from AVs. The problem is that even after we white list these files, for a future release, which sometimes does not include changes, just a new time stamp, the detection re-appears.

One of those moments when 0 is the number you love

Now we all know how customers can become frustrated when they can't use your software because an AV blocks them (by placing files in quarantine or automatically removing them). Bad things can turn even worse for software that is not a 10$ utility. No one wants this, and, by the end, no effort would be too low to deliver a paying customer with a working solution.

Moving forward, instead of focusing on any reported bugs and how to fix them ASAP, you need to start filing whitelisting forms with every AV company that can't find a solution to separate a legitimate company and its products from a threat. It's like having to remind everyone, again, the software you're building is on the market for more than a decade, it's been signed with the same digital signature, built by the same company and delivered to hundreds of thousands of machines all over the world.

Preventing False-Positive Detections

You would say the AV companies just do this because they want to get additional revenue and sell us a special service that would expedite a pre-release scan of our software and whitelist it. But none of them has such a solution, they don't even have an API for us to make automated submissions with our new releases. All submissions must be done manually, and the links for those pages are well placed, to make sure they are not easy to find.

Because we want our customers to never worry about such problems we've started applying the following routine for each release:

• We build the official release of Advanced Installer, but don't release it to our users
• We manually submit our list of binaries to VirusTotal.com, to see which "usual suspects" get detected (sometimes just a few, randomly)
• Once we have a list of detections, we start submitting whitelisting requests, starting with the big guys, as mentioned before
• After a couple of days the detections are removed, we make an official release announcement on our website and configure the auto-updater to display the new version as available for download

We use OneNote to keep track of our most detected files and also a list with the resources and requirements from the AV companies, to expedite our submission process.

Do you have a better solution to tackle these situations? Reach us on Twitter and tell us your story.