How to boot up a bug bounty program in a DevOps world

In the release-driven world of DevOps, where automation is king, there is still a need for manual assessments and ethical hacking to assess your attack surface. You may have spent time automating your static and dynamic analysis capabilities, maybe even focusing on differential assessments, where only changed code is assessed.

A bug bounty program might be right for your organization to add another layer of diligence beyond the de facto annual penetration test, and to continuously assess your external web and mobile application portfolio with manual independent assessors.

If you have been following recent trends in software security, bug bounty or responsible disclosure programs have been all the rage in identifying real production security vulnerabilities in live applications. Information security professional and writer Daniel Miessler states in his blog:

“If you want to continue finding more vulnerabilities, and the systems you’re testing are not overly sensitive (source code reviews, private networks, crown jewels, etc.), then you should start thinking about doing a bug bounty.”

[ Special Coverage: All in on All Day DevOps ]

It can be argued that starting with a bug bounty may allow for quick-traction vulnerability management. But I recommend starting with the proverbial low-hanging fruit by performing the basic application security blocking and tackling with secure code training, static analysis, dynamic analysis, on-going (targeted) penetration testing, and general vulnerability management.

Adam Bacchus, Chief Bounty Officer at HackerOne, says:

“One of the biggest causes of misunderstandings between hackers and security teams is a lack of communication.”

A bug bounty provides an invaluable means of collaborating with the large, verbose security researcher community. I recommend having a well-rounded security professional managing the relationships who can also re-test issues and discuss vulnerabilities intelligently.  While the security researchers are an extension of your team, you have to keep in mind that they are not employed by the organization, nor do they need the detail behind a business decision to accept a risk.

Receiving communications from a researcher requires finesse to handle the relationship, so I can’t stress enough that minute business details or technical aspects should not be argued.  As an example, why your team chose the cryptographic hash algorithm SHA-1 instead of the more modern SHA-256, even if it is a vendor or product limitation.  It is critical to recognize the submission and show appropriate appreciation for the effort, but always default back to a properly defined program policy with details about disclosure of remediation activities or follow-up communications once issues are submitted. Be consistent, and be fair.

As an information security professional who has had the opportunity to build software security programs in four different organizations, I have discovered some uncommon lessons over the years. Here are three quick tips.


Leave a Reply

Your email address will not be published. Required fields are marked *