Sim 231 0087

Understanding and Managing Complex Software
Vulnerabilities: An Empirical Analysis of Open-Source

Operating Systems
Jean-Loup Richet, Wafa Bouaynaya
Dans Systèmes d'information & management 2023/1 (Volume 28), pages 87 à 114
Éditions ESKA
ISSN 1260-4984
ISBN 9782747234764
DOI 10.54695/sim.28.1.0087
© ESKA | Téléchargé le 05/07/2023 sur www.cairn.info via Angers-Le Mans COMUE expérimentale (IP: 91.167.60.142)
Article disponible en ligne à l’adresse

https://www.cairn.info/revue-systemes-d-information-et-management-2023-1-page-87.htm
Découvrir le sommaire de ce numéro, suivre la revue par email, s’abonner...

Flashez ce QR Code pour accéder à la page de ce numéro sur Cairn.info.
Distribution électronique Cairn.info pour ESKA.

La reproduction ou représentation de cet article, notamment par photocopie, n'est autorisée que dans les limites des conditions générales d'utilisation du site ou, le
cas échéant, des conditions générales de la licence souscrite par votre établissement. Toute autre reproduction ou représentation, en tout ou partie, sous quelque
forme et de quelque manière que ce soit, est interdite sauf accord préalable et écrit de l'éditeur, en dehors des cas prévus par la législation en vigueur en France. Il est
précisé que son stockage dans une base de données est également interdit.
ARTICLE DE RECHERCHE
Understanding and Managing

Complex Software Vulnerabilities:
An Empirical Analysis of Open-Source
Operating Systems
Jean-Loup RICHET1 & Wafa BOUAYNAYA2
1. IAE Paris - Sorbonne Business School, Université Paris 1 Panthéon-Sorbonne, Paris, France
2. IAE d’Amiens et LEFMI, Université de Picardie Jules Verne, France
ABSTRACT
There is a growing gap between practitioners and researchers: existing scholarly research
on software vulnerabilities cannot adequately guide developers to effectively manage their
vulnerabilities in the complex context of ‘software as amalgam’, tight coupling and open
source. We respond to practitioners’ calls for more research on vulnerability management
with a case of effective vulnerability management in the context of an open-source operating
system (OSOS). Hence, our paper is aimed at bridging this gap with practice and discussing
this overlooked concern in the academic literature: how do organizations effectively ma-
nage their vulnerabilities? We provide an empirical contribution with an extreme case of
vulnerability management in a large OSOS (Debian). Our research uncovers behavioral
dynamics and practices that foster responsiveness and adaptation in complex vulnerability
management.
Keywords: Complexity, Open-Source Operating Systems, Vulnerability Management.
RÉSUMÉ
Le code des logiciels d’aujourd’hui est de plus en plus complexe, mobilisant l’open source,
se couplant fortement et s’amalgamant à des services externes. L’écart croît entre praticiens
et chercheurs : les recherches existantes sur les vulnérabilités logicielles ne fournissent pas de
guide adéquat pour comprendre et gérer efficacement la complexité de ces vulnérabilités.
Ainsi, notre article vise à combler cet écart avec la pratique et à discuter de cette préoccu-
pation négligée dans la littérature académique : comment les organisations gèrent-elles
efficacement leurs vulnérabilités logicielles ? Nous apportons une contribution empirique
avec un cas extrême de gestion des vulnérabilités dans un grand système d’exploitation open
source (Debian). Notre recherche dévoile des dynamiques et des pratiques comportementales
qui favorisent la réactivité et l’adaptation dans la gestion des vulnérabilités complexes.
Mots-clés : Complexité, Systèmes d’Exploitation Open Source, Gestion des Vulnérabilités.
N° 1 – VOL. 28 – 2023 87
https://doi.org/10.54695/sim.28.1.0087
Livre SIM 1_2023.indb 87 22/06/2023 15:26

SYSTÈMES D’INFORMATION ET MANAGEMENT
1. INTRODUCTION
components, which call on various other
open-source components, in some cases
“Here’s 30.000 vulnerabilities. If you can to the fourth or fifth degree”3. ‘Software as
get it done by Sunday, that would be great” amalgam’ and open source are increasing
(SANS [Sysadmin, Audit, Network, and the complexity of securing source code and
Security] Security webcast, July 24, 20191) fixing its vulnerabilities: “we hardly write
code anymore; we live in an era where we
This introductory quote from a famous simply borrow or re-use code”3.
software security podcaster illustrates the
gap between chief information officers’ This sentiment is also commonly
perception of vulnerability management highlighted in the practitioner literature:
and software developers’ daily struggles “As increasingly more development frame-
with vulnerability management. This illus- works provide standard or third-party
tration is also correlated with the increasing frameworks for common tasks, much
number of online manifestos claiming that less code is written in-house. For exam-
fixing vulnerabilities is a difficult endeavor: ple, some estimate that more than 90% of
code in Node.js applications is actually
– We don’t budget for it—and we don’t written by third parties. A 2017 survey
have extra time or resources. conducted by npm found that while 97%
– Operational teams are already of the developers responding to the survey
overworked. use open-source software, 77% of those
– It never ends—even if we remediate were concerned about the security of these
everything, new vulnerabilities are open-source libraries. It will be interest-
constantly being discovered, and reports ing to see if there is an increase in the
come in at different times and in diffe- percentage of organizations leveraging
rent formats, depending on the tools or [open source] software component or
teams being leveraged for identification. dependency analysis moving forward.”2 4
– It’s a business expectation, but not a Open-source vulnerability management is a
business requirement; therefore, the effort real, complex and pressing problem today:
is not always recognized and rewarded. “pervasive risks posed by unmanaged open
– Security is accountable—but is not res- source, including security vulnerabilities,
ponsible—for much of the work. […] outdated or abandoned components, and
(Aggregated from SANS Vulnerability license compliance issues.”5
Management Survey 20202)
There is strong evidence that the gap
Indeed, practitioners have highlighted between researchers and practitioners is
that today’s software projects are an growing and that existing scholarly research
“amalgamation of various open-source on software vulnerabilities is not able to
1
Podcast available here: https://www.sans.org/webcasts/rethinking-vulnerability-management-111490/
2
Podcast, panel and study available here: https://www.sans.org/webcasts/2020-vulnerability-management-
survey-114575/
3
Article available here: https://blog.isc2.org/isc2_blog/2017/09/open-source-and-associated-risks-are-the-new-
normal.html
4
Article available here: https://medium.com/npm-inc/security-in-the-js-community-4bac032e553b
5
Article available here: https://www.cio.com/article/309185/88-of-organizations-are-still-behind-in-keeping-
open-source-updated.html
88
Livre SIM 1_2023.indb 88 22/06/2023 15:26

UNDERSTANDING AND MANAGING COMPLEX SOFTWARE VULNERABILITIES:
adequately guide developers to effectively software vulnerability (Sharma & Singh,

manage their vulnerabilities in the context 2019; Singh et al., 2017; Syed, 2020).
of ‘software as amalgam’ and open source
(Sen & Heim, 2016). A panel of senior secu- To our knowledge, there is no study that
rity experts at SANS asked the following addresses ‘how organizations are dealing
unanswered question in 2020: “what are with vulnerabilities’ in practice… Sen and
some of the more common challenges Heim (2016) also shared this view that prior
related to remediating or fixing vulnera- empirical research in IS mostly focused
bilities and how are organizations deal- on the consequences and exploitation of
ing with these challenges?”2. The experts vulnerabilities (streams 1 and 2), whether
renewed a call for more industry research from open or closed sources, rather than
on vulnerability management. guiding practitioners in managing their
vulnerabilities. What is missing in the litera-
Likewise, academic research on infor- ture is a detailed and rich case description of
mation systems is insufficiently precise to ‘how’ to manage vulnerabilities. Moreover,
resolve the problem faced by practitioners. efficient management of vulnerabilities
Indeed, prior research in IS management may require the management of multiple
focused on (1) ‘what to do once a vulne- experts’ knowledge dependencies, i.e.,
rability is found’. This research stream knowledge coordination (Schutz et al.,
investigated business models related to 2009)… and setting a process aimed at facili-
vulnerabilities (Kannan & Telang, 2005), tating the transfer, absorption and utilization
market-based incentives for discovering of knowledge within this OSOS network,
and reporting private and open-source i.e., knowledge mobilization (Dhanaraj &
vulnerabilities (Ransbotham et al., 2012), Parkhe, 2006).
and the role of intermediaries in disclo-
sure (Li & Rao, 2007). Another research Our case responds to practitioners’ calls
stream in IS investigated (2) ‘what are the for more research on vulnerability man-
consequences of published vulnerabilities’, agement with a description of effective
with research on the impact of published vulnerability management in the context of
vulnerabilities on firm stock prices (Telang & an open-source operating system (OSOS).
Wattal, 2007), software disclosure behaviors Hence, our paper is aimed at bridging
and the risks related to the publication of this gap with practice and discussing this
vulnerabilities (Arora et al., 2006; Sen & overlooked concern in the academic lite-
Heim, 2016). A stream at the boundaries rature: how do organizations effec-
of IS and computer science also explored tively manage their vulnerabilities?
“what kind of vulnerabilities are patched the We provide an empirical contribution with
most”, with research on software vendors an extreme case of vulnerability manage-
patching decisions depending on the impact ment in a large OSOS (Debian), uncovering
on confidentiality, integrity, and availability complex behavioral dynamics and practices
(Temizkan et al., 2012), policies for patching related to knowledge mobilization and
and disclosure depending on vulnerability coordination that foster responsiveness and
severity (Arora, Krishnan, et al., 2010). A adaptation in vulnerability management.
rich literature in IS and computer science
addressed (4) “what is a vulnerability”, with OSOS as a context for the investigation
numerous operationalizations, measure- of vulnerability management is relevant for
ments and ontological representations of IS research for several reasons. First, OSOS
89
Livre SIM 1_2023.indb 89 22/06/2023 15:26

absolute transparency enabled us to have teams establish to manage their security

