Fix Bounty

Because finding bugs is 1337, but fixing them is 31337…

Background to Fix Bounty

The concept of “Fix Bounty” came about from conversations with colleagues on how there’s often little to no reward for providing security fixes to vulnerabilities found in open source software.

Open source projects can differ greatly in terms of size, popularity, number of active contributors and levels of security scrutiny achieved across those projects; as such security vulnerabilities can, and do manifest themselves in open source and even critical flaws can sometimes go unnoticed for some time, as exemplified with the Heartbleed OpenSSL security flaw disclosed in April 2014, yet introduced in 2012 [1].

The idea of Fix Bounty is to reward individuals for finding and fixing security vulnerabilities in open source software.

While this initiative has started as an internal scheme for NCC Group consultants, in the spirit of collaboration we urge others in the industry to take this model and copy or evolve it further.

The more resource we have identifying and fixing open-source code vulnerabilities, the better. Fix Bounty aims to allow those who work in development or security and who understand software vulnerabilities and their manifestations in code to be able to apply their expertise in the provision of fixes to those vulnerabilities.

In Fix Bounty, when a suggested security fix is confirmed as merged into the master project by the project owner(s) or maintainer(s), points are allocated to the ‘fixer’ which are tallied over time and converted into awards and prizes.

It is felt that these awards and prizes help acknowledge and compensate the time and effort spent by the ‘fixer’ in actively helping to secure open source software. The points-based system also somewhat gamifies the scheme and it is hoped that this gamification alongside bounty reward will help maximise participation.

How does NCC Group run Fix Bounty?

At its inception we (NCC Group) are currently only running Fix Bounty against projects hosted on the GitHub [2] platform.

Over time we may extend the scheme to other open source control platforms. We reiterate, however, that we encourage others to copy and/or modify the scheme as necessary in order to achieve maximum participation; so others might want to run Fix Bounty on other source control platforms, perhaps even just on internal platforms for internal software development teams.

At a high-level, at NCC Group our intention is to run Fix Bounty as follows:

• Consultants choose GitHub-hosted open source projects of interest and look for software vulnerabilities in those projects. The choice allows consultants to focus on specific languages or types of software that are of interest or familiarity to them
• Consultants can spend downtime or personal time on whatever projects they choose to inspect
• When consultants have found a vulnerability they write a suggested fix for this and liaise securely with the project maintainer(s) on implementing the suggested fix- use of pull requests is not allowed as a mechanism for communicating security vulnerabilities and proposed fixes (as this is not considered secure), unless explicitly requested and agreed by the project maintainer(s)
• The scheme will work on a points-based system. More points will be awarded for more popular and forked projects since those open source components are likely used in many different products and systems, therefore a fix to security flaws in those popular components should have material impact to future downloads of or updates from the master project. Currently we’re using the following calculation for the number of points achieved per fix:
  • Points = (Stars/10,000) * Forks
• Participants may want to focus on larger, more popular projects (as seen in [3], [4] and [5]) in order to achieve high numbers of points for any security flaws found and fixed in those projects. Accumulating points still allows individuals to build towards reward even if they’re finding and fixing flaws in n less popular open source projects that result in small amounts of points. Points will accumulate over time and so there will be no wasted effort in finding and having fixes merged into what might be seen in some cases as seldom-used software.
• Internally we use a vulnerability tracker to track all Fix Bounty submissions, proposed fixes and interactions with project maintainer(s) from discovery up to confirmation of fixes merged into the master code branch.

The prizes

Points will be tallied on a rolling basis and the first consultant to reach 10,000,000 points will receive a prize. Points are only awarded when proposed fixes have been confirmed and merged into the master code branch.

There will be a ‘Fixer of the Year’ award for the person who achieves the most points. The winner gets to attend a security or developer-focused conference of choice from a list of international conferences.

Additional prizes may be awarded mid-term, depending on the level of interest and engagement in the scheme.

Conclusion

There are many benefits to a scheme like Fix Bounty, whether run against open source or even internally on closed source within in-house software development teams.

There is much potential for learning and development by those who take part and those who simply observe the activities of participants, their vulnerability findings and recommended fixes – from these activities might come secure design patterns for reuse and overall improved software security consistency.

The gamification and prize aspect hopefully instils a healthy competition around the end-goal ofenhancing software security.

Fix Bounty is a new venture and so the scheme and its effectiveness will be monitored over time and changes or tweaks may be necessary to render it useful and worthwhile to both the open source community and scheme participants.

We aim to provide public updates on the efficacy of the scheme as will be observed from our internal running and involvement and we genuinely hope the scheme will gain traction both internally and externally through others who endeavour to launch their own Fix Bounty schemes.

We welcome conversations with anyone interested in learning more about our approach and the ethos of Fix Bounty.

We also welcome conversations with anyone wanting to learn more about our Secure Software Development Lifecycle practice and how we can help organisations achieve measurable security improvements in software security [6] and, how we can help improve developer security awareness through both classroom [7] and interactive game-like application security training [8].

References

[1] https://en.wikipedia.org/wiki/Heartbleed
[2] https://github.com
[3] http://github-rank.com/star
[4] http://github-rank.com/fork
[5] https://github-ranking.com
[6] https://www.nccgroup.trust/uk/our-services/security-consulting/technical-security-consulting/security-development-lifecycle/
[7] https://www.nccgroup.trust/uk/our-services/security-consulting/technical-security-consulting/cyber-security-training/
[8] https://www.nccgroup.trust/uk/about-us/newsroom-and-events/press-releases/2015/december/ncc-group-partners-with-codebashing/

Written by Matt Lewis
First published on 13/03/17