The effect of competition intensity on cybersecurity - An empirical

analysis of security patch release on the web browser market∗

Arrah-Marie Jo†

June 2016

Very preliminary and incomplete

Abstract

This paper empirically examines the effect of competition intensity on software vendors’ security provision

behavior. Specifically, we analyze the relationship between market competition intensity and the time a

software publisher spends to release a security patch when it is informed about a vulnerability affecting

its product. We study the case of a market at the heart of Internet based security issues, namely the web

browser market. We rely on a 10-year pooled cross-sectional data set on software vulnerabilities, discovered

and patched from January 2006 to December 2015. Our results suggest that market competition impacts

negatively the vendor’s responsiveness in releasing a security patch; that is, the more competitive the market

is, the less a software vendor invests in its product security. In addition, we find that disclosure accelerates

patch release and open source software are patched faster than proprietary software.

1 Introduction

Discovery of highly critical vulnerabilities such as Heartbleed, Shellshock, and Poodle, recently brought the

subject of vulnerability discovery and patching at the center of Internet and cybersecurity discussions. These

vulnerabilities have been extensively exploited for several years and have affected more than two third of active

web sites on the Internet, partly due to the predominance of few systems.1

Despite security practitioner’s efforts, attackers move faster to exploit critical vulnerabilities than vendors

provide patches. In 2014, vendors spent on average 59 days to release a patch for the five most exploited

zero-day vulnerabilities, while these vulnerabilities were exploited in thousands of attacks from the first month

∗I thank my thesis advisor Marc Bourreau for his patient guidance and support.†Telecom Paris Tech. E-mail: arrah-marie.jo@telecom-paristech.fr1Hearbleed, Shellshock and Poodle are vulnerabilities in cryptographic software library called OpenSSL. These weaknesses allow