full access to source code, commit his- and software vulnerabilities. Indeed, resear-
tory, and development notes and to assess chers “still face several data problems that
the evolution of code quality over time impede the identification and explana-
(MacCormack et al., 2006). Second, OSOS tion of differences in software security”
are uniquely positioned in the software (Gillies, 2011). Current theories and fin-
ecosystem at the boundaries of thousands dings have not sufficiently explained this
of subsystems and software components, phenomenon. Therefore, there is a need
with multiple contributors and software pac- for more mixed-method approaches in IS
kages that may be vulnerable (Dinh-Trong security research, combining the insights
& Bieman, 2005; Singh et al., 2017). As a from quantitative and qualitative analysis
result, OSOS represents an extreme case to explore emerging behaviors that are
for investigating vulnerability management currently unexplained (Schryen, 2011).
in a complex context (Benkeltoum, 2016).
Last, the responsiveness and efficiency of We combine different data collection
OSOS developers in fixing security vulnera- methods and analysis: a quantitative assess-
bilities has been explored in IS and software ment of Debian’s track changes archives
engineering literature (Fitzgerald, 2006; for vulnerabilities that were detected and
Midha & Bhattacherjee, 2012; Sharma & fixed, triangulated with archive and docu-
Singh, 2019), and they are better able “to mentation analysis, qualitative interviews
adapt to specialized security requirements” with the Debian team, and observation
than closed source software development of exchanges and coordination practices.
teams (Payne, 2002). Few empirical data
influenced the antecedents of the unique The next section develops our literature
capabilities enacted by OSOS teams concer- review and the theoretical background
ning information security issues and their of our research, while section 3 explains
management (Di Tullio & Staples, 2013). the research design (data collection and
methodology). Section 4 presents our
This research adopts a mixed-method results, beginning with the quantitative
approach to investigate vulnerability mana- investigation and following with our quali-
gement in a large open-source operating tative assessment. In section 5, we discuss
system named Debian. We were interested our contribution to research and practice
in OSOS teams’ coordinating behaviors and conclude with observations on the
regarding information security and vulne- limitations of our research and avenues for
rability management. Combining different future research.
methodological approaches is particularly
relevant in the context of our study of OSOS
vulnerability management. Indeed, current
research methods have uniquely focused
on the quantitative analysis of OSOS track
change archives (Schryen & Kadura, 2009;
Sen & Borle, 2015). While the quantitative
method has led to significant advancement
of our understanding of OSOS responsive-
ness in vulnerability fixing, it has failed to
improve our understanding of the parti-
cular and complex processes that OSOS
90
Livre SIM 1_2023.indb 90 22/06/2023 15:26

2. REVIEW OF RELEVANT
A literature at the boundaries of econo-
LITERATURE mics and IS also fostered the vulnerability
market, i.e., market-based incentives for
discovering and reporting private and open-
2.1. Software vulnerabilities source vulnerabilities (Ransbotham et al.,
Research, at the Boundaries 2012). Most of the research in this stream
of Software Engineering and focused on what to do with vulnerabili-
Information Systems Research ties that were discovered (sell identified
vulnerabilities, use them, or report them
A software vulnerability is a flaw in a sys- for free to the firm?) and is the origin of
tem that can be exploited by an attacker a rich strand on the market for software
(Dempsey et al., 2020). Software vulne- vulnerabilities, where security experts (or
rabilities are increasing in complexity and hackers) sell vulnerability information to sof-
scale and can have devastating impacts on tware vendors and companies. Researchers
the confidentiality, integrity, and availability have investigated business models related
of information systems (Le et al., 2022). to vulnerabilities (Kannan & Telang, 2005),
how hackers marketplaces may sell or use
Software vulnerabilities are frightening, vulnerabilities (Richet, 2022), the role of
and as a result, there are countless papers intermediaries in disclosure (Li & Rao,
in management and IS on the impacts 2007), the performance of the market for
and consequences of vulnerabilities. software vulnerabilities and how to retain
This stream of research has been highly participating security experts providing
popular in multiple subfields of manage- the most valuable vulnerabilities (Zhao et
ment science, from marketing to finance al., 2017).
to information systems. Public (and man-
datory) disclosure of vulnerabilities leads A stream at the boundaries of IS and
to increased threats to information systems computer science also explored what
and increased chances of data breaches kind of vulnerabilities are patched, by
and leaks (Arora et al., 2006; Sen & Heim, whom and in which conditions. Research
2016). Researchers have explored the has explored, for instance, the types of
impact of published vulnerabilities and patches deployed by software vendors,
subsequent data breaches on customer how vulnerability disclosure provides an
spending behaviors (Janakiraman et al., incentive for vendors to more quickly
2018). In particular, Martin et al. (2017) secure their product if they do not suffi-
explored customer data vulnerability and ciently internalize user losses (Cavusoglu
its impact on customers’ trust and feelings et al., 2008) and how software vendors’
of betrayal, which led in their case to a patching decisions depend on the impact
positive spillover effect toward rival firms. on confidentiality, integrity, and availability
Public vulnerabilities are damaging events (Temizkan et al., 2012). Arora, Krishnan
for firms, with impacts on customer trust et al. (2010), for instance, investigated
regardless of whether customer data were software vendors’ responsiveness to vulne-
subsequently misused (Fisher, 2012; Martin rability information disclosure and assessed
et al., 2017). Extant research has generally their policies for patching depending on
shown that published vulnerabilities lead vulnerability severity. Researchers have
to negative abnormal stock returns for investigated the impact of competition
firms (Malhotra & Kubowicz Malhotra, 2011; on software publishers’ patching behavior
Telang & Wattal, 2007). (Arora, Forman, et al., 2010).
91
Livre SIM 1_2023.indb 91 22/06/2023 15:26

A rich literature in IS and computer and shared rules of understanding (Di Tullio
science responded to what is a vulnera- & Staples, 2013). OSOS development needs
bility, with numerous operationalizations, “continuous commitment of developers”
measurements and ontological represen- (Fenton & Bieman, 2019). Open-source
tations of software vulnerability (Sharma software management has been considered
& Singh, 2019; Singh et al., 2017; Syed, less formal, leveraging informal leadership
2020). Such research describes bugs and (Fitzgerald, 2006) and distributed and bot-
vulnerabilities at the root of uncertainty and tom-up forms of management (Capra et al.,
entropy (Singh et al., 2017), which focuses 2008), such as in the OSOS Debian, where
mainly on the classification of vulnerabili- the “doer decides” (Tille, 2007). However,
ties (Aslam, 1995; Tsipenyuk et al., 2005) OSOS must also manage external pressures
or the classification of threats (Fachkha & and relationships with third parties (De Laat,
Debbabi, 2016; Koch et al., 2014). 2007): complex relationships can emerge
with hardware manufacturers in the context
Prior research in IS has mostly focused of security and vulnerability management
on the consequences and exploitation of (Prout et al., 2018). OSOS require distri-
vulnerabilities rather than guiding practi- buted control and loose forms of coordina-
tioners in managing their vulnerabilities tion and are noted for having complex forms
(Sen & Heim, 2016). Hence, our paper is of governance, such as blended democratic
aimed at bridging this gap with practice and and bureaucratic governance mechanisms
discussing this overlooked concern in the (Shaikh & Henfridsson, 2017).
academic literature: how do organizations
effectively manage their vulnerabilities? OSOS development is considered a com-
plex activity: it involves multiple program-
Our case responds to practitioners’ calls mers, multiple pieces of code embedded
for more research on vulnerability man- to form software, and multiple errors and
agement with a description of effective vulnerabilities introduced during multi-
vulnerability management, focusing on ple steps of the software development life
the knowledge behaviors of internal secu- cycle (Fenton & Bieman, 2019; Shin et al.,
rity professionals and in the context of a 2010). Open-source projects’ organiza-
complex OSOS. tional structures enable distributed team
members to dive through structural com-
plexity (Benkeltoum, 2013; Nan & Kumar,
2.2. Open-Source Operating
2013). Indeed, the networked approach
Systems as Complex of OSOS (Temizkan & Kumar, 2015) relies
Development Activities on a diverse set of experts to achieve orga-
nizational learning and cope with certain
What is specific to OSOS development aspects of software complexity (Au et al.,
(in contrast with closed-source operating 2009; Stewart & Gosain, 2006).
systems) is that anyone can contribute to
the code and become a member of the A seminal paper from Nizovtsev & Thursby
community. As a result, OSOS code is clearly (2007) is among the few studies to highlight
documented and embeds a transparent and the specific case of OSOS vulnerability
documented history of code modifications management. The authors demonstrate
(commits). OSOS development is based on that the positive effect of vulnerability
mechanisms of membership, reputation, disclosure on software quality becomes
92
Livre SIM 1_2023.indb 92 22/06/2023 15:26

greater when users (open-source develo- security process and countermeasures are
pers) are actively involved in finding and overlooked and coined as the ‘diffusion of
fixing software vulnerabilities (rather than countermeasures’ (p.6). In their seminal
just the software vendor). In this context, paper, Ransbotham et al. (2012) focus more
knowledge coordination in OSOS vulnera- on the attack process than on the security
bility management is based on the idea that process. The latter is based on interaction,
distributed teams of experts and users can collaboration and exchange with third par-
effectively collaborate and learn from each ties and stakeholders (Ransbotham et al.,
other. This knowledge coordination enables 2012); it enables the discovery of vulnerabi-
the community to quickly identify potential lities and the development of countermea-
security vulnerabilities, coordinate fixes and sures and software artifacts such as patches.
disseminate knowledge about the latest However, both discovery processes and
security best practices. The open-source collaborative creation of patches seem loo-
development model facilitates the flow sely coupled to the concept of knowledge.
of information among different stakehol- Although the focus of information security
ders to ensure the security of the software research has been on threats, there is a need
and its users. Users report issues to the to explore how these collaborative efforts
development team, who then use their in creating knowledge artifacts such as
expertise to fix the problem and share patches can be improved to gain increased
the knowledge with the community. The software security. Hence, our conceptual
process of knowledge mobilization and framework focuses on how knowledge is
coordination is key to ensuring that the mobilized and coordinated in the context of
software is secure and up to date. this overlooked vulnerability management.
Notably, individuals are already colla-

2.3. Collaboration and the
borating online to address problems, uti-
Sharing of Knowledge in the lizing any tools available to coordinate,
Discovery of Vulnerabilities develop their knowledge, and advance
their social identity (Becerra-Fernandez &
Lappas et al. (2016) performed a vulne- Leidner, 2008). Through online exchanges,
rability assessment related to the threat of individuals are seeking answers to their
fake reviews. The authors measured how information security interrogations and
attacks influence the visibility of hotels risk assessments or provide answers to
in platform ranking and highlighted the others (Wasko & Faraj, 2005). The main
importance of defense mechanisms as part focus of collaboration is the sharing of
of their «vulnerability perspective» (p.941). knowledge: what knowledge to share and
However, the authors do not describe with what knowledge to obtain. Much of the
further details how they conceptualized research and theorizing on knowledge
these internal defense mechanisms and collaboration is geared toward promoting
coordination behaviors between focus firms knowledge sharing (Becerra-Fernandez
and the platform. Ransbotham et al. (2012) & Leidner, 2008). By the application of
also assessed attack processes and the effi- theories such as social exchange and social
ciency of vulnerability management through capital, we have gained insight into the fac-
market mechanisms. While the authors tors that shape knowledge sharing in organi-
conceptualized the diffusion of attacks zational contexts (Mouakhar & Benkeltoum,
via the prism of innovation diffusion, the 2020; Wasko & Faraj, 2005). Nevertheless,
93
Livre SIM 1_2023.indb 93 22/06/2023 15:26

