Bug Resilience Program

In 2023, the Sovereign Tech Fund began implementing the Bug Resilience Program to proactively increase the resilience of open source software infrastructure against undiscovered vulnerabilities.

The Bug Resilience Program (BRP) currently consists of three components:

  1. Direct contributions to FOSS projects
  2. A bug & fix bounty program
  3. A code audit program

Undiscovered vulnerabilities in FOSS infrastructure projects such as Heartbleed (2014), Apache Struts Remote Code Execution (Equifax Breach, 2017), and Log4Shell (2022) have affected millions of people. Bug bounties and code audits have been a popular approaches to incentivize finding vulnerabilities in software and to recognize and reward security researchers.

For smaller open source projects, the incentives of traditional approaches of bug-bounty-programs come with some problems. Many open source projects have limited time and resources to address vulnerabilities discovered through these approaches, relying on communities of volunteers. In fact, there is often a backlog of known issues affects projects’ ability to maintain the source code effectively (Ellis, R et al., 2022). Furthermore, multiple bug bounty programs already exist that cover the same range of projects in which the STF invests. Research has shown that overlapping bug bounty programs have diminishing returns and may even have negative effects on existing programs.

On this page:


Bug Bounty Programs and Code Audits

Bug bounty programs and code audits are both important approaches to improve the security of software and make it more resilient to vulnerabilities, by monitoring and detecting potential weaknesses in software code bases. Bug bounty programs involve inviting security researchers to inspect software, and identify and report security vulnerabilities. In exchange, the researchers receive financial rewards (“bounties”) for their discoveries.

Likewise, code audits entail a thorough examination of source code by a security professional, either manually or with automated tools, to identify and rectify security vulnerabilities. They vary in scope and breadth, but can include analyzing the logic, design, and/or implementation of the code to ensure a robust and secure software component.

Bug bounty programs encourage and reward a diverse set of external security experts to discover vulnerabilities in real-world scenarios on a longer-term basis. Code audits provide a systematic, in-depth examination at a particular point of time to identify and rectify potential security issues within the software. Both bug bounty programs and code audits, when applied strategically, play an important role in proactively managing and enhancing the security posture of software.


STF’s Approach: Resilient, Responsive, and Responsible

Based on feedback from experts and FOSS infrastructure projects as well as a review of existing research, STF designed a holistic and preventative approach to increase FOSS project’s resilience to potential vulnerabilities. By reducing technical debt – restructuring code to be more easily maintained, for example – BRP helps improves maintainers’ capacity to respond to bugs.

Improving maintainers' ability to respond and resolve leads to simpler bugs being fixed or at least acknowledged. This allows security researchers to focus on discovering vulnerabilities that are more difficult to find through bounties and audits.

Here is an overview of the current components of the Bug Resilience Program.

Direct Contributions

Our partner Neighbourhoodie Software provides a variety of types of contributions to participating projects to address known issues, improve documentation, and reduce technical debt. Very often, FOSS projects maintainers know that certain parts of critical technologies on which they work contain vulnerabilities or security deficiencies. However, the maintainers may not have the capacity to deal with them yet, or can only address them with temporary solutions. Software projects also accumulate technical debt over time, making the software harder to maintain and creating more opportunities for vulnerabilities. Last but not least, having consistent and proper documentation and guidance can help improve the quality of external contributions and reduce the barrier to entry for contributors who can suggest security improvements to FOSS projects.

Bug & Fix Bounty Platform

We are working with the YesWeHack platform to provide selected FOSS projects with bounty programs that incentivize uncovering vulnerabilities in code, as well as compensate projects for the time spent addressing those issues. YesWeHack assists the projects with providing access to security researchers. They also help with triage and verification of the vulnerability reports when they are submitted by researchers. For each responsibly reported and fixed vulnerability, STF offers a “fix” bounty to participating projects.

Code Audits to Reduce High-Risk Vulnerabilities

Through a partnership with the Open Source Technology Improvement Fund, STF is offering security reviews for widely-used software components. These software components need a high standard of security to reduce the likelihood of undiscovered, high impact, and high risk vulnerabilities in critical infrastructure. Properly scoped security audits on critical open source software can provide invaluable insight to maintainers and help them to proactively assess the security posture of their code and infrastructure. Improving testing and code coverage strengthens the sustainability and longevity of projects, and enables maintainers to address issues before they are exploited.

Participating projects: cURL; Jackson; LLVM


How to Apply

Please read our program criteria carefully before you begin the application process.

Bug Resilience Program Criteria

Create an account to submit an application. Please note that you will only receive a submission confirmation from us if you agreed to receive emails or SMS from us when you registered. If you change this in the settings after your registration, it will only affect future messages from us, such as acceptances or rejections.

Go to application platform

Incoming applications are reviewed on an ongoing basis and checked for whether they meet our criteria and the services available through the Bug Resilience Program. Once we have received your application, we will send you a confirmation.

If we determine that a project is not eligible for the Bug Resilience Program, you will receive a response notifying you that your application has been declined. If a project is eligible, you will receive an invitation to join the program. Applications that do meet the criteria will be placed on a waiting list for the services selected in your application. Waiting time will vary according to current capacity and amount of incoming applications for that service.

Download a preview of the application form (PDF)

For technical issues with the application platform, please contact support@bugresilience.de


Bug Bounties and FOSS Study

In addition to those activities, the STF has commissioned a study focusing on the effects of different bug bounty approaches on FOSS projects, including the approach outlined on this page. This helps validate some of the assumptions, and fills a gap in the literature as most available research on security and bounty programs focuses on the security researcher side.

To this end, STF contracted Dr. Ryan Ellis, Associate Professor of Communication Studies at Northeastern University, to write a report on the efficacy of bug bounty programs. Dr. Ellis specializes in communication law, infrastructure politics, and cybersecurity. He is the author of "Letters, Power Lines, and Other Dangerous Things" (MIT Press, 2020) and the co-editor of "Rewired: Cybersecurity Governance" (Wiley, 2019).

Bug Bounties and FOSS: Opportunities, Risks, and a Path Forward


Questions

We have collected the answers to frequently asked questions on the page linked below. For example:

  • “What services are provided through the Bug Resilience Program?” and
  • “Who can apply for the Bug Resilience Program?”

Bug Resilience FAQ page