Microsoft forked out $13.7m in bug bounties. The reward program's architect thinks the money could be better spent Microsoft's bug bounty program has exploded in terms of scope and payouts. The Windows giant said on Tuesday that over the twelve months to June 30, 2020, it has paid out $13.7m for reports of vulnerabilities in its products, more than treble the year-ago total of $4.4m The coronavirus pandemic played a part in the bug-report …
Isn't the problem of using your own devs for bug bounties that they might leave bugs on purpose to find?
So is better to have non locals do it.
https://dilbert.com/strip/1995-11-13
[The Boss, Dilbert, Wally and Alice sit at a conference table. The Boss says, "Our goal is to write bug-free software. I'll pay a ten-dollar bonus for every bug you find and fix." Dilbert, Wally and Alice throw their arms up in excitement. Dilbert yells, "Yahoo!" Alice yells, "We're rich!" Wally yells, "Yes!!! Yes!!! Yes!!!" The Boss says, "I hope this drives the right behavior." Wally says, "I'm gonna write me a new minivan this afternoon!" ]
"Most security programs can find many more efficient uses for $14m in vulnerability prevention and detection in-house."
Sure but like, isn't that effective? We're Microsoft. We'll do not that. Let's not that that really hard until we don't know what thating that even is. That's the one. Let's do that.
Curious thing is, there's an obvious metric staring them in the face.
Keep the bug bounty program. Implement and improve on the in-house capabilities.
Do the bounty payouts decrease? No? Keep improving the in-house capabilities.
Do the bounty payouts decrease? No? Well, now they've proven a negative ROI for their in-house program, confounding the experts maybe, but as predicted by others.
And that might be key to Microsoft's thoughts. Do they write shit code? Yes, but people are still buying it. Are they able to improve their processes? No? Customer: "Wait, why are we buying shit code from an unreliable vendor? Uh-oh! So... MS: "Let's not prove how bad our company is for software!"
"Internal investments in hiring more skilled security people in-house, using better tools, and mandating a secure development lifecycle has a much higher return-on-investment than letting the public do the bug detection work for you after."
One word: DUH!
And that doesn't even begin to cover the bad PR that Redmond has generated for itself over the last couple decades, releasing crappy code as a matter of course to keep sales and marketing happy.
Instead of testing the overall program as a "black box" to see whether it works, one writes code to test - if necessary - every single line of the code to make sure every line works as it should.
Simple example: Let's say I increment a counter every time an event occurs:-
i := i + 1;
If that counter exceeds the maximum allowed for that value, and i wraps-around then - well, the "black box" may still work, but there is an error in there which might only occur once every 248 days*. How do you test for that? Line-by-line analysis is easy, you ask the question: this line of code I've written, how can it fail?
Sometimes no fault is discernable, the code may go all around the houses, visiting every possible value before spitting out the correct value. Profiling the code will determine whether the counter has been simply incremented, or whether it was (say) decremented right through the entire integer range (with errors swallowed) to rest on the value above what it was last set to. There may never ever be an error, but the program spends a hell of a long time "thinking" before spitting out a result.
* I believe Boeing have a problem that manifests itself after that time period. Ok my explanation may be simplistic, but these kind of glitches are often as a result of something simple that someone has obverlooked.
At least I would hope that former employees aren't eligible, to limit the chance of someone finding a $1 million bug as an employee, keeping it quiet and quitting, then going for the bounty.
Someone who finds those kinds of bugs regularly is obviously not going to take a regular security job, but is that such a bad thing? Most actors barely scrape by but the lucky few make $20 million for a movie. Why? Because they are worth more than $20 million to the movie. Same with the lucky/smart few security researchers who can find the biggest bugs.
Releasing buggy-code and then having to bug bounties to external people is plain and simple externalized cost, with the exception that the cost is actually paid.
Think of bad code in terms of pollution. An oil spill pollutes the sea, and the society has to bear the cost of remediating the damage. -> externalized cost, since the oil company does not pay for the remediation. This slowly changes however, but in the past this was basically for free.
I find it a good thing, that bad code causes actual cost (via the bug bounty) for the software company instead of mere bad PR. No company has ever died of bad PR, hence there was real incentive to change behaviour.
However, if bad code costs actual money, then there is finally an incentive that even bean counters understand.
External bug detection and bounty programmes; I think the assumption that this is being "focused on" as if it is the primary way of detecting bugs a little narrow minded.
No company (ok probably some, but certainly not Microsoft) relies exclusively on external users discovering bugs. It is worth remembering that these programmes have to exist. No software development will be 100% perfect, there will be bugs including security bugs in released software. The question is how you manage that:
1. have a bounty programme so bugs are reported to you (rather than to evil players/criminals/etc.) This way you have a chance to fix them.
2. Ask yourself the question; why did our internal controls not pick this up. Fix the controls and testing so you would have. There may be a pattern as to why that occured, which you can prevent future bugs or even identify similar bugs from.
1 is useful, but only provides long term benefit if you also do 2.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