we do not know what sequences of beha- The coordination of knowledge is the

viors in an online interaction are likely management of dependencies of team
to lead to knowledge collaboration out- members’ expertise (Schutz et al., 2009)
comes in extreme situations. Indeed, in and the extent to which stakeholders leve-
the context of crisis related to the disclo- rage and integrate their various areas of
sure of critical vulnerabilities, individuals expertise to create knowledge artifacts
mobilize and coordinate knowledge with (patch, countermeasures, security pro-
time constraints, peer pressure and scarce cesses, etc.). To effectively coordinate
resources. knowledge, one must know where it is
located, where it is needed, and how to
To address this issue, we propose two deliver it (Faraj & Sproull, 2000; Lancini &
closely related knowledge activities as a Sampieri-Teissier, 2012). With an increase
solution: Knowledge Mobilization and in OSOS developers and potential threats,
Knowledge Coordination. the requisite knowledge diversity neces-
sary to cope with increased vulnerabi-
lities may exponentially increase. This
2.4. Knowledge Mobilization &
increase may create a situation in which
Coordination in Vulnerability the common cognitive schema is too weak
Management to properly integrate knowledge (Carton &
Farastier, 2012; Dhanaraj & Parkhe, 2006)
We defined knowledge mobilization as Ko et al., 2005, Haines et Goodhue, 2003.
a process aimed at facilitating the transfer, Simultaneously, the diversity and heteroge-
absorption and utilization of knowledge neity of online exchange systems and the
within a network of stakeholders (Dhanaraj context of crises related to vulnerability
& Parkhe, 2006). By dispersing knowledge management can render the coordination
throughout the network and providing of heterogeneous knowledge increasingly
knowledge access to a requisite variety difficult (Yoo et al., 2010). Therefore, an
of actors, new knowledge artifacts such efficient knowledge integration system is
as patches and new countermeasures are necessary to maximize the OSOS develo-
generated. As knowledge is shared within pers’ contributions from a large variety
the network of stakeholders, the collec- of knowledge bases (Rashid et al., 2019).
tive learning effect expands, encouraging
synergy among stakeholders (Kozlowski This paper intends to provide an empi-
& Klein, 2000; Okhuysen & Eisenhardt, rical contribution with an extreme case of
2002). Online exchanges (e-mails, forum vulnerability management in a large OSOS
boards, centralized instant messaging sys- (Debian). Behavioral dynamics and prac-
tems, social platforms such as Discord, tices related to knowledge mobilization
etc.) may act as a form of memory, allowing and coordination are uncovered. The latter
knowledge to freely and rapidly flow across fosters responsiveness and adaptation in
mediums and enhancing the distribution of vulnerability management, highlighting
knowledge during this process (Yoo et al., its complexity and dynamics. We rejoin a
2010). Ultimately, the success of OSOS secu- strand of critical research highlighting the
rity communities in assimilating and using blurred lines of the concept of vulnerabi-
knowledge may depend on their ability to lity management (Fenz & Ekelhart, 2009;
sense vulnerability trends, pinpointing the Rescorla, 2005).
desired knowledge from many available
options.
94
Livre SIM 1_2023.indb 94 22/06/2023 15:26

3. RESEARCH METHODOLOGY
assessed vulnerability management prac-
tices through qualitative inquiry (interviews
and archives). We selected Debian based
3.1. Mixed-Method Approach on the wealth of open documentation and
research available on the system (Aberdour,
Our research is based on a mixed-me- 2007). Debian has already been explored
thod approach to investigate vulnerability in the IS and management literature in the
management processes in Debian, a large fields of knowledge management (Rashid
OSOS. Mixed-method research concur- et al., 2019), IT governance (Shaikh &
rently or sequentially uses quantitative and Henfridsson, 2017), and the economics of
qualitative methods to develop a deep IS (Mateos-Garcia & Steinmueller, 2008).
understanding of a phenomenon (Pascal et Our empirical research is aimed at uncove-
al., 2018). Mixed research methods can (1) ring patterns of behavior and practices for
simultaneously address confirmatory and security vulnerability management.
exploratory research, (2) provide stronger
inference than single-method approaches,
3.2. Data Collection and Analysis
and (3) foster a greater assortment of com-
plementary views, enriching our unders-
tanding of the investigated phenomenon We combined different methods for data
(Teddlie & Tashakkori, 2011). Creswell and collection and analysis.
Clark (2007) suggested four broad types
of mixed-method designs. Our approach In the first part of our research, we col-
follows the third type of design, which is lected quantitative data in an inductive
an explanatory approach. Qualitative data approach. We undertook a quantitative
are used to explain quantitative results in assessment of Debian’s track change
a complementarity approach. We adopted archives for vulnerabilities that were
a sequential design as recommended by detected and fixed. We assessed Debian’s
Venkatesh et al. (2013, p. 37): “quantitative track change archives and Debian Security
and qualitative data collection and anal- Advisory for vulnerabilities that were iden-
yses are implemented in different phases tified and fixed between 2000 and 2019 (n
and each is integrated in a separate phase”. = 4500 items describing vulnerabilities,
Venkatesh et al. (2013, p. 38) also suggest impacted packages, update requirements,
that “if IS researchers plan to conduct a etc.). OSOS organizations are transparent
study for which a strong theoretical foun- about their correct vulnerabilities and the
dation already exists, but previous findings way they correct them—weekly or monthly
were fragmented and/or inconclusive, they reports and annual syntheses log every
may consider conducting a quantitative major event related to the OSOS. Debian’s
study first followed by a qualitative study vulnerability reports are also frequently
to offer additional insights based on the published by third parties (such as com-
context-specific findings or reasons for puter emergency response teams) that
fragmented and/or inconclusive results monitor and issue alerts about security inci-
in previous studies.” Indeed, the quanti- dents. Such reports are frequently employed
tative study was designed to explore the as a source of software engineering data
most vulnerable packages and software (Lin & Li, 2014), and we utilized them as
components in Debian, and varying vulne- part of the triangulation process for both
rabilities were identified over time. We then our qualitative data and quantitative data.
95
Livre SIM 1_2023.indb 95 22/06/2023 15:26

This quantitative and exploratory approach stakeholders, comprehend and spread

was designed to provide us with a global the ideas of others (verbally or in a written
understanding of vulnerability variation in form such as chat, e-mail, etc.), and (2)
the Debian project over the last 20 years. the ease of knowledge acceptance and
However, quantitative data were insufficient deployment: ease of acceptance, exploi-
to explain Debian’s organizational structure tation and assimilation of knowledge. For
and processes—we needed to develop a instance, whether stakeholders recognize
qualitative inquiry based on our exploratory knowledge experts, accommodate, and
quantitative research. assimilate shared knowledge resources
to increase their own knowledge base.
In the second part of our research, we
adopted a qualitative approach to exa- Knowledge coordination is the manage-
mine Debian team behaviors. We were ment of dependencies of team members’
interested in gathering qualitative data expertise in a group and, more precisely, the
on the various managerial dimensions: extent to which stakeholders leverage and
project leadership, knowledge mobilization integrate their various areas of expertise to
and coordination behaviors, decision-ma- create knowledge artifacts. We interpreted
king processes, working practices concer- knowledge coordination as an understan-
ning information security and vulnerabi- ding of each stakeholder’s expertise, inte-
lity management (Capra et al., 2008; De gration of others’ knowledge and activi-
Laat, 2007). Knowledge mobilization, the ties aimed at the development of a shared
process aimed at facilitating the transfer, knowledge artifact (Schutz et al., 2009).
absorption and utilization of knowledge For instance, whether some stakeholders
within a network of stakeholders (Dhanaraj are able to anticipate other stakeholders’
& Parkhe, 2006), was interpreted as (1) diversity of responses, coordinate these
the ease of knowledge transfer: ease of responses to deliver them where they are
explaining, following and disseminating needed, and integrate them in a common
ideas, for instance, whether stakeholders and shared knowledge project (patch, coun-
are able to articulate an issue to other termeasures, security processes, etc.).
Table 1: Typology of Data Collected
Type of Data Volume and Source

Track Change archives 4500 items, from Debian’s track change archives and Debian Security Advisory.
Observation 120 exchanges directly related to vulnerability management: review of synchro-
nous and asynchronous conversations, such as emails, chat exchanges of securi-
ty experts discussing with end users, maintainers, developers, external advisors
and third parties.
Interviews 12 interviews: three interviews with Debian Developers (one junior and two
senior software engineer); two interviews with Debian Maintainers (one junior
and one senior profile); six initial interviews with members of the security team
(all experienced and senior profiles); one additional follow-up interview with a
member of the security team.
Document archives 64 documents: byelaws, charters, work plans, working group minutes and re-
port of meeting, announcements from the mailing list, news articles from the
forum, publications and reports
96
Livre SIM 1_2023.indb 96 22/06/2023 15:26

4. FINDINGS FROM OUR

We interviewed developers, security
experts and senior software engineers EMPIRICAL ANALYSIS
on the Debian team (n = 12); observed
email and chat exchanges and coordination 4.1. Context of Our Empirical
practices (n = 120); and analyzed archive
Study
and documentation (n = 64); see Table 1
for more details. This inductive perspective
is particularly adapted to examining emer- We selected Debian for our empirical
gent phenomena (Sharma & Singh, 2019). investigation mainly since Debian is a core
We conducted semi-structured interviews and long-running distribution, behind
that focused on security and vulnerabi- several other popular distributions such
lity management processes, information as Ubuntu and Linux Mint. Debian is a
asymmetries, learning management, and noncommercial GNU/Linux distribution
the coordination of security activities and that launched in 1993. Thousands of pro-
knowledge. These interviews enabled us to grammers are involved in the development
better understand developers’ interactions of this OSOS worldwide.
and interactions within the OSOS linked
to vulnerabilities. Archival data were also The most active programmers are
collected from project documentation responsible for managing one or more
(charters and byelaws), mailing list posts modules. Coordination structures are in
and internal and external online archives place to manage interactions among deve-
available on Debian Security (meeting lopers, and communications take place
notes, emails, reports, etc.), enabling us via email, chat, and conference calls. In
to triangulate our qualitative and quanti- contrast to other open-source software
tative data. projects, Debian developers are not anony-
mous—their identity is used to sign Debian
We analyzed our first findings using archives using digital signatures—but digital
open coding. We constantly compared signatures are also used for organizational
our emergent categories (Urquhart et al., processes: voting for features, risk assess-
2010) to uncover their properties, causal ment, and decision-making events such as
relationships, similarities and differences elections. Indeed, the Debian project leader
and to identify vulnerability management is elected by their peers every year, but the
dynamics. This mixed-method approach project leader’s decision-making rights are
enabled us to develop a longitudinal limited. As a Debian developer (Interviewee
understanding of the complex vulnerabi- 5) emphasized, “Debian developers have
lity management process enacted by OSOS the freedom and ability to realize their
stakeholders (direct accounts from deve- vision […] Every developer can influ-
lopers and observations, cross-checked ence the development of Debian—he just
with track change archives and the code has to do it.” Developers make decisions
itself, and triangulated with both internal about the future of the OSOS project. The
and external reports). Debian project leader oversees the project
management process and defines, with the
community, the goals and planning of the
next release. A significant contribution to
a given domain (security, release manage-
ment, development, etc.) is a requirement
97
Livre SIM 1_2023.indb 97 22/06/2023 15:26

