Competition and patching of security vulnerabilities: An empirical analysis

Abstract

a b s t r a c tWe empirically estimate the effect of competition on vendor patching of software defects by exploiting variation in number of vendors that share a common flaw or common vulnerabilities. We distinguish between two effects: the direct competition effect when vendors in the same market share a vulnerability, and the indirect effect, which operates through non-rivals that operate in different markets but nonetheless share the same vulnerability. Using time to patch as our measure of quality, we find empirical support for both direct and indirect effects of competition. Our results show that ex-post product quality in software markets is not only conditioned by rivals that operate in the same product market, but by also non-rivals that share the same common flaw.

A large scale exploratory analysis of software vulnerability life cycles

“…In [19], authors show that on average a vendor loses 0.6% of the stock price with the disclosure of a vulnerability. In [8], authors show that a vendor with more competitors patches the vulnerabilities more quickly. In [7], they show that the vulnerability disclosure accelerates the patch release.…”

“…The goal of such work is to estimate the number of vulnerabilities in new software products. Another direction of work aims to study the changes in the patching behavior of vendors in response to vulnerability disclosures and the existence of competitors [7], [8]. These studies analyze only small vulnerability data sets and do not cover the behavior of individual vendors.…”

A Conceptual Investigation of Maintenance Deferral and Implementation: Foundation for a Maintenance Lifecycle Model

“…This study shows, and this is in particular emphasized in work concerning maintenance in security and safety sensitive environments [38], that maintenance behavior in purchasing organizations is not universal, but can be unified into a maintenance lifecycle model that takes different contexts into account. It presents a comprehensive review of the reasons for maintenance deferral and implementation within the area of vendor software from the purchaser's perspective.…”

“…Should a trigger event occur and be ignored, possible consequences include economic damage to the company [38], higher expenditure and forced outages at a later time [30], or even demise of the purchasing organization itself [5].…”

“…Some papers alluded to the vendor maintenance release as a simple and sufficient trigger for a client organization's reaction to implement it [4,13,20,33]. Finally, exploits or threats that increase the risk in a safety-critical, life-critical or secure system are possible triggers for maintenance [5,38].…”