Software security: There’s more to it than bug-bounty programs

Take full advantage of white-hat hackers to help you secure your code. And still do all the other security stuff you should do before you release your code

Matt Asay Jul 27th 2018

By one estimate, more than 100 billion lines of code are released each year, with an ever-increasing proportion of that software connected to the internet. With more connected code, there’s more risk of hackers connecting to that code for their own nefarious ends.

Given this opportunity for compromised code, bug-bounty programs are booming. Although positive, they’re just one component of how to deliver superior security.

Although bug bounties aren’t new—they can be traced back to at least 1983—they’re growing in popularity. In the past few years, tens of millions of dollars (and VC-funded startups like HackerOne and Bugcrowd) have poured into the market to tackle bugs so easily accessed through internet connections.

Fortuitously, the population of ethical hackers reaching critical mass both in quantity and quality. IT has finally figured out that scanners and penetration testing (aka pen testing), as nice as they may be, simply aren’t uncovering all security vulnerabilities. At the same time, the U.S. federal government has been pushing for change through recommendations, frameworks, and, soon, legislation.

At the same time, while it used to be common for corporations to keep their dirty software laundry behind closed doors, there is a “big shift” from “a closed mindset in security to an open one,” just as we’ve seen with a shift toward embracing open source software. Companies are finally realizing that pooled defense is the best defense,” says HackerOne CEO Marten, “and that transparency is good for security.”

All of that is great, but it doesn’t necessarily mean that enterprises have baked the discipline of security into a company. Security is not so much about technology or products; it is about an everyday discipline that everyone follows (or should). This is the ideal, but it’s an ideal that is violated more than it is honored.

Making code open source is one key way that companies can force themselves to take security more seriously: If you’re opening up the code for all to see, you’re likely to be a bit more careful with it.

This also bleeds into another factor of good security process: an agility that lends itself to action. Mickos says, “Security is about outrunning the threats, so it is vital to build a readiness to react quickly when an incident happens.” Open source doesn’t necessarily deliver inherently more secure software (even though it may nudge developers to be more careful in their coding), but it does provide the means for flaws to be uncovered and remedied more quickly.

Which is not to say that the flaws will be uncovered or remedied, of course—developers and their managers have to commit the resources to actually do that work. In fact, not even all companies that launch bug-bounty programs are committed to actually fixing the bugs.

But, for those companies that are prepared find and squash security bugs in their code, there has never been a better time to harness the power of white hat hackers everywhere. Connected code has launched a new generation of black hat hackers intent on exploiting code vulnerabilities, but also white hat hackers determined (and able) to shut them down.

Take full advantage of these white-hat hackers to help you secure your code. And still do all the other security stuff you should do before you release your code to reduce any security holes, from security-conscious design to code vulnerability analysis to—yes—pen testing.