for being elected to a management position five years […] While there was a tremen-
in the domain (meritocracy). dous increase in public vulnerabilities, the
security team did not increase in size and
Debian’s 1,000 developers integrate more still managed to prevent important data
than 59,000 packages, enabling the OSOS breaches […] Developers and maintainers
to be customized to users’ needs with a are becoming security partners, more and
selection of subsets of these packages (edu- more involved in security operations.”
cation, health care, multimedia, etc.). As the
user Horst noted on the Debian mailing Below, we discuss the preliminary findings
list in a 2002 post archive, Debian focuses of our exploratory quantitative analysis.
on a “unique distribution” rather than
forking—if forked, it would be “nearly
4.2. Quantitative Exploration:
impossible to get security fixes as fast as
Debian”. The unique distribution enables Assessing the Evolution of
better “Bug Tracking […] Secure and stable Debian’s Vulnerabilities
system”. Interviewee 11 told us, “Releasing
a new Debian distribution is a continuous We investigated the variation in vulnera-
process: the testing distribution is continu- bilities identified over time. Although the
ously tested and hardened, and when we number of vulnerabilities that were disco-
feel it’s ready, it gets derived into a new vered steadily increased between 2000 and
distribution […] there are no strict dead- 2019, its variation was not linear (Figure 1).
lines […] thus quality and security is an
ongoing process rather than a last-minute Figure 1 highlights recurring patterns in
check before release.” the evolution of vulnerabilities over time
(note: in this Figure, v. x.x represents the
Interviewee 4 explained the shift in Debian release version, e.g., v. 3.1 Debian
Debian’s security culture over the last 20 version). We found that the number of
years: “There has been a rise in security vulnerabilities falls one quarter before
awareness […] At the beginning of the launching a new Debian distribution. It is
2000s, Linux was protected from cyber- possible that developers and security teams
criminals thanks to the fact it was a niche are more focused on hardening the next
operating system. Microsoft had to quickly distribution rather than focusing on the
harden its operating system, while Linux current version’s vulnerabilities.
progressively reinforced it […] The pop-
ularity of Android, based on the Linux However, the number of vulnerabilities
Kernel, and the development of Cloud fluctuated over time. To better assess the
and Virtualization services contributed to evolution of numerous vulnerabilities, we
increase the number of Linux users and applied exponential smoothing, which is an
thus the number of attacks on the kernel empirical method of smoothing randomized
[…] This was difficult for [the] Debian time series data. Exponential smoothing
development community, attached to the gives past observations a weight that expo-
operating system stability—reinforcing OS nentially decreases with their age. Figure 2
security was considered as a disruptive represents the smoothing function applica-
move, with impacts on users.” Interviewee tion. Thereafter, we applied homogeneity
5, a Debian developer, commented, “Debian tests on the smoothing function variables.
security team did a stunning job in the last This approach was aimed at reinforcing the
98
Livre SIM 1_2023.indb 98 22/06/2023 15:26

Figure 1: Variation in the Number of Vulnerabilities Detected Between

2000 and 2019
validity of the results (applying these tests identification of a break on average in a
on a smoothing function reinforces the series. Indeed, the tests that we applied
quality of the results by reducing excessive as part of this data exploration confirmed
variations). that there is a date from which there is a
trend break. Buishand (1982)’s test and
Homogeneity tests (see Buishand, 1982; Pettitt (1979)’s test suggest that the date
Pettitt, 1979) provided insights into the corresponds to the 3rd quarter of 2005.
Figure 2: Smoothing function application
99
Livre SIM 1_2023.indb 99 22/06/2023 15:26

The third quarter of 2005, as suggested The Debian project was under construction
by both homogeneity tests, corresponds to until Debian 3.1. This step is characterized
the launch of Debian version 3.1 (Debian by the open-source project’s ability to attract
version named ‘Sarge’). new developers to keep them motivated.
Developer involvement in the Debian pro-
Up to Debian 3.1, the number of Debian ject positively influences the number of pac-
project developers, packages, and affected kages that are developed and consequently
packages are strongly correlated (Figure 3). the number of vulnerabilities detected.
Figure 3: Variation in the Number of Packages, Vulnerable Packages

and Number of Developers per Debian Release
Starting from Debian 3.1, the Debian or affected has completely changed. The
project began to mature. The number of correlation coefficient decreased from 0.99
developers involved in the Debian project before Debian 3.1 to -0.24 after Debian 3.1
seems to reach its saturation threshold for realized packages and from 0.80 before
(approximately 1,600 developers). Debian Debian 3.1 to 0.33 after Debian 3.1 for affec-
3.1 was launched on June 6, 2005, and its ted packages. Linus’ law announces, “given
support ended in March 2008. enough eyeballs, all bugs are shallow”, that
is, “Given a large enough beta-tester and
To illustrate the change that occurred from codeveloper base, almost every problem will
Debian 3.1, we calculated the Pearson corre- be characterized quickly, and the fix will be
lation coefficient before and after the release obvious to someone.” This confirmation is no
of Debian 3.1. The correlation coefficient longer tangible after the Debian 3.1 release.
between the number of packages realized The study of security team practices, which
and the number of packages affected remains have a positive impact on the management
relatively high. The correlation coefficient of vulnerabilities, is therefore necessary.
decreased from 0.84 before Debian 3.1 to
0.70 after Debian 3.1. However, the correla- Over the twenty years of the study,
tion coefficient between the number of deve- Debian’s vulnerabilities were corrected by
lopers and the number of packages realized more than 2,400 contributors from either
100
Livre SIM 1_2023.indb 100 22/06/2023 15:26

maintainer teams or single maintainers. be a research connection between them.

Most of the vulnerabilities are corrected IT developers or secondary school teachers
by 25 groups of maintainers. If we dis- were also involved in the project.
regard the teams of maintainers for pac-
kages specific to programming languages To better understand the role of main-
such as Perl, Python, or Java, four teams tainer teams, it is essential to provide fur-
are particularly involved in fixing vulne- ther details on the evolution of interac-
rabilities: Debian Quality Assurance (QA) tions between the security team and other
Group, Debian Science Maintainers, Debian stakeholders in the vulnerability mana-
Med Maintainers, and Debian Multimedia gement process. Then, we highlight the
Maintainers. communication and learning processes at
work in Debian concerning vulnerability
The Debian Quality Assurance (QA) management.
Group tries to improve the distribution as
a whole, not only a specific set of packages.
4.3. Debian Stakeholders’
This group not only serves as a central
Interaction Dynamics in the
place for discussion about distribution-wide
problems and improvements regarding qua- Management of Vulnerabilities
lity but also ensures coordination of mass
bug filings and transitions and tracking of Figure 4 showcases the outcomes of our
maintainers Missing In Action (MIA). The qualitative assessment of Debian stakehol-
Debian QA group constantly runs systematic ders’ interaction dynamics in developing
checks on the entire archive and publicly and maintaining software components and
publishes their results. managing vulnerabilities. Figure 4 highlights
the necessary internal interaction dynamics
Sub-versions of Debian (such as Debian that enable vulnerability management pro-
Science, Debian Med and Debian Multimedia cesses at Debian. The Debian security team
projects, which are aimed at general science, plays an important role in this process, as
medicine or video editing communities) it coordinates knowledge from multiple
have their own teams of maintainers that internal stakeholders (maintenance mana-
also contribute to improving Debian as a gers, developers, stable release managers,
whole (all extras software and packages they etc.) toward the release of a knowledge
offer will either become part of Debian or artifact (patch).
are temporary workarounds to solve a need
of the target group that cannot be solved There are 11 contributors to the core
within Debian yet). This finding explains Debian security team. However, others
why Debian is popular for applications in are also involved, including Debian develo-
medicine or for scientific research. pers, Debian maintainers (maintainers work
on uploaded packages and are allowed to
Of these specific teams, individual aca- upload specific packages), computer emer-
demic researchers accounted for most of gency response teams (CERT) that advise
the vulnerabilities that were corrected. on emerging vulnerabilities, and external
Table 2 presents the profiles of 9 of these security researchers. While the core secu-
individual maintainers. The researchers rity team is “in charge of handling secu-
are geographically dispersed across several rity, issuing Debian security advisory and
continents, and there does not appear to hardening security of packages” (Debian
101
Livre SIM 1_2023.indb 101 22/06/2023 15:26

Table 2: Profiles of the 9 maintainers most involved in the Debian project

Maintainer Number of Position held Employer Country
vulnerabilities
resolved
Laszlo 352 Head of the Institute of Alpen-Adria University Austria
Boszormenyi Information Technology
and of the Research
Group Distributed
Multimedia Systems),
full professor
Mattias Ellert 311 Researcher in the De- Uppsala University Sweden
partment of Physics and
Astronomy, High Energy
Physics
Matthias Klose 278 Researcher Technische Universität Germany
Berlin
Alastair Mckinstry 217 Researcher Irish Centre for Ireland
High-End Computing
(ICHEC)
Dirk Eddelbuettel 202 Researcher University of Illinois United States
Urbana-Champaign
Sandro Tosi 177 Software Engineer Bloomberg LP United States
Alexander 165 Engineer JSC Zagorskaya Russia
Pozdnyakov GAES-2
Sebastian 155 Dipl.-Inf. (Research Technology University Germany
Humenda assistant) of Dresden
Samuel Thibault 149 Full professor University of Bor- France
deaux
Figure 4: Outcome of our empirical analysis: knowledge mobilization

and coordination in vulnerability management
102
Livre SIM 1_2023.indb 102 22/06/2023 15:26

archives), it is not in charge of infrastructure The security team particularly relies on

