Security Vulnerabilities in Infrastructure as Code:

What, How Many, and Who?

Aicha War (  [email protected] )
University of Luxembourg
Andrew Habib
ABB Corporate Research Center of Germany
Alioune Diallo
University of Luxembourg
Jacques Klein
University of Luxembourg
Tegawendé F. Bissyandé
University of Luxembourg

Research Article

Keywords: DevOps, DevSecOps, SecDevOps, Infrastructure as Code, Security Test, Information Security,
Security Vulnerability

Posted Date: November 16th, 2023

DOI: https://doi.org/10.21203/rs.3.rs-3600645/v1

License:   This work is licensed under a Creative Commons Attribution 4.0 International License.
Read Full License

Additional Declarations:
Competing interests: The authors declare no competing interests.
Security Vulnerabilities in Infrastructure as Code: What, How Many, and Who?

Aicha WAR · Andrew HABIB · Alioune DIALLO · Jacques

KLEIN · Tegawendé F. BISSYANDE

Received: date / Accepted: date

Abstract Infrastructure as Code (IaC) is a pivotal approach for deploying and managing IT systems and services using
scripts, offering flexibility and numerous benefits. However, the presence of security flaws in IaC scripts can have se-
vere consequences, as exemplified by the recurring exploits of Cloud Web Services. Recent studies in the literature have
investigated IaC security issues, but they often focus on individual components (IaC tools or scripts), providing only pre-
liminary insights. Our research extends the current knowledge by conducting a comprehensive investigation into various
aspects of IaC security, encompassing its core components. We explore vulnerabilities in terms of types, their predom-
inant locations, contributor responsibilities for introducing vulnerabilities, and more. Our methodology relies on widely
adopted static security testing tools, which analyze over 1600 repositories to identify IaC vulnerabilities. Our empirical
study yields valuable observations, highlighting severe and recurrent vulnerabilities within IaC, while also categorizing
their severity and types. We delve deeper into vulnerability patterns, examining source code, dependencies, and manifest
files across all IaC components, including tools, scripts, and add-ons (libraries or plugin tools). The study uncovers that
IaC components are plagued by exploitable vulnerabilities that span all ten categories of security bugs outlined in OWASP
2021. Furthermore, our investigation reveals that even when maintainers employ security tools to address vulnerabilities,
they do not integrate them systematically into their automation routines. Consequently, we propose that IT teams need to
foster stronger collaboration across DevOps profiles (developers and IT operators) and break down the boundaries with
security operators to enhance Infrastructure as Code’s security posture through the adoption of DevSecOps practices.

Aicha WAR
University of Luxembourg
E-mail: [email protected]
Andrew HABIB
ABB Corporate Research Center of Germany
E-mail: [email protected]
Alioune DIALLO
University of Luxembourg
E-mail: [email protected]
Jacques KLEIN
University of Luxembourg
E-mail: [email protected]
Tegawendé F. BISSYANDE
University of Luxembourg
E-mail: [email protected]
2 Aicha WAR et al.

1 Introduction

In the realm of DevOps, Infrastructure as Code (IaC) has emerged as a pivotal technology, offering automation and code-
driven management for infrastructure deployment and configuration. IaC empowers organizations to automate a wide
array of tasks, encompassing installations, configurations, provisioning, and deployments across a spectrum of resources,
including servers, operating systems, virtual machines, containers, and applications, whether on the cloud or on-premises
environments [1]. As DevOps practices have gained widespread adoption, IaC has become an integral part of modern
software development and deployment pipelines. Consequently, safeguarding the security and integrity of the underlying
infrastructure and systems has assumed paramount importance. IaC, however, is not immune to security vulnerabilities,
and issues such as misconfigurations, inadvertent secret exposures, lax access controls, and resource leaks pose significant
risks. The detection, comprehension, and mitigation of these security challenges are of utmost importance to protect the
assets associated with deployed systems.
Understanding the vulnerabilities inherent in IaC and identifying the parties responsible for introducing them are
crucial steps in preempting security incidents. To address these fundamental questions, this study pioneers a comprehen-
sive exploration of IaC vulnerabilities, encompassing not only IaC scripts, as investigated in prior research [2], but also
the IaC tools themselves and add-ons. Section 2 provides a detailed breakdown of these three distinct components. Our
methodology involves the examination of seven widely adopted IaC tools and over 1,600 IaC repositories, encompass-
ing both scripts and add-ons. We employ two widely accepted static security testing (SAST) tools from the open-source
community, namely Snyk 1 and Horusec 2 , to conduct this investigation. Additionally, attributing the responsibility for in-
troducing vulnerabilities in IaC is a nuanced challenge due to the diverse actors involved, including developers, operators,
and maintainers, each contributing to different components of IaC. Therefore, we employ the blaming method that assess
ones specialization (developer or IT operator in the context of IaC) depending on the types of files they edit frequently [3]
coupled with our own manual investigations (on the types of edits inside of those files and the profiles of maintainers) to
discern the origins of vulnerabilities within this multifaceted ecosystem.
In section 2, we elaborate on the difference between the three components. To perform the study, we collected seven
widely used IaC tools and over 1,600 IaC repositories that contain scripts or add-ons and we utilize two SAST tools:
Snyk and Horusec. Another aspect of understanding the security vulnerabilities in IaC is finding out who is responsible
for introducing such vulnerabilities. Since we analyze several components of IaC, different actors such as developers,
operators, and maintainers own and contribute to those components and hence, discerning “who is responsible for what”
becomes a crucial part of understanding, avoiding, and fixing those vulnerabilities. Therefore, we apply our blaming
method to answer this question.
Previous studies have investigated IaC security aspects [4, 5]. For instance, there have been efforts to establish testing
practices [6] tailored to IaC, primarily revolving around infrastructure configurations (i.e., scripts), including the use and
creation of linters, sandbox testing, and recently machine learning solutions [7, 8, 9] among others [10]. In our work, we
further perform security testing on IaC core components using static analyzers. Additionally, other studies [1, 11] have
characterized IaC scripts properties. However, because our study case involves two more components, we could not rely
on those characteristics only. Hence, we consider three common artifacts from IaC repositories. Those artifacts are the
source code, the manifest files, and the dependencies (libraries, packages, etc.). We apply Snyk and Horusec to perform
security testing on the code, dependencies and manifests of our IaC components. While prior work has investigated
security flaws for some IaC tools [12], our study is expanded to substantially more IaC tools. We also combine three IaC
components and study them altogether to localize IaC vulnerabilities. Compared to previous research [2, 13], our security
analysis provides new insights into IaC security, notably in terms of vulnerability occurrences, severity, component and
defect origins (impacted files, code, dependencies, manifests). We finally apply the latest OWASP top 10 categorization
to present our list of vulnerabilities. It is noteworthy that the OWASP top 10 includes DevOps security defects such as
category eight (A08:2021-Software and Data Integrity Failures) that integrates DevOps pipelines security issues.
Overall, the main contributions of this paper are as follows:

1 https://snyk.io/product/snyk-code/
2 https://github.com/ZupIT/horusec
Security Vulnerabilities in Infrastructure as Code: What, How Many, and Who? 3

– We provide a comprehensive view of vulnerabilities in IaC. In contrast to prior work, we investigate various different
components that are relevant to IaC and analyze how they impact IaC security.
– We discuss in-depth where security issues are localized within IaC components.
– We supplement the collected data with a categorization of security issues reported by Static Analysis Security Testing
tools, using the OWASP Top-10.

Among various insights, we note that:

– Vulnerabilities are widespread across all IaC components with every one of the 10 OWASP vulnerability types mani-
festing across each analyzed component;
– Although IaC maintainers demonstrate a proactive stance toward vulnerabilities, they do not seem to follow standard
automatic practices and routines to check for the existence of such issues consistently and systematically;
– Manifest files emerge as the most vulnerable artifacts within the IaC ecosystem;
– IaC vulnerabilities frequently stem from non-specialized actors attempting modifications within components outside
their expertise.

The rest of this paper is organized as follows: Section 2 introduces the background and related work, Section 3
discusses the study design, Section 4 presents the experimental results, and finally, Section 5 concludes the paper.

2 Background and Related Work

In this section we explore Infrastructure as Code’s background as well as previous studies that are similar or linked to our
research. We highlight our contributions on top of this related work.

2.1 Background

2.1.1 DevOps and DevSecOps

DevOps refers to the automation of development (Dev) tasks such as unit tests, in-
tegration tests, etc. as well as the automation of operation (Ops) tasks such as arti-
facts releases or deployments. Figure 1 illustrates how this automation fits into three
main pipelines: Continuous Integration (CI) for development tasks, Continuous De-
livery(CDE) for releases, and Continuous Deployment (CD) for IT operation tasks.
Our study focuses on CD, specifically on the security aspects of Infrastructure as
Code. To strengthen DevOps security, some practices and collaboration with security
operators have been grafted to DevOps [14]. And the generic terms for this evolution
are DevSecOps and SecDevOps [15]. Despite possible nuances, in this paper, we
refer to DevSecOps as an umbrella term for both DevSecOps and SecDevOps. We Fig. 1 DevOps automation and CI-
also refer to IaC maintainers as an umbrella term for developers, IT operators, and CDE-CD pipelines
DevOps engineers.
Beyond classical DevSecOps concerns, our study will explore other DevOps se-
curity aspects. Indeed, we investigate DevOps collaborating actors (developers, IT operators) to understand which profile
is more likely to introduce security flaws in IaC environments. With this blaming/profiling method, we expect to provide
insights for the development of tools that will help DevOps practitioners embrace DevSecOps and improve their security
practices to build better quality IaC environments. Furthermore, we explore IaC security vulnerabilities using different
SAST tools. We study those defects with several parameters like their severity, propensity, and locations (files impacted)
depending on IaC’s main components.
4 Aicha WAR et al.

2.1.2 Infrastructure as Code and its Components

Infrastructure as Code (IaC) is a process that involves scripts and components for automatically managing and provision-
ing infrastructure. Many IaC scripts are written using Domain Specific Languages (DSLs), which are designed to model
a specific domain: infrastructure in this case [11]. In general, IaC tools (Ansible, Terraform, Puppet, etc) have similar
writing styles: declarative, scripted, or mixed (both declarative and scripted). Usually, the declarative code is used for
configuration since it is more structured. It also allows faster management of infrastructure components. That declarative
coding style involves the use of packages, services, files, user accounts, etc. Figure 2 provides an excerpt of IaC declarative
script for deploying a Tomcat server.

