Crowdsourcing from Hackers: Strategic Coopetition and Governance in Bug Bounty Programs

1. Introduction

Organizations are constantly challenged to protect their assets in cyberspace. Traditional protection measures deter hacking using in-house detective and preventive measures (Gordon and Loeb 2002, Cavusoglu et al. 2009), managed security services (Lee et al. 2013, Cezar et al. 2014, Hui et al. 2019), and government enforcement (Png and Wang 2009). We study burgeoning bug bounty programs (BBPs), which differ from conventional deterrent measures by encouraging hackers—organizations’ potential “enemies”—to identify security vulnerabilities in information technology (IT) systems through monetary rewards (i.e., bug bounty rewards). Economic incentives significantly impact information security (Anderson and Moore 2006), but the implications of incentivizing threat actors to enhance security is largely unexplored. This paper explicates the economic, security, and social welfare implications of BBPs.

Consider Google’s BBP. In November 2010, Google published a BBP policy that details the monetary rewards for external parties who report security vulnerabilities in its public-facing products, such as Google Search and YouTube. All previously undiscovered vulnerabilities are eligible for the rewards with the amount depending on the expected impact and type of vulnerability. For example, a remote code exploit in Google Search qualifies for a $101,010 reward (Google 2024). In 2025, Google awarded $17 million to more than 700 reporters (Mendez and Göhmann 2024). Online Appendix A details Google’s BBP.

The computing industry has been ambivalent about BBPs. Proponents claim that BBPs help firms utilize crowd wisdom, especially potential hackers, to supplement internal efforts to identify vulnerabilities (Anglin 2020, Winder 2020). However, critics question the economic merits of rewarding outsiders when organizations have more capable internal experts. Some dismiss BBPs as a fad (Oracle.com 2015). Reliance on BBPs might lead a firm to complacency in in-house protection, potentially compromising overall security (Dayan 2022, Harrington 2022). BBPs also introduce new challenges, such as the legality of security testing and balancing the extra effort needed to handle duplicate and invalid submissions.

As shown in Table 1, 9 of the 10 largest IT companies in the United States and 6 of the 10 in China offer BBPs.¹ Companies at the technological frontier, including AI leaders such as Anthropic and OpenAI, have also adopted BBPs. During the COVID-19 outbreak when many organizations relied on digital communications for work-from-home arrangements, the number of major breach incidents associated with firms providing BBPs reduced to eight (nine incidents during 2019) with major breach incidents increasing to 97 for non-BBP firms (compared with 71 incidents during 2019).² However, more than 80% of Forbes Global 500 companies had not adopted a BBP by 2021 (Akgul et al. 2023). Even among BBP adopters, many limit the scope to selected systems (known as the program scope; see Online Figure A.1). Evidently, the uncertain effectiveness of BBPs is a major challenge for their development.

Table 1. Bug Bounty Programs Among Large IT Companies in the United States and China

To evaluate BBPs, this study addresses the following research questions: Under what circumstances do BBPs provide economic benefits to a firm? What are their impacts on information security and social welfare? How should bug bounty rewards be set under different cyber-environments? We also investigate policies that address common challenges faced by BBP providers, including the legality of security testing and the management of duplicate reports.

We develop a model in which a firm decides whether to offer a BBP to protect its vulnerable system from heterogeneous hackers, who might misuse the vulnerability for economic gains. Our model is similar to previous crowdsourcing analysis in that the firm can announce a reward to induce participants (hackers) to complete a task, namely, identify and report the vulnerability in the firm’s system. The unique feature of BBPs, however, is that participants can be a firm’s potential enemies. If the bounty reward is not sufficiently attractive, hackers might monetize a vulnerability elsewhere, such as by attacking the system directly. Furthermore, despite the BBP, a firm might still deploy in-house efforts to identify the vulnerability, and this enhances the system’s security and leaves fewer opportunities for hackers to find the vulnerability. These features give rise to both cooperation and competition dynamics or coopetition between a firm and external parties, a scenario that the BBP and crowdsourcing literature has not considered.

Our analysis generates interesting insights. First, a BBP benefits a firm when the firm is inefficient in vulnerability identification or when it faces a large proportion of coopetitive hackers (Proposition 1). The latter implies that BBPs can be beneficial even when hackers are inefficient in vulnerability identification. In contrast to the common wisdom that larger crowds enhance crowdsourcing effectiveness, more BBP participants might make a BBP less attractive. Second, a BBP increases overall security but might encourage competitive hackers to exert more efforts (Proposition 2). Third, although a BBP can improve the payoff and security of a firm, the firm’s provision of both rewards and in-house effort can be socially inefficient (Proposition 3). Our analysis suggests that widely applied cybersecurity regulations, such as breach penalties and bounty reward subsidies, might further exacerbate that inefficiency. We identify a complementarity between bounty subsidies and breach penalties, suggesting that combining and customizing them according to firm characteristics can increase BBP efficiency (Proposition 4). Fourth, contrary to the conventional wisdom that crowdsourcing rewards increase with participant size, we demonstrate that the coopetition feature of BBPs yields different reward properties. We identify scenarios in which a firm should reduce or make nonmonotonic adjustments to bounty rewards as the number of cooperative hackers increases (Proposition 5).

We extend the model to analyze two prominent BBP designs. Whereas it appears natural that a firm benefiting from ethical hacking should prefer legal safe harbors for security testing, we find that a safe harbor term (SHT) may reduce a firm’s payoff. We discuss several policies that can help avoid such losses (Proposition 6). We also compare policies to address duplicate report submissions. Interestingly, firms challenged by duplicate report submissions may suffer from policies that more effectively reduce these uninformative submissions, implying that firms should choose duplicate report policies strategically (Proposition 7).

This study makes three important contributions. First, to our knowledge, it is the first formal analysis of a firm’s incentive to provide a BBP. We systematically characterize the impact of BBPs on firms’ economic payoff, system security, and social welfare by accounting for the novel feature that participants might either attack or protect digital systems, and this has important strategic and social welfare implications. Our study lays the foundation for future research and practice on BBPs and advances the security investment literature by moving beyond conventional deterrence measures to examining how organizations can collaborate with potential adversaries to enhance cybersecurity.

Second, our analysis generates novel insights into multiple BBP policies and practices, and this should be of interest to practitioners and policy makers. For example, we demonstrate that common cybersecurity regulations, such as breach penalties and bounty reward subsidies, can reduce social welfare with BBPs and that popular suggestions, such as safe harbor terms and taxing duplicate reports, might reduce a firm’s return from BBPs. We also show that more cooperative participants might make BBPs less attractive and that a firm might need to reduce or adjust bounty rewards nonmonotonically in response to greater BBP participant size. These insights shed new implications for BBP practices and policies because they contradict conventional crowdsourcing and security protection wisdom.

Finally, we extend the crowdsourcing literature by considering the coopetition relationships between a firm and external parties (Brandenburger and Nalebuff 2011, Bouncken et al. 2015). Coopetition exists in many real-world settings,³ giving rise to insights remarkably different from conventional crowdsourcing wisdoms (e.g., Propositions 1 and 5). Our analysis provides a framework to extend this theoretical literature by explicitly incorporating the possibility for a firm to compete when cooperating with external parties.

2. Related Literature

This study is related to the literature on information security investment. Following Gordon and Loeb (2002), the literature discusses how organizations optimize security investments in various contexts, such as system interdependency (e.g., Hausken 2006), when hackers strategically identify poorly protected systems (e.g., Cremonini and Nizovtsev 2009, Bandyopadhyay et al. 2014), and when organizations share information (Gal-Or and Ghose 2005, Gao et al. 2015). To our knowledge, we are the first to formally examine organization incentives to invest in BBPs that encourage rather than discourage hackers’ identification of vulnerabilities.

A BBP’s structure is similar to crowdsourcing contests, vulnerability markets, and security outsourcing. Conceptually, it can be considered as a crowdsourcing application because it engages the public to help a firm solve a problem, namely, identifying unknown vulnerabilities (Fryer and Simperl 2017). Studies of crowdsourcing assess the optimal design of a contest (e.g., Chawla et al. 2019), such as award properties (e.g., Terwiesch and Xu 2008, Ales et al. 2017), incentive schemes (e.g., Horton and Chilton 2010), and participation policies (e.g., Jeppesen and Lakhani 2010, Boudreau et al. 2011). We extend the literature by studying the optimal policy design of BBPs and incorporating its unique elements: (i) participants might use an identified vulnerability to hurt the firm; (ii) the firm’s in-house security effort influences BBP outcomes as more in-house efforts reduce the chance of paying bounty rewards. In contrast, conventional crowdsourcing always awards the best external contribution regardless of the firm’s in-house effort (Terwiesch and Xu 2008, Chawla et al. 2019). (iii) BBPs focus on the uniqueness of the discovered vulnerabilities. This is not the case with conventional crowdsourcing contests, in which quality is often the top consideration.

The literature on vulnerability markets also studies the reward for vulnerability reporting by infomediaries (e.g., iDefense or Zero Day Initiative) and their influences on social welfare and vulnerability diffusion (e.g., Kannan and Telang 2005, Ransbotham et al. 2012, Mitra and Ransbotham 2015). It addresses infomediaries that reward vulnerability reporting and sell vulnerability information to subscribers. Firms with security needs do not offer rewards themselves but subscribe to the infomediary to receive passive vulnerability information. In contrast, BBPs allow firms, such as Alphabet and Meta, to reward vulnerability reporting directly and, thus, address their specific cybersecurity needs. Analysis of a firm’s incentives to reward vulnerability reporting instead of a market infomediary’s incentive is new.