security (managed by Debian system admi- IRC chat for knowledge mobilization purpo-
nistrators) or developer account security ses: exchanges about vulnerabilities within
(managed by Debian account managers). the team and between the team and other
developers. “In Debian teams, we solve
issues together; and if a decision has to
4.3.1. Knowledge mobilization
be taken, we take it together” (Interviewee
positively influences the 5). External information exchanges follow a
management of vulnerabilities process, with public announcements publi-
From a Debian developer’s point of view, shed on the Debian security announce-
software vulnerability is an “unexpected ment mailing list and Debian’s website,
behavior that is dangerous for users or while blog posting is directly performed
the system” (Interviewee 8). According by security team members and the security
to Interviewee 2, vulnerabilities in the community at Debian. Forum boards are
context of Debian impact confidentiality used both for information and knowledge
and integrity more frequently than data exchanges: “users often joke around and
availability: a vulnerability could lead to make sarcastic comments. However, they
exposing users’ data, unauthorized access always keep the main issue in focus and
to confidential data, or privilege escalation. usually offer helpful advice […] Debian
The security team plays a critical role in community isn’t made up of users who
facilitating the transfer, absorption and are dependent on answers from gurus.
utilization of knowledge related to vulne- Instead, everyone is encouraged to join in
rability management within Debian (Figure and help out. People like to demonstrate
4 in Section 4.3). their knowledge, and if it benefits others,
even better. Additionally, keeping up with
The 11 members of the core security team community discussions and contribut-
are located throughout the world (France, ing advice can be a great way to learn”
Germany, the U.S., and elsewhere). This vir- (internal document describing knowledge
tual team is organized with a front desk (the channel at Debian).
first point of contact for reporting security
vulnerability). The team was set up to ease Notably, knowledge is not mobilized by
internal and external communications, but security teams as part of a formal process,
it also enables the transfer of information nor is it explicitly defined. It is rather “cap-
on trending vulnerabilities. italized daily by security team members
[…] Debian is a do-ocracy, so if you want
The security team can also be securely to pursue your role and tasks and still be
contacted via a dedicated email address, engaged in Debian’s security, you have to
which enables external users to alert on a learn every day” (Interviewee 3). This claim
security issue. While an internal archive from was corroborated by a 2015 handbook distri-
2005 noted that “if the general [Debian] buted to Debian developers that stated that
archives were used more rigorously as a Debian authority, focused on competence
knowledge resource, it would cut the vol- and learning, is “the reign of knowledge”.
ume of traffic on the Debian lists by half ”,
the security archive has been indexed and New security team members are coached
well utilized as a knowledge base by the and supported (peer-review) and, most
security team since its creation in 2008. importantly, trained on the working
103
Livre SIM 1_2023.indb 103 22/06/2023 15:26

behavior of the security team: “trained end of 2017. On January 3, 2018, Google
on efficient learning […] trained on the Project Zero published a report revealing
process of identifying new vulnerabilities, the attack process. Detailed attack vectors
on the security team know-how but also were identified the same day by the Debian
on soft skills such as coordinating capa- security team: “2018/01/03 – [4:56:46 pm]
bilities” “I learned rigor […] and honed (User X): but I keep thinking an arbitrary
my coordination skills” (Interviewee 7). read wouldn’t lead to that level of panic”
(archival data, security team IRC chat),
The practice of “lessons learned” and a fix was released on January 4, 2018.
(Interviewee 3) and postmortem docu- However, the security team had largely
mentation is common: at the end of a collected data months before this disclo-
vulnerability resolution, team members sure “from the rumor mill” to be ready to
analyze their own practice to adapt more respond to the potential disclosure.
easily and absorb shared knowledge to
expand their own understanding. “Errors Security team members “learned to ana-
are acknowledged and discussed, hon- lyze and interpret weak signals […] They
estly and without filter […] we only aim are reactive on a lot of external informa-
to make Debian better” (Interviewee 7). tion sources […] It has become part of
Such lessons are learned through email [their] daily life” (Interviewee 10).
exchanges, informal IRC chat, or annual
physical meetings among the security team In the next section, we provide further
members. More formal lessons learned are details on the specific knowledge coordi-
organized for large crises involving multiple nation behaviors enacted by security teams.
external contributors (such as the 2014
Heartbleed vulnerability or 2018 Spectre
4.3.2. Managing vulnerabilities
and Meltdown vulnerabilities). “we have
a just culture, where mistakes are seen as related to external packages
a way to learn and make our processes requires specific forms of
better […] mistakes shouldn’t be viewed as knowledge coordination
shameful - they should be seen as a chance According to one of our interviewees
to learn and get better” (interviewee 6). (Interviewee 2), a long-running member
These practices create an environment of the security team and a Debian package
that is conducive to knowledge transfer maintainer, the security team has several
and absorption. “watch dut[ies]” with “formalized work-
flows for vulnerability” but “not really
The security team adopts vulnerability formalized modes of coordination between
sensing behaviors, documenting for them- developers, security and maintainers.”
selves potential vulnerabilities that could Authority is laterally distributed, while
impact the OSOS. The team follows a large knowledge coordination and decision-ma-
variety of expert resources to better exploit king about vulnerability management are
knowledge on emerging vulnerabilities. For “not formally done.”
example, Meltdown and Spectre vulnerabili-
ties (which impact Intel Central Processing However, in the absence of formal lea-
Unit and enable hackers to read data that dership, knowledge coordination is achie-
are normally not accessible at their usual ved through consensus on the severity of
level) were first rumored on Twitter at the vulnerability.
104
Livre SIM 1_2023.indb 104 22/06/2023 15:26

Indeed, a Debian security team pre- censoring public information, or restraining

sentation mentions three major types of knowledge mobilization related to this
vulnerabilities managed by the security vulnerability. If this situation happens, the
team: “public vulnerabilities, simple pri- Debian security team may be informed of
vate vulnerabilities, and complex private the vulnerability ahead of its public disclo-
vulnerabilities.” Public vulnerabilities are sure. However, the Debian security team
related to public bugs or commit, with has no right either to communicate the
known fixes, while simple private vulne- vulnerability (if it is related to an external
rabilities are related to a single Debian contributor, such as Intel, Microsoft, or a
package or code base—neither necessarily security researcher) or to keep it confiden-
involves large-scale coordination or deep tial after the vulnerability official disclosure
involvement of the security team (patches (if it is a vulnerability related to the Linux
are integrated in Debian as soon as possible, kernel or Debian components). While an
and as Interviewee 2 stated, managing speci- embargo restrains the spread of information
fic vulnerabilities is “rather a loose form of related to a vulnerability (thus reducing
coordination, with greater autonomy allo- mobilization), it is also aimed at enabling
cated to developers”). Conversely, complex impacted selected developers to coordinate
private vulnerabilities require significant and integrate current knowledge into a
knowledge coordination, investigation, and knowledge artifact (a patch), test it, and plan
correction time. Security team members a global deployment for the moment when
define complexity as vulnerabilities that the vulnerability will be officially disclosed.
impact “multiple codebases, with multiple
vendors, related to protocol vulnerability This was the case, for example, with the
or hardware vulnerability” (Interviewee APT vulnerability CVE-2019-3462 related
4), which will require correction at the to a vulnerable HTTP transport method,
hardware, firmware and OS layers, thus which involved external resources (HTTP
leveraging and integrating the expertise of experts) as it impacted multiple Linux dis-
multiple stakeholders. The vulnerabilities tributions. The external security researcher
of external packages fall into this category, who discovered the vulnerability warned
as they imply multiple development teams’ the open-source security community about
involvement and impact several code bases. potential remote code injection. As one
The resolution of complex vulnerabilities of the security team members recounts,
requires internal coordination with Debian the Debian team was informed on Friday,
maintainers and developers—an ad hoc January 18, 2019, and the team decided
internal team is created depending on the to embargo the vulnerability until the fol-
vulnerability (Wi-Fi protocol, Linux kernel, lowing Tuesday. The Debian maintainer
etc.). As part of this coordination process, quickly identified the patch; the security
external contributors such as penetration team coordinated the test over the weekend
testers (pentesters), security researchers, (test cases, integration, and regression tes-
partners, hardware and firmware developers ting); and the vulnerability was published
are also consulted to develop a patch taking on Tuesday, January 22, 2019.
into account all their insights.
Vulnerabilities are managed and inte-
Debian maintainers or an external contri- grated into knowledge artifacts by a security
butor can embargo complex vulnerabilities tracker maintained by the Debian secu-
related to external packages, temporarily rity team: “the tracker aggregates public
105
Livre SIM 1_2023.indb 105 22/06/2023 15:26

vulnerabilities from CVE [note: the aim different security footprints [and] may
of the CVE Program is to identify, define, involve multiple external developers and
and catalog publicly disclosed cybersecu- complex code bases.” These differences
rity vulnerabilities], and it’s also fed by a affect the way Debian teams assess and
public Git [repository] A private reposi- manage vulnerabilities related to external
tory enables the security team to manage packages.
embargoed vulnerabilities” (Interviewee
11). This security tracker enables knowl- Interviewee 6 also commented on a pro-
edge accumulation and sensing behaviors, cess specific to the OSOS that influences
as explained by one of the security team vulnerability management: security teams’
members: “This automated script connects practices of leveraging the knowledge of
daily to the MITRE [note: the organiza- users. Indeed, “Debian users are lead users
tion managing the CVE Program], to other […] they are experienced […] they will
Linux distribution announcements, and report if they run into a crash and can
public sources […] to ease the data col- help debug if they can […] Lead users
lection process […] we then triangulate have proficiency to check and help correct
with other private sources to see whether security vulnerabilities […] They act as
these announced vulnerabilities could be a network of informants.” This finding is
relevant for Debian.” further reinforced by Debian’s philosophy
of do-ers, encouraging users to participate
Another form of knowledge integra- in the release of a more secure distribution:
tion relates to hardening practices. As “We release a new distribution when it’s
highlighted by Interviewee 12, while the ready, contrary to a commercial company
number of developers and the platform’s pressured by time to market […] Everyone
user base increased, the security team works on improving code quality because
also evolved to automate the toolchain they want to, and they do it for fun, with
and harden Linux core components and no manager […] We follow what we are
internal packages: “the practice of fuzz- interested in […] passion fuels quality.”
ing [note: a software testing technique]
gained in popularity […] and internal This particular relationship and this prac-
packages were rewritten in more secure tice enable the security team to integrate
languages.” Knowledge about static and early users’ knowledge aimed at reinforcing
dynamic application security testing and the quality and security of the final release
hardening techniques were shared and (collaborating on the shared knowledge
integrated in Debian knowledge bases. artifact).
Evolving security tools were continuously
promoted on the Debian mailing list and
within the team. Interviewee 12 commented 5. DISCUSSION
on the differences between internal pac- AND CONCLUSION
kages and external packages: “Experts and
experienced developers develop Debian-
specific tools. The average Debian devel- 5.1. Summary of our findings
oper is better than the average employed
developers […] thus it’s not surprising This paper investigates the emergence of
that they showcase fewer vulnerabilities adaptive learning and vulnerability mana-
[…] conversely, external packages have gement in the context of the OSOS. The
106
Livre SIM 1_2023.indb 106 22/06/2023 15:26

