Heartbleed. Shellshock. Dirty Cow. Drown.
When it comes to finding nasty security vulnerabilities such as the above in open source projects, ethical hackers, or as they’re more commonly known ‘White Hats’, provide open source project managers with an important service. Actually, they provide valuable service to the entire community. And this goes both for open source projects released and managed by commercial organizations, like Facebook and Google, or projects managed by a community of contributors, such as Linux and OpenSSL.
But what motivates white hat hackers to take the time to prod and probe our software, looking for bugs. Money? Fame? Glory? Well, you might be surprised that it’s something else entirely.
Show Me the…Recognition
Many think the financial reward is the main reason why white hat hackers choose to inform open source projects about a security issue, instead of going public. However, only 15% of white hats surveyed recently expected money in return for a disclosure. While a staggering 70% said the only reward they expect is to be included in the security vulnerability remediation process.
Subsequently, good communication between white hats and open source project managers is a win-win for everyone. Open source projects get to effectively eliminate bugs, while white hats get the recognition they deserve. Unfortunately, this is not always the case, at least from the perspective of white hat hackers.
Breakdown in Communication
A far too common situation is that white hat hackers are left feeling angry and frustrated when it comes to communicating with project managers. This is because white hats see great value in the role they play. All the majority wants is to be included in the open source community, and help develop secure open source projects. However, project managers often only deal with security bugs due to the threat negative publicity, or the details of a vulnerability being released into the open.
In fact, failing to tell white hats when a security vulnerability has been fixed, or when a remediation timeline has been missed, are two main reasons why white hats release a vulnerability’s exploitation methods on open source security vulnerability databases.
Surprisingly, bug bounty programs indicate how project managers can solve this breakdown communication. Because the big benefit of bounty programs for white hats isn’t the money on offer, but the easy to navigate and recognized processes of communication and disclosure.
Ultimately, when communication does break down, all parties suffer. Open source projects are hurt in terms of reputation as their products are viewed as insecure, white hats become frustrated and despondent, and perhaps most importantly, technology users are impacted as vulnerabilities put them at risk. Subsequently, the only way to improve this situation is to implement vulnerability disclosure best practices.
Best Practices for Vulnerability Disclosure
Luckily, these best practices already exist in the International Standards Organization’s (ISO) standards, particularly ISO/IEC 29147 and ISO/IEC 30111. These practices are all about joining the dots when it comes to white hats reporting vulnerabilities to affected projects.
These guidelines recommend measures like project managers setting up dedicated communication channels like emails and websites where bugs can be reported, and regularly updating white hats about the status of the remediation process. However, communication is a two-way street. White hats should provide all documentation and artifacts needed for vulnerability verification, as this speeds up the vulnerability disclosure process.
White hats and open source projects disclosing vulnerabilities in tandem is not rocket science. There just needs to be open and regular communication between those who find vulnerabilities, and those who the vulnerabilities impact.
At the end of the day, white hats are providing open source projects a valuable service. Therefore, project managers should welcome white hats with open arms, instead of giving them the cold shoulder.