The strategic interaction between a firm and BBP participants resembles the interactions between an outsourcing firm and managed security service providers (Dey et al. 2010, Hui et al. 2012). This literature focuses on addressing inefficiencies because of double moral hazards (Gupta and Zhdanov 2012, Lee et al. 2013, Hui et al. 2019). Their setting is, therefore, a principal–agent problem with hidden actions (Jensen and Meckling 1976). In our context, a firm opens the BBP to the public and pays participants ex post when they find a vulnerability. Our setting is closer to a screening problem (Spence 1973) with the objective of separating different types of users, namely, black-hat and white-hat hackers, and inducing preferred actions, namely, submitting a vulnerability for a bug bounty reward instead of exploiting it.

This study is also related to the literature on hacker behavior, which assesses how hackers respond to stimuli such as law enforcement (Png et al. 2008, Romanosky et al. 2011, Kigerl 2016, Hui et al. 2017), nonfinancial incentives (Leeson and Coyne 2005), hacking technologies (Png and Wang 2009, Ransbotham and Mitra 2009), economic conditions (Png et al. 2008), and vulnerability disclosure (Arora et al. 2006, Ransbotham et al. 2012, Mitra and Ransbotham 2015). Despite the recognition that hackers are neither all black nor all white but sometimes gray (e.g., Gottlieb 1999, Wired 2000, Lacity et al. 2009, Harper et al. 2011), the literature mostly treats them as offenders. We advance this literature by explicitly considering the dual use nature of hackers (Katyal 2001): they can harm or help secure digital assets.

Lastly, a small but rapidly growing literature specifically studies BBPs. Finifter et al. (2013) and Zhao et al. (2015) assess selected BBPs in terms of economic efficiency, vulnerability evolution, and participant behaviors. Other studies examine economic trade-offs related to BBPs, such as relationships between bounty rewards and vulnerability severity (Munaiah and Meneely 2016) and competition among BBPs (Maillart et al. 2017). Zhao et al. (2017) analyze mechanisms that increase BBP effectiveness, including reducing invalid reports and optimizing participant allocation. Zhang et al. (2024) examine how different contextual factors affect firms’ bounty rewards and total costs.

Our study differs from this literature in three ways. First, the literature assumes that BBP participants are cooperative, neglecting the possibility that BBPs allow organizations to collaborate with potential enemies. Thus, it does not capture the attack diversion benefit of BBPs (Proposition 1). Second, the literature does not consider firms’ in-house vulnerability identification efforts in conjunction with BBPs, and hence, it does not explain why companies such as Alphabet and Meta maintain in-house teams for vulnerability identification despite using BBPs. Our model explicitly captures such in-house incentives, highlighting the coopetition dynamics between a firm and hackers (Propositions 1–7). Third, the literature does not examine the incentive of a firm to offer BBPs. For example, Zhao et al. (2017) and Zhang et al. (2024) assume that the firm has already adopted a BBP. We go one step backward to assume that a BBP is not necessarily beneficial, implying that some settings considered in extant research may not align with the firm’s incentive to offer a BBP. More importantly, the literature has not assessed the influence of BBPs on system security and social welfare. Collectively, we contribute to this literature by examining the economic, security, and social welfare implications of a BBP by accounting for its unique feature in enabling providers to coopete with potential enemies.

3. The Model

Consider a vulnerability identification model with one firm that invests to uncover a single vulnerability in its IT system.⁴ The firm invests effort $x_f$ to search for the vulnerability, for example, by conducting penetration tests and regular security audits or other experiments. It can also offer a public bounty award, r, to reward the first external party that finds and submits the vulnerability. The firm fixes the vulnerability (or implements workarounds) as soon as the vulnerability is identified internally or reported by an external party.⁵ It suffers a loss, $\lambda$, if the vulnerability is first found and misused by a hacker (e.g., by exploiting or other irresponsible disclosure or use of a vulnerability).

The market has T types of hackers with valuations from misusing the vulnerability, $v_t$, $t=1,2,\dots ,T$, where $v_1>v_2>\cdots >v_T\ge 0$. The size of each hacker type t is $n_t$. The kth hacker of type t exerts effort $x_{t,k}$ to search for the vulnerability, where $k=1,2,\dots ,n_t$.⁶ The firm and hackers compete to find the vulnerability, and only one of them can win the competition.⁷ We assume that the firm and hackers are risk-neutral, and vulnerability patching, submission, and exploitation are costless to focus on strategic interactions between the BBP and vulnerability identification decisions. Figure 1 shows an illustrative hacker distribution. We assume that the distribution of hacker valuations is public information and fixed throughout the game.

We model the game over two periods. In period 1, the firm chooses whether to offer a bug bounty reward and how much it will be. In period 2, the firm and hackers simultaneously choose their effort and make their vulnerability submission/exploitation decisions. We use this game structure because the BBP is offered publicly, but the firm’s and hackers’ efforts are private information. We assume that the firm and hackers form rational expectations. The solution concept is subgame perfect Nash equilibrium. Figure 2 shows the different scenarios in our setting.⁸

We use superscripts nb and b to indicate scenarios when the BBP is not offered and offered, respectively, and subscripts f and t to indicate the firm and hacker type t, $t=1,2,\dots ,T$. In general, the effort of an agent—the firm or a hacker—should increase its chance of finding a vulnerability relative to other agents. One commonly used tractable function that models this competitive dynamic is the Tullock contest success function (Tullock 1980), which is widely applied to analyze patent races (e.g., Loury 1979, Dasgupta and Stiglitz 1980), research and development contests (e.g., Baye and Hoppe 2003), and military conflicts (e.g., Garfinkel and Skaperdas 2007). With the firm’s effort $x_f$ and hackers’ efforts $x_{t,k}$, the Tullock contest success function defines the probability that the firm or any single hacker finds the vulnerability first:

Here, i denotes either the firm (when $i=f$) or a hacker (when $i=(t,k)$). The term $d>0$ captures the case when the vulnerability is not found. We can interpret d as the exogenous difficulty in finding the vulnerability or an exogenous competition from nature.

We complete the model specification by defining the firm’s and hackers’ cost functions. In general, the cost should increase with effort. We model the firm’s cost as $c_f{x}_f$, and each hacker’s cost as $c_h{x}_{t,k}$, where subscript h categorically indicates the hackers and $c_f$ and $c_h$ are exogenous cost parameters. A linear cost function helps obtain closed-form solutions and is common in Tullock contest settings (e.g., Dixit 1987, Baye and Hoppe 2003) because of analytical tractability. Our key insights are robust to any increasing and convex cost functions as shown in Online Appendix D.2. Cost parameters $c_f$ and $c_h$ measure the firm’s and hackers’ relative vulnerability identification efficiency (e.g., know-how and experience with security and whether they have access to sophisticated testing tools and knowledge). As is customary in the information security literature, we assume that $c_f$ and $c_h$ are common knowledge (Kannan and Telang 2005, Png and Wang 2009, Kannan et al. 2016).⁹

3.1. Equilibrium Without a BBP

The utility of a hacker is its valuation from misusing the vulnerability adjusted for the probability that it finds the vulnerability before all other players, net of its effort cost. Using (1), the net utility of hacker k of type t is¹⁰

Differentiating (2) with respect to $x_{t,k}$, the first-order condition (FOC) gives an implicit function for any hacker of type t (please refer to Online Appendix E for a detailed derivation):¹¹

where $X\equiv d+x_f+{\sum }_{j=1}^T{\sum }_{g=1}^{n_j}{x}_{j,g}$ measures the overall competition in finding the vulnerability. Equation (3) suggests that hackers of the same type make symmetric decisions. We simplify the notation by suppressing the individual hacker index, k. For example, we write $x_t$ instead of $x_{t,k}$ and $n_t{x}_t$ instead of ${\sum }_{k=1}^{n_t}{x}_{t,k}$. We emphasize that each hacker makes an independent decision.

Equation (3) implies $x_t\ge 0$ if and only if $v_t\ge c_{h}X$ (i.e., the valuation of exploiting the vulnerability must be large enough for a hacker to exert a positive effort). Otherwise, it chooses $x_t=0$. Because $v_1>v_2>\cdots >v_T\ge 0$, there exists some index $B\in [0,T]$ such that $x_t>0$ for all $t\le B$ and $x_t=0$ when $t>B$. If $B=0$, no hacker exerts a positive effort. Similarly, if $B=T$, all hackers compete to find the vulnerability.

When the competition result is determined by a Tullock function with an increasing and convex cost function, there exists a unique pure strategy equilibrium (see Szidarovszky and Okuguchi 1997, theorem 1). Intuitively, because the effort, $x_t$, is continuous, if the FOC of (2) is positive for any marginal hacker type t, the $n_t$ hackers of the same type must all expend effort in finding the vulnerability. It then follows that, in equilibrium, all hackers of type $B+1$ and beyond must exert zero effort. The boundary index, B, divides hackers into two groups—competing and noncompeting—in such a pure strategy equilibrium.

After obtaining the number of competing hackers, the firm’s payoff function becomes

The first term in (4) represents the loss from vulnerability misuse when a competing hacker finds the vulnerability before the firm. By combining the FOC of (4) and those of all hackers with type $t\le B$, we can compute the equilibrium B.

Lemma 1.

Without a BBP, hackers with type $t\le B^{nb}$ exert positive effort in finding a vulnerability, in which $B^{nb}$ is the largest index that satisfies the inequality

$$v_{B^{nb}}>\tau =\frac{\lambda c_h(N_1-N_{B^{nb}+1})}{c_f+\lambda c_h\sum _{j=1}^{B^{nb}}\frac{n_j}{v_j}},$$(5)

where $N_j\equiv n_j+n_{j+1}+\cdots +n_T$ represents the number of hackers with misuse benefits lower than or equal to $v_j$ and $N_1$ is the total number of hackers in the market.