first part of our research explored varia- specific knowledge accumulation processes
tions in vulnerabilities at Debian. As part with regard to vulnerabilities: training and
of our quantitative inquiry, we explored lessons learned as a way for security team
vulnerabilities in the Debian project. The members to review their own practices
quantitative study was designed to assess (1) to adapt more easily and accumulate the
the most vulnerable packages and software shared knowledge to broaden their own
components in Debian and (2) variations knowledge and hardening practices as a
in vulnerabilities identified over time. We way to integrate security knowledge into a
discovered that before 2005 and Debian 3.1, shared and common knowledge artifact. In
the project was more unstable. Variations in the years following Debian 3.1 (2005), the
the number of vulnerabilities were related development and security team reached
to the number of developers involved in a certain form of maturity with regard to
the Debian project, suggesting an imma- vulnerability management, which is show-
ture aggregation of resources generating cased in the quantitative exploration (post-
vulnerabilities. Afterward, the volume of Sarge era).
vulnerabilities stabilized with improving
security practices. We also observed vulnerability sensing
behaviors within the security team to pick
Our mixed-method approach provided up weak signals through social networks,
us with a holistic view of a fragmented triangulated with multiple information
phenomenon. Indeed, our qualitative sources on emerging vulnerabilities. This
research was a way to describe and forma- process was required as part of knowledge
lize interactions between developers and mobilization, both as a way to follow new
members of the security team concerning knowledge and as a way to distribute it
the way vulnerabilities were managed at (Yoo et al., 2010).
Debian (lateral information-sharing and
external communication). In particular, Most importantly, Debian’s culture (error
we showcased specific forms of knowledge is possible; knowledge is the foundation for
mobilization and knowledge coordination authority) positively influenced the resolu-
for complex private vulnerabilities related tion of vulnerabilities, as the involvement
to external packages. What the Debian team of end users and developers was consi-
developed is a specific vocabulary to term dered an important asset by the security
problem-solving challenges and increasing team. Debian lead users can report and
coordination required to patch a vulnera- debug security issues and vulnerabilities,
bility, where complex vulnerabilities are contributing to security team efforts and
related to the highest level of interdepen- cocreating knowledge artifacts (Rashid et
dencies. Resolution of complex vulnerabili- al., 2019; Schutz et al., 2009).
ties required the efficient transfer, absorp-
tion, and utilization of knowledge, as well
5.2. Scholarly Contribution
as internal knowledge coordination with
Debian maintainers and developers—crea-
ting ad hoc internal teams—and knowledge Our preliminary findings are consistent
integration from external contributors. This with previous research showcasing com-
specific form of knowledge coordination plex forms of management, such as blended
involves the practice of vulnerability embar- democratic and bureaucratic governance
goes to enable developers to build, test and mechanisms (Shaikh & Henfridsson, 2017),
deploy in an agile way. We also highlighted and the strong influence of information
107
Livre SIM 1_2023.indb 107 22/06/2023 15:26

