Creating a Longer List
Organizations learn about flaws in their applications they otherwise would not know about through bug bounty programs, but that knowledge doesn’t help if the organizations don’t have a way to triage the incoming reports and fix the issues. Enterprises can decide to invest in developing that process. That isn’t always an option for open source projects—if they don’t have corporate sponsors—as they tend to be underfunded and rely heavily on volunteers. The projects that would benefit from having more people scrutinizing the codebase for flaws are also the projects that are hurt because they can’t readily shift resources to fix those same issues.
“I disagree that it’s [bug bounty program] a good thing on its own. Where is the money for more paid maintainers?” Katie Moussouris, founder of Luta Security and expert in software vulnerability management, wrote on Twitter. “Oops. It’s not there.”
Consider the case of Network Time Protocol (NTP), an open source protocol used to synchronize clocks on servers and devices to make sure they all have the same time. It is arguably one of the most important pieces of software in use, but back in 2016, the lack of financial support meant there were grave concerns over maintaining the software long-term. There was too much for principal engineer Harlan Stenn, as the sole maintainer, to do alone, but without a sponsor or more funding, hiring someone to help wasn’t an option. NTP currently gets funding from the Linux Foundation’s Core Infrastructure Initiative, and the Network Time Foundation, a non-profit Stenn established for NTP, lists several corporate donors on the site.
But imagine if there had been a bug bounty program for NTP around the time the project team was trying to figure out its financial future. It makes sense—since NTP is critical Internet infrastructure in every way that matters—but without additional funding, these flaws would have remained unfixed.
“A #bugbounty on open source projects that don’t get any funding for additional maintainers is likely to decimate the volunteer maintainer labor pipeline of the future,” Moussouris wrote.
Deployment Challenges
Bug bounty programs operate on the assumption that resources exist to resolve the issues that are found. That assumption plays out differently for open source software and commercial software. When the issue is found and responsibly disclosed to the vendor, the vendor has time to fix it within a time period. Within a certain time period, there is typically no public information about the flaw. With open source software, that vulnerability may be saved to a public tracking system such as Bugzilla or GitHub Issues. There may be discussion between developers on the best approach to fixing the flaw.
If there is a delay in fixing the issues—because there is only one person and only so many hours in a day—users are left vulnerable because anyone could use the public details and create exploits targeting those flaws.
Where is the money for more paid maintainers? Oops. It’s not there.
“Any security issue disclosed in public leaves users vulnerable until a fix is found,” said Tim Mackey, senior technical evangelist at Black Duck by Synopsys.
Even if the developers fix the issue promptly, there remains the challenge of delivering the fix to all the users. Commercial software typically has a single release stream, so once the issue is addressed in that stream, all the users get the fix once they apply the update. In open source software, there are multiple release versions and branches, making it difficult to coordinate fixes in a way that all the branches pick up the updated code.
“This [delivering the fix] is by far the most significant hurdle for bug bounty-based efforts in [open source software],” Mackey said.
