Skip to main content

Is Public Disclosure Right For You?

  • May 18th , 2016

There are over 1,600 publicly disclosed vulnerability reports on the HackerOne platform!

We see security teams and hackers choose to publicly disclose their vulnerabilities over and over again. HackerOne firmly believes that transparency and information sharing improves security. We also recognize that information sharing through public disclosure is accompanied by inherent risks that must be carefully managed. On HackerOne, these risks are managed through a configurable disclosure process that seeks to serve everyone's best interests through mutual coordination.

"[Public] disclosure -- the practice of making the details of security vulnerabilities public -- is a damned good idea. Public scrutiny is the only reliable way to improve security, while secrecy only makes us less secure." - Bruce Schneier

The most common reasons for public disclosure we hear include:

  • Give public recognition to the hacker
  • Release a security advisory to users (especially if the user needs to take action, such as a software update)
  • Restore confidence to impacted users with authoritative messaging
  • Contribute educational material to the security community
  • Prevent future vulnerabilities from entering into the next generation of software
  • Challenge others to find a creative bypass or identify a regression
  • Incentivize future disclosures, especially when accompanied by a bounty

Public Disclosure on HackerOne

Our public disclosure process is designed to balance transparency while giving security teams and hackers control and a way to communicate jointly. Here is how it works from the perspective of a security team:

Alt textPublic Disclosure Workflow

Note that security teams have the ability to prevent any report from being publicly disclosed on HackerOne.

Control the Message

When publishing reports on HackerOne, the security team can choose to disclose the report in full or limit the information published. The default is to display all the communications between the hacker and the security team from first report to resolution. There are two ways a security teams can limit the information shared: redacting sensitive information or limiting visibility to a summary written by the security team along with a partial timeline. Here's an outstanding example of a summarized disclosure from the Shopify security team: https://hackerone.com/reports/64164.

Alt textExample of a summarized HackerOne Public Disclosure

Disclosure For Your Needs

HackerOne’s mission is to empower the world to build a safer internet. Sharing found vulnerabilities to teach others helps prevent the same vulnerabilities from being reproduced.

There will always be security teams with unique needs on HackerOne. A common case is hardware companies, who may resolve a vulnerability but defer disclosure for months to ensure adequate patch time. We encourage security teams to put their specific requirements on their Security Page to supercede these guidelines. HackerOne customers can always ask for assistance for writing a useful policy and configuring a custom disclosure process. For more information, please read the full HackerOne Disclosure Guidelines.

Questions or comments? Reach out to us on our social channels, especially Twitter @hacker0x01. Email works too via hello@hackerone.com.

-HackerOne

Recent articles

Bug Bounty Field Manual: The Definitive Guide for Planning, Launching, and Operating a Successful Bug Bounty Program

H1-415 Hackathon Delivers to Customers, Community, and Hackers

Just a few short weeks ago, an elite group of hackers huddled in conference rooms in a San Francisco high-rise…

Introducing CWE-based Weaknesses

HackerOne updated their vulnerability taxonomy to include a more complete weakness suite based on the industry-…