Slashdot Mirror
Mega Vulnerability Reward Program Starts Payouts: 7 Bugs Fixed In First Week
An anonymous reader writes "If you're a hacker or a security researcher, this is a reminder that you don't have to take on Google's or Mozilla's software to get paid for finding a bug. In its first week, the Mega vulnerability reward program has already confirmed and fixed seven bugs, showing that Dotcom really does put his money where his mouth is. Although Mega hasn't shared how much money it paid out in the first week, how many bug submissions were made, or even who found which bugs, the company did briefly detail the discovered security holes. It also confirmed that the program is here to stay and urged those participating to find more severe bugs."
And frankly, if this is the way yielding the best product for your money: Why not?
That's a very big if.
Science advances one funeral at a time- Max Planck
1. Is sadly how a large number of shops turn out work. A lot of software is about brand name and marketing over quality. If it's closed source, you'll have no idea just how bad it is. Not saying open source is better, but at least someone can decide objectively whether it's rubbish or not when they can see the inner workings.
2. Happens a lot, but not as often nowadays with very popular players. And a lot less when practically the whole world is looking at you. ME with Microsoft was probably the big poster child for this, but since then, they've been better (we'll skip Vista, since its biggest problem was making things that used to work, not work anymore)
3. Is also what Google does. And frankly, it's a very good system. Provided the majority of programmers are still driven by ethos and bragging rights, the money's just icing on the cake. Of course, if they still value money more, then that's a problem for the original software makers since governments can afford to shell out more dough.
The black market is very lucrative and there are very successful programmers in that world I.E. The Grugq. Now we can debate the ethics of the business, but in the end, they're just catering to demand. Killing supply doesn't work (case in point, the war on drugs), so that leaves the demand to be worked on by companies that care more about security and clients who push for it.
If computers were people, I'd be a misanthrope.
Frankly security related bugs /are/ the most important ones, because they provide attack vectors to the rest of the system. Missing functionality is just meh, but nothing to worry about.
CLI paste? paste.pr0.tips!
1. Pay unskilled programmers little money to quickly turn out software.
1. Pay the best programmers you can find and give them the time and resources they need to turn out a top quality product.
2. Release software you know is completely buggy and insecure.
2. Release software after it has been tested in every way you can think of, and fix even the smallest bugs you can find.
3. Offer bounty for better programmers to find bugs at overall cheaper rate.
This step remains the same - because it doesn't matter who you hire, how good they are, or how much time they have - any significant software system is so complex that only a total idiot would assume there are no bugs.
Indeed. I used to run a SW QA workshop for a large-ish company. The math is as you say. Based on analysis of years of data from multiple high-quality large software development projects (many of them defense- and space- related) using the latest quality assurance methods, only about 2/3 to 85% of bugs were caught prior to release. White box testing can only find about 1/3 of existing bugs - there's some interesting math behind that - note the word 'can'.
Most interestingly, given said quality engineering methods, the majority of bugs are built into the original design - they are not coding errors. (I think that a significant portion of those 'bugs' are arguably based on differences of opinion about how things ought to work.) From my work on these workshops I came up with the saying that "writing a small software program is like writing a 400 page book with no typos, no spelling or grammar errors, no ambiguous phrases, and no plot holes." (A 400 page book will have about 20,000 lines of text.)
About that time, I heard a talk at a conference by the then-head of IBM's OS 360 maintenance team, when OS360 was the OS for IBM mainframes that 'ruled the world' at the time. IIRC OS360 contained three million lines of code and had a 3 month maintenance release cycle. The speaker said that each cycle on average fixed two to three thousand new bugs.
More recently (late 1990s, early 2000s), analysis of a variety of software - again developed using 'good' methods', found that there was an average of one bug in every 200 lines of released, shipped code. I think it was about that time that Microsoft said they averaged about one bug in every 75 lines. (NB: It is not known if these numbers used the same metrics, so it is not evidence of any difference in coding quality.)
So, bottom line - no matter how carefully the code is designed and written, it will certainly have bugs - especially as you count design changes as bugs.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/