HackerOne Releases Best Practices for Vulns Disclosures

Written by

HackerOne, the vulnerability management and bug bounty platform, has announced its Vulnerability Coordination Maturity Model—an effort to help researchers and vendors improve communications around vulnerability disclosure processes.

The VCMM was created as a guide that companies can use to learn what the best practices are for vulnerability response, measure how they compare to others, and take actions that will help them address issues before bad actors can exploit them. Anyone can assess their vulnerability coordination maturity by going to HackerOne and answering a set of questions.

The VCMM is organized around five capability areas that determine an organization’s maturity level with respect to vulnerability response, including whether the company is organizationally set up to receive reports by having either a “security@company.com” email address, or via a form, and what actions the organization takes when a report is made.

There is much controversy around bug-hunting—as Oracle’s chief security officer recently demonstrated when she announced that she was writing cease-and-desist letters to third-party white-hats poking around in the software giant’s code. And she’s not alone: Historically, security researchers who found vulnerabilities either couldn’t find a way to report a security issue to a company, or if they did report issues, are often threatened with legal action.

“No software is immune to bugs; for most organizations it’s not a matter of if they’ll have an external hacker reporting security vulnerabilities, but when,” said Katie Moussouris, chief policy officer at HackerOne. “This maturity model shows how to build muscles and reflexes in vulnerability coordination to improve the security of an organization’s software, and the outcome for all parties when vulnerabilities are disclosed."

Others in the industry applauded the effort.

 “The Vulnerability Coordination Maturity Model is an important effort from HackerOne to codify some reasonable minimum standards on how organizations handle incoming, unsolicited vulnerability reports,” said Tod Beardsley, security research manager at security vendor Rapid7, in an emailed comment. “In the physical world, we are often implored to ‘see something, say something,’ but unfortunately, this is often not the case when it comes to accidental or intentional discovery of software vulnerabilities, even when those vulnerabilities end up affecting millions of end users.”

He added, “As a source of vulnerability reports, I'm often frustrated by the lack of a standard means to communicate findings to a vendor that's safe, secure and predictable. We've had the RFPolicy 2.0 since 2000, which was widely circulated at the time, and yet seven times out of 10, I get bounce messages when I try to contact a vendor at security@vendor-name.com. Even open source projects with mature bug tracking tend to react with surprise and suspicion when I show up to deliver some bad news.”

What’s hot on Infosecurity Magazine?