stealing information that are protected, under normal conditions, by the SSL/TLS encryption used to secure transactions on theInternet.The impact of these vulnerabilities is all the more serious as software affected by these vulnerabilities are extremely widespread. Asa matter of fact, in 2014, the combined market share of just Apache and Nginx, the two most widely spread webservers using theOpenSSL library, was over 66% out of the active web sites on the Internet. (Source: http://heartbleed.com)

1

of their discovery.2 How can we explain such difference in the attacker and vendor’s responsiveness? Technical

explanations may be part of the answer, yet in recent years, researchers have realized that economic analysis can

offer as much a valuable insight as technical answers (Anderson and Moore, 2007). From this perspective, a

relevant question is to identify the economic factors affecting a firm’s incentives to invest in the security of its

product. Considering that markets in the software industry are generally highly concentrated (Varian, 2001),

do software publishers have enough incentives to provide an appropriate level of security to their users? In

particular, does the market competition have a positive or a negative impact on a software’s security quality?

Economists have long been interested in the relationship between market competition and investment

incentives. An extensive IO literature covers the subject, yet it is hard to find general tendencies both in

theoretical and empirical results (Aghion and Griffith, 2008). Competitive pressure can encourage investments

in order to “escape competition”. On the other hand, post innovation rents may provide stronger incentives

to invest, that is, the “Schumpeterian effect” of competition can prevail (Aghion, Bloom, Blundell, Griffith,

and Howitt, 2005). In light of this context, our objective in this paper is to examine empirically the effect of

the competition intensity on a software vendor’s security provision behavior. More precisely, we analyze the

relationship between the market competition intensity and the time a software publisher spends to release a

patch when it is notified about a security flaw affecting its product. We study the case of a market situated at

the center of Internet based security issues, namely the web browser market.

For this purpose, we compiled a cross-sectional data set on software vulnerabilities of web browsers discovered

and patched from January 2006 to December 2015. Limiting our study to a single market – the web browser

market – is relevant for several reasons. First, it is a key market for Internet security issues, web browsers

being the principal “Window” of the World Wide Web, installed on almost all computers and devices that have

access to the Internet.3 For instance, the five most exploited zero day vulnerabilities in 2014 and 2015 have

directly affected web browsers.4 Secondly, we limit our study to a single market where we are able to obtain

a simple and accurate proxy of the market competition, using the Herfindahl-Hirschmann Index (HHI) from

the quarterly market share of each web browser.5 Third, we study a market presenting a large variation of the

concentration (and thus of the competition intensity) which enhances the robustness of our analysis. The model

is additionally tested on the rendering engine market, which we can consider as an upstream market for web

browsers. Lastly, we only consider vulnerabilities directly assigned to web browsers. In other words, we only

consider vulnerabilities which can be secured by web browser publishers themselves without relying on a third

party publisher so that the patching time spent by the vendor depends on its own investment decision.6

2Source: ISTR – Internet Security Report April 2015 Symantec figures in p.673The WWW is not Internet. It is rather one way to use the Internet. The World Wide Web Consortium (W3C) defines the

WWW as an information space where documents and other web resources are identified by URLs, interlinked by hypertext links,and can be accessed via Internet. Source: http://www.w3.org/Help/#webinternet

4Source: Symantec annual report on Internet Security (ISTR 2014 and 2015)5We use 1 - HHI/10 000 as a measure of the market competition intensity.6 For instance, vulnerabilities that concern Adobe Flash is excluded from our study because in this case, the patch is mainly

developed by Adobe and not the Web browser publishers.

2

Our results show that competition intensity has a negative impact on the rapid patching of a web browser by

its publisher. In other words, the more the market is competitive, the less the software vendor invests in product

security. This may be due to the specificity of the web browser market, which presents a revenue model typical

to markets with indirect network externalities: the use of web browsers are free of charge for the users and the

market is essentially subsidized by search engines revenu. In addition, we find that software vendors tend to

release a security patch more rapidly when the vulnerability information is disclosed to public earlier, and that

open source browsers or rendering engines are patched faster than proprietary ones.

This work draws from two strands of literature: the economics of information security and the economic

literature on the relationship between competition and investment.

The literature on the economics of information security is recent and thriving; it aims at studying the

potential market failures causing information systems insecurity. Vulnerability discovery and patch management

are one of the topics at the heart of this field. Analytical works in this literature study various questions: some

papers analyze the welfare implications of different liability and information disclosure policies (August and

Tunca, 2011; Choi, Fershtman, and Gandal, 2010; Arora, Nandkumar, and Telang, 2006b); others investigate the

coordination possibilities between software vendors and customers in the patch management process (Cavusoglu,

Cavusoglu, and Zhang, 2008) or examine the role of different vulnerability discovery mechanisms (Kannan and

Telang, 2005). However, few studies account for the impact of market structure on firms’ information security

provision. Kim, Chen, and Mukhopadhyay (2009) build a model of risk sharing for security losses between

software vendors and users. They show that market competition can lead to a higher level of risk sharing, and

therefore a higher level of security quality. They study the vendor’s incentive to share the risks with its users with

a broad definition of ”risk sharing”, which includes information sharing, damage cost or security investment cost

sharing. In our paper, we specifically focus on the vendor’s investment incentives in software security. Gal-Or and

Ghose (2005) examine the effects of market characteristics such as the degree of intra-industry competitiveness

and firm size on a firm’s information sharing behavior and security technology investment decisions. One of

their main findings is that the incentives to share information and to invest in security increase as the degree of

competitiveness in an industry increases. Their model focuses on the role of information sharing, which acts as a

strategic complement of firm’s security technology investment and as a social welfare-enhancing mean. Arora,

Caulkins, and Telang (2006a) analyze the initial security quality of a software and the patching behavior of

software vendors and find that the market size has a crucial role on the vendor’s behavior. Their model however

considers only a market under monopoly. To the best of our knowledge, no analytical paper investigates the

direct impact of market competition on the patching behavior of software vendors.

So far, empirical work dealing with vulnerability discovery and patch management have essentially focused

on issues related to vulnerability disclosure. Some researchers study the impact of vulnerability information

disclosure to stock exchange prices (Campbell, Gordon, Loeb, and Zhou, 2003; Telang and Wattal, 2007) and

3

other papers closer to ours on security investment (Gordon, Loeb, Lucyshyn, and Sohail, 2006; Arora, Krishnan,

Telang, and Yang, 2010b). In particular, Arora et al. (2010b) exploit similar data as in our study to investigate

the vendor’s responsiveness to vulnerability information disclosure and the impact of information disclosure on

the frequency of cyber-attacks. Ransbotham, Mitra, and Ramsey (2008) use security alerts data from a private

security service provider to examine the impact of market-based vulnerability disclosure on the risk of cyber

attacks. Our empirical model accounts for the impact of vulnerability information disclosure but it is not our

main subject of interest. Information disclosure is rather considered as one of the essential factors that enable to

isolate the effect of competition intensity.

The study that comes closest to ours is of Arora, Forman, Nandkumar, and Telang (2010a). Our paper has a

similar purpose with them in that we both analyze empirically the effect of competition on software publishers’

security investment behavior. Indeed, both of us consider that the extent to which a vendor internalizes its

customer losses is influenced by competition. Also, both of us use the time to patch as a measure of software

quality. However, our approach differs to theirs in several points. First, Arora et al. (2010a) analyze software

vendor’s investment behavior in reaction to other vendors that share a common vulnerability. They consider

that sharing the same vulnerability put vendors in a competitive situation, whether they are actually operating

in the same market or not. In our case, we consider a narrower definition of the market competition by limiting

our analysis to interactions within a single market and using a proxy of the market competition deriving from

the market concentration. Secondly, we test our model on one specific market during a relatively long period

of time – a ten-year-period – in order to capture both short and long term effect of competition to software

vendor’s investment behavior.7

The rest of the paper is organized as follows. In Section 2 we provide a brief summary of the web browser

market history and its specificities. Than we describe the vulnerability discovery and patching process. Section

3 describes the rationale behind our empirical approach. Section 4 presents the data. Section 5 presents the

econometric model and the variables. Estimation results follow in Section 6 and the final section provides

conclusions.

2 Background and economic framework

2.1 The web browser market

A web browser is a software that gives access to the World Wide Web (WWW). It retrieves and displays content

from remote web servers using the HyperText Transfer Protocol (HTTP). Web resource are usually written in

HyperText Markup Language (HTML) and may contain diverse types of content such as PDF or images. They

may be augmented with technologies such as Cascading Style Sheets (CSS), which adds additional layout and

styling information, or use JavaScript for client-side computation. The most popular web browsers today are

7Our data covers a 10-year-period from 2006 to 2015 while Arora et al. (2010a) consider a 4-year-period from 2000 to 2003.

4

Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, and Apple Safari (see Figure 1).

Figure 1: Web browser’s market share from 2006 to 2015

As it is the case for any software, web browsers are dependent to the operation system (OS) on which

they run. Its dependency to a platform naturally brings compatibility and lock-in issues. For instance, in the

mid-1990s, Microsoft took advantage of the dominance of Windows on computers to extend Internet Explorer’s

market share when facing the competition of Netscape. Today however, web browsers are available on various

types of hardware, from desktop computers to cell phones and tablets, and major operation systems of computers

and smartphones have more than 50 browsers available on it, which users can freely and easily install or remove.

Besides, a web browser is a platform itself, where web surfers and website owners meet. Moreover, increasingly,

a browser is not just a single piece of software but an entire suite of applications. For instance, Google Chrome

is totally integrated to Google’s other web services: the user is able to get its bookmarks or Google Maps history

back from one Chrome browser to another, just by logging on to its Google account. Along with the increasing

use of Internet and the growth of Web-related industry, the browser’s role as a platform is enlarged, benefiting

from direct and cross network externalities.

The privileged position of a web browser is also strengthened by the importance of its core component,

the rendering engine. The rendering engine, sometimes called “web browser engine” or “layout engine”, is the

component responsible for displaying the requested content according to the formatting information. It is also

used in a range of web applications such as email clients or eBook readers that require the displaying and editing

of web content. The four most used rendering engines are created and maintained by the four major web browser

publishers: Webkit by Apple, Blink by Google, Gecko by Mozilla and Trident by Microsoft. Except for Trident,

these rendering engines have an open source license, which allows developers to modify and integrate them freely

in other software.

Because the way a web browser as well as other web applications interpret and display web resource depend

on the rendering engine it uses, a rendering engine is not only essential for the web application itself but also

has a crucial role in the definition and evolution of web standards.8 Until 2000s, web browsers conformed to

only a part of web standards specifications. As a result, “users” of both sides of the “platform” had to bear the

8Web standards are the normative specifications of technology or methodology that are applicable to the World Wide Web. Inrecent years, the term has been more frequently associated with the trend of endorsing a set of standardized best practices forbuilding web sites, and a philosophy of web design and development that includes those methods. Source: Wikipedia

5

cost of incompatibility: when using the wrong browser, web surfers could not view content or perform desired

transactions and web designers should neglect some browsers thus locking out potential customers or implement

multiple versions of every web page in order to accommodate incompatible browsers. Today, web standards

application has been strengthen by the work of the World Wide Web Consortium (W3C) and the Web Standards

Project (WaSP).

The central role of web browsers as a platform explains why publishers do not charge any fee to the users.

Indeed, the revenue model of Web browser publishers differs from one to another, but none of them charge

directly the users. Most web browsers are paid by search engine companies to make their engine default or to

include them as an option. For instance, almost the entirety of Mozilla’s income comes from royalties paid by

Google. In the case of Apple, Microsoft and Google, the development of the web browser is funded by the sales

of other services and products. For instance, Google exploits user data from Chrome to improve Google AdSense

program, from which its main revenue comes.9

Internet Explorer dominated the web browser market until the beginning of 2000s but competition was

gradually introduced with the launch of Firefox in 2004 and Apple’s rendering engine becoming open source in

2005. The data used in our paper covers a ten-year-period just afterwards, from 2006 to 2015. It is a period

characterized by a dynamic market, with the development of competition and improvement of quality. Web

browser publishers started offering new functionalities, better rendering performance and frequent updates (see

Figure 2). New web browsers were released by small software vendors and open source projects. Also, Google

released its first browser Chrome in 2008. If developing its own rendering engine is a costly and timely process,

the possibility to use open source rendering engines have certainly accelerated the entry of new players in the

market.10 At the same time, Web standards application has been strengthen by the wide use of compliance

tests such as Acid2 in 2005 and Acid3 in 2008.11 After such period of dynamism, the market has become more

concentrated in recent years, with Google gradually acquiring a dominant position since the deployment of its

own open source rendering engine Blink in 2013.

All in all, we see that the web browser market has a very central role in the evolution of the WWW and that

behavior of firms playing in this market may have considerable repercussions in the Web industry. Within this

context, investment on quality by the web browser publishers – such as the provision of security to users – seems

clearly an important issue. Besides, estimating the market power of firms in this market and using its usual

definition – the ability of a firm to raise the market price over marginal cost – is difficult, as firms do not charge

any price to the consumer. It is impossible to understand a firm’s behavior by considering the web browser

market alone; at the same time, there are too many unknown factors to take account if we consider the whole

9Source: http://lifehacker.com/5763452/what-data-does-chrome-send-to-google-about-me, http://www.investopedia.

com/articles/investing/020515/business-google.asp10Mozilla’s rendering engine Gecko became open source in 1998, Apple’s rendering engine Webkit become open source in 2005,

Google forked its own rendering engine Blink from Webkit and released it also in open source in 2013.11Acid2 and Acid3 are tests of Web standards compliance published and promoted by the Web Standards Project to expose Web

page rendering flaws in web browsers. At the time of the first test’s release, every browser failed it, but now a the major browsers onthe market pass it. Source: Wikipedia

6

Figure 2: Web browser’s update frequency

multi-sided market (that is, all the markets depending on the web browser market).

2.2 Software vulnerability and cybersecurity

2.2.1 Vulnerability research programs

In information system and computer security, a vulnerability refers to a weakness in the architecture, design, or

code, which allows an attacker to reduce a system’s information assurance, such as compromising the integrity,

availability or confidentiality of the data it processes.12 If the affected device is connected to a network accessible

through Internet – which is actually the case of almost all devices nowadays – it may be targeted by remote

attackers.

A vulnerability can be fixed by the development of a security patch by the vendor and its installation by

the user. The active discovery of vulnerability and its rapid patching are thus crucial to minimize the risk of a

system’s exposure (Schneier, 2000; McGraw and CTO, 2004). Today, different public and private organisms

are specialized in vulnerability research and help software publishers and companies – the users of information

systems – to deal with security incidents. Some are non commercial, such as Computer Emergency Response

Teams (CERT), others work for commercial purpose, operating in the market for vulnerabilities. CERTs are

security expert groups acting as coordinators between software publishers, user companies and researchers

that identify the security flaws. A CERT may have its own research team but does not purchase vulnerability

information; security problems are reported on a volunteer basis. In the commercial side, security firms called

also security infomediaries remunerate researchers for the discovery of vulnerability and communicate with

vendors to provide protection solutions for their clients. iDefense and Tipping Point are the two major security

firms playing in this market. Also, an increasing number of software vendors manage their own security research

team or offer bounties for vulnerability discovery. Google, for instance, launched a program called Google Project

Zero since 2014.

In our study, the main data sources are precisely these vulnerability research programs, namely Tipping

Point’s Zero Day Initiative (ZDI) program, iDefense Vulnerability Contributor Program (VCP), and Google

12Source: https://cwe.mitre.org

7

Project Zero. ZDI is a program run by the security firm Tipping Point since 2005. VCP is the corresponding

program of Verisign initiated in 2003. Both ZDI and iDefense notify the affected vendors and communicate with

them until the release of a security patch. Google Project Zero is a recent project initiated by Google in 2014

similar to the two other programs, financially rewarding researchers for vulnerability discovery.13 Information

about the vulnerability is kept confidential during a period of time specified by the infomediary’s disclosure

policy.

2.2.2 Vulnerability lifecycle

Figure 3 presents major events that may occur during the lifecycle of a software vulnerability, from its discovery

(either by a malevolent or a well-intentioned actor) to its mitigation by the delivery of a patch and its installation.

This timeline is consistent with its representation by Ioannidis, Pym, and Williams (2012), Beres, Griffin, Shiu,

Heitman, Markle, and Ventura (2008), or Frei, May, Fiedler, and Plattner (2006).

Figure 3: Lifecycle of a vulnerability

Five key events outline the different phases of a vulnerability lifecycle: (1) the discovery of the vulnerability,

(2) the vendor being informed about the existence of the vulnerability, (3) public disclosure, (4) patch release

by the vendor, and (5) patch installation by the user. At each stage, the associated security risk is different

(Schneier, 2000).

The vulnerability may be discovered first by an individual or an organism that does not work for the affected

software’s vendor. We call it then a zero-day vulnerability, since the software vendor has zero days left to deliver

a patch before the vulnerability may be exploited once it is discovered.

The probability to identify a vulnerability and fix it, thus the probability the software is more secured may

depend on the effort the vendor puts in vulnerability discovery activity. In our study, we only consider the

vendor’s post-discovery effort, that is, its patching decision after being informed about the vulnerability.

From the moment the software vendor is informed about the vulnerability, he will spend some time to release

a security fix. All other factors being equal (such as the vendor’s initial assets to deliver a patch or the basic

time necessary to develop the patch), the faster the vendor releases the patch, the more it will cost for him. On

the other side, from the moment the vulnerability is discovered, the risk it is exploited will grow until a security

13Google Project Zero focuses especially on vulnerabilities that can affect its competitor’s product, an operation system where itsapplications may be installed, a module connected to its product, a standard or a protocol used by one of its product

8

patch is available. Yet, note that the risk associated to the vulnerability is not measurable by the vendor until it

is informed about it. Based on this idea, we consider the time spent to release the patch after the vulnerability

was known by the vendor as a measure of the vendor’s investment in security provision.

Information about the security flaw can be disclosed to public before the vendor releases a security fix.

Though the public disclosure of vulnerability information increases the software’s exposure to attack, many

advocate that disclosure can be an incentive for vendors to be more responsive in patching their software (Arora

et al., 2006a). Vulnerability research programs generally keeps the vulnerability information confidential during

a period of time after contacting the affected vendor, as they specify on their disclosure policy. For instance, ZDI

keeps the vulnerability information confidential for 4 months, iDefense for 6 months and Google Project Zero

for 3 months. Our study account for the impact of vulnerability information disclosure although it is not the

main focus of our model. It is rather used as one of the factors that help to isolate the effect of the competitive

pressure.

Lastly, the security risk will be entirely mitigated when the software user actually applies the patch. Though

some papers deal with this subject (Cavusoglu et al., 2008; Shostack, 2003) the patching behavior of the consumer

is beyond the scope of our paper.

3 The vendor’s patching decision

Economists often point out the necessity to attribute liabilities to those who can manage the risks. Software

vendor has naturally an essential role in securing the software. Although the user is responsible to actually install

the patch, software vendor is indeed the one who will determine the initial security quality of its software (Arora

et al., 2006a), decide whether he will differentiate the price of its product for more secured options (Anderson,

2001), defines its vulnerability discovery and patch development strategy as well as its vulnerability information

and disclosure policies (Choi et al., 2010).

In our paper, we focus on the patching strategy the vendor should set when it is informed about a security

flaw in its product. What is the reasoning behind its decision to develop the security patch more or less rapidly?

That is, what is the optimal cost it would accept to spend in patching the flaw?

Among the many examples we can give, take the case of the well-known Sony PlayStation attack. In April

2011, Sony PlayStation Network was hacked, leaving an outage of 23 days and causing the loss of 77 million

users’ personal data.14 Users of Sony PlayStation services were directly affected by the security breach since they

were not able to use the service they paid for almost one month. But most of all, they were victims of private

data loss of high importance such as their account’s password and bank account details. On the vendor side,

14The attack is guessed to be a mix of DDOS and SQL injection technics. Attackers exploited very simple weak-nesses of its network such as the use of outdated versions of web servers. Source: www.extremetech.com/gaming/

84218-how-the-playstation-network-was-hacked

www.consumerist.com/2011/05/04/security-expert-sony-knew-its-software-was-obsolete-months-before-psn-breach

9

Sony has suffered two types of damages: first, the network outage caused direct damages to the functioning of

the firm (such as business continuity) and second, he has suffered from the negative externalities caused by user

losses. In the case of a software vendor, it does not suffer direct damages from its own product’s vulnerability

unless it uses the product himself (compared to a service provider for which an outage of its service cause direct

damages to its business). Thus our model considers only the second effect, namely the indirect damages that the

vendor internalizes from the user losses.

Sony might have invested adequately in securing its network if it had rightly assessed the damage cost of the

attack. Similarly, a software vendor will decide to spend in security as much as the potential security breach on

its product is likely to cost for him. In other words, when the software vendor discovers a security flaw in his

product, two main factors will be taken account in his patching decision: the negative externalities caused by the

perceived potential security risks by users, and the cost of the patching. Our objective is to examine the impact

that the competitive pressure may have on these two factors on which the vendor’s patching decision is based.

What are the factors considered by users to evaluate the security quality of a software?15 First, from the

moment the consumer is informed about a vulnerability, that is, from the moment the user becomes aware about

the security risk, each day the software remains unpatched will impact negatively the user’s perception of the

security quality. Thus public disclosure of the vulnerability information is essential to the vendor reputation.

Factors such as the criticity or the type of the vulnerability play also an important role in shaping the vendor

reputation. Indeed, users may be more sensible to certain types of vulnerabilities that involve confidential data or

which are evaluated as critical by security professionals. Several papers address these points. For instance, Arora

et al. (2010b) study the impact of public disclosure and Campbell et al. (2003) the impact of security breaches

according to their confidential nature. Our econometric model also accounts for these factors.16 However, our

focus is more on the extent to which the vendor considers its reputation important, according to the market

competition level. Indeed, we expect that the vendor will consider more or less importantly its reputation

depending on the competitive pressure and its market power. This corresponds to what Aghion et al. (2005)

name the “escape competition effect” in the sense that market competition may foster investment by ”reducing

a firm’s pre-investment rents by more than it reduces its post-investment rents”.

The software publisher will also take account the initial cost of the patching in order to determine how much

he will additionally spend on the patch to release it more or less rapidly. Patching cost will depend both on the

technical complexity of the patch and the vendor’s ability to develop it. Security experts will need more time to

develop a patch for a technically more complex vulnerability then a less complex one. The vendor may also be

able to react more rapidly to security incidents if it has a permanent team dedicated to security issues or it

employs skilled developers capable of finding efficient solutions within a short time, which will necessarily cost

respectively more than not having a permanent team and employing less competent developers. The ability

15Vendor reputation is determined by the quality of the product as it is perceived by the users (Shapiro, 1982).16Note also that in the case of Web browsers, the vast majority (75.05%) of vulnerabilities are disclosed to public after the patch

is released. The disclosure effect is nevertheless considered in our model as a control variable.

10

of a firm to invest in fixed cost (such as having a security research team) may depend on the firm size, since

large vendors typically have higher sales volume that allows higher economy of scale. It may also depend on the

market size for similar reasons of economy of scale (Arora et al., 2006a). But more importantly, it may depend

on the competitive pressure, which can either encourage or impede the firm to invest in security quality. This is

what (Aghion et al., 2005) name the “Schumpeterian effect”.

All in all, our hypothesis is that the speed of patching depends on two main factors, that is, the extent to

which the vendor internalizes the cost of the insecurity perceived by the users and the necessary cost to develop

the patch, which in turn, are both influenced by the competitive pressure.

4 The data

For the purpose of our empirical analysis, we combine four data sources: (1) vulnerability information collected

from three different vulnerability research programs, (2) important dates (patch and new versions release

dates) about each web browsers from the publisher’s website, (3) quaterly market share of each browsers from

Statcounter.com, (4) additional information about each vulnerability from the National Vulnerability Database

(NVD) .

Our data was primarily collected from three different vulnerability research programs: Zero Day Initiative

(ZDI), iDefense Vulnerability Contributor Program (VCP), and Google Project Zero. ZDI is a program run by

the security firm Tipping Point since 2005. VCP is the corresponding program of Verisign initiated in 2003. As

explained in Section 2, these firms are the two primary players in the commercial vulnerability market, which

financially reward the researchers in exchange for the information they have about new vulnerabilities they

discover. Both ZDI and iDefense notify the affected vendor and communicate with her until the release of a

security patch. Information about the vulnerability is kept confidential during a period of time specified by their

disclosure policy. The disclosure timing policy is not strictly applied, but the actual duration of confidentiality is

revealed on the program’s website after the release of the patch. Google Project Zero is a recent project initiated

by Google in 2014 similar to the others.17 As in other programs, the vulnerability information is disclosed to

public once a patch has been released or after a 90-day-deadline.

In order to measure the time a software vendor spends to patch a vulnerability, we needed both the date of

the patch delivery and the date on which the vulnerability was reported to the vendor. Given that the later

information is of a highly confidential nature (especially from the software vendor point of view), these programs

were some of the few sources that provided this information.

From the websites of these three programs, we collected and consolidated the data about web browser

vulnerabilities they identified from January 2006 to December 2015. We only consider vulnerabilities affecting

web browsers and which the web browser publisher itself can secure without relying on a third party intervention.

17Google Project Zero focuses especially on vulnerabilities that can affect its competitor’s product, an operation system where itsapplications may be installed, a module connected to its product, a standard or a protocol used by one of its product

11

For instance, vulnerabilities that concern Adobe Flash are not taken account because in these cases, patches are

mainly developed by Adobe.

This database has been completed with information from the National Vulnerability Database (NVD) about

vulnerability characteristics such as the severity (CVSS),18 the type of security impacts, and the public disclosure

date. As some primary information such as the disclosure date is collected from this source, we consider only the

NVD-listed vulnerabilities.

For vulnerabilities that affect more than one browser, we created separated observations for each browsers.

This allows us to assess separately the behavior of each publisher. Indeed, different publishers can release patches

for their browsers within a different timeline even if they are affected by the same vulnerability.

From each browser’s website, we collect information about the release date of the affected browser’s versions

and the patch release date.

Lastly, for each vulnerability-browser pair, we collect the quarterly market share of the affected browser at

the date when the vulnerability was reported to the vendor, from Statcounter.com.

The 521 observations we consider in our analysis represents 14% of the total number of browser vulnerabilities

referenced on NVD.19 It is a sample that represents the whole population in a balanced manner over time (Figure

4 left). Nonetheless we note that vulnerabilities of very high severity (CVSS of 9 to 10) are significantly more

represented in our sample compared to the parent population. We explain this bias by the commercial nature of

the programs that reported the vulnerabilities (Figure 4 right). This bias is controlled in our regression by the

use of the CVSS as a control variable.

Figure 4: Comparison of the studied sample to the whole population

18CVSS is a scoring system initiated by the National Infrastructure Advisory Council (NIAC) of the United States and maintainedtoday by the Forum of Incident Response and Security Teams (FIRST).

19The parent population we are considering is all the vulnerabilities affecting Web browsers and referenced on the CVE catalog ofNVD as identified during the investigated period of time.

12

5 Econometric model and variables

In order to evaluate the effect of the market competition intensity to the vendor’s responsiveness in vulnerability

patching, the following OLS regression model has been defined:

Patching T = β0 + β1Comp+ β2V uln char + β3V&Soft char + β4User ext+ β5T effect+ ε (5.1)

From the moment a software vendor is alerted about a vulnerability affecting its product, it will spend a certain

period of time to develop the patch and to release it. Our dependent variable Patching T (patching time) is

the time spent by the vendor to release the patch, that is, the duration between the date the vendor is informed

about the vulnerability and the date he releases a patch for it.

Our hypothesis is that the software vendor’s decision to publish the security fix more or less rapidly is

influenced by the market competition level. Hence our key independent variable is the competition intensity level

in the web browser market Comp (comp intensity). We define it as equal to 1–HHI with HHI the Herfindahl

index of the market at the date when the vulnerability is discovered. The HHI is computed from the quarterly

market share of each browser from Statcounter.com.

In order to isolate the market competition effect, our model control for a list of exogenous factors that may

impact the responsiveness of the vendor to develop a security patch.

First, V uln char accounts for the characteristics of the vulnerability such as the severity and the type of

the vulnerability. This vector of variables captures the impact of the potential risk the vulnerability represents

(whatever the market competition intensity or the position of the vendor on the market are, the vendor will

prefer to patch more rapidly a vulnerability that has a severe security impact) and the complexity of the patch

(vulnerabilities more complex to secure will need more time to be developed). More precisely, we use two types

of information: The Common Vulnerability Scoring System (CVSS) and the Common Weakness Enumeration

(CWE).20 The CVSS is a value ranging from 1 to 10 and takes account a number of characteristics such as the

complexity and the type of intrusion or the access complexity. The CWE is a formal list of software weaknesses

that can lead to exploitable security vulnerabilities.21 CVSS value is directly used as the vulnerability severity

variable. CWE are used as a system of dummies we named vulnerability type. These exogenous variables enable

us to capture the necessary cost and therefore the basically necessary time to release the patch.

Secondly, we control for the characteristics of the web browser and its publisher by V&Soft char. First,

the incentive of the vendor to release a security patch more or less quickly can depend on the maturity of the

software (software age). Indeed, software vendors usually limit or end the support for a product after a certain

period of time. We also control for vendor-specific characteristics by a vector of dummies (each vendor has

20These are “common language” defined with the goal of providing a common baseline standard for vulnerability identification,mitigation, and prevention efforts. Both are standardized metrics used by the development community and security practitioners.

21Software weaknesses referenced as CWE are: buffer overflows, format strings, etc.; structure and validity problems; commonspecial element manipulations; channel and path errors; handler errors; user interface errors; pathname traversal and equivalenceerrors; authentication errors; resource management errors; insufficient verification of data; code evaluation and injection; andrandomness and predictability. Source: MITRE

13

an assigned dummy). Indeed, vendors may have specific patch release policies that affect their patch release

decisions but are unobserved by us. Some of them may care more about their reputation because of the spillover

effect on their other products. The patching time can also depend on their financial ability to invest in security

(for example in order to afford a larger security development team). In Arora et al. (2006a), this gap between

vendors is controlled by the vendor size. In our case, web browser publishers present heterogeneous forms of

organization and business models, from open source foundation to multinationals listed on stock exchange (see

Table 1). The size of a firm is hence not an adequate information to account for the vendor specific unobserved

and we preferred to attribute a dummy variable for each vendor. In addition, our model takes account the effect

of opensource collaboration by using a dummy variable for whether the rendering engine is developed with an

opensource license.

Table 1: Comparison of web browsers

Browser Browser Rendering Rendering engine Vendor Type oflicense type engine license type Organization

Internet Explorer Proprietary Trident Proprietary Microsoft Multinational, publicly held corp.Chrome Freeware Blink GNU LGPL Google Multinational, publicly held corp.Safari Freeware Webkit GNU LGPL Apple Multinational, publicly held corp.Firefox Opensource MPL Gecko MPL Mozilla Foundation Foundation, non profit org.

Third, User ext captures externalities directly linked to users, such as the impact of information provided to

users and the number of users. Specifically, we account for the impact of vulnerability information disclosure by

the variable earlier disclosure, which is a dummy variable taking the value 1 if the vulnerability is disclosed to

public from 0 to 89 days after being reported to the vendor (That is, earlier than the conventional 90 days stated

by the disclosure policy of each vulnerability search programs from where our data set comes) and 0 if it is

disclosed to public after 90 days. The variable n users is the number of users for the concerned web browser and

therefore the number of users affected by the vulnerability. It captures the impact of the network size affected

by the vulnerability. We consider that the number of users of a web browser at a given time is the product of

the number of Internet user (total number of mobile and fixed broadband subscription in the World from ITU)

and the market share of the browser, assuming that for one connection to the Internet one web browser is used.

Finally, T effect captures the potential time trend and ε is the error term.

After having tested the linear relationship between patching time and market competition, we then test the

quadratic relationship. For this purpose, the following variant model has been defined:

Patching T = β0 + β1aComp+ β1bComp2+

β2V uln char + β3V&Soft char + β4User ext+ β5T effect+ ε

(5.2)

14

Next, Eq. (5.1) and Eq. (5.2) are tested on the rendering engine market (So far, we have considered the

web browser market.). A rendering engine (called also the layout engine) is a core component of a web browser

that renders and interprets formatting information in order to display the web contents with required layout

and appearance. The web browser market is dependent to the rendering engine market since the later is a an

essential component of the web browser. Our objective here is to see whether we observe the same relation

between competition and patching time on the upstream market of web browsers. The econometric model does

not change, but the values of some variables are recalculated according to the considered market, such as the

HHI or the number of users affected by the vulnerability.

Lastly, we define a variant model using the market share of the affected web browser as the key explanatory

variable:

Patching T = β0 + β1M share+

β2V uln char + β3V&Soft char + β4User ext+ β5T effect+ ε

(5.3)

Patching T = β0 + β1aM share+ β1bM share2+

β2V uln char + β3V&Soft char + β4User ext+ β5T effect+ ε

(5.4)

While the main objective of our study is to examine the impact of the market competition intensity which

reflects the potential market power some publishers can benefit when they are in a favorable position (such as

having a big market share), Eq. (5.3) and Eq. (5.4) rather test how publishers behave when they hold a larger

part of the market. We note that having a large market share does not necessarily imply having a large market

power.

All the models are estimated with ordinary least squares (OLS). For robustness checks, we also performed

variant regression tests with or without some of the control variables. A description of all variables is included in

Table 2 , while Table 3 presents descriptive statistics.

15

Table 2: Description of variables

Variable DescriptionDependent variablePatching time (Patching T )patching time Time spent by the editor to release a patch (unit: number of days)

(Release date of the patch – Reported date of the vulnerability to the vendor)Explanatory variablesCompetition intensity (Comp)comp intensity Herfindahl-Hirschman Index,(comp intensity)2 measured by each browser’s market share at the vulnerability discovery date

(reported date)Market share (M share)market share Market share of each browser at the date when the vulnerability was reported(market share)2 to the vendorVulnerability specific effects (V uln char)vulnerability severity Level of severity of the vulnerability (CVSS base score from 1 to 10)vulnerabililty type Classification of the type of weakness the vulnerability is subject to, such as “cross site

scripting”, “SQL injection”, “Information leak”. 12 type of weaknesses were associatedto web browsers vulnerabilities (dummies)

Software and vendor specific effects (V&Soft char)software age Maturity of the software at the time when the vulnerability is discovered

(unit: number of days) (discovery date of the vulnerability – release date ofthe earliest browser version affected by the vulnerability)

vendor dummies Dummies for each vendors : Google, Apple, Mozilla, Microsoft (dummies)opensource 1 if the affected web browser’s engine is opensource, 0 if not (dummy)User related externalities (User ext)n users Number of users of the browser on the date on which the vulnerability was reported.

(Market share of the browser number of internet user)earlier disclosure 1 if the vulnerability was publicly disclosed earlier than the conventional period of time

of 90 days, after being notified to the vendor, 0 if not. (dummy)Time effect (T effect)time effect The date on which the vulnerability was reported to the editor (unit: quaterly date)

Table 3: Descriptive statistics of variables

variable mean min max sdFor web browser marketpatching time 105 0 665 61.80comp intensity .725 .385 .791 .086cvss 8.9 3.3 10 1.13cwe119 Buffer errors (dummy) .42 0 1 .49cwe17 Code (dummy) .00 0 1 .062cwe94 Code injection (dummy) .11 0 1 .31cwe16 Configuration (dummy) .00 0 1 .044cwe79 Cross-Site Scripting (dummy) .00 0 1 .044cwe200 Information leak (dummy) .01 0 1 .11cwe20 Input validation (dummy) .05 0 1 .21cwe189 Numeric errors (dummy) .02 0 1 .15cwe22 Path traversal(dummy) .00 0 1 .044cwe264 Privileges and access control (dummy) .04 0 1 .19cwe362 Race conditions (dummy) .00 0 1 .062cwe399 Ressource management errors (dummy) .30 0 1 .46software age (number of days) 2197 0 5415 1534google (dummy) .05 0 1 .21apple (dummy) .11 0 1 .31mozilla (dummy) .11 0 1 .31opensource (dummy) .26 0 1 .44n users 524 11 1399 255earlier disclosure (dummy) .49 0 1 .50time effect 2012q4 2005q4 2015q4 9qFor rendering engine marketcomp intensity .65 .385 .731 .062blink (dummy) .021 0 1 .1439webkit (dummy) .13 0 1 . 337n user 580 51 1750 256

16

6 Estimation results

We first provide preliminary evidence on the relationship between competition and patching time through a

scatter plot of the patching time versus market competition, without accounting for other effects. Next we

present the regression results for linear models and for quadratic ones. For quadratic models, we compare the

different curves fitting with the estimated results. We also perform various robustness checks. In particular, we

present the estimated results for the rendering market. Lastly, we provide estimated results for the relationship

between patching time and vendor’s market share.

Figure 5: Scatter plot of patching time against competition intensity

First of all, when we look at the relationship between security investment and market competition without

accounting for any other effects, we observe a U-shape relationship as illustrated by Figure 5. Figure 5 plots a

measure of competition (1–HHI) on the x-axis against the patching time of a vulnerability for a web browser

on the y-axis. Each point represents a vulnerability-web browser pair. On the y-axis, we present the patching

time in an inverted way (we go toward the upside of the y-axis when the number of days passed to release the

patch decreases) to be consistent with the idea that the more the software vendor invests in security the faster

the patch is released.

The quadratic regression of competition intensity on patching time without other control variables provides a

consistent result with the scatter plot (Table 4); indeed the quadratic term of competition intensity is negative

and statistically significant and the x-coordinate of the maximum is located at 0.60.22 We though note that

this simple model accounts only for 2.4% of the data. Most of all, this regression does not account for some

factors that significantly impact the dependent variable such as the time trend, public disclosure of vulnerability

information, or individual characteristics of software vendors.

We now test the linear models that control also for other effects than competition intensity. Column 1 to 6

22Measure of the market competition varies from 0 to 1 as we have computed it as 1−HHI

17

of Table 4 display the regression results for linear models that include all or some of the control variables that

we have defined, as summarized below:

• (1) All control variables included (vulnerability specific effects, software and vendor specific effects, impact

of public disclosure and number of users, time trend)

• (2) All control variables except vulnerability type dummies

• (3) All control variables except opensource dummy

• (4) All control variable except number of users

• (5) All control variable except disclosure impact

• (6) All control variable except time effect

Table 4: OLS Regression of patching time by competition intensity

Competition intensity (Comp)comp intensity 1,003***

(346.3)(comp intensity)2 -840.6***

(284.2)Other control variablesV uln char NoV&Soft char NoUser ext NoT effect No

Observations 521R-squared 0.024

Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1

Table 5: OLS regression of patching time, linear relationship

VARIABLES (1) (2) (3) (4) (5) (6)Competition intensity (Comp)comp intensity 197.2*** 208.3*** 193.7*** 161.6*** 195.1*** -31.98

(48.29) (48.34) (48.21) (45.16) (55.68) (36.64)Vulnerability specific effect (V uln char)vulnerability severity Yes Yes Yes Yes Yes Yes

vulnerability type dummies (V&Soft char) Yes Yes Yes Yes Yes

Software and vendor specific effectsoftware age Yes Yes Yes Yes Yes Yes

vendor dummies Yes Yes Yes Yes Yes Yes

opensource Yes Yes Yes Yes Yes

User related externalities (User ext)n users Yes Yes Yes No Yes Yes

earlier disclosure Yes Yes Yes Yes Yes

Time effect (T effect) Yes Yes Yes Yes Yes

Observations 521 521 521 521 521 521R-squared 0.368 0.344 0.366 0.362 0.178 0.329

Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1

Table 5 displays only the coefficients for variable comp intensity. Overall, we observe that patching time

18

get longer when competition intensity is higher. That is, a negative relationship between the responsiveness of

the vendor in releasing a patch and the market competition intensity. In other words, the more the market is

concentrated, the faster the vendor releases a security patch. Consistent results for the different regressions from

Column 1 to 6 confirm the robustness of our initial model Eq. (5.1) that account for all the control variables.

Figure 6: Evolution of competition intensity (1-HHI) from 2006 to 2015

We note that the impact of the competition intensity is statistically not significant for regression that does

not account for the time effect (Column 6). In fact, the time effect variable is strongly correlated with our

variable of interest comp intensity. Indeed, we see in Figure 6 that the competition intensity follows globally a

linear trend over the studied period of time except in recent years. Independently of the current market structure

of web browser market, there is no doubt that software industry actors, including the software vendors, show an

increasing interest in cybersecurity over time. They also invest more in security than before. Accounting for the

time trend in our model is therefore important in order to isolate the effect of market competition from other

factors that evolved similarly over time. We note that the time effect variable can also capture a part of the

competition effect.

In order to check the robustness of the linear model and to understand the role of the time effect variable

in our estimation, we also test the quadratic model (Eq.5.2). Table 6 displays the regression results for the

quadratic models accounting for different control variables as such:

• (1) No control variable

• (2) All control variables taken account (vulnerability specific effects, software and vendor specific effects,

impact of public disclosure and number of users, time trend)

• (3) All control variables except vulnerability type dummies

• (4) All control variables except opensource dummy

• (5) All control variable except number of users

• (6) All control variable except disclosure impact

• (7) All control variable except time effect

We also compute the curvature and the x-coordinate of the maximum for the function Patching T =

β1(comp)2 + β2comp+ γ in order to visualize graphically the relationship between our dependent variable and

19

Table 6: OLS regression of patching time, quadratic relationship

VARIABLES (1) (2) (3) (4) (5) (6) (7)Competition intensity (Comp)comp intensity 1,003*** 1,486*** 1,573*** 1,492*** 1,327*** 1,741*** 940.5***

(346.3) (412.5) (344.8) (413.9) (408.7) (474.1) (349.1)(comp intensity)2 -840.6*** -1,010*** -1,072*** -1,017*** -919.1*** -1,212*** -777.5***

(284.2) (315.1) (263.7) (316.4) (314.2) (360.9) (295.6)Vulnerability specific effect (V uln char)vulnerability severity Yes Yes Yes Yes Yes Yesvulnerability type dummies Yes Yes Yes Yes Yes

Software and vendor specific effect (V&Soft char)software age Yes Yes Yes Yes Yes Yesvendor dummies Yes Yes Yes Yes Yes Yesopensource Yes Yes Yes Yes Yes

User related externalities (User ext)n users Yes Yes Yes Yes Yesearlier disclosure Yes Yes Yes Yes Yes

Time effect (T effect) -3.847*** -4.141*** -3.791*** -2.840*** -4.287***(0.840) (0.729) (0.835) (0.755) (0.922)

Observations 521 521 521 521 521 521 521R-squared 0.024 0.388 0.369 0.387 0.379 0.207 0.341

x coordinate of Maximum (−β2/2β1 ).597 .735 .733 .733 .722 .718 .605

Curvature (|β1|)841 1010 1072 1017 919 1212 777

Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1

explanatory variable of interest.

For all the regressions, we find a negative and statistically significant effect of the quadratic term of competition

intensity on the patching time. This result is also confirmed by the regression (7) where we do not account for

the time effect. Consistent results for the different regressions from (1) to (7) confirm the robustness of our

initial model that accounts for all the control variables. We also note that the linear model is as robust as the

quadratic model.

The negative coefficient for the quadratic term suggests an U-form relationship between market competition

and the speed of patch release. That is, software vendors invest more in security patch in a highly concentrated

market or in a highly competitive market one. Nevertheless, considering that the measure of competition intensity

in the studied market varies from 0.39 to 0.79 (cf. Table 3 of descriptive statistics) and that the x-coordinate of

the maximums are located close to 0.79, the relationship between patching time and competition intensity is

globally monotonous on the range of concentration rate covered by our tests. This is also graphically visible in

Figure 7 where we plot the fitting curves for quadratic regressions (1) to (7).

When we compare the curves of the regressions that accounts for the time effect variable to those that does

not, we see that the negative impact of the competition intensity on patching time is more emphasized when

the model accounts for the time effect, that is, regression (2) to (6). Moreover, we observe for these regressions

results that the variable time effect is negative and statistically significant (see Table 6): patches are released

20

Figure 7: Fitting curves for quadratic regressions

in average from 2.6 to 4.3 days earlier every quarter.

In Table 7 , we focus on other explanatory variables than competition intensity, such as the effect of opensource

and public disclosure. Table 7 displays the results for the following regressions:

• (1) Linear model with all the control variables (vulnerability specific effects, software and vendor specific

effects, impact of public disclosure and number of users, time trend)

• (2) Linear model with all the control variables except opensource dummy

• (3) Linear model with all the control variables except the disclosure impact

• (4) Quadratic model with all the control variables

• (5) Quadratic model with all the control variables except opensource dummy

• (6) Quadratic model with all the control variables except the disclosure impact

• (7) Quadratic model with all the control variables except the time effect

Our results support the idea that opensource software is patched more rapidly and that disclosure of

vulnerability information quickens the vendors to release a security patch.

Next, we apply our model to the market for rendering engines. The same linear and quadratic models

(Eq. 5.1 and Eq. 5.2) are applied, but we consider as one observation a vulnerability-rendering engine pair

(and not a vulnerability-web browser pair). As a result, the explanatory variable of interest value changes,

as well as values of some control variables such as vendor dummies and number of users. Estimation results

(displayed in Table 8) are similar to the web browser market except that the “escape competition effect” is

more emphasized. Indeed, we find a positive and statistically significant relation of competition intensity with

the patching time (the more market competition is intensive, the later patches are released) and a negative

and statistically significant quadratic term of competition intensity for the quadratic model. Besides, rendering

engine market is less impacted by competition intensity than the web browser one: on the web browser market,

the patching time presents a variation of 197 days for 1% of variation of the market competition intensity

21

Table 7: OLS Regressions of patching time, results for opensource & disclosure variables

VARIABLES (1) (2) (3) (4) (5) (6) (7)Competition intensity (Comp)comp intensity 197.2*** 193.7*** 195.1*** 1,486*** 1,492*** 1,741*** 940.5***

(48.29) (48.21) (55.68) (412.5) (413.9) (474.1) (349.1)(comp intensity)2 -1,010*** -1,017*** -1,212*** -777.5***

(315.1) (316.4) (360.9) (295.6)

Vulnerability specific effect (V uln char) Yes Yes Yes Yes Yes Yes Yes

Software and vendor specific effect (V&Soft char)software age & vendor dummies Yes Yes Yes Yes Yes Yes Yes

opensource -66.95*** -63.00*** -61.72*** -56.84*** -37.93**(16.78) (19.02) (16.12) (18.28) (15.10)

User related externalities (User ext)n users Yes Yes Yes Yes Yes Yes Yes

earlier disclosure -58.08*** -58.05*** -56.82*** -56.77*** -58.51***(4.199) (4.193) (4.002) (3.995) (4.272)

Time effect (T effect) Yes Yes Yes Yes Yes Yes

Observations 521 521 521 521 521 521 521R-squared 0.368 0.366 0.178 0.388 0.387 0.207 0.341

Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1

Figure 8: Fitting curve for regressions with all CV

22

Table 8: OLS Regression of patching time, considering the rendering engine market

Linear Quadratic QuadraticVARIABLES no CVCompetition intensity (Comp)comp intensity 98.48** 1,727** 1,031**

(45.78) (735.6) (401.9)(competition intensity)2 -1,345** -924.6***

(601.3) (352.9)Vulnerability specific effect (V uln char)vulnerability severity Yes Yes

vulnerability type dummies Yes Yes

Software and vendor specific effect (V&Soft char)software age Yes Yes

vendor dummies Yes Yes

opensource -56.94*** -55.03***(17.12) (16.55)

User related externalities (User ext)n users Yes Yes

earlier disclosure -58.81*** -56.77***(4.226) (3.960)

Time effect (T effect) Yes Yes

Observations 521 521R-squared 0.368 0.344

x-coordinate of Maximum (−β2/2β1) N.A .64 .56Curvature ( |β1| ) N.A 1344 925

Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1

(according to the linear model with all control variables included) while we estimate a variation of 98 days

for the rendering engine market. Moreover, the x-coordinate of the Maximum is smaller for the rendering

engine market than in the case of web browser market, meaning that the idea of a U-relationship between

patching time and competition intensity is more consistent in the rendering engine market. Figure 8 helps

to visualize this difference of estimation results between the web browser market and the rendering engine market.

Lastly, Table 9 shows the result for the variant model (Eq. 5.3 and Eq. 5.4) using the market share of the

vendor as the key explanatory variable. It displays the regression results accounting for the different control

variables as such:

• (1) Linear model with all the control variables (vulnerability specific effects, software and vendor specific

effects, impact of public disclosure and number of users, time trend)

• (2) Linear model with all the control variables except opensource dummy

• (3) Linear model with all the control variables except the number of users

• (4) Linear model with all the control variables except the disclosure impact

• (5) Quadratic model with all the control variables

• (6) Quadratic model with all the control variables except opensource dummy

23

• (7) Quadratic model with all the control variables except the number of users

• (8) Quadratic model with all the control variables except the disclosure impact

Table 9: OLS Regression of patching time with market share as key explanatory variable

Variables (1) (2) (3) (4) (5) (6) (7) (8)Market share (M share)market share -145.8** -140.6** -62.51* -148.2** 13.53 1.313 34.92 -442.0

(58.44) (58.55) (32.14) (72.54) (306.9) (308.0) (61.73) (340.8)(market share)2 -128.0 -113.9 -143.3* 236.0

(234.1) (234.6) (76.87) (256.5)Vulnerability specific effect (V uln char)vulnerability severity Yes Yes Yes Yes Yes Yes Yes Yes

vulnerability type dummies Yes Yes Yes Yes Yes Yes YesYes Yes Yes Yes

Software and vendor specific effect(V&Soft char)software age Yes Yes Yes Yes Yes Yes Yes Yes

vendor dummies Yes Yes Yes Yes Yes Yes Yes Yes

opensource -64.44*** -59.07*** -60.75*** -66.57*** -66.67*** -56.89***(17.83) (17.01) (19.78) (18.16) (18.10) (19.78)

Externalities related to users (Userext)nbuser Yes Yes Yes Yes Yes Yes

earlier disclosure -57.99*** -57.95*** -57.75*** -58.52*** -58.42*** -58.57***(4.218) (4.214) (4.176) (4.217) (4.209) (4.291)

Time effect (T effect) Yes Yes Yes Yes Yes Yes

Observations 521 521 521 521 521 521 521 521R-squared 0.356 0.354 0.353 0.166 0.357 0.355 0.357 0.168

Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1

The regression results show that the impact of market share is highly significant and affect the patching time

in the same direction as the competition effect. In other words, we observe a negative relationship between the

responsiveness of the vendor and its market share. Its estimated impact is as large as the competition effect (we

can compare the coefficients as they are normalized) for the linear model. Low statistical significance of the

competition intensity variable for the quadratic models supports the robustness of the linear result. Note that

the estimated results confirm also the positive and significant impact of opensource and disclosure variables.

7 Conclusion

We have built a data set related to vulnerabilities of web browsers and factors that may impact their patching

time. Our main objective was to examine the effect of the market competition to the vendor’s patching behavior.

We limited our tests on the web browser market, which is a representative market of the Internet based industry

and situated at the center of cybersecurity issues. We use a very simple measure of the market competition

intensity based on the HHI.

We find evidence that competition impacts negatively the vendor’s responsiveness in releasing a security

patch, that is, the more the market is competitive, the less the vendor spends in security provision. This

24

argument is also supported by the estimated results for the rendering engine market. In addition, the negative

relationship between vendor’s responsiveness and its market share confirm the idea that a software vendor does

not necessarily take advantage of its market position to neglect the security quality of its product. On the

contrary, the larger his market share is, the faster he fixes the security flaw.

Our finding is not intuitive. Indeed, although an extensive IO literature covers the relationship between

market structure and investment, it is hard to find general tendencies both in theoretical and empirical studies.

The unique empirical study in our knowledge dealing with similar data for a similar objective is Arora et al.

(2010a) and support a different conclusion regarding the relationship between competition and the security

provision effort of vendors. Our approach also differs from theirs in that we use a direct measure of the market

concentration to estimate the effects of competition while they analyze the impact of a vendor’s patching behavior

to its competitor ones.

References

P. Aghion and R. Griffith. Competition and growth: reconciling theory and evidence. 2008.

P. Aghion, N. Bloom, R. Blundell, R. Griffith, and P. Howitt. Competition and innovation: An inverted-urelationship. The Quarterly Journal of Economics, 120(2):701–728, 2005.

R. Anderson. Why information security is hard-an economic perspective. In Proceedings of the 17th AnnualComputer Security Applications Conference, page 358. IEEE Computer Society, 2001.

R. Anderson and T. Moore. Information security economics–and beyond. pages 68–91, 2007.

A. Arora, J. P. Caulkins, and R. Telang. Research note-sell first, fix later: Impact of patching on software quality.Management Science, 52(3):465–471, 2006a.

A. Arora, A. Nandkumar, and R. Telang. Does information security attack frequency increase with vulnerabilitydisclosure? an empirical analysis. Information Systems Frontiers, 8(5):350–362, 2006b.

A. Arora, C. Forman, A. Nandkumar, and R. Telang. Competition and patching of security vulnerabilities: Anempirical analysis. Information Economics and Policy, 22(2):164–177, 2010a.

A. Arora, R. Krishnan, R. Telang, and Y. Yang. An empirical analysis of software vendors’ patch releasebehavior: impact of vulnerability disclosure. Information Systems Research, 21(1):115–132, 2010b.

T. August and T. I. Tunca. Who should be responsible for software security? a comparative analysis of liabilitypolicies in network environments. Management Science, 57(5):934–959, 2011.

Y. Beres, J. Griffin, S. Shiu, M. Heitman, D. Markle, and P. Ventura. Analysing the performance of securitysolutions to reduce vulnerability exposure window. pages 33–42, 2008.

K. Campbell, L. A. Gordon, M. P. Loeb, and L. Zhou. The economic cost of publicly announced informationsecurity breaches: empirical evidence from the stock market. Journal of Computer Security, 11(3):431–448,2003.

H. Cavusoglu, H. Cavusoglu, and J. Zhang. Security patch management: Share the burden or share the damage?Management Science, 54(4):657–670, 2008.

J. P. Choi, C. Fershtman, and N. Gandal. Network security: Vulnerabilities and disclosure policy*. The Journalof Industrial Economics, 58(4):868–894, 2010.

S. Frei, M. May, U. Fiedler, and B. Plattner. Large-scale vulnerability analysis. pages 131–138, 2006.

25

E. Gal-Or and A. Ghose. The economic incentives for sharing security information. Information SystemsResearch, 16(2):186–208, 2005.

L. A. Gordon, M. P. Loeb, W. Lucyshyn, and T. Sohail. The impact of the sarbanes-oxley act on the corporatedisclosures of information security activities. Journal of Accounting and Public Policy, 25(5):503–530, 2006.

C. Ioannidis, D. Pym, and J. Williams. Information security trade-offs and optimal patching policies. EuropeanJournal of Operational Research, 216(2):434–444, 2012.

K. Kannan and R. Telang. Market for software vulnerabilities? think again. Management Science, 51(5):726–740,2005.

B. C. Kim, P.-Y. Chen, and T. Mukhopadhyay. An economic analysis of the software market with a risk-sharingmechanism. International Journal of Electronic Commerce, 14(2):7–40, 2009.

G. McGraw and C. CTO. Exploiting software: How to break code. In Invited Talk, Usenix Security Symposium,San Diego, 2004.

S. Ransbotham, S. Mitra, and J. Ramsey. Are markets for vulnerabilities effective? ICIS 2008 Proceedings,page 24, 2008.

B. Schneier. Managed security monitoring: Closing the window of exposure. Counterpane Internet Security,2000.

C. Shapiro. Consumer information, product quality, and seller reputation. The Bell Journal of Economics, pages20–35, 1982.

A. Shostack. Quantifying patch management. Secure Business Quarterly, 3(2):1–4, 2003.

R. Telang and S. Wattal. An empirical analysis of the impact of software vulnerability announcements on firmstock price. Software Engineering, IEEE Transactions on, 33(8):544–557, 2007.

H. R. Varian. High-technology industries and market structure. University of California, Berkeley, 33, 2001.

26