Uploaded by A C


Working Paper
2014 TPRC / 42 nd Research Conference on Communication, Information and Internet Policy,
George Mason University School of Law, Arlington, Virginia, September 12-14, 2014
Analyzing Bug Bounty Programs:
An Institutional Perspective on the Economics of Software Vulnerabilities
Andreas Kuehn and Milton Mueller
School of Information Studies, Syracuse University
ankuhn@syr.edu, mueller@syr.edu
1 Introduction
This working paper applies institutional economics theory (North, 1990) to examine the recent
developments of bug bounty programs. A software vulnerability, commonly referred to as a bug, is a
security flaw in computer code. Until the bug is fixed with a software patch, it presents a security
loophole and may be exploited in a cyber attack. Major software companies, among them Microsoft,
Adobe, and Oracle, received considerable media attention in 2013 and 2014 for severe security issues
and breaches. Some of their widely used applications were in danger of being exploited based on
previously unknown code vulnerabilities. Given software companies’ incentives to fix vulnerabilities in
their software, major software vendors significantly adapted their approaches in recent years by more
openly incorporating externally gathered vulnerability information. Google, Microsoft, and Facebook, for
instance, created structured programs where bug hunters can submit their digital prey, in exchange for
a bounty. Depending on the severity and significance of a security vulnerability, the bounty price may
range from a few hundred US dollars up to USD 100,000.
The objective of this paper is to examine the institutionalization of software vulnerability markets,
particularly with regard to bug bounty programs, and assess whether this constitutes a significant
change in how cybersecurity is produced. Will these changes lead to emerging norms and practices that
will reduce the level of uncertainty in the exchange of critical vulnerability information, as institutional
economic theory suggests? Will this consequently boost the security and reliability of software and the
Internet? The fact is that in recent years, software vulnerability information has turned into a
commodity. Individuals who previously shared this information in order to build their reputations as
experts in information security are now considering trading this knowledge on security vulnerability
markets to increase their income.
Electronic copy available at: http://ssrn.com/abstract=2418812
To examine the emerging institutions and their implications, this preliminary analysis (1) provides a brief
historical narrative of the development of bug bounty programs; (2) conducts an institutional,
comparative analysis; and (3) describes changes related to security practices. Using document analysis,
the empirical institutional analysis examines the bug bounty programs operated by Facebook and
Microsoft; two major Internet and software companies. Based on the preliminary analysis, the paper
suggests that a new paradigm in securing software vulnerabilities evolving. Future research will enhance
this analysis based on qualitative interviews with independent penetration testers, engineers in
software companies, and operators of bug bounty programs. This paper is part of ongoing dissertation
research that looks at the institutionalization of norms and practices in cybersecurity, particularly the
trade with zero-day exploits and related questions about its regulation. In this particular work, an
account on these norms and practices specifically for software vendor-supported vulnerability markets
is described.
Building and extending upon earlier research on markets for software bugs in computer science and
economics (e.g., Finifter, Akhawe, & Wagner, 2012; Moussouris, 2014; Ozment, 2004; Ransbotham,
Mitra, & Ramsey, 2012), this paper takes an institutional perspective to explain the emergence of
bounty programs and discusses and conceptualizes these programs as institutions. As such, it makes a
contribution to the larger debate on cybersecurity, responsible disclosure and markets for software
vulnerabilities. There is room for critical questions about software vulnerability markets, as some
scholars pointed out (Böhme, 2005; Ozment, 2004). Böhme (2005) in particular concluded that bug
bounty programs “are not the best possible solutions”. While it is beyond the scope of this paper to
measure the effects of vulnerability markets on Internet and software security, it maps out the growing
space and illustrates major changes in this field.
2 Background
This section of the paper establishes a general understanding of software bugs and the working of
vulnerability markets, including a brief historical account about past and recent developments in bug
bounty programs.
2.1 What is a Bug?
A software bug or a software vulnerability is a flaw in computer code that can compromise the security
of a computer system. Computer software and network protocols often contain security vulnerabilities
that are unintended consequences of design choices or mathematical errors in models. It is important to
note that a software bug has no physical characteristics. As such, a bug is knowledge about a
vulnerability, a pure information good. A bug might exist for a long time before it is discovered and
recognized as a security issue.
Software engineering has brought forward various approaches to design and test software, but the
interdependencies within a single piece of code and across distributed applications running on multiple
platforms are too complex to be bug free. Consequently, the mass of software is just good enough to be
released. A more rigorous testing regime would increase the cost of software significantly.
Electronic copy available at: http://ssrn.com/abstract=2418812
When a bug is discovered to have security implications on a computer system or network, the software
vulnerability allows unauthorized actors to intrude into, destroy, manipulate or steal data from an
information system. To exploit a vulnerability in such a way, a hacker needs to write software code,
referred to as a software exploit. Those software vulnerabilities and software exploits represent a value
to different actors: Software companies that commercially develop and sell software have an interest
that their products are secure and safe. Thus, software companies employ internal security researchers,
engineers and penetration testers to scrutinize their software, find security holes and patch them on a
regular basis as part of a professional software development practice. Independent security researchers
and white hat hackers, too, are aware of the economic value of security bugs and the risk they pose for
software companies and users of their software. If they identify a bug and report it to those companies,
they expect to be rewarded. Cyber criminals are on the other side of the cat-and-mouse-game in
cybersecurity and driven by a different set of motivations. Their interest lies in exploiting the
vulnerabilities to intrude into information systems. Note, since the article focuses on software
vulnerabilities and legitimate markets, the article will not further address software exploits. However, it
needs to be recognized that exploits are closely linked to software bugs. For instance, a working exploit
as a proof of concept might be required to participate in a vulnerability market. The function of the
exploit in this context is merely to document the seriousness of the vulnerability. An exploit is likely to
yield higher prices than a bug, if offered on the grey or black market.
2.2 What is a Bug Bounty Program?
Bug bounty programs (BBP), also referred to as vulnerability rewards programs (VRP) or bug challenges
(Böhme, 2005) reward independent security researchers, penetrations testers, and white hat hackers
for discovering exploitable software vulnerabilities and sharing this knowledge with the operator of a
particular BBP. Böhme (2005) describes bug bounty programs as “the simplest and oldest form of
vulnerability markets”.
BBP operators, commonly a software company or a third-party, define the scope of the program (e.g.,
types of vulnerability included in the BBP, technical specifications), participation criteria (e.g., minimum
age), terms and conditions, and submission and review processes. A BBP may provide monetary and/or
non-monetary rewards. Depending on the severity and significance of a security vulnerability, the
bounty price may range from a few hundred US dollars up to USD 100,000. Non-monetary remuneration
may include gifts or swag, such as t-shirts, and importantly, acknowledgments in the security hall of
fame of the respective bounty program.
Acquiring software bugs and monetarily rewarding its discoverers through a formalized bounty program
is a rather new development. Issues around security breaches based on previously unknown code
vulnerabilities received considerable media attention in 2013 and 2014 (e.g., Microsoft, Adobe, and
Oracle), when widely used applications were in danger of being exploited. In recent years, major
software companies significantly adapted their security practices by more openly incorporating
externally acquired vulnerability information. Software vulnerability information became a commodity:
individuals who previously shared this information in order to build their reputations as experts in
information security are now considering trading this knowledge on security vulnerability markets to
Electronic copy available at: http://ssrn.com/abstract=2418812
increase their income. As this analysis will elaborate hereafter, the commodification of software
vulnerabilities - bugs for bucks - is a significant shift with sweeping implications for cybersecurity.
A typology of BBP reveals the wide variations of how such programs can be set up. A BBP may focus on a
single software product, a class of products, or the service infrastructure of an entire organization. Some
programs cover commercial software while others offer monetary and/or non-monetary rewards for
free and open source software, others offer bounties for bugs in third-party software or even their
competitor’s software. The type of software ranges from operating systems, browsers, web and mobile
technologies to embedded software. The purpose of a BBP may vary, too. Some BBP operators seek
bugs to fix software. Others attempt to leverage BBP to shape market dynamics, and disrupt and
exacerbate cyber criminals’ pursuit to gain access to sophisticated exploits on black markets. Other
forms of software vulnerability markets related to BBP include: vulnerability brokers and bug
competitions; for a detailed discussion, see Böhme (2005).
2.3 Past and Recent Developments towards Bug Bounty Programs
The idea of trading software vulnerabilities and remunerating bug hunters for their discoveries is
certainly not new. Hackers have been selling and buying vulnerabilities and exploits for a long time on
black markets, mostly among themselves and for reputation (Miller, 2007).
With regard to finding and fixing bugs, Donald E. Knuth used to reward discovered bugs in his TEX and
METAFONT programs. Starting from initially USD 1.28, the bounty doubled every year until it reached
the capped maximum of USD 327.68 (Jackson, 2002). Netscape was among the first, if not the first
company to run a bug bounty program. Back in 1995, it offered USD 1000 for vulnerabilities found in its
browser software. And in 2005, a security researcher used eBay to find a buyer for a vulnerability he
discovered in Microsoft Excel. The online auction platform shut off the auction before it was completed;
the highest bid reached roughly USD 53 (Naraine, 2005).
Security researcher Charlie Miller observed in 2005/2006 that no markets existed to efficiently transact
vulnerability information. Researchers were left alone to identify potential buyers, to determine
accurate prices, and to overcome various barriers in executing a sale. This was contrary to the
discoverer’s interest whose purpose it was to sell a vulnerability “as quickly and discreetly as possible”
once it was discovered (Miller, 2007, p. 3). The barriers, among others, were attributed to the
characteristics of software vulnerabilities as an information good. See section “Obstacles to Markets for
Software Vulnerabilities” below for an overview of Miller’s (2007) “inherent obstacles” that precluded
the formation of legitimate software vulnerability markets.
In recent years, numerous vulnerability markets have emerged; particularly in the past two to three
years the numbers of BBP increased significantly. Internet and software companies started to run or
experiment with some forms of bug bounty programs, or other approaches that harness external
security expertise (see Table 1 for an overview of selected BBPs). Mozilla, for instance offers a USD 3,000
reward for security critical and high severity bugs in Firefox and Thunderbird (Mozilla, n.d.). Google pays
out between USD 100 and USD 20,000 for found vulnerabilities in Google.com, Youtube.com, among
others; the BBP further includes browser apps and extensions developed by the search giant (Google,
n.d.). In addition, Google runs an experimental program, in which it seeks security patches for selected
open source projects, offering awards between USD 500 to USD 10,000 (Google, 2013). In 2012 and
2013, respectively HackerOne (n.d.) and Bugcrowd (n.d.) which aggregate or host bug bounty programs
not for just one company but for many major software applications and Internet services. Despite the
barriers that Miller (2007) described in his account, how was it possible that these bug bounty programs
Table 1: List of Bug Bounty Programs
BBP / Organization
Mozilla’s bug bounty program offers a USD 3,000 reward for security critical and
high severity bugs in its Firefox, Thunderbird, or related Mozilla services (Mozilla,
GitHub is a distributed revision control system, mostly for software code. The
bounty program covers the GitHub API, GitHub Gist, and its main website
github.com. Rewards range from USD 100 up to USD 5,000 (GitHub, n.d.).
Google’s reward program covers Google.com, Youtube.com, Blogger.com, and
Orkut.com, among others, as well as browser apps and extensions developed by
the search giant. Rewards start from USD 100 and go up to USD 20,000 (Google,
n.d.). Further, Google runs an experimental program, in which it seeks security
patches for selected open source projects. Here awards between USD 500 to USD
10,000 are offered (Google, 2013).
Samsung’s Smart TV Security Bug Bounty Program seeks submissions for its 20122014 Smart TV and Blu-Ray products. The bounty reward is USD 1,000 or more
(Samsung, n.d.).
3 Theoretical Framework: Software Vulnerability Markets
The preliminary framework introduced in this paper draws from institutional economic theory (North,
1990). This strain of institutionalism has developed a series of theoretical and empirical concepts for the
study of institutions, particularly with regards to scarcity of resources and competition in markets. North
(1990, p. 3) defines institutions as “the rules of the game” that shape social interaction and order
markets. They can take the form of informal constraints (e.g. customs, traditions, norms, taboos, codes
of conduct) and formal rules (e.g. constitutions, laws, regulations, property rights) (DiMaggio & Powell,
1991; Scott, 2001). Once established, institutions provide a procedure for standardized interactions that
allow, for instance, efficient transacting on markets (Jepperson, 1991).
Of particular interest to this paper are (1) how bug bounty programs, as institutions, emerge; and (2)
which components in bug bounty programs facilitate transactions of software vulnerabilities. Following
institutional economics, some form of institutionalization needs to take place to enable BBPs. This paper
argues that this in fact happened with the emergence of BBPs as a subset of the legitimate vulnerability
market, in which institutionalized norms lowered transactions costs and uncertainty.
To study changes over time, we need a reference point in the past to compare the recent developments
against. For this task, the paper draws on Miller’s (2007) account of two attempts to sell bugs to the
legitimate markets for software vulnerabilities around 2006/07, a time when BBPs were not yet
established. Miller, himself a security researcher, documented a successful and a failed sale. The success
case involved selling a “remote vulnerability in a common Linux daemon” for USD 50,000 to an
undisclosed party. The other attempt, involving a bug in Microsoft’s PowerPoint XP and 2003, failed to
sell because it got discovered and patched during the sales negotiations. In addition to these two
accounts, Miller provides some observations of difficulties and barriers that hinder or impede such
3.1 Obstacles to Markets for Software Vulnerabilities
The following list is a summary of Miller’s (2007 “inherent obstacles” to software vulnerability markets;
they constitute problems that make it difficult to trade security bugs.
1. “Vulnerability information is time-sensitive”: The value of a software vulnerability may decrease
significantly over time. Reasons for such a decline include: (A) the vulnerability is discovered and
patched; (B) technical changes in the software platform render software bug unexploitable or
ineffective (e.g., software updates, changes of default settings); and (C) the vulnerability is
independently discovered by another security researcher.
2. “No Transparency in Pricing”: Pricing information is not publicly available, which make it difficult
to determine the value of a software vulnerability. Prices may differ widely across operating
systems and applications and be determined by various factors, such as the diffusion and user
base of the software that is affected by the vulnerability.
3. “Difficulty Finding Buyers and Sellers”: There is no mechanism that matches buyers and sellers
of software bugs. Sellers and buyers have significant search costs to bear to find a party that
wants to transact with them. This time-consuming process may decrease the value of the
4. “Checking the Buyer”: If the discovered bug should be sold only to a ‘legitimate’ buyer, the
seller needs to verify the buyer’s benign intensions. This increases the search costs and may
consequently decrease the bug’s value.
5. “Value Cannot be Demonstrated Without Loss”: The most intricate challenge in selling a
software vulnerability is striking the right balance between disclosing and retaining information
to a potential buyer. A software vulnerability as a pure informational good leads to the following
conundrum: If too much information is disclosed, the potential buyer may then posses enough
information to reconstruct the bug without compensating the security researcher’s work.
Conversely, if too much information is retained, the potential buyer may not be able to assess
the effectiveness of the vulnerability and avoid a blind bargain.
6. “Ensuring Claim to Vulnerability”: When a vulnerability is offered, there is a risk that a potential
buyer may claim the bug to be their own discovery and use the information retained in the offer
at the buyer’s discretion (e.g., to sell the bug to another party).
7. “Exclusivity of Rights”: To achieve the highest price, the security researcher must agree to
transfer all information about the vulnerability exclusively to the seller. Since bugs are an
information good, the seller cannot truly surrender the knowledge completely to the acquiring
party. This leaves room for deviant behavior after the initial sale. The seller, for instance, could
disclose the vulnerability to the public or sell it to another party.
3.2 Institutional Framework
Disclosing vulnerabilities or buying and selling software bugs comes with a high degree of uncertainty as
described in the obstacles and barriers above. This is exacerbated through the intangible nature of
software bugs as an informational good. Central to North’s (1990) argument is that (1) institutions exist
due to the uncertainties in human interaction, and (2) institutions are constraints that structure the
interaction between humans. The emerging bug bounty programs can be theorized as institutions that
provide constraints for economic exchange. These institutions provide a stable structure to reduce the
uncertainty in the exchange of software vulnerabilities. While in neo-classical economic theory, under
the condition of zero transaction costs, an efficient outcome can be achieved regardless of the
institutional arrangements (Coase, 1960), transactions are costly in the case of software vulnerabilities
and thus, institutions matter. Institutions, among others, determine transaction costs and hence the
feasibility of the economic exchange (see North, 1990, p. 118). In fact, institutions facilitate economic
exchange despite uncertainty that might otherwise inhibit such transactions (North, 1990, p. 47). This is
particularly important in the case of impersonal exchanges, where the identity of the parties in online
transactions may be concealed and the exchanged good is difficult to observe and measure, leading to a
higher risk of defection. These circumstances account for higher transaction costs and thus provide an
explanation for the emerging institutions.
Table 2: Framework 'Formal Institutions'
of Institutions
Guiding Questions
What are the technical specifications that define the bounty program? What
security vulnerabilities are included or excluded?
Terms and
Do explicit terms and conditions exist? Do they exclude or limit prosecution? Is
there a privacy policy?
and Reputation
How are security researchers rewarded? What role does acknowledgement and
reputation play?
How are vulnerabilities reported? Are there required formats and particular
documentation that needs to be submitted?
The difficulties that arise out of the exchange of software vulnerabilities (but are also fundamental to
the regulatory challenge that they pose) are rooted in the fact that they are intangible, information
goods, largely based on knowledge. This type of good comes with a particular paradox: a buyer cannot
assess the quality or the value of the information in advance without having the information. The seller
would not provide this information (the actual good), fearing that the potential buyer would lack the
incentive to acquire the information later on, since the buyer has already obtained the wanted
knowledge during the assessment of the good. This is why Arrow (1962, p. 616) argues that it is difficult
to create a market for information. Further, neither the buyer nor the seller knows whether there is
somebody else who possesses the same information. All these factors affect the pricing, the structure of
the markets, and the form of the transactions.
Table 2 introduces the institutional analysis framework. Consisting of the formal institutional elements
(1) procedures; (2) technical specifications; (3) terms and conditions; and (4) acknowledgement and
reputation of contributing actors, the framework is applied to Microsoft’s and Facebook’s BBP.
4 Bug Bounty Programs
4.1 Microsoft’s Bounty Programs
Microsoft launched its Bug Bounty Program in June 2013, announcing that it was “[…] offering direct
payments in exchange for reporting certain types of vulnerabilities and exploitation techniques”
(Microsoft, 2013b). While the software giant had undertaken earlier outreach efforts to the security
researcher community, in 2011, for instance, Microsoft rejected the idea of a bug bounty program in
favor of its bug competition, the BlueHat Prize (Keizer, 2011). With the BBP, Microsoft attempted to gain
advantage in the cat and mouse game of security. It referred to the new program as “direct investments
in the research community, calling upon the clever hackers of the world to work with us on
strengthening our platform-wide defenses” (Microsoft, 2013b). Microsoft sees this development as a
decisive moment not only for the company but for the entire industry.
The initial BBP consisted of three components which encouraged the discovery of security bugs but
further encouraged the submission of novel exploitation techniques and defensive approaches to
prevent them. In November 2013, Microsoft extended the program (Microsoft, 2013a). Previously,
submissions were limited to security experts who designed novel bypass techniques, later it included
unprecedented bypass techniques that were observed in actual attacks. Consequently, the scope of
participants widened from a few security experts to thousands of skilled individuals. As July 2014, the
BBP is structured as follows:
The Internet Explorer 11 Preview Bug Bounty program rewards up to USD 11,000 for critical
software flaws in the browser’s beta version. The submission to this program was limited to the
beta release phase of 30 days (June 26 to July 26, 2013).
With the Mitigation Bypass Bounty the software giant elicited novel exploitation techniques
that target its advanced protection technology (e.g., Data Execution Prevention, and Address
Space Layout Randomization). Bounties of up to USD 100,000 are offered in this category.
The BlueHat Bonus for Defense seeks defensive approaches and recommendations effective
against novel exploitation techniques and offers awards up to USD 50,000.
By July 2014, Microsoft paid out USD 253,000 to 7 different security researchers, including two amounts
of USD 100,000 for Mitigation Bypass techniques, and 15 instances of a vulnerability in the public
preview of Internet Explorer 11 (Microsoft, n.d.-a). Notably, Microsoft targets the black market around
illegal exploitation of bugs with its BBP. The company stated that it was “cutting down the time that
exploits and vulnerabilities purchased on the black market remain useful, especially for targeted attacks
that rely on stealthy exploitation without discovery” (Microsoft, 2013a).
4.2 Facebook’s Bug Bounty Program
Even before Facebook formalized its bug bounty program, the social networking company embraced
external security researchers under its White Hat initiative to support its internal security team. In 2010,
the Electronic Frontier Foundation was involved in creating Facebook’s first responsible disclosure
policy, after having supported a security researcher to report a security flaw to the social networking
site (Hofmann, 2010). The policy’s intention was to encourage security researchers to submit security
bugs but to abstain from civil or criminal investigations if the researcher followed the rules of the BBP.
The program with monetary rewards started in July 2011. Valid bugs generated USD 500 at the
minimum; their submitters were named on Facebook’s White Hat portal. Only three weeks after its
start, Facebook reported that more than USD 40,000 had been paid out (Facebook, 2011).A year later,
Facebook widened the program and included its internal infrastructure to the bug hunting grounds,
including corporate networks, and the production infrastructure (Robertson, 2012). In 2013, Facebook
recently reported, it received 14,763 submissions of which 687 were eligible security flaws for which it
awarded USD 1.5million to 330 researchers. Forty-one bugs were categorized as high severity. The
largest Facebook bounty by then amounted to USD 33,500.
The program is subject to continuous growth in terms of participating security researchers, scope, and
numbers of submissions. This leads to continuous refinement of the program: Facebook reported that
the number of high-severity issues was falling, increasing the efforts needed to discover “good bugs”. It
announced increases in the bounty amounts in areas of particular security interest (Greene, 2014).
5 Institutional Analysis
Seller and buyers of software vulnerabilities face certain challenges when transacting software
vulnerabilities. Due to its characteristics as an information good, a software vulnerability differs
considerably from a traditional physical good or service with regard to assessing its qualities. BBP as
institutions can remediate those issues and facilitate a market for security bugs by lowering transaction
costs and uncertainty. What follows is an analysis of four institutional elements – (1) procedures; (2)
technical specifications; (3) terms and conditions; (4) acknowledgement and reputation.
Trust is a central component to enroll security researchers in participating in BBP; the four institutional
elements contribute towards establishing trust. These institutions harness hackers for good to discover
security vulnerabilities that are then subsequently patched. Unbundling trust, working vulnerability
markets need to provide institutional guarantees, including: reliability; payments for independent
security researchers who submit valid security bugs; protection against law suits and criminal
investigation if security testing was conducted in adherence to the BBP’s guidelines; and sanctions.
5.1 Procedures
Internal and external procedures enable the functioning of the BBP. This includes, for instance,
procedures that integrate external knowledge into the internal security team to write and deploy
patches. Procedures at the interface between the BBP and independent security researchers constitute
an important element to keep transaction costs low. After a bug is discovered, how can it be reported in
a consistent manner with little effort for both parties? Ideally, these procedures are easy to find and
use, and together with the other institutional elements of the BBP represent the legitimacy of the
program and its operator’s reputation.
Once discovered, a security researcher reports all necessary information to reproduce and demonstrate
the vulnerability and its security implications through a reporting procedure. The security researcher is
not privy to the internal process used to review the submission. This may be troublesome in cases where
the same vulnerability has already been submitted previously. The BBP may clarify what actions it takes
in such a situation, for instance by addressing such circumstances in its guidelines, or terms and
conditions. Such clarifications help the BBP to build up a trusted position and maintain good relations to
the security community.
Microsoft’s BBP offers security researchers to submit their discoveries via email. The guidelines that
outline the submission procedure require an eligible submission to comprise novel and effective
exploitation techniques against state-of-the-art mitigation technology (Microsoft, 2013c). A submission
must include a technical analysis of the vulnerability and a functioning software exploit. Facebook
requires submitting a discovered vulnerability via its social networking site; a Facebook account is
needed. An eligible bug must satisfy requirements set forth in the technical specification of the
Facebook’s White Hat initiative.
5.2 Technical Specifications
Technical specifications define the scope of the BBP. It describes what makes a submission eligible to
participate in the program, as outlined in the Microsoft example above. Facebook, too, lists the
specifications a submission must satisfy and states an eligible vulnerability as defined as one that
“compromise[s] the integrity of user data, circumvent the privacy protections of user data, or enable
access to a system within our infrastructure, such as: Cross-Site Scripting (XSS), Cross-Site Request
Forgery (CSRF/XSRF), Broken Authentication (including Facebook OAuth bugs), Circumvention of our
Platform/Privacy permission models, Remote Code Execution, Privilege Escalation, and Provisioning
Errors” (Facebook, n.d.). Part of the technical specification may further include characteristics and
attributes of a good vulnerability report, technical guidelines, and relevant white papers and a list of
excluded or ineligible security issues. Due to constant development and adaption of the programs,
technical specifications are subject to change.
5.3 Terms and Conditions
Terms and conditions and other policy-like elements govern each bounty program and design its
structure and scope. The terms and conditions – together with further guidelines and technical
specifications – may specify what products and services the BBP encompasses. This includes the size of
the bounty (i.e., lower limit, upper limit, or range) offered for a valid security bug; the bounty
information provides important signals to the market and the security research community. The
structure of the program and the size of the bounties provide means for the BBP operators to set
incentives and manipulate behavior. For instance, they may pay higher bounties during the pre-release
phase (e.g., Tarsnap (n.d.)) or limit the BBP to the pre-release period (e.g., Microsoft (n.d.-b)). Program
guidelines and rules describe the course of action, for instance in a case when the same vulnerability is
submitted multiple times (e.g., Facebook gives the bounty to the first who submits the bug (Facebook,
n.d.); Tarsnap splits the bounty if the bug is reported roughly around the same time (Tarsnap, n.d.)).
Terms and conditions come in various forms and degrees. Facebook’s White Hat program is an example
where only minimal governing elements are explicitly stated. Its core governing text is referred to as the
“Responsible Disclosure Policy,” which is surprisingly short and free of legalese known from other
policies of large Internet giants. It states: “If you give us reasonable time to respond to your report
before making any information public, and make a good faith effort to avoid privacy violations,
destruction of data, and interruption or degradation of our service during your research, we will not
bring any lawsuit against you or ask law enforcement to investigate you” (Facebook, n.d.). The policy is
accompanied by further information about eligibility (e.g., not reside in a US-sanctioned country), the
bounty (e.g., bounties area awarded at the discretion of Facebook). A credible statement from the BBP
operator that it will not to bring lawsuits or law enforcement investigations against white hat hackers
who adhere to the program’s guidelines lowers uncertainty and contributes to trust.
Microsoft has more elaborated terms and conditions, including a privacy statement, legal notice,
guidelines and FAQs. These institutional elements are subject to change. Facebook, for instance,
adjusted the program to demands from the security research community. One such example is the fact
that it is not transparent how the decisions are made whether a bug is eligible for the program, and how
the size of a bounty is determined. With a note in August 2013, Facebook attempted to address this
issue but remained rather abstract. According to the social networking site, the size of a bounty is
determined by the impact of the bug, the quality of the bug report, the value of the target, and
secondary, indirect damage of the bug (Facebook, 2013).
In many programs, a bounty award is determined at the discretion of the security team. Since the
internal assessment of the security bug is not accessible to submitters, this may cause trust issues if the
wider security community gauges the vulnerability significantly different (e.g., more severe and thus
more valuable) than the BBP operator. Such a case became known as ‘t-shirt gate’, when in 2013 Yahoo
offered initially USD 12.50 to be redeemed in the company’s online merchandising store for each of two
submitted XSS vulnerabilities (High-Tech Bridge, 2013). The security firm High-Tech Bridge who
submitted the security bugs responded with a press release, headed “What’s your email security worth?
12 dollars and 50 cents according to Yahoo.” Consequently, Yahoo redesigned its BBP and increased its
offer for the bugs to USD 1,000. The security firm’s press release is evidence that trust and reputation
are crucial to run these programs effectively; it read “[a]t this point we decided to hold off on further
research” and “[p]aying several dollars per vulnerability is a bad joke and won’t motivate people to
report security vulnerabilities to them, especially when such vulnerabilities can be easily sold on the
black market for a much higher price. Nevertheless, money is not the only motivation of security
researchers.” Ambiguous signals and untransparent decision-making may unsettle and discourage the
security researchers’ participation in these relatively new programs.
5.4 Acknowledgement and Reputation
Besides monetary rewards, reputation is a crucial element in the security research community. Both,
Microsoft and Facebook, list contributors to their BBP in the respective program’s ‘Hall of Fame’. Public
acknowledgments increase the security researcher’s reputation. Security researchers can indicate
whether and how they want to be listed; real name or alias are provided, often with affiliations, links to
websites or Twitter handle.
6 Changes Towards a New Cybersecurity Paradigm
Exploring the causes and effects of recently established bug bounty programs below, the paper suggests
a new paradigm in securing software vulnerabilities. As the examples of Facebook and Microsoft
showed, BBPs constitute a significant change in the way vulnerability information is acquired by
software vendors. Related emerging norms and practices reduced the level of uncertainty in the
exchange of critical vulnerability information. The shift towards this new paradigm originated in
technical, economic, organizational, and institutional changes. Table 3 provides an overview of these
Applying institutional economic theory (North, 1990), this paper argued that the emerging bounty
programs, a form of a vulnerability market, established new institutions that facilitate the exchange of
software vulnerability information. Lowered uncertainty and transaction costs provide a rationale for
the formation of BBP.
Established institutions and trust in these institutions are key to facilitating a market for security bugs.
As an information good, this vulnerability information poses peculiar challenges to transactions, and
thus accounts for higher transaction costs (cf. Arrow, 1962). The examples of Microsoft’s and Facebook’s
programs demonstrated that – even if not perfect – uncertainty has been largely overcome, resulting in
new, but still fragile forms of desired exchanges. While institutions also deal with the paradox of the
impossibility to evaluate an information good without rendering its value worthless, the trust embodied
in these institutions prevail against these barriers and facilitate these transactions. Operators of BBPs
have to send clear signals to security researchers that they will not defect from their promise to pay for
a security vulnerability even though they have gained the desired information already at the point of
submission of the bug report.
The state of software vulnerability affairs has significantly changed with the commodification of
vulnerability information; its ramification will shift how we think about and produce cybersecurity. The
proposition to frame these changes as a new paradigm in cybersecurity suggests that more
vulnerabilities are reported and consequently fixed. This affects positively the security and reliability of
the Internet, and makes more secure our computers and networks we are daily relying on. While this
answer sounds intriguing, it is up to future research to quantitatively examine the accuracy of this
suggested answer.
Table 3: Changes towards a new paradigm
Markets. No legitimate markets for software
vulnerabilities exist.
BBPs emerge; number of BBPs is increasing.
Disclosure. Security researchers report software
bugs for free / for reputation; software companies
do not pay for vulnerabilities in their software.
Security researchers are compensated for
discovered security bugs; software companies
offer rewards for bugs in their software and in
some cases even for bugs in third-party software.
Testing. Security testing conducted by internal,
corporate employees within organizational
boundaries; hiring information security personnel
through traditional human resource channels.
Crowd sourcing of security and penetration testing
to independent security researchers across
organizational boundaries to support internal
security efforts; hiring security researchers who
successfully contributed to BBPs.
Value of Vulnerabilities. Security vulnerability
information does not represent a monetary value.
Commodification of software vulnerability,
representing an economic and/or
intelligence/military value.
Actors. Exploiting unknown software
vulnerabilities (i.e., zero-day exploits) for
sophisticated cyber attacks confined to state
actors (e.g., military and intelligence services)
Increase in number of cyber attacks that exploit
software vulnerabilities to circumvent security
features, to commit cyber crime.
Expertise and Skills. Technical security expertise
required to identify security bugs.
Tools for automated security testing and bug
discovery become more readily available.
Bug Types. Focus on easy-to-find, shallow bugs.
Focus on more sophisticated bugs and security
circumvention techniques; fewer easy-to-find bugs
left in software.
Income. Difficulty to generate legitimate income
as a bug hunter.
Additional, legitimate income for independent
security researchers; occasionally hired into
internal security team because of participation in
Arrow, K. (1962). Economic Welfare and the Allocation of Resources for Invention. In The Rate and
Direction of Inventive Activity: Economic and Social Factors (pp. 609 – 626). National Bureau of
Economic Research. Retrieved from http://www.nber.org/chapters/c2144
Böhme, R. (2005). Vulnerability Markets - What is the economic value of a zero-day exploit? In 22C3.
Berlin, Germany. Retrieved from http://events.ccc.de/congress/2005/fahrplan/attachments/542Boehme2005_22C3_VulnerabilityMarkets.pdf
Bugcrowd. (n.d.). Crowdsource Your Cybersecurity. Retrieved July 01, 2014, from https://bugcrowd.com
Coase, R. H. (1960). The Problem of Social Cost. Journal of Law and Economics, 3, 1–44.
DiMaggio, P., & Powell, W. W. (1991). Introduction. In P. DiMaggio & W. W. Powell (Eds.), The New
Institutionalism in Organizational Analysis (pp. 1 – 38). Chicago, IL: University of Chicago Press.
Facebook. (n.d.). Facebook White Hat Program. Facebook White Hat. Retrieved July 01, 2014, from
Facebook. (2011). Updates to the Bug Bounty Program - Why a Bug Bounty Program? Notes by Facebook
Security. Retrieved July 01, 2014, from https://www.facebook.com/notes/facebooksecurity/updates-to-the-bug-bounty-program/10150270651335766
Facebook. (2013). An update on our Bug Bounty Program. Notes by Facebook Security. Retrieved July 01,
2014, from https://www.facebook.com/notes/facebook-security/an-update-on-our-bug-bountyprogram/10151508163265766
Finifter, M., Akhawe, D., & Wagner, D. (2012). An Empirical Study of Vulnerability Rewards Programs. In
Proceedings of the 22nd USENIX Security Symposium (pp. 273–288). Washington, D.C.
GitHub. (n.d.). GitHub Security Bug Bounty. Retrieved from https://bounty.github.com/
Google. (n.d.). Vulnerability Reward Program. Retrieved July 01, 2014, from
Google. (2013). Patch Rewards. Retrieved July 01, 2014, from
Greene, C. (2014, April 3). Bug Bounty Highlights and Updates. Facebook.com. Retrieved from
HackerOne. (n.d.). Effective vulnerability disclosure programs. Retrieved July 01, 2014, from
High-Tech Bridge. (2013). What’s your email security worth? 12 dollars and 50 cents according to Yahoo.
press release. Retrieved July 01, 2014, from
Hofmann, M. (2010). Knowledge is Power: Facebook’s Exceptional Approach to Vulnerability Disclosure.
Electronic Frontier Foundation. Retrieved July 01, 2014, from
Jackson, A. (2002). All Questions Answered: Donald Knuth. Notices of the AMS, 49(3), 318–324.
Jepperson, R. L. (1991). Institutions, Institutional Effects, and Institutionalism. In The New
Institutionalism in Organizational Analysis (pp. 143 – 163). Chicago, IL: University of Chicago Press.
Keizer, G. (2011). Microsoft kicks off $250,000 security contest. Computerworld. Retrieved July 01, 2014,
Microsoft. (n.d.-a). Bounty Hunters: The honor roll. Security TechCenter. Retrieved July 01, 2014, from
Microsoft. (n.d.-b). Microsoft Bounty Programs. Security TechCenter. Retrieved July 01, 2014, from
Microsoft. (2013a). Bounty Evolution: $100,000 for New Mitigation Bypass Techniques Wanted Dead or
Alive. BlueHat Blog. Retrieved July 01, 2014, from
Microsoft. (2013b). Heart of Blue Gold – Announcing New Bounty Programs. BlueHat Blog. Retrieved
July 01, 2014, from http://blogs.technet.com/b/bluehat/archive/2013/06/19/heart-of-blue-goldannouncing-new-bounty-programs.aspx
Microsoft. (2013c). New Bounty Program Details. Security Research and Defense Blog. Retrieved July 01,
2014, from http://blogs.technet.com/b/srd/archive/2013/06/17/new-bounty-program-details.aspx
Miller, C. (2007). The legitimate vulnerability market: the secretive world of 0-day exploit sales. In 6th
Workshop on the Economics of Information Security (WEIS 2007). Retrieved from
Moussouris, K. (2014). Presentation on Microsoft Bounty Program. In 4th Workshop Explorations in
Cyber International Relations. Boston, MA, January 7.
Mozilla. (n.d.). Bug Bounty Program. Retrieved July 01, 2014, from http://www.mozilla.org/security/bugbounty.html
Naraine, R. (2005, December 9). eBay Pulls Bidding for MS Excel Vulnerability. eWeek. Retrieved from
North, D. C. (1990). Institutions, Institutional Change and Economic Performance. Cambridge University
Ozment, A. (2004). Bug Auctions: Vulnerability Markets Reconsidered. In 3rd Workshop on Economics
and Information Security (WEIS 2004). Minneapolis, MN, May 13-14. Retrieved from
Ransbotham, S., Mitra, S., & Ramsey, J. (2012). Are Markets for Vulnerabilities Effective? MIS Quarterly,
36(1), 43–64. Retrieved from http://misq.org/are-markets-for-vulnerabilities-effective.html
Robertson, J. (2012). Facebook Widens “Bug Bounty” Program to Combat Internal Breaches. Bloomberg.
Retrieved July 01, 2014, from http://www.bloomberg.com/news/2012-07-26/facebook-widensbug-bounty-program-to-combat-internal-breaches.html
Samsung. (n.d.). Samsung Smart TV Security Bug Bounty Program. Retrieved from
Scott, W. R. (2001). Institutions and Organizations. Thousand Oaks, CA: SAGE Publications.
Tarsnap. (n.d.). Tarsnap Bug Bounties. Tarsnap. Retrieved July 01, 2014, from