package: jdk
file: /var/lib/ tomcat / server .conf
package: tomcat
owner: tomcat
group: tomcat
service: tomcat
mode: 0644
port: 8443
contents: $TEMPLATE (/ src/ appserver / tomcat / server .conf. template )
user: tomcat
group: tomcat

Fig. 2 Excerpt from IaC declarative script written for deploying a Tomcat server

IaC tools can be categorized into two groups depending on their main tasks. There are orchestration tools (Terraform
and Vagrant for example) that perform provisioning, organizing, and managing processes for infrastructure components. In
addition, there are configuration management tools (Ansible, Chef, Puppet for example) that allow installations, updates
or management of softwares in infrastructure components. In our study we investigate both categories. Deploying IaC
scripts into servers follows a generic automation process. This process implies a set of CI and CD tools (specifically IaC
tools in our context). IaC tools are employed to write IaC scripts. We can see IaC tools as development kits for IaC scripts.
Through Figure 3, we explain the automation activities that lead to IaC scripts deployment:

Fig. 3 IaC deployment schema

– The DevOps engineer writes the IaC script

– The DevOps engineer commits the IaC script changes to a Version Control System (VCS)
– The changes trigger the CI tool to run static testings
– The CI tool incorporates the IaC script changes when tests are positive (and rejects changes otherwise)
– The CI tool deploys the updated IaC script into the targeted server(s).
Security Vulnerabilities in Infrastructure as Code: What, How Many, and Who? 5

In this study, we rely on Jenkins as a CI tool for the experiments, and Github (Github and its API GitAPI) to collect
IaC-related repositories.

2.1.3 OWASP top 10

The OWASP Top 10 is a standard awareness document for developers and web application security. The report is put
together by a team of security experts from all over the world and the data comes from a number of organisations and
is then analysed. It represents a broad consensus about the most critical security risks to web applications. These risks
include DevOps pipeline flaws. This is why we rely on the OWASP top 10 categorization (of 2021) of defects to present
the vulnerabilities we have detected with Infrastructure as Code.

Fig. 4 OWASP top 10 2021 security vulnerabilities categories.

2.2 Related Work

2.2.1 Security of Infrastructure as Code

Researches have been carried out in the domain of IaC security. When it comes to security testing for IaC, it generally
revolves around the use or creation of IaC linters [10] or performing sandbox testing [6]. In this paper, we rely on SAST
tools that, for some, integrate IaC linters. However, we also perform static security testing on the code and manifest files
of our different artifacts. We base those two testing types on researches that have characterized IaC scripts. Since we
investigate scripts, we not only have pieces of code to test but also IaC manifest files that commonly exist, generally, in
every IaC script according to existing studies [1, 11]. Those manifest files are the main configuration files in IaC scripts.
Depending on the language of the IaC tool, manifest files can be YAML files (for python) or JSON files (for JavaScript),
etc. Still in the line of security investigation with IaC, some papers have explored IaC scripts security for some IaC tools
with IaC linters[12]. Our work covers more IaC tools: more precisely, seven tools (Ansible, Terraform, Chef, Puppet, Va-
grant, Pulumi, Saltstack). Furthermore, we investigates the scripts for each tool and, in addition, we inspect the very own
code of each IaC tool and their extra projects repositories. Because IaC automation relies on a toolstack, we dig in deeper
to that stack to highlight a wider range of security issues and their apportionment (in term of files, tools) that might have
been missed. As a result, we indeed present in this study, more vulnerabilities and information about their severity, their
distribution in IaC files, tools, manifests that were not reported in previous papers [2, 13, 12]. Other papers have drawn a
taxonomy for IaC defects[16] with eight categories of defects for IaC. However, the vulnerabilities we detected naturally
led us to rely on the OWASP top 10 2021 ranking.
6 Aicha WAR et al.

2.2.2 Static Detection of Bugs

In our study, we investigate security vulnerabilities in infrastructure components. In the literature, researchers actively
study the security of infrastructure as Code [17, 18, 19, 20]. In their investigations, practitioners rely on tools for testing
infrastructure security [21]. We have infrastructure tools’ linters [2, 22], static analyzers [23], and custom-made secu-
rity tools [24, 25, 26] for infrastructure. Unfortunately, common IaC linters are tool-oriented (for example Ansible Lint 3
or TFLint 4 respectively for Ansible and Terraform). Hence, they have limits when finding security vulnerabilities for
different infrastructure tools. On the other hand, custom-made tools developed by the research community are either tool-
oriented [24, 27] or limited to a few programming languages. When they are polyglot tools, custom-made analyzers are
also limited to a few infrastructure tools [25] and still do not entirely cover the three components we are investigating.
Hence, we rely on two Static Analysis Security Testing (SAST) tools with databases of CVEs/CWEs for infrastructure:
Snyk and Horusec. We also expect to study the impact or outcome of using different security analyzers on our infrastruc-
ture components’ projects. Both tools are open-source security tools intelligence.

2.2.3 Blaming Method

Previous studies have designed some techniques to assess the specialization of Linux maintainers[3]. In order to assess
the profiles for the security flaws potential contributors in DevOps, we apply these research contributions to Infrastructure
as Code’s context. The method mainly relies on the frequent edits of some types of files. For example, if dev files (.java
files, .js files, etc) are frequently edit for a certain type of vulnerability, then we will consider developers to be likely to be
their authors.

3 Methodology

We present the overall outline of our study methodology. We employ two Static Application Security Testing (SAST) tools
to analyze datasets comprising infrastructure components, including tools, scripts, and add-ons. The study specifically
aims to answer the following research questions:

– RQ1: What types of security vulnerabilities occur with IaC? The primary focus of this research question is to identify
and categorize the prevalent security vulnerabilities associated with IaC. Understanding the specific vulnerabilities
inherent in IaC environments is crucial for developing robust patterns for the detection and prevention of infrastructure-
related security issues. We supplement our analysis by providing insights on the severity of vulnerabilities, their
frequency of occurrence, and their origins.
– RQ2: How do vulnerabilities evolve in infrastructure components? In this research question, we investigate the
evolution of vulnerabilities across versions of IaC components. We assess to what extent vulnerabilities persist across
versions.
– RQ3: How are vulnerabilities introduced in Infrastructure as Code? Finally, with this research question, we inves-
tigate the locations (in terms of file type) where vulnerabilities appear, as well as the contributors associated with the
vulnerable code. The profiles (i.e., developers, IT operators) of these contributors are also analyzed with respect to the
introduced vulnerabilities: who introduces which vulnerabilities where?

3 https://github.com/ansible/ansible-lint
4 https://github.com/terraform-linters/tflint
Security Vulnerabilities in Infrastructure as Code: What, How Many, and Who? 7

Fig. 5 Jenkins automated security testing on IaC components using Snyk, Horusec

3.1 Data Collection

In our study, we analyze the source code of three main components of IaC: tools, scripts, and add-ons[28]. To perform
our security analysis, we collected open-source projects about these components into three datasets. First, we considered
the popular open-source IaC tools that are widely referred to in the literature [29, 30, 31, 32, 33, 34]: Ansible, Terraform,
Chef, Puppet, Saltstack, Pulumi, Vagrant. We therefore build the first dataset by downloading their source code. These
tools further come with a vast selection of add-ons distributed in hundreds of repositories and grouped by programming
language (Java, PHP, Go, JavaScript, Shell, Python, PowerShell, Ruby). We mined the source code of all5 maintained
add-ons of every collected infrastructure tool by programming language. Finally, our last dataset, i.e., the collection of
IaC scripts, is mined from repositories of projects that leverage the identified IaC tools for their build/deploy/manage
processes.
All dataset collections were automatically performed using Jenkins. Overall, we collected the source codes of 7 IaC
tools and that of over 1,600 Infrastructure as Code scripts and add-ons. For each, we mined the latest releases of the source
codes in the repository’s default branch.

3.2 Experimental Procedure

We explain in this section our static security testing techniques, data presentation, and profiling method for the potential
contributors associated with the detected vulnerable parts.

3.2.1 Static Application Security Testing

In the literature, several security analyses have been conducted on IaC projects [17, 18, 19, 20]. However, these studies are
generally limited. For example, some are focused on projects written in a specific programming language, while others
rely on a single or a few IaC tools. Our work improves over these studies by widening the research focus to a substantially
larger set of tools, to a large array of programming languages, and finally by considering IaC core components (tools
and scripts) as well as add-ons. Indeed, it is noteworthy that previous studies have mainly characterized defective IaC
scripts [35], while our work investigates also tools and add-ons. Our study therefore bears more constraints: the same
analyses cannot be applied similarly to scripts, tools and add-ons. We propose three characteristics that each repository
of our IaC components generally possesses: a source code, dependencies, and manifest files. Manifests are files used
to deploy and manage resources with Infrastructure as Code. When analyzing our components with our security appli-
cation security testing (SAST) tools, we will take the vulnerabilities’ origins as those enunciated characteristics (code,
dependencies, manifests). We present our security testing architecture with Jenkins as a CI tool in Figure 5:
– At steps 1 and 2, Jenkins orchestrates the collection of IaC components.
– At stage 3, Jenkins performs the security testing with our selected SAST tools: Snyk and Horusec.
– At stage 4, Jenkins presents the detected vulnerabilities in a report for the components.
5 The cut-off date is August 2022
8 Aicha WAR et al.

3.2.2 Collection and Presentation of Vulnerabilities

Our static security testing with Snyk and Horusec on the code, dependencies and manifests of IaC components displayed
various vulnerability types. We show in this paper the distribution and severity of IaC vulnerabilities depending on those
three artifacts. In order to categorize the detected vulnerabilities, we looked into existing infrastructure vulnerabilities’
taxonomies. In previous works, IaC vulnerabilities are categorized into eight groups [16]: conditional, configuration data,
dependency, documentation, idempotency, security, service, and syntax. However, our study solely focuses on the security
aspects of Infrastructure as Code, not its global vulnerabilities. Therefore, we have categorized the detected vulnerabilities
using the OWASP top 10:2021. This categorization is indeed suitable since, based on the CVE/CWE information, every
detected vulnerability could be fit to a specific category in OWASP Top 10. Due to space constraints, we only focus on the
ten critical vulnerabilities that are most represented under each OWASP Top 10 category. Therefore, not all vulnerabilities
are presented in this paper. We display for each OWASP category, the top 10 of the detected vulnerabilities automatically
with our CI tool Jenkins and using the analysis reports of our SAST tools. The ranking is performed first depending on
the severity, the origin (code, dependencies, manifests), and then on the occurrence of the vulnerability type. Then, we
manually assigned the types of vulnerabilities detected under each OWASP category. We first search for the vulnerability
type in the OWASP categories vulnerability list. If we do not find the vulnerability type in the category, we look for its
CWE correspondence and search again across the top 10 categories with the CWE number. If we still do not find an explicit
category, we read the description of the CWE until we find the vulnerability match. We also provide in our categorization
of vulnerabilities, the occurrences of the same instances of vulnerabilities that both Snyk and Horusec report. We use
Jenkins to automatically match the vulnerable paths and lines that point to the same instance of vulnerabilities for Snyk
and Horusec.

