Every now and then I see something on a blog or Twitter about how you can’t replace a pen test with a bug bounty. For a long time I agreed with this, but I’ve recently changed my mind. I know this isn’t a super popular opinion (yet), and I don’t think either side of this argument is exactly right. Fundamentally the future of looking for issues will not be a pen test. They won’t really be bug bounties either, but I’m going to predict pen testing will evolve into what we currently call bug bounties.
First let’s talk about a pen test. There’s nothing wrong with getting a pen test, I’d suggest everyone goes through a few just to see what it’s like. I want to be clear that I’m not saying pen testing is bad. I’m going to be making the argument why it’s not the future. It is the present, many organizations require them for a variety of reasons. They will continue to be a thing for a very long time. If you can only pick one thing, you should probably choose a pen test today as it’s at least a known known. Bug bounties are still known unknowns for most of us.
I also want to clarify that internal pen testing teams don’t fall under this post. Internal teams are far more focused and have special knowledge that an outside company never will. It’s my opinion that an internal team is and will always be superior to an outside pen test or bug bounty. Of course a lot of organizations can’t afford to keep a dedicated internal team, so they turn to the outside.
So anyhow, it’s time for a pen test. You find a company to conduct it, you scope what will be tested (it can’t be everything). You agree on various timelines, then things get underway. After perhaps a week of testing, you have a very very long and detailed report of what was found. Here’s the thing about a pen test; you’re paying someone to look for problems. You will get what you pay for, you’ll get a list of problems, usually a huge list. Everyone knows that the bigger the list, the better the pen test! But here’s the dirty secret. Most of the results won’t ever be fixed. Most results will fall below your internal bug bar. You paid for a ton of issues, you got a ton of issues, then you threw most of them out. Of course it’s quite likely there will be high priority problems found, which is great. Those are what you really care about, not all the unexciting problems that are 95% of the report. What’s your cost per issue fixed from that pen test?
Now let’s look at how a bug bounty works. You find a company to run the bounty (it’s probably not worth doing this yourself, there are many logistics). You scope what will be tested. You can agree on certain timelines and/or payout limits. Then things get underway. Here’s where it’s very different though. You’re paying for the scope of bounty, you will get what you pay for, so there is an aspect of control. If you’re only paying for critical bugs, by definition, you’ll only get critical bugs. Of course there will be a certain amount of false positives. If I had to guess it’s similar to a pen test today, but it’s going to decrease as these organizations start to understand how to cut down on noise. I know HackerOne is doing some clever things to prevent noise.
My point to this whole post revolves around getting what you pay for, essential a cost per issue fixed instead of the current cost per issue found model. The real difference is that in the case of a bug bounty, you can control the scope of incoming. In no way am I suggesting a pen test is a bad idea, I’m simply suggesting that 200 page report isn’t very useful. Of course if a pen test returned three issues, you’d probably be pretty upset when paying the bill. We all have finite resources so naturally we can’t and won’t fix minor bugs. it’s just how things work. Today at best you’ll about the same results from a bug bounty and a pen test, but I see a bug bounty as having room to improve. I think the pen test model isn’t full of exciting innovation.
All this said, not every product and company will be able to attract enough interest in a bug bounty. Let’s face it, the real purpose behind all this is to raise the security profiles of everyone involved. Some organizations will have to use a pen test like model to get their products and services investigated. This is why the bug bounty program won’t be a long term viable option. There are too many bugs and not enough researchers.
Now for the bit about the future. The near future we will see the pendulum swing from pen testing to bug bounties. The next swing of the pendulum after bug bounties will be automation. Humans aren’t very good at digging through huge amounts of data but computers are. What we’re really good at and computers are (currently) really bad at is finding new and exciting ways to break systems. We once thought double free bugs couldn’t be exploited. We didn’t see a problem with NULL pointer dereferences. Someone once thought deserializing objects was a neat idea. I would rather see humans working on the future of security instead of exploiting the past. The future of the bug bounty can be new attack methods instead of finding bugs. We have some work to do, I’ve not seen an automated scanner that I’d even call “almost not terrible”. It will happen though, tools always start terrible and get better through the natural march of progress. The road to this unicorn future will pass through bug bounties. However, if we don’t have automation ready on the other side, it’s nothing but dragons.
Source From: fedoraplanet.org.
Original article title: Josh Bressers: I have seen the future, and it is bug bounties.
This full article can be read at: Josh Bressers: I have seen the future, and it is bug bounties.