and knowledge flows (Cheruy et al., 2017). local teams for increased responsiveness
Leadership positions have associated and problem solving).
rights, but leaders defer to the commu-
nity. Simultaneously, loose forms of coor- Notably, the current literature has only
dination related to knowledge coexist sketched the boundaries of vulnerability
with tight and formalized control mecha- management in OSOS (Benkeltoum, 2016;
nisms such as workflows. For instance, Schryen, 2011). We obtained evidence of
the Debian security front desk (the first specific knowledge orchestration processes
point of contact for reporting security (Dhanaraj & Parkhe, 2006) concerning
vulnerability) follows a strict procedure vulnerability management, particularly the
for knowledge mobilization: the procedure complexity of qualifying vulnerabilities, and
stipulates that the security front desk can multiple and diverse distributed interactions
act as a knowledge gatekeeper if needed, of internal and external development teams,
preventing knowledge flows in the context including OSOS security teams and third
of embargoed vulnerabilities. Decision- parties (vendors, computer emergency res-
making structures necessary for global ponse teams, and hardware manufacturers).
OSOS management are formally in place. However, the current literature has focused
Given that decision-making is distributed, on a very static perspective on vulnerabilities
local teams (e.g., the security team) are related to fixed threats and causes (Singh
given a margin of actions and autonomy for et al., 2017). The conceptual framework of
informal decision-making processes. These Ransbotham et al. (2012) on the pathways
teams are able to mobilize knowledge from to vulnerability disclosure focused on the
a large variety of resources and transfer ‘discovery’ of threats to analyze disclosure
and share it within the network of Debian behaviors (immediate disclosure, nonpublic
stakeholders, encouraging synergy among disclosure, and market disclosure from
developers and progressively building com- external security professionals); howe-
mon knowledge on OSOS vulnerabilities ver, the process leading to vulnerability
(Okhuysen & Eisenhardt, 2002). Due to patching was overlooked. There is a need to
that freedom and autonomy in terms of explore how collaborative efforts in creating
cognitive schemas, security teams are also knowledge artifacts such as patches can be
able to efficiently coordinate a requisite improved for increased software security.
variety of stakeholders to properly inte- In this research, we present a pathway to
grate vulnerability knowledge and manage vulnerability management, focusing on the
these vulnerabilities (Carton & Farastier, knowledge mobilization and coordination
2012; Dhanaraj & Parkhe, 2006) Ko et al., behaviors of internal security professionals,
2005, Haines et Goodhue, 2003. that develop, emerge and evolve over time
toward collective learning (Kozlowski &
Proposition 1: OSOS are complex soft- Klein, 2000; Okhuysen & Eisenhardt, 2002).
ware, that showcase simultaneous forms Our paper uncovers vulnerability dynamics
of tight coupling (reporting on goals, for- and the need to manage the detection and
malized controls and strict workflows that fixing process. In our context of OSOS,
support knowledge mobilization, strong we observed both informal modes and
interdependencies within the OSOS, tight informal modes of information exchanges
interdependencies with numerous external and knowledge exchanges aimed at coor-
third parties) and loose coupling (distri- dination for complex vulnerabilities. The
bution of decision-making, loose forms do-ers culture in our case further nourished
of knowledge coordination, autonomy of individual and independent problem-solving
108
Livre SIM 1_2023.indb 108 22/06/2023 15:26

capabilities, learning within the security learning in OSOS security) and a rich case
team, but also knowledge-sharing across the on vulnerability management, highlighting
organization (Chiva-Gómez, 2003). Indeed, its complexity and dynamics. We respond
individual knowledge mobilization fostered to a lack of qualitative research on software
collaboration and knowledge coordination, security and vulnerability management
leading to further knowledge accumulation (Schryen, 2011; Schryen & Kadura, 2009)
and to the creation of knowledge artifacts and a lack of research examining complex
(Faraj & Sproull, 2000; Kozlowski & Klein, collaborative and coordinating behaviors in
2000; Temizkan & Kumar, 2015). The latter OSOS vulnerability management (Meneely
were collectively assimilated and recorded & Williams, 2009; Sharma & Singh, 2019).
in the OSOS organizational memory (forum Therefore, our research highlights behavio-
boards, social platforms, archives, lesson ral dynamics at work in the management
learned, annual meetings, etc). Hence, our of vulnerabilities. Debian’s success results
rich description contributes to improving from collective and adaptive learning about
our understanding of adaptive learning in security. Indeed, vulnerability management
OSOS, requiring complex knowledge coor- is not limited to a taxonomy and technical
dination and specific learning management measures; it is aimed at fostering autonomy
processes (Mouakhar & Benkeltoum, 2020; and inspiring trial and error learning beha-
Sessa & London, 2015). viors (Rerup & Feldman, 2011) within the
security team and across the organization
Proposition 2: Knowledge mobilization (lead users). These practical findings are
emerge from individual interactions, and particularly relevant to the design of effi-
fuels knowledge coordination. Interaction cient vulnerability management processes
dynamics of these two processes over time focused on supporting collective learning
enable the emergence of second-order and acknowledging behavioral dynamics.
properties such as collective learning,
enabling OSOS to effectively manage From a practical standpoint, we highlighted
their software vulnerabilities (detection, best practices in designing efficient vulne-
countermeasures, and recording of this rability management processes and organi-
knowledge in the organizational memory). zational structures fostering responsiveness
and adaptive learning in security. This paper’s
best practices showcase the high level of
5.3. Implications for Practice
security maturity in OSOS and suggest several
best practices relevant to the management
Our case responds to practitioners’ calls of vulnerabilities: formal and informal dyna-
for more research on vulnerability man- mics for vulnerability management (internal
agement with a description of effective and external communication on vulnerabi-
vulnerability management in the context of lity and coordination practices); technical
a complex open-source operating system learning processes and tools to ease the
(OSOS). This paper joins a strand of critical process of sensing vulnerabilities (security
research highlighting the lack of concep- team’s sensing behaviors, hardening and
tualization and blurring of OSOS vulne- automatization); and the involvement of end
rability (Fenz & Ekelhart, 2009; Rescorla, users in vulnerability management (users
2005). We aim to address this shortfall and are trained to be mindful of vulnerabilities
provide both a grounded empirical contri- in both internal packages and external pac-
bution (uncovering behavioral dynamics kages.). Indeed, while informal and formal
that foster responsiveness and adaptive dynamics encourage reporting behaviors,
109
Livre SIM 1_2023.indb 109 22/06/2023 15:26

learning processes are facilitated. Hence, end related to vulnerability management within
users become lead users who embrace the each software community. Notably, prac-
vulnerability management process, reporting, tices such as ‘lesson learned’ and a ‘just
debugging, testing and contributing to the culture’ are common in OS communities
security team activities. Such a diversity of – such practices create an environment that
behavioral responses is natural in complex is conducive to knowledge transfer and
projects and should be monitored and tap- absorption. Our case suggests that efficient
ped to stimulate knowledge exchanges. security in OS is achieved due to specific
forms of knowledge coordination, such as
the use of collaborative and user-led security
5.4. Limitations and Future
trackers and, more importantly, the leverage
Research and integration of users’ knowledge into
security knowledge artifacts.
More research is needed to further
explore and test our initial findings in other In terms of limitations, this research is
contexts (closed OS development, for ins- based on a unique and in-depth case, so we
tance). Further research could explore the could only provide an account of the prac-
following aspects in greater detail: (1) lead tices and information security management
users and their influence on other users of the Debian OSOS. However, this immer-
regarding vulnerability awareness and posi- sion in rich and complex case data helped us
tive behaviors (reporting, debugging, and sharpen existing theories (Siggelkow, 2007)
testing); (2) vulnerability governance dyna- and fill the gaps that we identified. First, we
mics from a longitudinal perspective, focu- provide a comprehensive elaboration of the
sing, for instance, on gathering insights into complexity of vulnerability management in
governance difficulties and implementation OSOS and its knowledge dynamics (mobili-
issues. Indeed, our qualitative findings hint zation and coordination). This elaboration
at nuancing previous research on Debian is particularly relevant for practitioners, as it
governance, as we show a lack of formal contributes to a repertoire of vulnerability
leadership and decision-making via consen- management practices. Second, we provide
sus (interview 5); (3) knowledge coordina- an empirical examination of the antecedents
tion and learning management processes of the unique capabilities enacted by OSOS
regarding vulnerability as components of teams regarding vulnerability management
global security management and how they issues. Previous research examining OSOS
contribute to organizational-level security. vulnerabilities uniquely focused on the
quantitative analysis of OSOS track change
Our findings have significant implica- archives (Dinh-Trong & Bieman, 2005; Singh
tions for the understanding of vulnerability et al., 2017). Our mixed-method case helped
management processes in open-source resolve the issues that we identified in past
software development: indeed, the findings research that has disregarded the com-
of this investigation complement those of plexity of OSOS vulnerability management.
earlier studies on the efficiency of open-
source security (Payne, 2002; Schryen, 2011;
Schryen & Kadura, 2009). In particular, the REFERENCES
results of this research support the idea that
open-source security teams play a critical Aberdour M. (2007), “Achieving quality in
and specific role in facilitating the transfer, open-source software”, IEEE Software, IEEE,
absorption and utilization of knowledge vol. 24, n°1, pp. 58–64.
110
Livre SIM 1_2023.indb 110 22/06/2023 15:26

Arora A., Forman C., Nandkumar A. & Telang Carton S. & Farastier A. (2012), “Intégration
R. (2010), “Competition and patching of des connaissances client dans un projet
security vulnerabilities: An empirical ana- en systèmes d’information : influence de
lysis”, Information Economics and Policy, l’environnement de connaissance du pro-
Elsevier, vol. 22, n°2, pp. 164–177. jet”, Systemes d’information management,
Arora A., Krishnan R., Telang R. & Yang Y. ESKA, vol. 17, n°2, pp. 39–80.
(2010), “An empirical analysis of software Cavusoglu H., Cavusoglu H. & Zhang J.
vendors’ patch release behavior: impact (2008), “Security patch management:
of vulnerability disclosure”, Information Share the burden or share the damage?”,
Systems Research, INFORMS, vol. 21, n°1, Management Science, INFORMS, vol. 54,
pp. 115–132. n°4, pp. 657–670.
Arora A., Nandkumar A. & Telang R. (2006), Cheruy C., Robert F. & Belbaly N. (2017), “OSS
“Does information security attack frequency popularity: Understanding the relationship
increase with vulnerability disclosure? An between user-developer interaction, market
empirical analysis”, Information Systems potential and development stage”, Systèmes
Frontiers, Springer, vol. 8, n°5, pp. 350–362. d’information & management, ESKA, Paris,
Aslam T. (1995), A Taxonomy Of Security vol. 22, n°3, pp. 47–74.
Faults In The Unix Operating System, Chiva-Gómez R. (2003), “The facilitating fac-
MITRE. tors for organizational learning: bringing
Au Y. A., Carpenter D., Chen X. & Clark J. G. ideas from complex adaptive systems”,
(2009), “Virtual organizational learning Knowledge and Process Management, Wiley
in open source software development Online Library, vol. 10, n°2, pp. 99–114.
projects”, Information & Management, De Laat P. B. (2007), “Governance of open
Elsevier, vol. 46, n°1, pp. 9–15. source software: state of the art”, Journal
Becerra-Fernandez I. & Leidner D. E. (2008), of Management & Governance, Springer,
Knowledge management: an evolutionary vol. 11, n°2, pp. 165–177.
view, Vol. 12, ME Sharpe. Dempsey K., Takamura E., Eavy P. & Moore
Benkeltoum N. (2013), “Évaluation de l’inno- G. (2020), Automation support for security
vation des logiciels open source”, Systèmes control assessments: Software vulnera-
d’information & management, ESKA, Paris, bility management, National Institute of
vol. 18, n°3, pp. 37–84. Standards and Technology.
Benkeltoum N. (2016), “Adoption de l’open Dhanaraj C. & Parkhe A. (2006), “Orchestrating
source pour la conception de systèmes innovation networks”, Academy of
d’information critiques : le cas Thales”, Management Review, vol. 31, n°3, pp.
Systèmes d’information & management, 659–669.
ESKA, Paris, vol. 21, n°4, pp. 71–98. Di Tullio D. & Staples D. S. (2013), “The
Buishand T. A. (1982), “Some methods for governance and control of open source
testing the homogeneity of rainfall records”, software projects”, Journal of Management
Journal of Hydrology, Elsevier, vol. 58, Information Systems, Taylor & Francis, vol.
n°1–2, pp. 11–27. 30, n°3, pp. 49–80.
Capra E., Francalanci C. & Merlo F. (2008), Dinh-Trong T. T. & Bieman J. M. (2005),
“An empirical study on the relationship “The FreeBSD project: A replication case
between software design quality, deve- study of open source development”, IEEE
lopment effort and governance in open Transactions on Software Engineering,
source projects”, IEEE Transactions on IEEE, vol. 31, n°6, pp. 481–494.
Software Engineering, IEEE, vol. 34, n°6, Fachkha C. & Debbabi M. (2016), “Darknet
pp. 765–782. as a Source of Cyber Intelligence: Survey,
111
Livre SIM 1_2023.indb 111 22/06/2023 15:26

Taxonomy, and Characterization.”, IEEE des dépendances dans un bloc opératoire”,

Communications Surveys and Tutorials, Systèmes d’information et management,
vol. 18, n°2, pp. 1197–1227. ESKA, vol. 17, n°4, pp. 9–37.
Faraj S. & Sproull L. (2000), “Coordinating Lappas T., Sabnis G. & Valkanas G. (2016), “The
expertise in software development teams”, Impact of Fake Reviews on Online Visibility:
Management Science, INFORMS, vol. 46, A Vulnerability Assessment of the Hotel
n°12, pp. 1554–1568. Industry.”, Information Systems Research,
Fenton N. & Bieman J. (2019), Software met- INFORMS: Institute for Operations Research,
rics: a rigorous and practical approach, vol. 27, n°4, pp. 940–961.
CRC press. Le T. H., Chen H. & Babar M. A. (2022), “A
Fenz S. & Ekelhart A. (2009), “Formalizing survey on data-driven software vulnera-
infor mation security knowledge”, bility assessment and prioritization”, ACM
Proceedings of the 4th International Computing Surveys, ACM New York, NY,
Symposium on Information, Computer, vol. 55, n°5, pp. 1–39.
and Communications Security, pp. Li P. & Rao H. R. (2007), “An examination of
183–194. private intermediaries’ roles in software
Fisher J. A. (2012), “Secure my data or pay the vulnerabilities disclosure”, Information
price: Consumer remedy for the negligent Systems Frontiers, Springer, vol. 9, n°5,
enablement of data breach”, Wm. & Mary pp. 531–539.
Bus. L. Rev., HeinOnline, vol. 4, p. 215. Lin C. & Li Y. (2014), “Rate-Based Queueing
Fitzgerald B. (2006), “The transformation Simulation Model of Open Source Software
of open source software”, MIS Quarterly, Debugging Activities”, IEEE Transactions
JSTOR, pp. 587–598. on Software Engineering, vol. 40, n°11,
Gillies A. (2011), “Improving the quality of pp. 1075–1099.
information security management systems MacCormack A., Rusnak J. & Baldwin C. Y.
with ISO27000”, The TQM Journal, Emerald (2006), “Exploring the Structure of Complex
Group Publishing Limited. Software Designs: An Empirical Study
Janakiraman R., Lim J. H. & Rishika R. (2018), of Open Source and Proprietary Code”,
“The effect of a data breach announcement Management Science, INFORMS, vol. 52,
on customer behavior: Evidence from a mul- n°7, pp. 1015–1030.
tichannel retailer”, Journal of Marketing, Malhotra A. & Kubowicz Malhotra C.
vol. 82, n°2, pp. 85–105. (2011), “Evaluating customer information
Kannan K. & Telang R. (2005), “Market for breaches as service failures: An event study
software vulnerabilities? Think again”, approach”, Journal of Service Research,
Management Science, INFORMS, vol. 51, SAGE Publications Sage CA: Los Angeles,
n°5, pp. 726–740. CA, vol. 14, n°1, pp. 44–59.
Koch R., Golling M. & Rodosek G. D. (2014), Martin K. D., Borah A. & Palmatier R. W. (2017),
“A Revised Attack Taxonomy for a New “Data privacy: Effects on customer and firm
Generation of Smart Attacks”, Computer performance”, Journal of Marketing, vol.
and Information Science, vol. 7, n°3, p. 18. 81, n°1, pp. 36–58.
Kozlowski S. W. & Klein K. J. (2000), “A mul- Mateos-Garcia J. & Steinmueller W. E. (2008),
tilevel approach to theory and research in “The institutions of open source software:
organizations: Contextual, temporal, and Examining the Debian community”,
emergent processes.”, Jossey-Bass. Empirical Issues in Open Source Software,
Lancini A. & Sampieri-Teissier N. (2012), vol. 20, n°4, pp. 333–344.
“Contribution des Objets-Frontière (OF) à Meneely A. & Williams L. (2009), “Secure
la Gestion des Connaissances (GC) : analyse open source collaboration: an empirical
112
Livre SIM 1_2023.indb 112 22/06/2023 15:26

study of linus’ law”, Proceedings of the “Measuring the Impact of Spectre and
16th ACM Conference on Computer and Meltdown”, 2018 IEEE High Performance
Communications Security, Association for Extreme Computing Conference (HPEC),
Computing Machinery, New York, NY, USA, pp. 1–5.
pp. 453–462. Ransbotham S., Mitra S. & Ramsey J. (2012),
Midha V. & Bhattacherjee A. (2012), “Are markets for vulnerabilities effective?”,
“Governance practices and software main- Mis Quarterly, JSTOR, pp. 43–64.
tenance: A study of open source projects”, Rashid M., Clarke P. M. & O’Connor R. V. (2019),
Decision Support Systems, vol. 54, n°1, pp. “A systematic examination of knowledge
23–32. loss in open source software projects”,
Mouakhar K. & Benkeltoum N. (2020), International Journal of Information
“Capacité d’absorption des entreprises de Management, vol. 46, pp. 104–123.
l’open source : du modèle d’affaires à l’in- Rerup C. & Feldman M. S. (2011), “Routines
tention d’affaires”, Systèmes d’information as a source of change in organizational
& management, ESKA, Paris, vol. 25, n°1, schemata: The role of trial-and-error lear-
pp. 47–88. ning”, Academy of Management Journal,
Nan N. & Kumar S. (2013), “Joint Effect of Academy of Management Briarcliff Manor,
Team Structure and Software Architecture in NY, vol. 54, n°3, pp. 577–610.
Open Source Software Development”, IEEE Rescorla E. (2005), “Is finding security holes a
Transactions on Engineering Management, good idea?”, IEEE Security & Privacy, IEEE,
vol. 60, n°3, pp. 592–603. vol. 3, n°1, pp. 14–19.
Nizovtsev D. & Thursby M. (2007), “To disclose Richet J.-L. (2022), “How cybercriminal com-
or not? An analysis of software user beha- munities grow and change: An investigation
vior”, Information Economics and Policy, of ad-fraud communities”, Technological
Elsevier, vol. 19, n°1, pp. 43–64. Forecasting and Social Change, vol. 174,
Okhuysen G. A. & Eisenhardt K. M. (2002), p. 121282.
“Integrating knowledge in groups: How Schryen G. (2011), “Is open source security
formal interventions enable flexibility”, a myth?”, Communications of the ACM,
Organization Science, INFORMS, vol. 13, ACM New York, NY, USA, vol. 54, n°5, pp.
n°4, pp. 370–386. 130–140.
Pascal A., Aldebert B. & Rouziès* A. (2018), Schryen G. & Kadura R. (2009), “Open source
“Les méthodes mixtes en systèmes d’infor- vs. closed source software: towards mea-
mation: enjeux épistémologiques et métho- suring security”, Proceedings of the 2009
dologiques”, Systèmes d’information et ACM Symposium on Applied Computing,
Management, Cairn/Softwin, vol. 23, n°3, pp. 2016–2023.
pp. 99–126. Schutz D., Kim Y.-Y., Yoo Y. & Pavlou P. (2009),
Payne C. (2002), “On the security of open “An Empirical Investigation on the Role of IT
source software”, Information Systems Materiality in Multidisciplinary Innovation”,
Journal, John Wiley & Sons, Ltd, vol. 12, ICIS 2009 Proceedings, available at: https://
n°1, pp. 61–78. aisel.aisnet.org/icis2009/73.
Pettitt A. N. (1979), “A non-parametric Sen R. & Borle S. (2015), “Estimating the
approach to the change-point problem”, contextual risk of data breach: An empi-
Journal of the Royal Statistical Society: rical approach”, Journal of Management
Series C (Applied Statistics), Wiley Online Information Systems, Taylor & Francis, vol.
Library, vol. 28, n°2, pp. 126–135. 32, n°2, pp. 314–341.
Prout A., Arcand W., Bestor D., Bergeron B., Sen R. & Heim G. R. (2016), “Managing enter-
Byun C., V. Gadepally, M. Houle, et al. (2018), prise risks of technological systems: An
113
Livre SIM 1_2023.indb 113 22/06/2023 15:26

exploratory empirical analysis of vulnera- announcements on firm stock price”, IEEE

bility characteristics as drivers of exploit Transactions on Software Engineering,
publication”, Decision Sciences, Wiley IEEE, vol. 33, n°8, pp. 544–557.
Online Library, vol. 47, n°6, pp. 1073–1102. Temizkan O. & Kumar R. L. (2015), “Exploitation
Sessa V. I. & London M. (2015), Continuous and Exploration Networks in Open Source
learning in organizations: individual, Software Development: An Artifact-
group, and organizational perspectives, Level Analysis”, Journal of Management
Psychology Press. Information Systems, Routledge, vol. 32,
Shaikh M. & Henfridsson O. (2017), “Governing n°1, pp. 116–150.
open source software through coordination Temizkan O., Kumar R. L., Park S. & Subramaniam
processes”, Information and Organization, C. (2012), “Patch release behaviors of software
Elsevier, vol. 27, n°2, pp. 116–135. vendors in response to vulnerabilities: An
Sharma R. & Singh R. (2019), “Vulnerability dis- empirical analysis”, Journal of Management
covery in open-and closed-source software: Information Systems, Taylor & Francis, vol.
a new paradigm”, Software Engineering, 28, n°4, pp. 305–338.
Springer, pp. 533–539. Tille A. (2007), “Custom Debian Distributions”,
Shin Y., Meneely A., Williams L. & Osborne Website, Http://People. Debian. Org/~ Tille/
J. A. (2010), “Evaluating complexity, code Debian-Med/Talks/Paper-Cdd/Debian-Cdd.
churn, and developer activity metrics as En. Pdf.
indicators of software vulnerabilities”, IEEE Tsipenyuk K., Chess B. & McGraw G. (2005),
Transactions on Software Engineering, “Seven pernicious kingdoms: A taxonomy
IEEE, vol. 37, n°6, pp. 772–787. of software security errors”, IEEE Security
Siggelkow N. (2007), “Persuasion with case & Privacy, vol. 3, n°6, pp. 81–84.
studies”, Academy of Management Journal, Urquhart C., Lehmann H. & Myers M. D.
Academy of Management Briarcliff Manor, (2010), “Putting the ‘theory’ back into
NY 10510, vol. 50, n°1, pp. 20–24. grounded theory: guidelines for grounded
Singh V., Sharma M. & Pham H. (2017), theory studies in information systems”,
“Entropy based software reliability analysis Information Systems Journal, John Wiley
of multi-version open source software”, IEEE & Sons, Ltd, vol. 20, n°4, pp. 357–381.
Transactions on Software Engineering, Wasko M. M. & Faraj S. (2005), “Why should
IEEE, vol. 44, n°12, pp. 1207–1223. I share? Examining social capital and
Stewart K. J. & Gosain S. (2006), “The impact knowledge contribution in electronic
of ideology on effectiveness in open networks of practice”, MIS Quarterly, pp.
source software development teams”, Mis 35–57.
Quarterly, JSTOR, pp. 291–314. Yoo Y., Henfridsson O. & Lyytinen K. (2010),
Syed R. (2020), “Cybersecurity vulnerabi- “Research commentary—the new organi-
lity management: A conceptual ontology zing logic of digital innovation: an agenda for
and cyber intelligence alert system”, information systems research”, Information
Information & Management, Elsevier, vol. Systems Research, vol. 21, n°4, pp. 724–735.
57, n°6, p. 103334. Zhao M., Laszka A. & Grossklags J. (2017),
Teddlie C. & Tashakkori A. (2011), “Mixed “Devising effective policies for bug-bounty
methods research”, The Sage Handbook platforms and security vulnerability dis-
of Qualitative Research, Sage Thousand covery”, Journal of Information Policy,
Oaks, CA, vol. 4, pp. 285–300. Pennsylvania State University Press, vol. 7,
Telang R. & Wattal S. (2007), “An empirical ana- n°1, pp. 372–418.
lysis of the impact of software vulnerability
114
Livre SIM 1_2023.indb 114 22/06/2023 15:26

Sim 231 0087

Transféré par

Droits d'auteur :

Formats disponibles

Sim 231 0087

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sim 231 0087

Transféré par

Droits d'auteur :

Formats disponibles

Understanding and Managing Complex Software

Vulnerabilities: An Empirical Analysis of Open-Source

Article disponible en ligne à l’adresse

Découvrir le sommaire de ce numéro, suivre la revue par email, s’abonner...

Distribution électronique Cairn.info pour ESKA.

Understanding and Managing

Livre SIM 1_2023.indb 87 22/06/2023 15:26

Livre SIM 1_2023.indb 88 22/06/2023 15:26

adequately guide developers to effectively software vulnerability (Sharma & Singh,

Livre SIM 1_2023.indb 89 22/06/2023 15:26

absolute transparency enabled us to have teams establish to manage their security

Livre SIM 1_2023.indb 90 22/06/2023 15:26

Livre SIM 1_2023.indb 91 22/06/2023 15:26

Livre SIM 1_2023.indb 92 22/06/2023 15:26

Notably, individuals are already colla-

Livre SIM 1_2023.indb 93 22/06/2023 15:26

we do not know what sequences of beha- The coordination of knowledge is the

Livre SIM 1_2023.indb 94 22/06/2023 15:26

Livre SIM 1_2023.indb 95 22/06/2023 15:26

This quantitative and exploratory approach stakeholders, comprehend and spread

Table 1: Typology of Data Collected

Type of Data Volume and Source

Livre SIM 1_2023.indb 96 22/06/2023 15:26

4. FINDINGS FROM OUR

Livre SIM 1_2023.indb 97 22/06/2023 15:26

Livre SIM 1_2023.indb 98 22/06/2023 15:26

Figure 1: Variation in the Number of Vulnerabilities Detected Between

Figure 2: Smoothing function application

Livre SIM 1_2023.indb 99 22/06/2023 15:26

Figure 3: Variation in the Number of Packages, Vulnerable Packages

Livre SIM 1_2023.indb 100 22/06/2023 15:26

maintainer teams or single maintainers. be a research connection between them.

Livre SIM 1_2023.indb 101 22/06/2023 15:26

Table 2: Profiles of the 9 maintainers most involved in the Debian project

Figure 4: Outcome of our empirical analysis: knowledge mobilization

Livre SIM 1_2023.indb 102 22/06/2023 15:26

archives), it is not in charge of infrastructure The security team particularly relies on

Livre SIM 1_2023.indb 103 22/06/2023 15:26

Livre SIM 1_2023.indb 104 22/06/2023 15:26

Indeed, a Debian security team pre- censoring public information, or restraining

Livre SIM 1_2023.indb 105 22/06/2023 15:26

Livre SIM 1_2023.indb 106 22/06/2023 15:26

Livre SIM 1_2023.indb 107 22/06/2023 15:26

Livre SIM 1_2023.indb 108 22/06/2023 15:26

Livre SIM 1_2023.indb 109 22/06/2023 15:26

Livre SIM 1_2023.indb 110 22/06/2023 15:26

Livre SIM 1_2023.indb 111 22/06/2023 15:26

Taxonomy, and Characterization.”, IEEE des dépendances dans un bloc opératoire”,

Livre SIM 1_2023.indb 112 22/06/2023 15:26

Livre SIM 1_2023.indb 113 22/06/2023 15:26

exploratory empirical analysis of vulnera- announcements on firm stock price”, IEEE

Livre SIM 1_2023.indb 114 22/06/2023 15:26

Vous aimerez peut-être aussi