3.2.3 Evolution of vulnerabilities across components versions

We follow the evolution of the detected vulnerabilities across different versions of our components’ projects. We chose
5 projects for each of our IaC components: tools, scripts, and add-ons. These projects were identified based on their
GitHub Watch, Fork, and Star numbers. The more the better. Then, we selected 2 versions backward for each project
sample. After our dataset of projects is constituted, we automatically run security analysis using Snyk and Horusec in
our CI tool, Jenkins. We kept tracking the history of the instances of the detected vulnerabilities using the paths, lines,
and vulnerability descriptions that Horusec 6 and Snyk 7 report. We manually check if the warnings are fixed or new
vulnerability instances appear. Consequently, we could observe if vulnerabilities have been fixed across those versions.

Language : Leaks
Severity : CRITICAL
Line: 98
Column : 18
SecurityTool : HorusecEngine
Confidence : MEDIUM
File: /Users/aicha.war /. jenkins / workspace / componentsevotestingsnyk / scripts / community . general /3/ tests/unit
/ plugins / modules / test_keycloak_realm .py
Code: ’auth_password ’: ’admin ’,
RuleID : HS -LEAKS -26
Type: Vulnerability
ReferenceHash : eb97965e94f0e19392916ea8d800295f99312b609fd9f49dc4c057d374e54611
Details : (1/1) * Possible vulnerability detected : Hard -coded password
The software contains hard -coded credentials , such as a password or cryptographic key , which it uses for
its own inbound authentication , outbound communication to external components , or encryption of internal
data. For more information checkout the CWE -798 (https :// cwe.mitre.org/data/ definitions /798. html) advisory .

Fig. 6 Hard-coded password vulnerability report by Horusec

Security Vulnerabilities in Infrastructure as Code: What, How Many, and Who? 9

[Low] Hardcoded Secret

Path: tests/unit/ plugins / modules / test_java_keystore .py , line 88
Info: Avoid hardcoding values that are meant to be secret . Found a hardcoded string used in here.

Fig. 7 Hardcoded Secret vulnerability report with Snyk

3.2.4 Security responsibilities of DevOps maintainers

Finding vulnerabilities’ origins is an important task in IT systems. Hence, many Version Control Systems (VCS) tools like
Git or automation tools like Jenkins provide functionalities for such tasks. For example, the git-blame command shows
which revision an author made, who last modified which line of which file among repository maintainers, etc. Previous
research can also help to identify IT profiles contributing the most to the introduction of vulnerabilities in source code.
They have defined a method to estimate, according to the frequency of edits of a certain type of file, the specialization
of the maintainers [3]. Because DevOps is about collaborative work between development and operation activities, we
thought it relevant to investigate the responsibilities of these maintainers in IaC vulnerabilities. Specifically in the types of
files that they manipulate the most. Unlike developers, IT operators are the ones specialized in managing the infrastructure,
and thus dealing with manifest files. Hence, we investigate if developers introduce more vulnerabilities in manifest files
than in development files. First, we automatically collect information about the commits in IaC projects and about their
maintainers. Then we were able to access the maintainers’ profiles to check their specialization. Using our samples from
each IaC component, we also investigate the types of files edited (readme files, JSON files, etc), and the types of edits (e.g:
comments, features) to match the relevant files and edits with the vulnerabilities reported by Snyk and Horusec. Finally,
we assess the responsibilities of developers and IT operators in IaC components using the specialization of projects’
maintainers, the types of files they have edited in those projects, and the types of edits that hosted vulnerabilities in these
specific files.

3.2.5 Propensities and distribution of vulnerabilities in components

Our study also gives insights into the location of the detected vulnerabilities in Infrastructure as Code. We automatically
sort the vulnerabilities reported by our SAST tools by severity, IaC component, occurrence, and types of files. Localizing
vulnerabilities with their severity and distribution in components gives better visibility on the most severe locations. It also
naturally shows where to work in priority to build better security patterns for IaC components and reduce vulnerabilities.

3.3 Threats to Validity

Our study bears a number of threats to validity, which we try to mitigate:

Infrastructure as Code’s Components. Our study focuses on a sample number of tools for collecting IaC. We considered
a set of free and open-source ones. Our results may therefore be only representative of these tools. Nevertheless, we
attempted to mitigate this threat by considering popular tools, which are explored even in industry.
Vulnerability assessment. As an external threat to validity, we have collected our subject projects from GitHub default
repository branches. Since such master branches are supposed to host clean, tested, and ready-for-deployment code, it
is possible that our study was not able to capture the entire variety of vulnerabilities in IaC. Indeed, if the maintainers
performed static security analysis before pushing some code to the default branches, our results will not be representative.
Nevertheless, this threat is mitigated by the use of various tools.
When presenting the vulnerabilities in infrastructure components, we only considered the top 10 under each OWASP
category. This is the threat to conclusion validity, since it may be perceived that other levels of severity are not sufficiently
problematic. Actually, We could not display all vulnerability types for space concerns. However, repeated Low to Medium
vulnerabilities could have a severe impact on aviation and medical fields, for example.
10 Aicha WAR et al.

Static Analyzers. Also, static analyzers are known to produce false positives [36, 37]. Although we did not manually verify
each reported warning, we mainly reported warnings flagged by two mature and widely adopted tools that have databases
of CVEs and CWEs, respectively: Snyk and Horusec. In our security analysis, Snyk shows more types of vulnerabilities
than Horusec. Likewise, other existing SAST tools could also show new types of vulnerabilities that our selected tools did
not because they are built differently. Hence, we may have missed vulnerabilities in analyzing IaC’s components.
Maintainers security responsibilities Moreover, our blaming method finds the possible authors of the detected vulner-
abilities according to their specialization and expertise. We assume that their DevOps profile is based on the files they
manipulate the most [3] and on the types of edits they make to the source code. We cannot prove the accuracy of this
method since we did not manually check all hundreds of repositories from the scripts, tools and add-ons. However, we
relied on samples of each IaC component to manually evaluate the types of edits (simple comments or real features) and
profiles of their contributors (using their Github profile information).

4 Study Results

We present the investigation findings related to the research questions of our study. First, we summarize the key answers
(cf. Section 4.1). Second, we overview the landscape of vulnerabilities affecting IaC (RQ1, cf. Section 4.2). Third, we
dissect how vulnerabilities evolve with IaC code changes (RQ2, cf. Section 4.3). Fourth, we present the investigation
results on where and who introduces vulnerabilities in IaC (RQ3, cf. Section 4.4).

4.1 Summary of key findings

– Answer to RQ1: IaC is affected by all OWASP Top 10 categories of vulnerabilities. The distributions of these vulner-
abilities as well as their severity underscores the significant security concerns within the IaC realm.
⇒ Vulnerabilities in IaC components do not appear to be largely addressed in research and practice. Yet, given the im-
portance of IaC in today’s IT infrastructure, those vulnerabilities, which are easily discoverable by existing tools could
be exploited by malicious parties. It is therefore essential to develop pattern-based tooling for fixing IaC vulnerabilities
at scale with adequate documentation for practitioner adoption.
– Answer to RQ2: The analysis of development artifacts reveal that IaC maintainers detect vulnerabilities, using secu-
rity linters for example, and actually fix them in their projects. However, we also note that a variety of vulnerability
instances, across the severity spectrum, survive changes that evolve IaC components.
⇒ We conclude that while IaC maintainers demonstrate a certain degree of proactive behavior in addressing vulnera-
bilities, they do not seem to adhere to established automated practices and routines for the consistent and systematic
detection of IaC vulnerabilities.
– Answer to RQ3: The security analysis data reveal that the most severe and recurrent vulnerabilities in IaC components
are mainly located in manifest files, database files, and other configuration files in this order. Our results further
indicate that DevOps actors are associated vulnerable composants which they are the least experienced with.

4.2 IaC vulnerabilities: categories, types, and severity

The execution of Snyk and Horusec SAST tools on the datasets of IaC components yielded a large volume of reports
(359,884 log entries from Jenkins) describing a variety of vulnerabilities for different components. These vulnerabilities
appear with diverse occurrence rates across components and present different severity scores. In every component dataset,
we analyzed the source code, dependencies, and manifest files of projects using Snyk and Horusec. In table 1 we present
a taxonomy of these vulnerabilities using the OWASP Top 10:2021. Under each OWASP category, we sort the vulnera-
bilities based on the severity score. We then report the ten most severe vulnerabilities and their occurrence information.
Furthermore, for each vulnerability type, we detail the propensities and severity of the detected vulnerabilities depending
on the origin (or artefact) of the detected vulnerability (source code, dependencies, manifests) and the used SAST tool.
We also provide the number of vulnerability instances that both Snyk and Horusec detect when analyzing the components.
Security Vulnerabilities in Infrastructure as Code: What, How Many, and Who? 11

Table 1 Top 10 IaC vulnerabilities for each OWASP top 10 category detected by SAST tools on the IaC artefacts. L→ Low severity; M→ Medium
severity; H→ High severity; ∩SAST: Intersection between Snyk and Horusec vulnerability reports. Results (#vulnerabilities) are encoded as ‘k/n‘ where
’k’ is the number of vulnerabilities reported by Snyk, and ’n’ is the number of vulnerabilities reported by Horusec
Source Code Dependencies Manifests
Vulnerability L M H C Total ∩SAST L M H C Total ∩SAST L M H C Total ∩SAST
OWASP A01:2021 Broken Access Control
Improper Access Control 0/0 0/0 0/0 0/0 0/0 0 4/0 0/0 3/0 2/0 9/0 0 -/- -/- -/- -/- -/- -
Path Traversal 28/0 0/0 661/0 0/0 689/0 0 0/0 0/0 0/0 0/0 0/0 0 -/- -/- -/- -/- -/- -
Sandbox Bypass 0/0 0/0 13/0 0/0 13/0 0 0/0 0/0 0/0 0/0 0/0 0 -/- -/- -/- -/- -/- -
Privacy Leak 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 11/0 0/0 11/0 0 -/- -/- -/- -/- -/- -
Cross-Site Request Forgery (CSRF) 150/0 96/0 8/0 0/0 254/0 0 0/0 11/0 1/0 0/0 12/0 0 -/- -/- -/- -/- -/- -
Directory Traversal 0/0 0/0 0/0 0/0 0/0 0 44/0 16/0 8/0 0/0 68/0 0 -/- -/- -/- -/- -/- -
OWASP A02:2021 Cryptographic Failures
Hardcoded Secret Transmission of Sensitive Information 85/0 0/0 81/0 0/166 166/166 166 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/6,169 0/6,169 0
No Use Weak Random Number Generator 0/0 0/0 0/200 0/0 0/200 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/561 0/0 0/561 0
Use of Password Hash With Insufficient Computational Effort 89/0 1,387/0 0/0 0/0 1,476/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0
Improper Certificate Validation 19/0 142/0 0/0 0/0 161/0 0 19/0 0/0 52/0 0/0 71/0 0 0/0 0/0 0/0 0/0 0/0 0
Information Exposure 3/0 91/0 0/0 0/0 94/0 0 31/0 67/0 16/0 13/0 127/0 0 0/0 0/0 0/0 0/0 0/0 0
TLSCertVerificationDisabled 0/0 0/0 49/0 0/0 49/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0
Insecure Data Transmission 0/0 0/0 33/0 0/0 33/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0
Insecure Hash 0/0 183/0 0/0 0/0 183/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0
OWASP A03:2021 Injection
No Use Eval 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/406 0/406 0
Arbitrary Code Execution 0/0 0/0 0/0 0/0 0/0 0 0/0 9/0 21/0 25/0 55/0 0 0/0 0/0 0/0 0/0 0/0 0
SQL Injection 0/0 0/0 199/0 0/0 199/0 0 0/0 0/0 27/0 14/0 41/0 0 0/0 0/0 0/0 0/0 0/0 0
Remote Code Execution (RCE) 0/0 0/0 0/0 0/0 0/0 0 0/0 1/0 87/0 5/0 93/0 0 0/0 0/0 0/0 0/0 0/0 0
Command Injection 81/0 0/0 143/0 0/0 224/0 0 0/0 4/0 48/0 2/0 54/0 0 0/0 0/0 0/0 0/0 0/0 0
XML External Entity (XXE) Injection 14/0 0/0 13/0 0/0 27/0 0 0/0 9/0 484/0 1/0 494/0 0 0/0 0/0 0/0 0/0 0/0 0
Cross-site Scripting (XSS) 111/0 0/0 1,341/0 0/0 1,452/0 0 13/0 76/0 6/0 0/0 95/0 0 0/0 0/0 0/0 0/0 0/0 0
LDAP Injection 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/194 0/0 0/194 0
HTTP Header Injection 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 72/0 0/0 72/0 0 0/0 0/0 0/0 0/0 0/0 0
Code Injection 1/0 0/0 26/0 0/0 27/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0
OWASP A04:2021 Insecure Design
Out-of-bounds Read 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 98/0 0/0 98/0 0 -/- -/- -/- -/- -/- -
Prototype Pollution 0/0 6/0 0/0 0/0 6/0 0 3/0 45/0 44/0 0/0 92/0 0 -/- -/- -/- -/- -/- -
HTTP Request Smuggling 0/0 0/0 0/0 0/0 0/0 0 1/0 83/0 0/0 1/0 85/0 0 -/- -/- -/- -/- -/- -
Buffer Overflow 0/0 0/0 0/0 0/0 0/0 0 0/0 60/0 0/0 0/0 60/0 0 -/- -/- -/- -/- -/- -
OWASP A05:2021 Security Misconfiguration
Privileged container in deployment -/- -/- -/- -/- -/- - -/- -/- -/- -/- -/- - 0/0 0/0 22/322 0/0 22/322 22
Default service account used in compute engine -/- -/- -/- -/- -/- - -/- -/- -/- -/- -/- - 0/0 0/0 104/0 0/0 104/0 0
Credentials are configured via provider attributes in provider -/- -/- -/- -/- -/- - -/- -/- -/- -/- -/- - 0/0 0/0 80/0 0/0 80/0 0
Hardcoded admin password in VM configuration in compute -/- -/- -/- -/- -/- - -/- -/- -/- -/- -/- - 0/0 0/0 71/0 0/0 71/0 0
S3 restrict public bucket control is disabled in S3 -/- -/- -/- -/- -/- - -/- -/- -/- -/- -/- - 0/0 0/0 28/0 0/0 28/0 0
S3 block public policy control is disabled in S3 -/- -/- -/- -/- -/- - -/- -/- -/- -/- -/- - 0/0 0/0 28/0 0/0 28/0 0
S3 block public acls control is disabled in S3 -/- -/- -/- -/- -/- - -/- -/- -/- -/- -/- - 0/0 0/0 28/0 0/0 28/0 0
S3 ignore public acls control is disabled in S3 -/- -/- -/- -/- -/- - -/- -/- -/- -/- -/- - 0/0 0/0 21/0 0/0 21/0 0
Rolebinding or clusterrolebinding is using a pre-defined role -/- -/- -/- -/- -/- - -/- -/- -/- -/- -/- - 0/0 0/0 13/0 0/0 13/0 0
Role with too wide permissions in clusterrole -/- -/- -/- -/- -/- - -/- -/- -/- -/- -/- - 0/0 0/0 13/0 0/0 13/0 0
OWASP A06:2021 Vulnerable and Outdated Components
Insecure API 56/0 2/0 0/0 0/0 58/0 0 0/0 0/0 0/0 0/0 0/0 0 -/- -/- -/- -/- -/- -
Insecure Xml Parser 207/0 163/0 0/0 0/0 370/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0
OWASP A07:2021 Identification and Authentication Failures
Use of Hardcoded Credentials 949/0 1,024/0 0/0 0/242,103 1,963/242,103 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0
Returns Password 0/0 3/0 0/0 0/0 3/0 0 0/0 0/0 0/0 0/0 0/0 0 -/- -/- -/- -/- -/- -
OWASP A08:2021 Software and Data Integrity Failures
Deserialization of Untrusted Data 1/0 0/0 21/0 0/0 22/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0
Resources Downloaded over Insecure Protocol 0/0 0/0 0/0 0/0 0/0 0 1/0 0/0 0/0 0/0 1/0 0 0/0 0/0 0/0 0/0 0/0 0
OWASP A09:2021 Security Logging and Monitoring Failures
Regular Expression Denial of Service (ReDoS) 10/0 0/0 49/0 0/0 59/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0
Clear Text Logging 15/0 125/0 0/0 0/0 140/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0
Improper Output Neutralization for Logs 0/0 0/0 0/0 0/0 0/0 0 32/0 0/0 0/0 0/0 32/0 0 0/0 0/0 0/0 0/0 0/0 0
Denial of Service (DoS) 0/0 1/0 0/0 0/0 1/0 0 0/0 0/0 0/0 0/0 0/0 0 0/0 0/0 0/0 0/0 0/0 0
OWASP A10:2021 Server-Side Request Forgery
Server-Side Request Forgery (SSRF) 2/0 0/0 114/0 0/0 116/0 0 0/0 0/0 0/0 0/0 0/0 0 -/- -/- -/- -/- -/- -

4.2.1 Snyk vs Horusec

The execution results on our IaC datasets show that Snyk and Horusec are not systematically in agreement: they do not
always detect the same types and instances of vulnerabilities in the same projects. Snyk has a database of CVEs with
references to IaC components. In contrast, Horusec relies on a database of CWEs, which are not directly linked to the
analyzed components. Furthermore, we observe that both SAST tools can associate different severity levels with the same
vulnerability instances. Snyk also only shows warnings related to the vulnerabilities it has in its database of CVEs while
Horusec not only presents the vulnerabilities related to its database of CWEs but also issues that it considers as potential
vulnerabilities (ex: Hard-coded Password and Potential Hard-coded Password). Consequently, as revealed in Table 1,
Horusec has thousands of vulnerability instances while Snyk has only hundreds of vulnerability instances. Hence, using
12 Aicha WAR et al.

different static security tools may offer a good combination for finding more vulnerabilities in IaC components. However,
it will create challenges in triaging a larger number of false positives.

4.2.2 Vulnerability of IaC components

Data in Table 1 indicate that all categories of the OWASP Top 10 are reported in the execution of Horusec and Snyk
on our IaC datasets. Despite the fact that both SAST tools may assert severity differently, there is one constant aspect
of these vulnerabilities: they are all serious and exploitable security issues. This means that IaC tools, scripts, and add-
ons are vulnerable and exploitable projects. IaC maintainers could benefit from adopting security testing automation
in their DevOps routines and increase their security awareness and skills. If we take the example of the vulnerability
“container has no CPU limit” (OWASP A05, Figure 8) in the file misc/gce-federation/files/mongo-rs.yaml from the
openshift project 6 , it can easily be fixed by updating lightly the configuration parameters of the container (cf. Figure 9).
We specify a request of 0.5 CPU and a limit of 1 CPU in the use of the container. We also specify, under the args section,
2 CPUs that the mongo container should be allowed to use in case it needs more resources. From this example, we
can highlight that some vulnerabilities represented in Table 1 can be avoided if maintainers give better care to the basic
configurations with IaC.

apiVersion: extensions / v1beta1

kind: ReplicaSet
metadata:
labels:
name: mongo
name: mongo
spec:
replicas: 3
template:
metadata: -image: mongo
labels: name: mongo
name: mongo resources:
spec: limits:
containers: cpu: "1"
- image: mongo request:
name: mongo cpu: "0.5"
args: args:
- --replSet --replSet
- rs0 --rs0
ports: --cpus
- name: mongo --"2"
containerPort: 27017
volumeMounts:
Fig. 9 Correction of the vulnerability Container has no CPU
- name: mongo -db
limits
mountPath: /data/db
volumes:
- name: mongo -db
persistentVolumeClaim:
claimName: mongo - storage

Fig. 8 Excerpt of script used in an Ansible project - Example

of “Container has no CPU limits” vulnerability

6 https://github.com/openshift/openshift-ansible-contrib.git
Security Vulnerabilities in Infrastructure as Code: What, How Many, and Who? 13

We observe that vulnerabilities, detectable by different SAST tools, spread across all IaC components. Further-
more, the security testing results revealed that these vulnerabilities are often severe, multiple and various: all
OWASP Top 10 categories are represented among vulnerabilties found in IaC scripts, IaC tools and IaC add-
ons. This finding underscores the gravity of vulnerabilities within the IaC ecosystem.

4.3 Vulnerabilities Lifecycle in IaC Components

Given a downloaded release of an IaC component, we investigate the evolution of the vulnerabilities comparing against
prior versions. To assess this evolution across different components, we uniformly sample 5 projects per component type.
For each sample, we consider its two preceding major release versions on which we also apply the SAST tools. Our
objective is then to find the changes in the vulnerabilities across projects’ versions. It appears that vulnerabilities evolve
in different versions of the same project (Table 2). We observe from one project version to another, that one vulnerability
can have three statuses: it can be a new instance created, or it can be fixed in-between, or it can remain the same in-
stance. We notice that, generally, IaC maintainers actually fix old vulnerabilities in their projects, in all components. The
vulnerabilities that appear in newer projects’ versions are mostly new vulnerability instances. We can however find the
same instances of vulnerabilities in different versions of the same project for some components. This means that even if
maintainers fix security issues in IaC projects, they do not systematically analyze them using security tools in automatic
pipelines. Consequently, DevSecOps is not yet consistently applied by IaC maintainers.
 14
Table 2 Evolution of vulnerabilities across the versions of IaC component samples using Snyk and Horusec Part 1
Snyk Manifests
∗ EATPINE: EC2 API termination protection is not enabled, EIAI: EC2 instance accepts IMDSv1, LBIIF: Load balancer is internet facing, NERBD: Non-Encrypted root block device, COPUCCWHU: Container’s or Pod’s UID could clash with host’s UID, RCBD: Redis Cache backup disabled
∗ COPIRWPEC: Container or Pod is running without privilege escalation control, KVAPPD: Key Vault accidental purge prevention disabled, SADNELT: Storage Account does not enforce latest TLS
∗ CIRWML: Container is running without memory limit, CIRWLP: Container is running without liveness probe, COPIRWWRF: Container or Pod is running with writable root filesystem, CHNCL: Container has no CPU limit, CDNDADC: Container does not drop all default capabilities
∗ COPIRWRUC: Container or Pod is running without root user control, ROCIUAPR: RoleBinding or ClusterRoleBinding is using a pre-defined role, VNDPPD: Virtual Network DDoS protection plan disabled, ASAD: App Service authentication disabled, VKEDNS: Vault key expiration date not set
∗ CCBRWOI: Container could be running with outdated image, COPIRWRUC: Container or Pod is running without root user control, ASIM: App Service identity missing, VAINPAFW: VM Agent is not provisioned automatically for Windows, GRFACID: Geo replication for Azure Container Images disabled
∗ TMSATSAD: Trusted Microsoft Service access to storage account is disabled, ASMTD: App Service mutual TLS disabled, ASHD: App Service HTTP/2 disabled, CAAFD: CosmosDB account automatic failover disabled, CIIDFA: Container Insights is disabled for AKS, ANPD: AKS Network Policies disabled
∗ ASSINUSI: Azure Search Service is not using system-assigned identities, ASSEAID: Azure SQL server extended auditing is disabled, TMIPP: Traffic Manager insecure probing protocol, KVPPID: Key Vault purge protection is disabled, SAGD: Storage Account geo-replication disabled
∗ AASAHT: Azure App Service allows HTTP traffic, UTOMASPI: Use two or more App Service Plan instances, ETRAIRFTI: Ensure that RDP access is restricted from the internet, AMAAATDP: API Management allows anonymous access to developer portal, EDSCAC: Ensure Diagnostic Setting captures appropriate categories
∗ ETSAIRFTI: Ensure that SSH access is restricted from the internet, ANSGAPA: Azure Network Security Group allows public access, CEHNE: CDN Endpoint https not enforced, CAPNAE: CosmosDB account public network access enabled, RUATDOIACD: Restrict user access to data operations in Azure Cosmos DB
∗ RCMTV: Redis Cache minimum TLS version, ANSRAPA: Azure Network Security Rule allows public access, ASAFD: App Service allows FTP deployments, VMICWPAFA: Virtual machine is configured with password authentication for admin, LVMHPAE: Linux virtual machine has password authentication enabled
∗ ASSPNAE: Azure Search service public network access enabled, ASNRLNV: App Service not running latest .Net version, ASDNUPLS: App Service does not use production level SKU, ASNRLJV: App Service not running latest Java version, SCAPA: Storage container allows public access
∗ WVSSEAHD: Windows VM scale set encryption at host disabled, AKDE: AKS Kubernetes Dashboard enabled, ASRDE: App Service remote debugging enabled, DFPAE: Data Factory public access enabled
∗ AGDNUO3R: App Gateway does not use OWASP 3.x rules, PSMTV1.2: PostgreSQL server minimum TLS version 1.2, SFDNUADA: Service fabric does not use active directory authentication, ASAPA: API Server allows public access
∗ FABAD: Function App built-in authentication disabled, PALFSC&BIE: Public access level for storage containers & blobs is enabled, DFNEWCMK: Data Factory not encrypted with customer managed key, FADNEH: Function App does not enforce HTTPS

Name V1 V2 V3 V1 Instances V2 Fixed V2 New V2 Same V3 Fixed V3 New V3 Same

Ansible (T) v1.0 v2.0.0-0.1.alpha1 v2.15.2 0 0 0 0 0 0 0
EATPINE:91/EIAI:91/
Terraform (T) v0.1.0 v1.0.0 v1.6.0-alpha20230719 0 0 0 0 0 0
LBIIF:1/NERBD:91
Chef (T) v17.0.0 v18.0.0 v18.2.44 0 0 0 0 0 0 0
Puppet (T) 7.0.0 8.0.0 upstream/0.25.5 0 0 0 0 0 0 0
Vagrant (T) v1.0.0 v2.0.0 v2.3.7 0 0 0 0 0 0 0
COPUCCWHU:1/COPIRWWRF:1/
COPUCCWHU:1/COPIRWWRF:1/
CIRWML:1/ROCIUAPR:1/
CIRWML:1/ROCIUAPR:1/
CHNCL:1/COPIRWRUC:1/
ansible-for-devops (S) 1.0 2.0 2.2 0 0 0 0 0 CHNCL:1/COPIRWRUC:1/
COPIRWPEC:1/CIRWLP:1/
COPIRWPEC:1/CIRWLP:1/
CCBRWOI:1/
CCBRWOI:1/CDNDADC:1
CDNDADC:1
vagrant-scripts (S) 2.0.4 2.3.0 3.0.0 0 0 0 0 0 0 0
terraform-generator (S) v3.0.0 v4.0.0 v5.3.1 0 0 0 0 0 0 0
community.general (S) 6.0.0 7.0.0 7.2.1 0 0 0 0 0 0 0
NetBeansPuppet (S) v1.2 v2.0.0 V2.0.3 0 0 0 0 0 0 0
soccer-stats (X) v0.0.1 v0.0.2 NA 0 0 0 0 0 0 0
ansible-runner (X) 1.0.1 2.0.0 2.3.3 0 0 0 0 0 0 0
CCBRWOI:3/CHNCL:3/
CCBRWOI:2/CHNCL:2/
CCBRWOI:2/CHNCL:2/ COPIRWWRF:4/COPIRWRUC:4/
COPIRWWRF:3/COPIRWRUC:3/
COPIRWWRF:3/COPIRWRUC:3/ CDNDADC:3/COPIRWPEC:4/
CDNDADC:2/COPIRWPEC:3/
CCBRWOI:1/CHNCL:1/ CDNDADC:2/COPIRWPEC:3/ AMAAATDP:1/KVAPPD:3/
KVAPPD:2/VNDPPD:14/
COPIRWWRF:1/COPIRWRUC:1/ KVAPPD:2/VNDPPD:14/ VNDPPD:35/TMSATSAD:23/
TMSATSAD:11/ASAD:10/
CDNDADC:1/COPIRWPEC:1/ TMSATSAD:11/ASAD:10/ ASAD:2/ASIM:2/ASMTD:2/
ASIM:13/ASMTD:13/
KVAPPD:1/VNDPPD:21/ ASIM:13/ASMTD:13/ ASHD:2/COPUCCWHU:4/
ASHD:13/COPUCCWHU:3/
TMSATSAD:12/AMAAATDP:1/ ASHD:13/COPUCCWHU:3/ CIRWML:3/CIRWLP:3/
CIRWML:2/CIRWLP:2/
EDSCAC:3/DFNEWCMK:2/ CIRWML:2/CIRWLP:2/ EDSCAC:3/VAINPAFW:3/
VAINPAFW:3/GRFACID:1/ ASNRLNV:5/ASDNUPLS:3/
COPUCCWHU:1/CIRWML:1/ VAINPAFW:3/GRFACID:1/ GRFACID:1/CAAFD:2/
ASNRLJV:1/ASRDE:4/
CIRWLP:1/CAAFD:2/ CAAFD:1/VKEDNS:1/ VKEDNS:2/DFNEWCMK:2/
CAAFD:1/VKEDNS:1/ AKDE:16/FADNEH:3/FABAD:3/ KVAPPD:1/VNDPPD:6/
VKEDNS:1/CIIDFA:3/ CIIDFA:6/ANPD:6/RCBD:3/ CIIDFA:9/ANPD:8/RCBD:3/
CIIDFA:6/ANPD:6/RCBD:3/ PALFSC&BIE:2/ASAD:8/ TMSATSAD:3/CIIDFA:1/
ANPD:2/SAGD:10/ ASSINUSI:1/SAGD:7/ ASSINUSI:1/SAGD:17/
terraform-provider-azurerm (X) v2.0.0 v3.0.0 v3.67.0 ASSINUSI:1/SAGD:7/ 0 ASIM:11/ASMTD:11/ KVPPID:1/SAGD:3/
ASSEAID:4/KVPPID:2/ ASSEAID:1/TMIPP:3/ ASSEAID:5/TMIPP:3/
ASSEAID:1/TMIPP:3/ ASHD:11/CAAFD:1/ ETRAIRFTI:1/ANSGAPA:1/
SADNELT:15/UTOMASPI:3/ KVPPID:2/SADNELT:11/ KVPPID:3/SADNELT:26/
KVPPID:2/SADNELT:11/ UTOMASPI:14/AASAHT:11/ VMICWPAFA:1/LVMHPAE:1
ANSGAPA:2/CAPNAE:2/ UTOMASPI:13/AASAHT:13/ UTOMASPI:2/AASAHT:2/
UTOMASPI:13/AASAHT:13/ CAPNAE:1/RUATDOIACD:1/
RUATDOIACD:2/ASAPA:3/ ETRAIRFTI:1/ANSGAPA:1/ ETRAIRFTI:1/ANSGAPA:3/
ETRAIRFTI:1/ANSGAPA:1/ ASAFD:11
VMICWPAFA:4/LVMHPAE:1/ CEHNE:1/CAPNAE:2/ CEHNE:1/CAPNAE:3/
CEHNE:1/CAPNAE:2/
SCAPA:2/DFPAE:2/AGDNUO3R:1/ RUATDOIACD:2/ASAPA:7/ RUATDOIACD:3/ASAPA:10/
RUATDOIACD:2/ASAPA:7/
PSMTV1.2:2/SFDNUADA:1/ RCMTV:3/ANSRAPA:1/ RCMTV:3/ANSRAPA:1/
RCMTV:3/ANSRAPA:1/
WVSSEAHD:1/AKDE:16/ ASAFD:13/VMICWPAFA:3/ ASAFD:2/VMICWPAFA:7/
ASAFD:13/VMICWPAFA:3/
FADNEH:3/FABAD:3/ LVMHPAE:1/SCAPA:1/ LVMHPAE:2/SCAPA:3/
LVMHPAE:1/SCAPA:1/
PALFSC&BIE:2 ASSPNAE:1/ASNRLNV:5/ ASSPNAE:1/DFPAE:2/
ASSPNAE:1/ASNRLNV:5/
ASDNUPLS:3/ASNRLJV:1/ WNEOAG:1/AGDNUO3R:1/
ASDNUPLS:3/ASNRLJV:1/
ASRDE:4 PSMTV1.2:2/SFDNUADA:1/
ASRDE:4
WVSSEAHD:1
cookstyle (X) v6.0.0 v7.0.0 v7.32.3 0 0 0 0 0 0 0
pulumi-datadog (X) v3.0.0 v4.0.0 v4.21.0 0 0 0 0 0 0 0
∗ In the Name Column: T=tools, S= scripts, X=add-ons
∗ NA: Not Available

Aicha WAR et al.

 Security Vulnerabilities in Infrastructure as Code: What, How Many, and Who?
Table 3 Evolution of vulnerabilities across the versions of IaC component samples using Snyk and Horusec Part 2
Snyk Code
∗ PT: Path Traversal, PHWICE: Password Hash With Insufficient Computational Effort, HC: Hardcoded Credentials, CI: Cryptographic Issues, SSRF: Server-Side Request Forgery, IES: Inadequate Encryption Strength, BRCA: Broken or Risky Cryptographic Algorithm
∗ JAE: Jinja auto-escape set to false, IND: Improper Neutralization of Directives, ReDos: Regular Expression Denial of Service, DUD: Deserialization of Untrusted Data, NHV: no hostname verification, IXP: Insecure Xml Parser, ITF: Insecure Temporary File
∗ MPSSL: Missing protocol in ssl.wrap-socket, CTL: Clear Text Logging, HS: Hardcoded Secret, P2SC: Python 2 source code, ICV: Improper Certificate Validation, CInj: Command Injection, XSS: Cross-site Scripting, AFW: Arbitrary File Write

Name V1 V2 V3 V1 Instances V2 Fixed V2 New V2 Same V3 Fixed V3 New V3 Same

PT:47/HC:7/JAE:6/P2SC:43/ ReDos:1/IES:3/HC:3/
P2SC:24/XSS:1/ICV:1/ DUD:1/ReDos:3/IND:1/AFW:2/ PT:4/PHWICE:2/XSS:1/ ReDos:2/IND:1/XSS:1/
Ansible (T) v1.0 v2.0.0-0.1.alpha1 v2.15.2 0 CInj:13/IXP:5/DUD:1/SSRF:6/ JAE:2/PHWICE:18/DUD:1/
PHWICE:2/PT:4/JAE:2 HC:3/PT:2/IES:3/PHWICE:54 P2SC:24/JAE:2 PHWICE:38/P2SC:24
HS:8/AFW:10/ITF:1 AFW:2/PT:4
XSS:1/SSRF:1/CTL:1/ICV:1/ XSS:1/SSRF:1/CTL:1/ICV:1/
Terraform (T) v0.1.0 v1.0.0 v1.6.0-alpha20230719 HS:1/CInj:1/PT:1/PHWICE:2 CInj:1/PT:1 HS:1/PHWICE:2 0 CInj:2/PHWICE:2
HS:2/IES:1/PHWICE:19/PT:3 HS:3/IES:1/PHWICE:21/PT:3
Chef (T) v17.0.0 v18.0.0 v18.2.44 HC:30/PT:1/P2SC:4 P2SC:3/PT:1 HC:6 HC:30 HC:4 0 HC:32
Puppet (T) 7.0.0 8.0.0 upstream/0.25.5 HC:17/BRCA:1 0 0 HC:17/BRCA:1 0 0 HC:17/BRCA:1
Vagrant (T) v1.0.0 v2.0.0 v2.3.7 ICV:1/P2SC:1 ICV:1/P2SC:1 HC:13/BRCA:1 0 BRCA:1 HC:11 HC:13
ansible-for-devops (S) 1.0 2.0 2.2 P2SC:4 P2SC:4 0 0 0 0 0
vagrant-scripts (S) 2.0.4 2.3.0 3.0.0 0 0 0 0 0 0 0
terraform-generator (S) v3.0.0 v4.0.0 v5.3.1 0 0 0 0 0 0 0
HC:3/PT:1/HS:21/MPSSL:2/ HC:3/PT:1/HS:21/MPSSL:2/ HC:3/PT:1/HS:21/MPSSL:2/
community.general (S) 6.0.0 7.0.0 7.2.1 0 0 0 0
IXP:7/NHV:4/PHWICE:8 IXP:7/NHV:4/PHWICE:8 IXP:7/NHV:4/PHWICE:8
NetBeansPuppet (S) v1.2 v2.0.0 V2.0.3 0 0 0 0 0 0 0
soccer-stats (X) v0.0.1 v0.0.2 NA 0 0 0 0 0 0 0
ansible-runner (X) 1.0.1 2.0.0 2.3.3 PT:1 PT:1 PT:4 0 PT:4 CI:1 0
HC:23/PHWICE:25/PT:5/
terraform-provider-azurerm (X) v2.0.0 v3.0.0 v3.67.0 HC:23/PT:5 PT:1/PHWICE:6 PHWICE:9/IES:1/SSRF:1 0 CTL:1/HC:20/PHWICE:3/PT:5 PHWICE:15/IES:1/PT:1/SSRF:1
IES:1/SSRF:1
cookstyle (X) v6.0.0 v7.0.0 v7.32.3 0 0 0 0 0 0 0
pulumi-datadog (X) v3.0.0 v4.0.0 v4.21.0 0 0 0 0 0 0 0
Snyk Dependencies
∗ DoS: Denial of Service, RCE: Remote Code Execution, IPSp: IP Spoofing, IE: Information Exposure, AFEE: Arbitrary File Existence Exposure, DLL: DLL Loading Issue, DT: Directory Traversal, CSRF: Cross-site Request Forgery
∗ ACI: Arbitrary Code Injection, WCP: Web Cache Poisoning, IIV: Improper Input Validation, XEE: XML External Entity, ACB: Access Control Bypass, IHUDT: Improper Handling of Unexpected Data Type, NPD: NULL Pointer Dereference, IPM: Improper Privilege Management

Ansible (T) v1.0 v2.0.0-0.1.alpha1 v2.15.2 0 0 0 0 0 0 0

ReDos:5/DoS:18/XSS:13/ ReDos:5/DoS:18/XSS:13/
Terraform (T) v0.1.0 v1.0.0 v1.6.0-alpha20230719 IPSp:4/IE:4/AFEE:1/ACI:3/ IPSp:4/IE:4/AFEE:1/ACI:3/ 0 0 0 0 0
DLL:2/DUD:2/WCP:1 DLL:2/DUD:2/WCP:1
ReDos:19/DoS:8/XSS:1/ DUD:2/ReDos:16/DoS:6/
Chef (T) v17.0.0 v18.0.0 v18.2.44 ReDos:3/DoS:2/IIV:1 XSS:1/DUD:3/ACI:1 DUD:5/ReDos:16/DoS:6/ACI:4 WCP:1 XSS:2/WCP:1
IIV:1/DUD:2/ACI:3/WCP:1 XSS:1/WCP:1/ACI:3
Puppet (T) 7.0.0 8.0.0 upstream/0.25.5 0 0 0 0 0 0 0
ACI:1/XEE:3/XSS:9/DT:3/ ACI:1/XEE:3/XSS:9/DT:3/
ReDos:3/DoS:11/ACB:1/ ReDos:3/DoS:11/ACB:1/
Vagrant (T) v1.0.0 v2.0.0 v2.3.7 0 0 0 0 0
IE:1/CSRF:1/IHUDT:1/WCP:1/ IE:1/CSRF:1/IHUDT:1/WCP:1/
NPD:1/CInj:1/RCE:1 NPD:1/CInj:1/RCE:1
ansible-for-devops (S) 1.0 2.0 2.2 0 0 0 0 0 0 0
vagrant-scripts (S) 2.0.4 2.3.0 3.0.0 0 0 0 0 0 0 0
terraform-generator (S) v3.0.0 v4.0.0 v5.3.1 IPM:1/ReDos:2 0 0 IPM:1/ReDos:2 IPM:1/ReDos:2 0 0
community.general (S) 6.0.0 7.0.0 7.2.1 0 0 0 0 0 0 0
NetBeansPuppet (S) v1.2 v2.0.0 V2.0.3 0 0 0 0 0 0 0
soccer-stats (X) v0.0.1 v0.0.2 NA 0 0 0 0 0 0 0
ansible-runner (X) 1.0.1 2.0.0 2.3.3 0 0 0 0 0 0 0
terraform-provider-azurerm (X) v2.0.0 v3.0.0 v3.67.0 0 0 0 0 0 0 0
cookstyle (X) v6.0.0 v7.0.0 v7.32.3 0 0 0 0 0 0 0
pulumi-datadog (X) v3.0.0 v4.0.0 v4.21.0 0 0 0 0 0 0 0
Horusec
∗ APK: Asymmetric Private Key, LDAPInj: LDAP Injection, HC: Hardcoded Credentials, HP: Hardcoded Password, WRNG: Weak Random Number Generator, SSRF: Server-Side Request Forgery, AWS: AWS Secret Key, NDH: No Default Hash, NUPA: No Use Prohibited APIs
∗ BRCA: Broken or Risky Cryptographic Algorithm, ESI: Exposure of Sensitive Information, MCSPH: Missing Content-Security-Policy header, PC: Privileged Container, ShOS: Using shell interpreter when executing OS commands, PHC: Potential Hard-coded Credential
HP:2/PHC:4/ HP:10/PHC:8/ASK:1/ HP:2/PHC:4/ DSSNBE:1/OSBVDCOC:1/ HP:36/PHC:5/ASK:1/
Ansible (T) v1.0 v2.0.0-0.1.alpha1 v2.15.2 0 HP:12/APK:7
DSSNBE:1/OSBVDCOC:1 APK:5 DSSNBE:1/OSBVDCOC:1 PHC:7 APK:5
APK:1/HP:5/PHC:7/ NUWRNG:2/DSSNBE:1/ APK:4/HP:13/PHC:6/
Terraform (T) v0.1.0 v1.0.0 v1.6.0-alpha20230719 ASK:2/HP:8/APK:3 APK:1/HP:5/PHC:6 0 APK:4/HP:3
NUWRNG:2/DSSNBE:1/OSBVDCOC:1 OSBVDCOC:1/PHC:1 ASK:2
PFIHU:5/APK:32/HP:25/ PFIHU:5/APK:32/HP:25/ PFIHU:5/APK:48/HP:26/
Chef (T) v17.0.0 v18.0.0 v18.2.44 0 APK:19/HP:3/PHC:3 HP:2/APK:3 0
PHC:1 PHC:1 PHC:4
HP:42/ASK:1/APK:31/ HP:33/ASK:1/APK:31/ HP:33/ASK:1/APK:36/
Puppet (T) 7.0.0 8.0.0 upstream/0.25.5 HP:9 APK:5 PFIHU:5 0
IRORULF:1/PFIHU:10 IRORULF:1/PFIHU:10 IRORULF:1/PFIHU:5
MXCTOH:1/EOSI:1/HP:1/ MXCTOH:1/EOSI:1/HP:1/ MXCTOH:1/HP:13/PHC:3/ MXCTOH:1/PHC:3/PFIHU:1/ MXCTOH:1/EOSI:1/HP:5/
Vagrant (T) v1.0.0 v2.0.0 v2.3.7 0 HP:13
PFIHU:2/MCSPH:1 MCSPH:1/PFIHU:2 PFIHU:1/MCSPH:1 MCSPH:1 PHC:1/PFIHU:5/APK:1
ansible-for-devops (S) 1.0 2.0 2.2 0 0 HP:8/APK:4/PC:6 0 HP:1 0 HP:7/PC:6
vagrant-scripts (S) 2.0.4 2.3.0 3.0.0 0 0 0 0 0 0 0
terraform-generator (S) v3.0.0 v4.0.0 v5.3.1 0 0 ShOS:1 0 0 0 ShOS:1
community.general (S) 6.0.0 7.0.0 7.2.1 0 0 PHC:187/HP:312/APK:30 0 APK:1 PHC:12/HP:17 PHC:187/HP:312/APK:29
NetBeansPuppet (S) v1.2 v2.0.0 V2.0.3 0 0 NUPA:1/NDH:2 0 0 0 NUPA:1/NDH:2
soccer-stats (X) v0.0.1 v0.0.2 NA NDH:1 0 0 NDH:1 0 0 0
ansible-runner (X) 1.0.1 2.0.0 2.3.3 0 0 HP:1 0 0 HP:2 HP:1
APK:7/ASK:17/ HP:22/PHC:1/LSK:3/ APK:7/ASK:7/HP:260/ LCI:1/APK:15/HP:93/ APK:17/HP:282/PHC:49/
terraform-provider-azurerm (X) v2.0.0 v3.0.0 v3.67.0 ASK:10 LSK:1
HP:260/PHC:48 APK:10/TCI:5 PHC:48 PHC:53/ASK:87 ASK:7/LSK:2/TCI:5
cookstyle (X) v6.0.0 v7.0.0 v7.32.3 0 0 0 0 0 PHC:3 0
pulumi-datadog (X) v3.0.0 v4.0.0 v4.21.0 APK:6/PHC:5 APK:6/PHC:5 LSK:12 0 LSK:12 HP:1/APK:3/NUE:1/PHC:33 0
∗ In the Name Column: T=tools, S= scripts, X=add-ons
∗ NA: Not Available

15
16 Aicha WAR et al.

Besides the evolution of vulnerabilities in IaC projects, our study investigates how maintainers actually address them.
To that end, we mine commit messages that are associated to source code changes, as well as bug reports submitted on
the project repository issue tracking system. It is noteworthy that some mentioned vulnerabilities are the same detected
by the SAST tools: Remote Code Execution (RCE), Arbitraty Code Execution, Directory Transversal, Deserialization of
Untrusted Data, Cleartext Password, Insecure Hash, Hardcoded Admin, Container Auth. We also observe that while some
issues were reported to be fixed, some were just marked without any clear action. Due to the use of specific names, we
also found that maintainers use linters in IaC to address vulnerabilities in specific tools, such as Ansible, Terraform, Chef,
etc. (For more details on linter detection, cf. Methodology in Section 3). Furthermore, from Github commit messages,
we observe that maintainers fix some vulnerabilities by updating or creating new features (mostly configuration features).
They also add vulnerable code warnings for some dependencies.

Overall, mining IaC projects has revealed that IaC maintainers display, to some extent, a proactive approach
towards addressing vulnerabilities. Unfortunately, the recurrence of some vulnerabilities within and accross
releases suggest that IaC development does build on established automatic practices and routines for consistent
and systematic detection and fixing of vulnerabilities.

4.4 IaC vulnerabilties: What, Where and Who?

In this section, we further dig into the details of IaC vulnerabilities to present the results in terms of IaC components,
severity, file, programming languages, etc.

4.4.1 Occurrences and Severity of vulnerabilities

We summarize the occurrences of vulnerabilities and their severity for IaC components based on Horusec and Snyk (Snyk
code, Snyk manifest, and Snyk IaC, respectively for source code, dependencies, and manifest files security testing). From
Figures 10 and 11, we note large differences in terms of vulnerability occurrences depending on the SAST tool and
component.

Fig. 11 Vulnerabilities reported by SAST tools in IaC scripts and add-ons.

Fig. 10 Vulnerabilities reported by SAST tools on IaC tools.

Although Horusec and Snyk agree on some instances of vulnerabilities 1 in IaC components, Horusec reveals substan-
tially more occurrences of issues. Indeed, Horusec not only reports any vulnerabilities that is recognized to be associated
to a given weakness (CWE), but also the issues that it considers as potential vulnerabilities(ex: Hardcoded-password vs
Potential Hardcoded-password). On the other hand, Snyk will only report vulnerabilities that relate to CVEs.
Security Vulnerabilities in Infrastructure as Code: What, How Many, and Who? 17

Fig. 13 Severity of vulnerabilities in IaC scripts and add-ons.

Fig. 12 Severity of vulnerabilities in IaC tools.

In terms of severity, the analysis results show that all IaC tools are affected largely more by vulnerabilities that are
tagged as “critical” than others. Actually, vulnerabilities tagged with high to low severity scores are minimal. On the
other hand, IaC scripts and add-ons have more critical and high-severity vulnerabilities than medium to low-security ones.
Despite the fact that Snyk results 1 have more Medium to Low severity vulnerabilities, Horusec’s huge vulnerability
proportions make it insignificant in the overall results.
We further observe that while SAST tools may find the same types of vulnerabilities, they assess their severity based on
different standards and parameters. Nevertheless, all the vulnerabilities reported by Snyk and Horusec are either involving
CVEs or associated to known CWEs. This suggests that they are significant in terms of potential exploitability. Therefore,
regardless of their severity, exploiting those vulnerabilities can lead to significant impact on IaC.

4.4.2 Vulnerable files and programming languages propensities

In previous sections, the vulnerability distributions have been presented in terms of occurrences by origin, i.e., within tools,
scripts, and add-ons. We propose to investigate another dimension, i.e., localization in terms of file types and affected code
by programming language.

Fig. 14 Vulnerabilities reported by SAST tools in IaC tools by source file

Fig. 15 Propensities of vulnerable files on IaC scripts and add-ons
type.

Figure 14 summarizes the occurrences of vulnerabilities in IaC tools per file type. Python and JSON files appear to be
the most affected by IaC vulnerabilities. In contrast, certificate files (.pem, .crt) contain few vulnerabilities. It is noteworthy
18 Aicha WAR et al.

that in absolute numbers, most vulnerabilities are in Python, JSON and Ruby files, which are common programming
languages used in IaC. Furthermore, Python and JSON files represent common configuration files, which are pervasive in
IaC tools written in those languages (cf. Table 4).

Table 4 Languages used to program our dataset of IaC tools

IaC tools Ansible Terraform Chef Puppet Pulumi Vagrant Saltstack

Programming Languages Python Go Ruby Ruby Go Ruby Python

Figure 15 illustrates how, in contrast to the case of IaC tools, vulnerabilities of IaC scripts and add-ons are mainly
located in general-purpose programming language files (e.g., .java, .rb, .py, etc).
Configuration files, which are core IaC files, are significantly affected by vulnerabilities in IaC. Our study further
reveals that such vulnerabilities are often labeled as being severe. We postulate that a community effort to
systematically address vulnerabilities in Manifest files will substantially improve IaC security in various axes,
including authentication, access control, etc.

4.4.3 DevOps profiles investigation

After investigating the origin and location of the widespread vulnerabilities within IaC, we study who (between developers
and IT operators) bears the responsibilities of introducing them.
We explore the list of edited files on our dataset of IaC tools repositories. The most redundant ones (Table 5) are usual
development files (rb, go, js, html, etc.), manifest files (YAML files, JSON files, etc.), specification/configuration files
(toml, spec, etc.), and script files (sh) in this order. These results show that development files are more involved in the
making of IaC tools than operation files. Therefore, the profile of those who create infrastructure tools is probably that of
developers. However, we observe that development files (.js, .go, etc.) contain the least vulnerabilities inside IaC tools in
Figure 14 compared to manifest files except for Python and Ruby files. This is because, in the context of Infrastructure
as Code, these two specific files are strongly used for IaC 4. Consequently, manifest files and most of the development
files, which are the most edited files in IaC tools repositories, are likely to be manipulated by operation specialists. We
validated this hypothesis from samples of IaC tools’ projects (cf. Table 2) by manually investigating the GitHub profiles
of maintainers who edited manifest files to determine their specialization. Furthermore, after we manually investigated the
edits from these maintainers on those IaC tools, we could match them with the vulnerabilities that Snyk and Horusec had
detected in those projects. Overall, we observed that IT operators are mainly responsible for introducing vulnerabilities in
IaC tools’ environments.
On the other hand, we investigated the list of edited files in IaC scripts and add-ons source code. Notably, we have 5
types of files that are often affected as illustrated in Table 6. Those are Python files, reStructuredText files (.rst), Nullsoft
Scriptable Install System files (.nsi), YAML/YML files, and shell files. We thus note that the most edited files in IaC
scripts and add-ons components are all operation files. Nevertheless, they were not the most vulnerable files reported (cf.
Figure 15).
In addition, we observe that on the OWASP list of vulnerabilities, manifest vulnerabilities (Table 1) barely have high-
severity vulnerabilities and zero critical vulnerabilities. We also note that there are more files that match with developers
profile, like Java, PHP, or JavaScript files in Table 6 than in Table 5. These results suggest that developers are the
most responsible for vulnerabilities inside IaC scripts and add-ons environments. We again manually investigated the
specialization of maintainers who edited development files from the samples of scripts and add-ons in Table 2 based
on their GitHub profiles, and confirm that These maintainers indeed mainly have developer profiles. From the manual
checking of their edits on development files, we could match some of them with the vulnerabilities our SAST tools had
detected. Overall, we can confirm that developers introduce more vulnerabilities in scripts and add-ons.
Security Vulnerabilities in Infrastructure as Code: What, How Many, and Who? 19

Table 5 List of files edited by IaC tools maintainers

Files extensions Ansible Terraform Chef Puppet Pulumi Vagrant Saltstack
Table 6 List of files edited by IaC scripts and add-ons maintainers
.yml/.yaml 3,259 127 1,918 538 999 5,775 171
.json 0 966 95 0 170 174 0 Files extensionsAnsible Terraform Chef Puppet Pulumi Vagrant Saltstack
.py 102,108 0 0 0 1,245 0 394,750
.rb 0 50 945,912 1,235 0 95,748 0 .yml/.yaml 60,162 5,612 960 590 2,960 1,891 111
.go 0 97,844 0 0 53,463 1,313 0 .json 1,104 13,493 401 147 181 333 172
.js 234 2 0 0 76 0 0
.sh 55 44 0 0 110 56 132
.py 162 270 905 1332 107 400 212
.gemspec 0 0 576 208 0 298 0 .rb 63 896,448 2,012 1,448 1,512 604 1,296
.erb 0 2,328 0 78 0 300 0 .go 3,077 996 189 0 222 546 954
.mod 0 365 0 0 820 106 0
.sum 0 370 0 0 426 107 0
.sh 305 604 1,400 194 82 1,890 320
.cs 0 0 0 0 138 0 0 .php 126 738 4,719 111 119 0 25
.proto 0 0 0 0 142 68 0 .java 1,090 244 322 1,030 200 484 19,740
.spec 118 0 0 8 0 28 0
.ts 0 0 0 0 3,768 0 0 .js 201 214 396 2,058 94 168 204
.rst 58 0 0 0 0 0 5,252 .xml 2,408 140 189 1,440 45 744 51,420
.toml 0 0 53 0 0 0 0
.html 2,100 0 0 0 0 0 0

Investigations into contributors of IaC vulnerability reveal that IT operators are mainly responsible for vulner-
abilities in IaC tools, while developers are more responsible to those that occur in IaC scripts and add-ons.
Therefore, we confirm that in IaC, similarly to other settings, vulnerabilities are likely to be introduced when an
actor (e.g. an IT operator) modifies components outside of his/her area of expertise (e.g. IaC tool).

5 Conclusion

In this study, we have provided a comprehensive investigation into the security landscape of Infrastructure as Code (IaC)
through its main components: tools, scripts, and add-ons. Leveraging the analysis capabilities of Snyk and Horusec, we
analyzed a large number of component repositories. In every repository, we analyzed three main vulnerability origins:
the code, the dependencies, and the manifests, and we categorized the different security issues according to the OWASP
top 10 taxonomy. Our findings have unveiled key insights: i) Vulnerabilities are widespread across all IaC components
with every one of the 10 OWASP vulnerability types manifesting across each analyzed component; ii) Although IaC
maintainers demonstrate a proactive stance toward vulnerabilities, they do not seem to follow standard automatic practices
and routines to check for the existence of such issues consistently and systematically, iii) Manifest files emerge as the
most vulnerable artifacts within the IaC ecosystem, iv) IaC vulnerabilities frequently stem from non-specialized actors
attempting modifications within components outside their expertise. These findings collectively underscore the critical
importance of reinforcing security awareness among IaC developers and operators. The imperative is to galvanize a
paradigm shift towards the systematic adoption of DevSecOps within DevOps teams. By integrating security checks into
the heart of IaC component development, we can facilitate the continual evolution of secure IaC environments. As future
work, we will focus on advancing techniques for the more precise characterization and detection of vulnerabilities within
Infrastructure as Code manifests.

