How much is a vulnerability worth?

As part of its crowdsourced security program, Zoom has recently increased the maximum payout for vulnerabilities to $50,000. Such figures make great headlines and attract new talent in search of the big bucks, but here is a question that begs to be answered: how much is a vulnerability worth?

I have previously found several bugs in Zoom’s products, although these now date back several years, to when the company’s crowdsourced security program was a fledgling enterprise. Three of them had already been found by others before me – what we in crowdsourced security call a “duplicate”– so I got no reward for my time and effort even though they were valid bugs. The fourth vulnerability was quite interesting, since it re-appeared at the start of the pandemic when Zoom was under increased usage (and increased scrutiny).

I labelled is as “Potentially unsafe URIs can cause Local file inclusion, command injection or remote connection,” which is exactly what it did/allowed. To summarize: one could effectively send URIs that would appear as links to someone they were chatting with and these could do various things like open up malicious websites, download files or even run commands on their system (bizarrely, it even worked with the gopher protocol). The vulnerability that re-appeared at the beginning of 2020 was identical and focused on UNC paths so that the attacker exploiting it could send NTLM credentials to an attacker’s domain.

For discovering and reporting this vulnerability I was awarded the “princely” sum of $50, and it took about six months to receive it. Two years later I received a message saying the vulnerability had been fixed, and could I spend my free time checking whether the fix was good? (I didn’t).

Should we really be paying out $50,000 for a vulnerability?

At the height of the pandemic, exploits for Zoom zero-day vulnerabilities (in the Windows app) were reportedly being offered for sale for $500,000 and companies like Zerodium frequently traffic in these kinds of vulnerabilities in the “grey market” vulnerability marketplaces.

There are many downsides to ever-increasing payouts in crowdsourced security programs. While the main aim is to increase interest in the program (remember, crowdsourced programs rely on the gig workers that essentially work for free unless/until they find a valid bug), increasing payouts have the counter-productive effect of cannibalizing talent away from legitimate security areas, salaried or otherwise.

The cost effectiveness of paying to fix vulnerabilities when they are live is also in play. $50,000 could easily be spent fixing root causes of vulnerabilities and “shifting-left” to pay for far more than a single unitary fix. Some obvious examples of what that money could be used for:

• A full-time application security engineer
• Anywhere between 10 – 20 pen tests or code reviews (depending on day rate)
• A full suite of automated pen testing software
• Full deployment and implementation of SAST software (code scanning/dependencies) across upwards of 10 million lines of code
• Train hundreds of developers in secure coding techniques

Any of the above would help spot security issues before they make it into a live environment. While an often heard argument is that the bug reward offsets the monetary impact the eventual vulnerability exploitation would cause, the counter to that is that if a shift-left approach is taken, the offset is multiplied by a factor of ten.

If your SAST or application security engineers or even your code reviews spot ten of these vulnerabilities before going live, you’ve also mitigated the additional cost of refactoring code and pushing a single build to fix a single vulnerability.

Crowdsourced security and ever-increasing rewards won’t alleviate the structural issue that should be solved by good application security hygiene. The same could be said for the alphabet soup of acronyms currently present in the cybersecurity technology space (think IAM, WAF, DAST, SIEM, etc.): many technologies are simply band-aids over a wound that a comprehensive application security pipeline would patch up.

Paying 5-figure rewards for single vulnerabilities won’t immediately lead to better security. When deciding how much to pay for a vulnerability, if the question becomes “Is this too much for a vulnerability?”, you should instead ask yourself whether you are “shifting left” enough.