Lemma 1 suggests that, in the baseline setting without a BBP, there exists an endogenous threshold of valuation, $\tau$, which relates positively to type $1,2,\dots ,B^{nb}$ hackers’ valuations and the firm’s security loss, $\lambda$, from the vulnerability, by which hackers are sorted into potential attackers (i.e., those who would spend effort to find and misuse the vulnerability) and nonattackers (i.e., those who would not exert effort to find the vulnerability). Figure 3 illustrates such an endogenous equilibrium distribution of hackers. Note that $\tau$ need not coincide with the valuation of any type of hacker.

After identifying $B^{nb}$, we can compute the equilibrium strategies of the firm and hackers from the FOC of (4) and (2). Lemma 2 summarizes the equilibrium outcomes.

Lemma 2.

Without a BBP, the equilibrium effort of any hacker of type t is $x_t=X^{nb}\left(1-\frac{c_h{X}^{nb}}{v_t}\right)$ when $t\le B^{nb}$, where $X^{nb}=\frac{\tau }{c_h}$. The effort $x_t=0$ for all $t>B^{nb}$. The hackers’ equilibrium expected payoff when $t\le B^{nb}$ is

$$u_t^{nb}=v_t{\left(1-\frac{c_h{X}^{nb}}{v_t}\right)}^2,$$(6)

and zero when $t>B^{nb}$.

The equilibrium effort of the firm is $x_f=X^{nb}\left(c_h{X}^{nb}{\sum }_{j=1}^{B^{nb}}\frac{n_j}{v_j}+1-N_1+N_{B^{nb}+1}\right)-d$, and its equilibrium expected payoff is

$${\pi }_f^{nb}=c_f\left[d-X^{nb}\left(c_h{\displaystyle \sum _{j=1}^{B^{nb}}\frac{n_j}{v_j}}{X}^{nb}+2-N_1+N_{B^{nb}+1}\right)\right].$$(7)

3.2. Equilibrium with a BBP

In addition to exerting effort to compete with hackers in finding the vulnerability, the firm could offer a bug bounty reward, r, to entice a hacker who finds the vulnerability first to submit it to the firm instead of misusing it. The incentive compatibility constraint of any hacker of type t requires that the reward from submission is not less than that from misusing the vulnerability. From (2), this means $\frac{r{x}_{t,k}}{d+x_f+{\sum }_{j=1}^T{\sum }_{g=1}^{n_j}{x}_{j,g}}-c_h{x}_{t,k}\ge \frac{v_t{x}_{t,k}}{d+x_f+{\sum }_{j=1}^T{\sum }_{g=1}^{n_j}{x}_{j,g}}-c_h{x}_{t,k}$ or $r\ge v_t$.

From the firm’s perspective, by Lemma 1, $r>\tau$ because, when a hacker’s valuation is less than $\tau$, the hacker would not exert any effort, making the bug bounty reward unnecessary. Similarly, $r\le v_1$ because $v_1$ is the highest valuation that any hacker can obtain. Any r beyond $v_1$ offers zero marginal benefit to the firm. Also, $r\le \lambda$ because the firm should not pay an award that is larger than its maximum potential loss. Finally, the firm would not offer a bug bounty reward when even the hacker with the lowest valuation, $v_T>\lambda$ (i.e., the maximum loss it would suffer from exploitation). We assume that $v_T\le \lambda$ to rule out this trivial case.

Combining the constraints in r characterized above, the firm needs to choose an r within the range $(\tau ,\min \{\lambda ,v_1\}]$ in period 1. Denote $B^M$ as the smallest index of hacker type that satisfies $v_{B^M}\le \lambda$ (i.e., the marginal hacker type that the firm is still willing to entice using a bug bounty reward). The firm’s problem in period 1 has the following cases:

The first term in each line of (8) is the expected net loss because of hackers misusing the vulnerability. The second term represents the expected net payout of the bug bounty reward when hackers submit the vulnerability. Traversing the cases downward, the first two terms suggest that, as r increases, more hackers are willing to submit the vulnerability to the firm than misusing it. Essentially, the bug bounty reward, r, sorts hackers into three groups with heterogeneous responses (cf. two groups when the BBP is not offered; see Figure 3).

• Cooperative hackers: When $v_T<\tau$, some hackers with low valuations from vulnerability misuse are incentivized by the bug bounty reward to help the firm find the vulnerability. All hackers with valuation $v_t\le \tau$ belong to this group.

• Coopetitive hackers: When $r>v_{B^{nb}}$, some hackers who would otherwise pose a security threat without a BBP now submit the vulnerability. Hackers with moderate misuse benefits, those with valuation $v_t>\tau$ and $v_t\le r$, belong to this group.

• Competitive hackers: When $r<v_1$, some hackers always pose a security threat regardless of whether a BBP is offered. Hackers with high misuse benefits, those with valuation $v_t>r$, belong to this group.

Figure 4 provides an illustrative sorting of hackers in the case with a BBP. We compute the equilibrium using backward induction. The following lemma summarizes the firm’s and hackers’ behaviors when a BBP is offered.

Lemma 3.

Denote $B^O$ as the smallest index of hackers with $v_{B^O}\le r^{*}$, where the optimal reward is defined implicitly by $r^{*}=r(B^{nb}+1)$, $r(B^{nb}+1)$ being the solution of the dynamic programming problem $r(i)={\mathrm{arg\hspace{0.17em}}\max }_{r\in \{r_i,r(i-1)\}}{\pi }_f^b(r)$ with the initial condition $r(1)=v_1$, and $r_i$ and ${\pi }_f^b(r)$ are defined in the Online Appendix.¹² The equilibrium effort of any hacker of type $t<B^O$ is $x_t=X^b(1-\frac{c_h{X}^b}{v_t})$ and of type $t\ge B^O$ is $x_t=X^b(1-\frac{c_h{X}^b}{r^{*}})$, where $X^b=\frac{(N_1-N_{B^O})\lambda +N_{B^O}{r}^{*}}{c_f+N_{B^O}{c}_h+\lambda c_h{\sum }_{j=1}^{B^O-1}\frac{n_j}{v_j}}$. The hackers’ equilibrium expected payoff is