References

1. A. Rahman, in 2018 IEEE 11th International Conference on Software Testing, Verification and Validation (ICST) (2018), pp. 434–435. DOI
10.1109/ICST.2018.00057
2. A. Rahman, C. Parnin, L. Williams, in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE) (IEEE, 2019), pp. 164–175
3. N. Palix, G. Thomas, S. Saha, C. Calvès, J.L. Lawall, G. Muller, in ASPLOS 2011 - 16th International Conference on Architectural Support for
Programming Languages and Operating Systems (ACM, Newport Beach, California, United States, 2011), pp. 305–318. DOI 10.1145/1950365.
1950401. URL https://hal.archives-ouvertes.fr/hal-00940355
4. A. Verdet, M. Hamdaqa, L. Da Silva, F. Khomh, arXiv preprint arXiv:2308.03952 (2023)
5. P.R. Reddy Konala, V. Kumar, D. Bainbridge, in 2023 IEEE International Conference on Cyber Security and Resilience (CSR) (2023), pp. 281–288.
DOI 10.1109/CSR57506.2023.10224925
6. M. Hasan, F.A. Bhuiyan, A. Rahman, (2020), pp. 7–12. DOI 10.1145/3416504.3424334
20 Aicha WAR et al.

7. M. Cankar, N. Petrovic, J. Pita Costa, A. Cernivec, J. Antic, T. Martincic, D. Stepec, in Companion of the 2023 ACM/SPEC International Conference
on Performance Engineering (Association for Computing Machinery, New York, NY, USA, 2023), ICPE ’23 Companion, p. 201–205. DOI
10.1145/3578245.3584943. URL https://doi.org/10.1145/3578245.3584943
8. N. Petrović, preprint (2023)
9. R. Opdebeeck, A. Zerouali, C. De Roover, in 2023 IEEE/ACM 20th International Conference on Mining Software Repositories (MSR) (2023), pp.
534–545. DOI 10.1109/MSR59073.2023.00079
10. S. Reis, R. Abreu, M. d’Amorim, D. Fortunato, in Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering
(Association for Computing Machinery, New York, NY, USA, 2023), ASE ’22. DOI 10.1145/3551349.3560419. URL https://doi.org/10.
1145/3551349.3560419
11. K. Morris, Infrastructure as Code (O’Reilly Media, 2020). URL https://books.google.lu/books?id=R24NEAAAQBAJ
12. A. Rahman, M.R. Rahman, C. Parnin, L. Williams, ACM Trans. Softw. Eng. Methodol. 30(1) (2021). DOI 10.1145/3408897. URL https:
//doi.org/10.1145/3408897
13. A. Rahman, L. Williams, IEEE Security & Privacy 19(3), 33 (2021). DOI 10.1109/MSEC.2021.3065190
14. A.A.U. Rahman, L.A. Williams, Proceedings of the Symposium and Bootcamp on the Science of Security (2016)
15. V. Mohan, L.B. Othmane, in 2016 11th International Conference on Availability, Reliability and Security (ARES) (2016), pp. 542–547. DOI
10.1109/ARES.2016.92
16. A. Rahman, E. Farhana, C. Parnin, L. Williams, in 2020 IEEE/ACM 42nd International Conference on Software Engineering (ICSE) (2020), pp.
752–764. DOI 10.1145/3377811.3380409
17. A. Hortlund. Security smells in open-source infrastructure as code scripts: A replication study (2021)
18. S. Almuairfi, M. Alenezi, Computer Fraud & Security 2020(10), 13 (2020)
19. A. Ibrahim, A.H. Yousef, W. Medhat, in 2022 2nd International Mobile, Intelligent, and Ubiquitous Computing Conference (MIUCC) (IEEE, 2022),
pp. 284–288
20. R. Druta, N. Botosan-Bora, M. Iovan, D.S. Cruzes, Available at SSRN 4461951
21. M. Guerriero, M. Garriga, D.A. Tamburri, F. Palomba, in 2019 IEEE international conference on software maintenance and evolution (ICSME)
(IEEE, 2019), pp. 580–589
22. A. Rahman, L. Williams, IEEE Security & Privacy 19(3), 33 (2021)
23. M. Chiari, M. De Pascalis, M. Pradella, in 2022 IEEE 19th International Conference on Software Architecture Companion (ICSA-C) (IEEE, 2022),
pp. 218–225
24. N. Petrović, M. Cankar, A. Luzar, in 2022 30th Telecommunications Forum (TELFOR) (IEEE, 2022), pp. 1–4
25. N. Saavedra, J.F. Ferreira, in Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering (2022), pp. 1–12
26. A. Rahman, C. Parnin, IEEE Transactions on Software Engineering 49(6), 3536 (2023). DOI 10.1109/TSE.2023.3265962
27. T.J.A. Ribeiro, An ide plug-in to detect security vulnerabilities in infrastructure-as-code scripts. Ph.D. thesis, Universidade do Porto (Portugal)
(2021)
28. A. War, A. Habib, A. Diallo, J. Klein, T.F. Bissyandé. Security Vulnerabilities in Infrastructure as Code: What, How Many, and Who? URL
https://github.com/Sherlock0001/empirical-study-iac.git
29. N. Cottrell, N. Cottrell, MongoDB Topology Design: Scalability, Security, and Compliance on a Global Scale pp. 151–171 (2020)
30. M. Valkeinen, Cloud infrastructure tools for cloud applications: Infrastructure management of multiple cloud platforms. Master’s thesis (2022)
31. O. Paloviita, et al., (2022)
32. J.E. Castro Sánchez, (2020)
33. L. Houde, D. Jacob, T. Rabemanantsoa, J.F. Rey, Gestion automatique d’environnement virtuel (gaev). Ph.D. thesis, INRAE (2021)
34. A. Rodrı́guez Couto, (2022)
35. A. Rahman, in 2018 IEEE/ACM 40th International Conference on Software Engineering: Companion (ICSE-Companion) (2018), pp. 476–479
36. A. Habib, M. Pradel, in 2018 33rd IEEE/ACM International Conference on Automated Software Engineering (ASE) (2018), pp. 317–328. DOI
10.1145/3238147.3238213
37. C. Cadar, A.F. Donaldson, in Proceedings of the 38th International Conference on Software Engineering Companion (2016), pp. 765–768