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:
Public 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.
Example 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
HackerOne is the #1 hacker-powered security platform, helping organizations find and fix critical vulnerabilities before they can be criminally exploited. As the contemporary alternative to traditional penetration testing, our bug bounty program solutions encompass vulnerability assessment, crowdsourced testing and responsible disclosure management. Discover more about our security testing solutions or Contact Us today.