$$u_t^b=\{\begin{array}{l}{v}_t{\left(1-\frac{c_h{X}^b}{v_t}\right)}^2, \text{when} t<B^O\hfill \\ r^{*}{\left(1-\frac{c_h{X}^b}{r^{*}}\right)}^2, \text{when} t\ge B^O.\hfill \end{array}$$(9)

The equilibrium effort of the firm is $x_f=X^b[c_h({\sum }_{j=1}^{B^O-1}\frac{n_j}{v_j}+\frac{N_{B^O}}{r^{*}})X^b+1-N_1]-d$, and its equilibrium expected payoff is

$${\pi }_f^b=c_f\left(d-X^b\left[c_h\left({\displaystyle \sum _{j=1}^{B^O-1}\frac{n_j}{v_j}}+\frac{N_{B^O}}{r^{*}}\right)X^b+2-N_1\right]\right).$$(10)

Because the firm’s payoff in (8) is discontinuous when r exceeds $v_i$ (which changes the firm’s expected cost from $\lambda$ to r), the optimal r can be computed from a dynamic programming problem, namely, we must solve a concave maximization problem across cases of the firm’s profit function in (8).¹³ We present an efficient algorithm to obtain the optimal r with time complexity $O(B^{nb})$ in the proof of Lemma 3.

The purpose of BBP contradicts the commonly held deterrence view of security protection in Section 3.1; instead of unequivocally deterring hacking and hoping to reduce the number of hackers, a BBP might incentivize more cooperative and coopetitive hackers to search for the vulnerability. A moderate degree of hacking by the right group of people might reduce a firm’s security risk when a BBP is used.

4. Impact of the Bug Bounty Program

Comparing the firm’s payoffs, ${\pi }_f^{nb}$ from (7) and ${\pi }_f^b$ from (10), the first proposition follows.

Proposition 1.

A BBP improves a firm’s payoff if and only if

1. The efficiency of the firm in finding the vulnerability is sufficiently low relative to hackers (i.e., $\frac{c_f}{c_h}>\widehat{c}$), where $\widehat{c}$ is the unique solution to $\widehat{c}-\frac{2(N_1-N_{B^{nb}+1})\lambda {\sum }_{i=1}^{B^{nb}}\frac{n_i}{v_i}}{\widehat{c}+\lambda {\sum }_{i=1}^{B^{nb}}\frac{n_i}{v_i}}+N_1-N_{B^{nb}+1}-2+\lambda {\sum }_{i=1}^{B^{nb}}\frac{n_i}{v_i}=0$.

2. The market contains a sufficiently large portion of coopetitive hackers, that is, there exist hacker type(s) $t_0\le B^{nb}$ such that $\frac{n_{t_0}}{N_{t_0}}\lambda -v_{t_0}+\frac{1}{N_{t_0}}{E}_{t_0}\ge 0$,¹⁴ where $E_{t_0}\ge v_{t_0}{N}_{t_0}-n_{t_0}\lambda$ whenever $\frac{n_{t_0}}{N_{t_0}}\lambda -v_{t_0}\ge 0$. A sufficient condition is $\frac{n_{t_0}}{N_{t_0}}\lambda -v_{t_0}\ge 0$.

The first condition in Proposition 1 is expected because it represents typical motivation for a firm to outsource a task (Quinn and Hilmer 1994). What is interesting in Proposition 1 is the second condition, which suggests that as long as a sufficient number of hackers is coopetitive, the BBP benefits the firm irrespective of the relative efficiency between the firm and hackers (note that the sufficient condition $\frac{n_{t_0}}{N_{t_0}}\lambda -v_{t_0}\ge 0$ does not depend on the cost parameters). Furthermore, in contrast to the common belief that a larger crowd enhances crowdsourcing effectiveness, here, more BBP participants might make a BBP less attractive. When the first condition in Proposition 1 is not met, more cooperative hackers, which increase $N_{t_0}$ without affecting $n_{t_0}$, make the second condition less likely to hold.

To understand Proposition 1, we characterize two key benefits of BBPs. Rearranging the firm’s payoff with and without BBP,

where $B^O$ denotes the smallest index such that $v_{B^O}\le r$. The BBP changes the firm’s payoff in two ways.

First, it incentivizes cooperative hackers indexed by $B^{nb}+1,\dots ,T$ to find the vulnerability. Their efforts add to the denominators in (12), namely, $d+x_f+{\sum }_{j=1}^{B^{nb}}{n}_j{x}_j$ becomes $d+x_f+{\sum }_{j=1}^T{n}_j{x}_j$. Because $r\ge v_t$ for coopetitive hackers, they exert more effort to compete with competitive hackers, who now face greater competition from other hackers. The firm’s security risk is reduced; the first term in (12) decreases as the sum of efforts in the denominator increases. Meanwhile, a new cost in the third term in (12) appears because of an expected bug bounty payment to cooperative hackers.

Conceptually, this effect of a BBP is similar to delegating protection to cooperative and coopetitive hackers. We call this effect protection delegation. The less efficient a firm is at vulnerability identification than the hackers ($\frac{c_f}{c_h}>\widehat{c}$), the more profitable such delegation becomes. This captures the conventional outsourcing wisdom: organizations with relatively low in-house efficiency can leverage the crowd to increase task efficiency (Terwiesch and Xu 2008). One difference here, however, is that the firm uses the crowd to combat competitive hackers instead of simply completing an outsourced task.

Another departure from conventional crowdsourcing is reflected in the second term of (11) and (12). Without the BBP, coopetitive hackers would be attackers inflicting damages, $\lambda$, on the firm if they had found the vulnerability first. The BBP reward, r, reduces such potential damage. Note that $v_t\le r\le \lambda$ for coopetitive hackers, that is, the bug bounty reward, r, is greater than their gain from misusing the vulnerability but smaller than the firm’s loss, $\lambda$, when the vulnerability is misused. This suggests that the firm can take advantage of the gap between $\lambda$ and $v_t$, where $t\in \{B^O,\dots ,B^{nb}\}$, and offer a bug bounty reward r to entice coopetitive hackers. This leads to a Pareto improvement for the firm and coopetitive hackers because the firm does not need to suffer a loss because of vulnerability misuse, and coopetitive hackers can receive a higher payoff. We call this benefit of the BBP attack diversion.

The second condition of Proposition 1 is more likely to hold when $\frac{n_{t_0}}{N_{t_0}}$ and the difference between $\lambda$ and $v_{t_0}$ are large. A large $\frac{n_{t_0}}{N_{t_0}}$ means that, prior to having the BBP, a large portion of hackers would already be looking for the vulnerability (recall $t_0\le B^{nb}$), but their valuation from misuse, $v_{t_0}$, is small relative to $\lambda$. In such a case, the firm might benefit from the BBP even when hackers are not more efficient at vulnerability discovery because the key benefit of the BBP lies in diverting the threat from this large group of coopetitive hackers.

It is important to recognize that, although the firm always has an incentive to offer a bug bounty reward $r\ge v_t$ provided that $v_t<\lambda$, it must balance the benefit from dissuading coopetitive hackers from attacking it and the influence on hackers with lower misuse benefit because the firm offers the same BBP reward to all hackers. The reward induces hackers with lower valuations, who would otherwise not search for the vulnerability, to exert more effort to pursue the bug bounty reward and increase the firm’s expected bug bounty payment. Increased effort from these low-valuation (cooperative) hackers helps reduce the expected security loss, but the net benefit to the firm is ambiguous because of the extra cost incurred for the bug bounty payment. When cooperative hackers are inefficient but sizeable, their large size can undermine the return on investment from the BBP and renders it unprofitable.

Some large organizations, such as Oracle, criticize BBPs, whereas others, such as Alphabet and Meta, choose to adopt them. Proposition 1 can help reconcile this discrepancy. Oracle offers paid enterprise software that is accessible mostly to users with experience and skills. Hackers with such specialized knowledge might have high valuations from misusing the vulnerability (i.e., when $v_{t_0}$ is large), and the size of such hackers might be small relative to the entire hacker distribution (i.e., $\frac{n_{t_0}}{N_{t_0}}$ is small). Furthermore, companies such as Oracle might have more resources to engage top-tier security experts with high efficiency to safeguard their systems. Accordingly, both conditions in Proposition 1 are less likely to hold, and this might explain why it does not favor BBPs.

By contrast, the products from Alphabet and Meta and similar online platforms, are often used in the public domain. They may attract significant numbers of casual hackers actively searching for vulnerabilities in their customer-facing products even without a BBP (i.e., $\frac{n_{t_0}}{N_{t_0}}$ is large). If many of these hackers are coopetitive and willing to trade the vulnerability finding for a bounty reward, the benefit of the BBP can be high because the cost of the bounty reward can be substantially lower than the cost of vulnerability misuse (Herley and Florêncio 2010). In such a case, the BBP is beneficial regardless of hacker efficiency.

We end the discussion of Proposition 1 by highlighting its relevance to some BBP phenomena that are not readily explained by existing crowdsourcing theories.

The first is underpaid hackers. If no hacker had a misuse benefit below $v_{t_0}$, then $n_{t_0}=N_{t_0}$, and hence, $\frac{n_{t_0}}{N_{t_0}}\lambda -v_{t_0}\ge 0$ would hold for any $v_{t_0}<\lambda$, suggesting that a firm is willing to offer a bug bounty reward to entice type $t_0$ hackers whenever $v_{t_0}<\lambda$. The presence of hackers with lower misuse benefits (i.e., the presence of the $\frac{n_{t_0}}{N_{t_0}}$ term), however, limits a firm’s incentive to do so. This is a kind of pecuniary externality imposed by low-valuation hackers on other hackers; the mere presence of low-valuation hackers limits the firm’s incentive to offer larger bounty rewards that might otherwise have diverted more high-valuation (coopetitive) hackers.

Because of this pecuniary externality, a firm might underpay bug bounty rewards, leaving hackers with $v_t\in (r,\lambda )$ more willing to misuse the vulnerability than cooperating with the firm despite the fact that they are not too expensive to divert. Hackers often complain about low BBP payments (Krebs 2013). For example, “various BBPs have been criticized over the years for issues ranging from allegedly underpaying researchers…out of this frustration, researchers have publicly published apparent zero-days and sold their exploits to third parties such as zero-day brokers” (Culafi 2021, para. 2). Uber once paid $100,000 when extorted by a hacker for a vulnerability that could have led to a data breach, and yet the highest listed reward on Uber’s public BBP is $10,000 (Perlroth and Isaac 2018).

Next is bug bounty reward discrimination. The pecuniary externality provides an interesting implication for BBP design. In general, the higher the $v_{t_0}$, the less likely $\frac{n_{t_0}}{N_{t_0}}\lambda -v_{t_0}\ge 0$ holds, suggesting that offering $r\ge v_{t_0}$ would more likely stimulate low-valuation hackers’ excessive effort that might erode the firm’s profit. In other words, when a firm offers a large bug bounty reward to gain the attack diversion benefit, the bug bounty payment itself might become a significant cost. The firm should manage the (unintended) payment to low-valuation hackers by disincentivizing them from exerting too much effort. One possibility is price discrimination; the firm might promise different award levels to different types of hackers by self-selection. For example, Apple’s BBP, which offers rewards up to one million dollars, states that “reports that include a basic proof of concept instead of a working exploit are eligible to receive no more than 50% of the maximum payout amount” (Apple 2019). The discriminatory bug bounty reward policy might dissuade low-value hackers from exerting too much effort, reducing the pecuniary externality that they inflict on higher value (coopetitive) hackers.¹⁵

From this point onward, we assume that the condition described in Proposition 1 holds; that is, it is beneficial for the firm to offer a BBP.

4.1. Security Impact

We now examine the security implications of a BBP. Let S denote the probability of vulnerability misuse; $1-S$ then represents the security of the system. To examine the security with and without a BBP, we compare $S^{nb}={\sum }_{i=1}^{B^{nb}}\frac{n_i{x}_i}{d+x_f+{\sum }_{j=1}^{B^{nb}}{n}_j{x}_j}$ and $S^b={\sum }_{i=1}^{B^O-1}\frac{n_i{x}_i}{d+x_f+{\sum }_{j=1}^T{n}_j{x}_j}$. From the analysis in Proposition 1, a BBP incentivizes coopetitive hackers not to attack the firm (i.e., eliminating ${\sum }_{i=B^O}^{B^{nb}}\frac{n_i{x}_i}{d+x_f+{\sum }_{j=1}^T{n}_j{x}_j}$ from the vulnerability misuse risk) and both cooperative and coopetitive hackers to compete against the competitive hackers (i.e., adding the effort terms ${\sum }_{j=B^{nb}+1}^T{n}_j{x}_j$ to the denominator of the vulnerability misuse risk). These two factors improve the security.

Nevertheless, changes in coopetitive and cooperative hackers’ behaviors distort competitive hackers’ and the firm’s incentives. From the Tullock function in (1), the firm’s effort is a strategic substitute of cooperative and coopetitive hackers’ efforts under the BBP. Referring to the firm’s payoff function in (8), its marginal benefit from in-house effort under a BBP, $\frac{\partial {\pi }_f^b}{\partial x_f}=\frac{1}{d+x_f+{\sum }_{j=1}^T{n}_j{x}_j}({\sum }_{v_i>r}\lambda \frac{n_i{x}_i}{d+x_f+{\sum }_{j=1}^T{n}_j{x}_j}+{\sum }_{v_i\le r}r\frac{n_i{x}_i}{d+x_f+{\sum }_{j=1}^T{n}_j{x}_j})-c_f$, depends on two factors: (i) the difficulty of finding the vulnerability itself, $\frac{1}{d+x_f+{\sum }_{j=1}^T{n}_j{x}_j}$, and (ii) the expected cost when the vulnerability is found first by hackers in terms of either vulnerability misuse cost or bug bounty payment cost, ${\sum }_{v_i>r}\lambda \frac{n_i{x}_i}{d+x_f+{\sum }_{j=1}^T{n}_j{x}_j}+{\sum }_{v_i\le r}r\frac{n_i{x}_i}{d+x_f+{\sum }_{j=1}^T{n}_j{x}_j}$. The bug bounty reward induces greater competition among hackers, and this increases the difficulty for the firm to find the vulnerability first. Because of the attack diversion and protection delegation benefits, it also decreases the expected cost of the firm when hackers find the vulnerability first. Both factors incentivize the firm to reduce its in-house effort.

Competitive hackers now face more competition from coopetitive and cooperative hackers but less competition from the firm. The net influence of a BBP on their effort depends on the balance of these two opposing forces. Figure 5 shows the equilibrium effort of competitive hackers in an illustrative market with three types of hackers, $T=3$.¹⁶ When the number of cooperative hackers is small and the bug bounty reward is not high, a BBP does not induce significant competition among the hackers. However, the firm would reduce its in-house effort because of reduced threats from coopetitive hackers. Accordingly, the competitive hackers might respond by exerting even more effort than when the BBP is absent because its chance of finding the vulnerability first can be higher now. This incentive of competitive hackers decreases as the number of cooperative hackers increases, and this increases the competitive intensity in finding the vulnerability because of the protection delegation effect.¹⁷ In Online Appendix C.1, we present the exact conditions for competitive hackers to increase or decrease their efforts.

Proposition 1 suggests that, when too many hackers with low misuse benefits expend effort to find the vulnerability, the firm’s payoff can decrease because of the bug bounty payment. These hackers’ effort, however, always improves system security because they compete with competitive hackers and, thus, discourage competitive hackers from expending effort. The implication is that, when an organization cares more about security than economic benefits, the pecuniary externality described in Proposition 1 is moot. The BBP can be designed to entice as many cooperative hackers as possible. For example, the U.S. Department of Defense (2018) increased the reach of its BBP, “Hack the Pentagon,” by inviting registered hackers on multiple bug bounty platforms such as HackerOne and Bugcrowd. Our analysis suggests that this might be security-driven rather than economically motivated.

Figure 6 shows how the various effects of BBP vary with the number of cooperative hackers. They collectively raise the system’s security.

Proposition 2.

The system’s security increases with a BBP.

Despite the strategic substitution induced by the attack diversion and protection delegation benefits, Proposition 2 suggests that the firm retains sufficient in-house effort to ensure enhanced overall system security. In other words, unlike typical crowdsourcing, the firm should continue to compete with hackers, leveraging them for vulnerability identification using the BBP. The point of departure is that the bounty payment (i.e., the second term in (8)) decreases with the firm’s effort, creating an incentive for the firm to use its own effort to economize the BBP payment.

4.2. Social Welfare

We now consider social welfare. In line with the cybersecurity literature (e.g., August and Tunca 2011, Kannan et al. 2016, August et al. 2022), we assume society prefers minimizing security losses and all effort costs:¹⁸

A bounty reward does not enter social welfare because it is a transfer payment from the firm to the winning hacker. However, it indirectly affects social welfare by influencing the security loss and effort costs. An excessive bug bounty reward reduces security loss but raises hackers’ effort costs, and this may potentially lower social welfare, suggesting that the socially optimal bounty reward is finite.

Assume that a social planner can optimize the bounty reward and in-house effort to maximize social welfare. Comparing the firm’s choice with that of the social planner, see the following proposition.

Proposition 3.

In a BBP, the firm offers (weakly) insufficient bug bounty rewards. There exists a threshold, $c_w>0$, for which the firm’s in-house effort is socially efficient only when $c_f=c_w$. Its in-house effort is excessive when $c_f>c_w$ and insufficient when $c_f<c_w$.

A bounty reward provides greater benefits to society than the firm. Comparing $W^b$ and ${\pi }_f^b$ in (13), the firm does not internalize two positive externalities of the bounty reward. First, a reward diverts some hackers into nonharmful activities (additional $u_i^b$ in ${\sum }_{v_i\le r}{n}_i{u}_i^b$). Second, a higher reward improves the payoffs of cooperative and coopetitive hackers (each $u_i^b$ in ${\sum }_{v_i\le r}{n}_i{u}_i^b$ increases with r), and it reduces competitive hackers’ effort too (reduced ${\sum }_{v_i>r}{c}_h{n}_i{x}_i$). The firm tends to undersupply bug bounty rewards because of these two externalities.

Comparing the payoff of the social planner in (13) with that of the firm in (12), two disparities determine the in-house effort inefficiency: (i) A bounty payment directly reduces the firm’s payoff but not that of the social planner. The incentive to reduce a bounty payment leads the firm to exert excessive in-house effort. (ii) The social planner accounts for all effort costs, but the firm only focuses on its own effort. When its efficiency is high relative to the hackers’, the social planner prefers the protection effort from the firm than the hackers. The firm, however, ignores this social benefit, leading to insufficient in-house effort. Similarly, when the firm’s efficiency is low relative to the hackers, its effort becomes excessive because more effort from hackers would save protection effort costs. Taken together, the firm exerts excessive effort when its efficiency is low and insufficient effort when its efficiency is high.

Market efficiency has always been central to the security outsourcing literature. Yet the inefficiency identified here is unique. In typical security-outsourcing scenarios (e.g., Lee et al. 2013, Hui et al. 2019), the firm undersupplies protection because it does not bear the full consequence of a security breach; instead, the managed security service provider absorbs part of the loss through compensation. In a BBP, this incentive to undersupply effort is absent because the firm suffers the full loss of a security breach. Yet it can either oversupply or undersupply security effort and reward because it does not internalize two novel social benefits of BBP: diverting some hacking into nonharmful activities and saving protection costs by reallocating security efforts between the firm and hackers.

We explore policies to increase social welfare. The BBP has two unique characteristics. First, unlike conventional contexts that typically feature insufficient protection (e.g., in security investment, e.g., Anderson and Moore 2006; outsourcing, e.g., Lee et al. 2013, Hui et al. 2019; and software patching, e.g., August and Tunca 2011), BBPs might lead a firm to oversupply effort. Addressing such inefficiency and its implications on existing cybersecurity policies is largely unexplored. Second, the inefficiencies in bounty rewards and the firm’s in-house effort may call for different policies.

We focus on two broad categories of policies. The first directly increases the benefit for the firm to offer a large bounty reward. Examples include tax reductions and direct subsidies for bounty payments. For example, the European Union has sponsored BBPs for some open-source software since 2017 (European Commission 2019). This can be incorporated by representing the firm’s bounty payment as ${\sum }_{v_i\le r}(r-s)\frac{n_i{x}_i}{d+x_f+{\sum }_{j=1}^T{n}_j{x}_j}$ in (8), in which s represents a reward subsidy or tax reduction. Another approach involves indirectly influencing the firm’s incentive by penalizing or subsidizing data breaches. For example, many countries impose additional fines for data breach. This can be modeled by representing the firm’s security loss as ${\sum }_{v_i>r}(\lambda +l)\frac{n_i{x}_i}{d+x_f+{\sum }_{j=1}^T{n}_j{x}_j}$ in (8), in which l represents a breach penalty or subsidy (when $l<0$). We focus on these two policies because of their practicality, requiring minimal changes to existing practices. We can obtain other (more complex) approaches—such as collecting taxes to fund BBPs—by combining these two approaches. The key question is, should the government subsidize bounty rewards (or provide equivalent tax reductions), impose breach penalties, or subsidize data breaches to induce more efficient BBP use?

Proposition 4.

A breach penalty is the preferred policy for social welfare when the firm’s effort efficiency is high ($c_f<c_w$), whereas a bounty subsidy is the preferred policy for social welfare when the firm’s effort efficiency is low ($c_f>c_w$).

Table 2 summarizes the impacts of different policies on social welfare and inefficiencies. When the firm’s effort efficiency is low, bounty subsidies align with the social planner’s objectives. When the firm’s effort efficiency is high, breach penalties help align the objectives. Breach subsidies always exacerbate reward inefficiency. The potential for bounty subsidies (breach penalties) to improve social welfare when breach penalties (bounty subsidies) reduce social welfare suggests their complementary relationship in addressing BBP inefficiencies.

Table 2. The Welfare Impact of Different Policies

A bounty subsidy affects the firm’s incentive in two ways. First, it lowers the cost of paying a bounty reward, making the firm more willing to offer a higher reward. This aligns with the social planner’s bounty reward preference. Second, the lower cost of paying cooperative and coopetitive hackers when they find the vulnerability first induces the firm to lower its in-house effort. This aligns with the social planner’s protection effort preference when the firm is relatively inefficient. When the firm is efficient, reduced in-house effort exacerbates the protection effort inefficiency, which can reduce social welfare. Kannan and Telang (2005) advocate government-funded vulnerability reporting to improve social welfare without endogenizing firms’ protection efforts. Our analysis suggests that such reporting could reduce social welfare when the firm has high protection efficiency.

Breach penalties are common in cybersecurity regulation, but their implications on social welfare with BBPs are not trivial. A breach penalty increases the firm’s expected security loss and, in turn, the marginal benefit of a bounty reward, leading the firm to offer a higher reward. It can, thus, increase reward efficiency. Nevertheless, it raises the firm’s costs when competitive hackers find the vulnerability first, and this encourages the firm to increase in-house effort. This increases protection effort efficiency when the firm is relatively efficient, but it can exacerbate protection effort inefficiency in other cases. Conversely, although a breach subsidy increases effort efficiency when the firm’s efficiency is low, it lowers the firm’s incentive to offer a high reward, hence exacerbating the firm’s reward inefficiency.

Our findings highlight the need to review existing cybersecurity regulations to account for BBPs, particularly by considering a firm’s capability. For example, current U.S. cybersecurity laws seldom consider companies’ BBP adoption when levying breach fines. Our analysis suggests that it can be counterproductive if uniform penalties are applied to companies with BBPs but poor cybersecurity capabilities. In contrast, under the General Data Protection Regulation (GDPR), adoption of BBPs by companies can lead to reduced fines for data breach (HackenProof 2023). Although differential treatment is necessary, we advocate for a more tailored approach that considers firms’ cybersecurity capabilities because leniency to competent companies might reduce social welfare. Furthermore, although most governments rely on reactive measures, such as imposing penalties after breaches occur, they should recognize the limitations of these measures and explore proactive approaches, such as selective BBP subsidies, as complementary policies.

5. The Optimal Bounty Reward

We perform a comparative static analysis to understand the properties of the bounty reward (i.e., $r^{*}$ in Lemma 3). We use the main model to draw general conclusions. To avoid cluttered details and better highlight the key trade-offs and findings, we consider the following stylized scenario with three types of hackers.¹⁹

There are three types of hackers indexed by H, M, and L. Their respective sizes are $n_H$, $n_M$, and $n_L$ and have valuations $v_H$, $v_M$, and $v_L$ from misusing the vulnerability. Furthermore, $v_H>\lambda$, $v_M\in ({\tau }_s,\lambda )$, and $v_L\le {\tau }_s$, where ${\tau }_s=\frac{\lambda c_h(n_H+n_M)}{c_f+\lambda c_h(\frac{n_H}{v_H}+\frac{n_M}{v_M})}$ from Lemma 1.

This stylized model captures the essential characteristics of three hacker groups. As cooperative hackers, L-type hackers have a low misuse benefit and are incentivized by the bounty reward to help the firm find the vulnerability. M-type hackers have a moderate misuse benefit (which can be considered as the average black market price for the vulnerability), posing a security threat without BBP though they might participate in the BBP if the reward is attractive. As competitive hackers, H-type hackers are unlikely to participate in the BBP because of their high misuse benefit.

Proposition 5.

The optimal bounty reward can increase or decrease with an increasing number of cooperative hackers. In the stylized scenario, the influence of increased cooperative hackers on the optimal bounty reward in various scenarios is reported in Table 3. The optimal bounty reward (weakly) increases with the breach cost, lower in-house efficiency relative to the hackers, and increased number of competitive hackers.

Table 3. The Influence of L-Type Hackers on the Bounty Reward

Figure 7 shows how the optimal bounty reward changes with the number of L-type (cooperative) hackers. Factors such as general interest in BBPs and the firm’s marketing and promotion of a BBP can influence the number of cooperative hackers.

Conventional crowdsourcing wisdom suggests that the optimal reward increases with participant size (e.g., Ales et al. 2017, Liu et al. 2018). However, Proposition 5 suggests that this principle applies only when a firm’s efficiency and $v_M$ are low as shown in Figure 7(a). Here, by offering a small reward, the firm can attract both L- and M-type hackers, deriving protection delegation and attack diversion benefits from the BBP. As the number of cooperative hackers increases, their overall capability grows, incentivizing the firm to invest more in the BBP by increasing the reward.

However, as Figure 7, (b) through (d), shows, in a broad range of scenarios, conventional crowdsourcing results do not apply because the firm’s bounty reward might become insensitive, decrease, or change nonmonotonically as the number of cooperative hackers increases. First, in cases (b) through (d), the firm’s reward is insensitive to increased L-type hackers when their numbers are small. With a small number of L-type hackers, the pecuniary externality described in Proposition 1 is not salient, so the firm is willing to offer a relatively large reward $r=v_M$ to obtain the attack diversion benefit. Yet, unlike case (a), the firm has little incentive to increase the reward beyond $v_M$ because the high reward (cases (b) and (c)) or hackers’ low efficiency (case (d)) make a large bounty reward influence the firm’s payoff negatively ($\frac{\partial {\pi }_f^b}{\partial r}<0$). Therefore, the optimal bounty reward is $r=v_M$, which is sufficient for an attack diversion benefit, minimizing the bounty cost.

Although the firm uses a similar reward strategy in cases (b) through (d) with a small number of L-type hackers, it should apply different strategies when the number of L-type hackers is large. Specifically, with a high $v_M$ and efficient hackers, the firm would decrease reward initially and then increase it as the number of L-type hackers increases (Figure 7(b)). Why would increased L-type hackers influence the optimal reward in opposite ways in different ranges of $n_L$? A high $v_M$ renders a large bounty reward, $r=v_M$, economically unsustainable because the bounty payment can become excessive with more L-type hackers. Once the number of L-type hackers reaches a threshold, the firm should first lower the bounty reward to save bounty costs and focus on the protection delegation benefit. However, if the number of L-type hackers increases further, the firm should increase the reward again as in case (a) (i.e., L-type hackers’ increased overall capability). However, the reward will never return to the previous peak (i.e., $v_M$) because of the financial burden of rewarding the large pool of L-type hackers. In other words, the firm’s bounty reward tends to be larger when the number of cooperative hackers is small.

In contrast, if $v_M$ is moderate and hackers are relatively efficient, the firm’s bounty reward is larger when the number of cooperative hackers is large as shown in Figure 7(c). Although a small number of L-type hackers does not affect the optimal reward, their increased size increases the firm’s incentive to offer a larger reward, which can eventually exceed $v_M$ if $v_M$ is below the threshold $\overline{v_M}$. Beyond this point, more L-type hackers would further drive the optimal reward above $v_M$. Comparing Figure 7, (b) and (c) (or (a)), and if we interpret $v_M$ as the black market price for the vulnerability, one surprising implication is that, for firms that are otherwise similar, those with high black market vulnerability prices—potentially because of their connections to more valuable targets—tend to reduce their bounty rewards as the market attracts more cooperative hackers, whereas those with low vulnerability prices tend to increase their rewards.

Figure 7(d) shows that, sometimes, the firm’s bounty reward drops abruptly from a high value to zero. As discussed in Proposition 1, inefficient cooperative hackers offer little protection delegation benefits and would, in fact, erode attack diversion benefits through pecuniary externality, gradually negating the BBP benefits as their number increases. We also find that breach costs, hackers’ efficiency relative to the firm, and the number of competitive hackers have expected positive influences on a bounty reward. These factors heighten a firm’s security risks, incentivizing it to raise the bounty reward to address such risks.

Proposition 5 highlights a nuanced relationship between the optimal reward and participant size in crowdsourcing with coopetition. Although extant studies examine how participant size affects rewards, none has considered the influence of coopetition on the optimal reward choice, which we show can lead the optimal reward to exhibit remarkably different properties. Our findings underscore the importance of accounting for coopetitive dynamics when optimizing rewards for BBPs and other similar crowdsourcing contests.

6. Extensions

Our model can serve as the foundation to analyze various BBP policies and regulation of settings involving coopetitive relationships. This section examines two prominent BBP policy designs: safe harbor terms and policies for managing duplicate report submissions. Online Appendix D discusses other extensions, including general cost functions, incorporating altruistic hackers, and a sequential decision setting.

6.1. Safe Harbor Terms

Although BBPs allow firms to benefit from hackers’ efforts, traditional cybersecurity regulations often suppress hacking, including many security-testing activities that are necessary for vulnerability identification. For example, the Computer Fraud and Abuse Act (CFAA) in the United States makes it illegal to “intentionally access a computer without authorization or exceed authorized access, and thereby obtain…information from” almost any computer. The Computer Misuse Act of 1990 in the United Kingdom and China’s criminal law contain similar provisions (e.g., Qi et al. 2009, Swinhoe 2020). These laws have long been criticized for their ambiguity regarding what constitutes authorized access, creating a challenging environment for hackers to participate in BBPs because of the potential risk of legal repercussions for their security research. As a canonical incident, the drone manufacturer DJI once threatened legal action under the CFAA against a hacker regarding a nondisclosure agreement amid the hacker’s efforts to report a vulnerability through DJI’s BBP (Gallagher 2017).

One solution recommended by legal scholars and industry experts is to include an SHT in BBP policies to explicitly authorize ethical security testing (e.g., Thompson 2008, Elazari 2018). A typical SHT reads, “Safe Harbor: we will not threaten or bring any legal action against anyone who makes a good faith effort to comply with this BBP, or for any accidental or good faith violation of this policy. This includes any claim under the DMCA for circumventing technological measures to protect the services and applications eligible under this policy. As long as you comply with this policy: We consider your security research to be ‘authorized’ under the CFAA” (from Mozilla’s BBP).²⁰ Many big companies, such as Amazon, GitHub, and Tesla, include SHTs in their BBPs though numerous other firms do not amid criticisms from researchers (Elazari 2018).

Is the SHT beneficial to a firm using BBPs? Our analysis so far assumes no legal risk in security testing, which is a reasonable simplification because people conducting vulnerability research have rarely been convicted criminally (e.g., Etcovitch and van der Merwe 2018).²¹ We now extend the model to analyze an SHT’s influence by assuming that testing a firm’s system brings nontrivial legal risks, represented by a disutility, $\xi$.²² A hacker’s payoff function without an SHT becomes

which incorporates the key consideration that a hacker who tests a system ($x_{t,k}>0$) incurs a disutility $\xi x_{t,k}$ because of the legal risks. Ceteris paribus, this disutility term reduces the incentive for cooperative or coopetitive hackers to help a firm find vulnerabilities, a key reason many people recommend an SHT in a BBP.

An SHT introduces two changes. First, the firm exempts hackers from legal liabilities when they participate in the BBP ($\xi x_{t,k}$ disappears in the first scenario of (15)). Ideally, competitive hackers should still be held accountable for testing the firm’s system, but as noted by some legal scholars (e.g., Thompson 2008), it is practically challenging for a firm to differentiate ethical testing from malicious ones because the firm observes only its systems being accessed by outsiders. We consider the payoff function

We introduce the parameter $\alpha \in [0,1]$ to model the change in legal risks when competitive hackers test the system. The extreme case $\alpha =1$ represents an ideal situation in which competitive hackers cannot benefit from a SHT, and so they face the same legal risks as before. The other extreme, $\alpha =0$ represents the case when the SHT broadly authorizes security research. For example, Disclose.io, a website that promotes SHTs, recommends a template: “When conducting vulnerability research, according to this policy, we consider this research conducted under this policy authorized concerning any applicable antihacking laws…”²³ The previous example from Mozilla mentions that the term applies when hackers “comply with this BBP.” Limited provisions such as this increase $\alpha$ above zero because, if competitive hackers’ misuse of a vulnerability is investigated and convicted, they might still face legal penalties associated with their research activities. Therefore, different values of $\alpha$ reflect variations in SHT design. We are interested in how $\alpha$ affects the benefit of BBPs.

Second, an SHT changes hackers’ incentive compatibility constraints, reflected by $\rho (v_t)\le r$ and $\rho (v_t)>r$ in (15), in which $\rho (·)$ is an endogenous discount function (the technical details are available in the proof of Proposition 6). When deciding whether to report or misuse a vulnerability, hackers need to consider the additional legal risk of $\alpha \xi x_t$ associated with misuse. We assume that hackers use the function $\rho (v_t)$ to discount their misuse benefit to decide whether to report a finding. Clearly, $\rho (v_t)<v_t$ whenever $\alpha >0$.

Proposition 6.

The firm’s payoff from including an SHT in the BBP decreases as $\alpha$ decreases. There exists a threshold $\widehat{\alpha }\in (0,1)$ such that an SHT increases the firm’s payoff when $\alpha >\widehat{\alpha }$. When $\alpha \le \widehat{\alpha }$, an SHT increases the firm’s payoff only when the firm’s efficiency in finding the vulnerability is sufficiently low relative to hackers (i.e., $\frac{c_f}{c_h}$ is sufficiently large). It reduces the firm’s payoff otherwise.

Proposition 6 suggests that an SHT is beneficial only when $\alpha$ is close to one, and it might bring net harm otherwise. This might explain the paradox of why many companies are reluctant to adopt SHTs despite benefiting from ethical hacking and being criticized. First, firms face uncertainty regarding whether an SHT brings net benefits. Second, even if they realize that the benefits of SHTs depend on $\alpha$ (i.e., the SHT’s influence on competitive hackers), they might anticipate a low $\alpha$ if they adopt a recommended SHT such as the one from Disclose.io.

An SHT brings direct benefits and indirect costs. The first benefit is intuitive: it incentivizes ethical hacking by mitigating the associated legal risks. Second, and more subtly, it can help a firm save bounty costs. The minimum bounty the firm needs to offer to attract type t hackers is $r=v_t$ without an SHT, but with an SHT, this minimum decreases to $r^{\prime }=\rho (v_t)\le v_t$ as long as $\alpha >0$. In other words, an SHT provides the firm with a lever to conserve the bounty reward. However, the cost is that an SHT might be abused by competitive hackers. When $\alpha$ is small, an SHT incentivizes competitive hackers just as it incentivizes cooperative and coopetitive hackers, negating its positive influence on ethical hacking. Moreover, if $\alpha \to 0$, then $\rho (v_t)\to v_t$, meaning that the firm would lose the lever to conserve the bug bounty reward when $\alpha$ is small. An SHT, thus, increases the firm’s payoff mostly when $\alpha$ is large, and it can reduce the firm’s payoff otherwise except for a small parameter range (i.e., when $\frac{c_f}{c_h}$ is sufficiently large).²⁴

The key implication is that, to make SHTs beneficial to a firm, simply including authorizing language in BBP policies might not suffice; a firm should take proactive measures to ensure that $\alpha$ is sufficiently large. In other words, the firm should prevent hackers from interpreting SHTs as a general reduction of legal risks when probing vulnerabilities. Two strategies might increase $\alpha$. One is informational. According to perceptual-deterrence theory (e.g., Apel 2013, Chalfin and McCrary 2017), when potential offenders (competitive hackers here) are made more explicitly aware of the legal consequences of their criminal actions (security testing associated with vulnerability misuse), the deterrence effect of the law strengthens. We conjecture that $\alpha$ would be higher if an SHT delivers a clear message about the consequences of security research associated with vulnerability misuse. Meta’s BBP includes explicit terms that certain research activities disqualify one from SHT protection: “You make a good faith effort to avoid privacy violations and disruptions to others…access another person’s data or company data may demonstrate a lack of good faith and disqualify you from any benefit of the Safe Harbor…” (Facebook 2022).

A second promising approach is to require BBP participants to disclose identifier information during security testing and make SHT contingent on such disclosure. The idea is to induce hackers to self-select, which can make competitive hackers more distinguishable. For example, Amazon’s BBP requires participants to create accounts and include account information in their network traffics when testing Amazon’s systems.²⁵ This leaves competitive hackers with two options: test without identifier information, which Amazon can detect and block easily, or create fake accounts by incurring additional costs, which might still leave traces for investigation once they misuse a vulnerability. In both cases, because the research activities of competitive hackers become more identifiable, SHTs need not reduce the legal risks for competitive hackers.

Although a few studies have analyzed SHTs (e.g., Zhang et al. 2024), none considers SHTs’ influence on competitive hackers. Our findings demonstrate that this omission leads to overestimation of SHTs’ benefits, and it may result in suboptimal designs of SHTs.²⁶ Our study, thus, underscores the importance of considering the strategic interactions between competitive hackers and the firm in evaluating SHTs.

6.2. Duplicate/Invalid Reports

We extend the model to analyze the duplicate/invalid report problem.²⁷ Hackers may obtain duplicate or invalid findings when trying to identify vulnerabilities. They might submit such findings without validating them (see Endnote 27 for an example). Such invalid findings do not provide additional security information or value to the firm, and yet processing and validating them consumes the firm’s effort.

For brevity, we highlight the key model changes and present detailed discussions of model choices in Online Appendix D.1. Referring to the dashed area in Figure 8, the new model feature is that cooperative and coopetitive hackers might submit invalid reports with the expected number positively related to their effort, and so the total number of invalid reports can be represented by $N^{\mathit{\text{invalid}}}={\sum }_{v_i\le r}b{n}_i{x}_i$, where $b>0$ is a positive scale parameter. The firm has to validate invalid submissions to avoid paying wrong bounty rewards. The need to handle invalid submissions reduces the resources that the firm would otherwise spend on identifying valid vulnerabilities, so the firm’s remaining effort dedicated to vulnerability identification becomes $x_f-x_{vf}(N^{\mathit{\text{invalid}}})$, where $x_{vf}(N^{\mathit{\text{invalid}}})={\theta }_f{N}^{\mathit{\text{invalid}}}$ represents effort diverted to validating invalid reports and ${\theta }_f$ represents the firm’s efficiency at handling invalid findings with a smaller ${\theta }_f$ representing greater efficiency. Therefore, the firm’s payoff after considering invalid submissions becomes

where $X^{nv}=d+[x_f-x_{vf}({\sum }_{v_j\le r}b{n}_j{x}_j)]+{\sum }_{j=1}^T{n}_j{x}_j$ represents the aggregate effort that the firm and hackers invest in vulnerability discovery and $c_f$ and $c_{fv}$ represent the effort parameters for vulnerability identification and validation. We assume $c_f=c_{fv}$ and show that our results are robust in Online Appendix D.1. With this setting, we confirm that invalid reports reduce a firm’s BBP payoff and the optimal bounty reward, and hackers have little incentive to validate their findings (see Online Appendix D.1).

We are interested in policies to address the invalid report problem. The industry and academic literature primarily discuss two approaches to handle invalid reports:

• Taxing duplicate reports: The idea is to raise the cost of submitting invalid reports, similar to a tax on spam emails (Rao and Reiley 2012). For example, HackerOne assigns a reputation score to bug reporters, and duplicate report submissions lower a reporter’s reputation, and this may influence their eligibility for future BBPs (HackerOne 2025). BugCrowd follows a similar approach. A firm can incentivize hackers to validate submissions using penalties such as low reputation scores, hence reducing invalid or duplicate report submissions.

• Algorithms to handle duplicate reports: A stream of literature (see Zhang et al. 2023 for a review) proposes to enhance a firm’s efficiency in identifying duplicate reports through machine learning models. Recent studies (Xiao et al. 2020) show that deep neural network–based algorithms can identify duplicate reports with accuracy as high as 98% based on textual descriptions and other metadata in the reports. This efficiency corresponds to a lower ${\theta }_f$.

Proposition 7.

Taxing duplicate reports reduces the firm’s payoff when $\frac{c_f}{c_h}$ is sufficiently large and ${\theta }_{f}b$ is sufficiently small (i.e., $\frac{c_f}{c_h}>\overline{c}$ and ${\theta }_{f}b<\overline{\mu }$, where $\overline{c}$ and $\overline{\mu }$ are positive thresholds), and it increases the firm’s payoff otherwise. Efficient handling of duplicate reports increases the firm’s payoff whenever the efficiency-enhancing technology is not too costly to implement.

Proposition 7 reveals a paradox. Whereas taxing duplicate reports substantially reduces invalid report submissions, it may end up reducing a firm’s payoff. Conversely, improving efficiency in handling reports does not reduce invalid submissions, but it often improves the firm’s payoff. This insight has important implications for the duplicate report literature, which focuses on identifying policies that most effectively reduce duplicate submissions (e.g., Schechter 2002, Zhao et al. 2017). With that focus, their implication might be that firms should prioritize policies that minimize duplicate submissions. Our findings suggest that this approach may be unfounded as fewer duplicate submissions can be associated with a lower payoff.

Taxing duplicate reports encourages hackers to validate reports, saving the firm efforts but burdening hackers. Increased time spent by hackers on validating findings reduces their time available to identify vulnerabilities, which can impede their vulnerability identification efficiency. When the firm’s vulnerability identification efficiency is low ($\frac{c_f}{c_h}$ is high), it relies on cooperative and coopetitive hackers’ greater efficiency for vulnerability identification (protection delegation). In such cases, reduced hacker efficiency can diminish the firm’s BBP return, particularly if duplicate submissions are less critical than identifying vulnerabilities, for example, when the chance of duplication is low because of insufficient submissions or diverse system scopes (i.e., small b) or when the firm has an efficient system to handle duplicate submissions (i.e., small ${\theta }_f$). Therefore, taxing duplicate reports is beneficial primarily when the firm is less concerned about hackers’ vulnerability identification efficiency (e.g., when the firm is primarily seeking attack diversion benefits) and might backfire otherwise.

By contrast, enhanced efficiency in handling invalid reports reduces the influence of such submissions on in-house effort. The firm is then able to devote more effort to vulnerability identification, and this reduces both security and bounty payment costs. The firm’s payoff, thus, improves as long as implementing the efficiency-enhancing algorithm is not too costly.

One implication that contradicts the extant literature is that organizations may strategically choose to embrace duplicate report submissions even with the option of penalizing such uninformative submissions. In fact, some BBPs reward reporters for duplicate submissions by providing acknowledgment (e.g., Hao et al. 2022).

7. Concluding Remarks

“Do I not destroy my enemies when I make them my friends?” said Abraham Lincoln at the conclusion of the American Civil War. BBPs capture this spirit in cyberspace and inspire how firms and governments may approach cybersecurity. Although the idea of enlisting help from hackers is not new (Felicetti 2016, Leswing 2016, McGee and Breslauer 2016), BBPs stand out in comparison with traditional ways of hiring white-hat hackers directly because they allow organizations to convert a large number of hackers from the open market into white hats without specifying individual wages or ex ante differentiating between white- and black-hat hackers. This study contributes an analytical framework to scrutinize the implications of BBPs, including their economic and security benefits, social efficiency, and policy design. Our analysis generates multiple insights and implications as Table 4 summarizes.

Table 4. Practical Insights

Our findings offer organizations two key benefits. First, some organizations and security experts question BBPs because of concerns about economic returns and potential negative influences on in-house protection (e.g., Oracle.com 2015, Dayan 2022). Such concerns are often based on intuition instead of formal analysis, which can lead to undue hesitation or suboptimal BBP decisions. We provide a theoretical framework that clarifies these trade-offs. For example, we identify two distinct benefits of BBPs, illustrating BBPs’ value to organizations with strong internal security capabilities, and show that BBPs’ positive security benefits outweigh their negative influence on in-house protection (points 1 and 3 of Table 4). These insights are especially relevant as AI tools (e.g., Mythos) increasingly enhance firms’ ability to detect vulnerabilities, prompting questions about whether BBPs remain necessary (e.g., Okunytė 2026). Our findings suggest that BBPs remain valuable even when firms possess highly capable AI-based security tools, particularly when their primary benefit arises from attack diversion. Moreover, we offer guidance on the strategic design of SHTs and duplicate report policies to improve the effectiveness of BBPs (points 10 and 11). We believe that these insights can enable organizations to make more informed decisions and enhance the acceptance of BBPs.

Second, we demonstrate that BBPs require strategies that contradict conventional crowdsourcing or security protection practices. For example, conventional crowdsourcing emphasizes the benefits of a larger crowd and increasing rewards with the crowd’s size, but we show that more participants can diminish BBP returns and lead optimal rewards to decrease or change nonmonotonically (points 2, 8, and 9). Similarly, conventional protection measures focus on disincentivizing all external hackers, but BBPs convert some hackers into allies though they potentially encourage some malicious hackers to exert more efforts; organizations also need tailored strategies for different types of hackers (points 3 and 10). By highlighting these unique characteristics, our findings can help organizations more effectively adapt to the distinctive challenges and complexities posed by BBPs.

As BBPs gain traction and their ecosystem evolves, firms may face new design problems. For example, should BBP platforms promote information sharing among hackers? The trade-offs revealed in our analysis call for different design considerations when compared with traditional crowdsourcing platforms. In conventional crowdsourcing, knowledge sharing among the crowd—such as sharing technologies or tools—is often encouraged to boost task efficiency (Jin et al. 2021). In BBPs, however, such shared knowledge could empower competitive hackers, and this may reduce the firm’s payoffs. Promoting such knowledge sharing is beneficial only when the firm obtains protection delegation benefits from the higher efficiency of hackers (see Proposition 1) or when the shared information primarily benefits cooperative/coopetitive hackers without aiding competitive hackers (e.g., the firm may design the bug bounty platform so that only verified hackers have access to the shared information). Similarly, we can design BBPs to influence hackers’ perception of competition. In conventional crowdsourcing, firms often downplay competition to elicit more crowd efforts (Terwiesch and Xu 2008). Here, firms need not prefer more effort from hackers because hackers who find the vulnerability first may exploit it. Instead, firms may dissuade hacker efforts by using bug bounty forums to intensify perceived competition or congestion—such as by inserting duplicate hackers as external participants or publicizing a large number of active hackers—especially when firms are primarily obtaining attack diversion benefits (i.e., when firms have high in-house capabilities; see Online Appendix D.5 for a brief analysis).

We emphasize two insights for the government. First, it should recognize the value of BBPs in hacking regulation, particularly through the attack diversion benefit of BBPs. Unlike traditional regulatory approaches that rely on punitive measures or hiring selected hackers, BBPs allow society to exploit hackers’ expertise and efforts productively and on a greater scale. If coopetitive hackers can find more legitimate opportunities in BBPs, they might gradually divert effort away from harmful hacking. This unique social benefit of BBPs warrants government attention. Second, the third row (points 5–7) of Table 4 highlights the need for the government to address BBP inefficiency. A pertinent challenge is the difficulty of a single policy to address effort inefficiency, which can manifest as either insufficient or excessive protection efforts in different scenarios and reward inefficiency. Therefore, we recommend multifaceted policies to address BBP inefficiencies. More broadly, our findings suggest that the government must recognize and deliberate the intertwined inefficiencies when evaluating existing policies and developing new policies to accommodate BBPs and other emerging protection methods.

This study advances the crowdsourcing and security investment literature. For crowdsourcing, we incorporate coopetitive interactions between an organizer and participants. Although this study focuses on cybersecurity, its findings might apply to other contexts that involve coopetition. Consider an industry facing potential disruptive innovations. A company might use crowdsourcing preemptively to internalize innovative ideas and prevent them from being proposed to competitors. Such an incentive for adopting crowdsourcing—preempting the threat that competitors have access to innovative ideas first—is not documented in extant crowdsourcing research, but it is similar to the attack diversion mechanism discussed in this study. Future research should explore how such coopetition influences strategy and social outcomes, including innovation, competition, and social welfare, in other contexts.

For security investment, this study represents the first step toward developing the theoretical underpinning of how firms can work with potential enemies, namely, hackers, to enhance information security. Conventional security strategies often attempt to prevent hackers from finding a vulnerability (Gordon and Loeb 2002). However, those solutions cannot minimize the potential damage when hackers already found a vulnerability before a firm.²⁸ BBPs allow firms to address such risks. Future research should cultivate methods to recruit instead of desert hackers. Our research offers a novel framework in that direction.

Our analysis is subject to several limitations. To maintain tractability and focus on the main insights, we made several simplification assumptions. For example, we assume complete information on the relative cost parameters. One future research direction is to examine how introducing uncertainty affects our findings. We model only hacker heterogeneity in terms of valuations toward the vulnerability. Hackers can be heterogeneous in other ways, such as their preferences for addressing different bugs. Future research might consider other hacker heterogeneity. We focus on a single reward, but a natural extension is to explore how firms can set multiple reward levels, including designing reward discrimination. We also focus on security risks because of vulnerability misuse, but organizations experience other security risks, such as system interdependency risks (e.g., Kunreuther and Heal 2003, Hui et al. 2012, August et al. 2022) or risks that do not involve vulnerabilities (e.g., social engineering or distributed denial of service). Future research can examine whether BBPs have externalities on other security risks and how they collectively influence system security. We focus on how a firm’s choice of BBPs affects the probability of various parties finding a vulnerability first and how a BBP broadly affects hackers’ choices of misuse or protection. Future research can assess other effects because of BBPs. For example, a BBP might offer additional benefits such as greater specialization, learning from hackers, reputational gain, and costs such as the operational cost of trialing reports or communicating with hackers, GDPR data breach notification liability when participants obtain customer data accidentally (Porup 2020), and wage payments as BBP participants might be considered employees under the U.S. federal labor law and California’s laws (Porup 2020). These considerations can be analyzed by fine-tuning our model without major changes to its basic structure. Our contribution, thus, lies in both the study’s results and insights and the foundation it builds for future BBP research.

To conclude, previous security measures based on deterrence focus on sticks: how to punish hackers for attacking others. Contrary to this tradition, a BBP acts as a carrot through which a firm converts an enemy (i.e., coopetitive hackers) into an ally. As shown in our analysis, combining carrots and sticks is often superior to using sticks alone. Future cybersecurity research and practice should systematically investigate ways to use underground hacking resources more effectively.