The Seven Sins: Security Smells in Infrastructure as Code Scripts

Abstract

Context: Security smells are coding patterns in source code that are indicative of security weaknesses. As infrastructure as code (IaC) scripts are used to provision cloud-based servers and systems at scale, security smells in IaC scripts could be used to enable malicious users to exploit vulnerabilities in the provisioned systems. Goal: The goal of this paper is to help practitioners avoid insecure coding practices while developing infrastructure as code (IaC) scripts through an empirical study of security smells in IaC scripts. Methodology: We apply qualitative analysis with 3,339 IaC scripts to identify security smells for IaC scripts written in three languages: Ansible, Chef, and Puppet. We construct a static analysis tool called Security Linter for Infrastructure as Code scripts (SLIC) to automatically identify security smells in 61,097 scripts collected from 1,093 open source software repositories. We also submit bug reports for 1,500 randomly-selected smell occurrences identified from the 61,097 scripts. Results: We identify nine security smells for IaC scripts. By applying SLIC on 61,097 IaC scripts we identify 64,356 occurrences of security smells that included 9,092 hard-coded passwords. We observe agreement for 130 of the responded 187 bug reports, which suggests the relevance of security smells for IaC scripts amongst practitioners. Conclusion: We observe security smells to be prevalent in IaC scripts. We recommend practitioners to rigorously inspect the presence of the identified security smells in IaC scripts using (i) code review, and (ii) static analysis tools.

Configuration smells in continuous delivery pipelines: a linter and a six-month study on GitLab

“…Previous work has introduced generic [44] or specialized [9,36] linters that can help developers to improve their CD configurations. In contrast to previous work on CI smells that relies on historical information [44], in this paper, we proposed CD-Linter, a static analysis tool able to identify four types of CD smells in CD pipelines, right when they are introduced in the pipeline configuration.…”

“…While those smells are more similar to traditional code smells (i.e., they concern with maintainability and understandability of Puppet code), CD-Linter detects smells specific to the CI/CD configuration where developers violate principles. Rahman et al [36] implemented a linter that detects seven types of security problems in IaC scripts. Their work is complementary to ours as it deals with a very specific category of problems related to IaC scripts.…”

“…Gallaba et al, [9] achieved a high user acceptance when pointing out the misuse of four different configuration options, like executing commands in the wrong build step. Rahman et al [36] focused on security-related issues and Sharma et al [38] on Infrastructure-as-Code (IaC) smells. While these works show that semantic linting of CD pipelines is useful, they do not solve the problem of avoiding CD anti-patterns in configurations files.…”

Automatically detecting risky scripts in infrastructure code

“…Many infrastructure code analysis approaches have been proposed to identify security, availability and reliability issues. SLIC [38] detects seven security smells in Puppet manifests, including admin by default, hard-coded secret, suspicious comments, etc. FSMoVe [41] identifies ordering violations and missing notifiers in Puppet programs, which can cause the infrastructure become unavailable [3] or unreliable [39].…”

Towards Semantic Detection of Smells in Cloud Infrastructure Code

“…In software engineering research, smell detection has been a key topic [16]. Several studies have used a rule-based approach to detect smells in different artifacts such as objectoriented programs [9], service descriptions [10], and infrastructure automation scripts [11,15]. The rule-based approach is also popular in industry, for instance, so-called Lint tools for Docker, Chef, TerraForm, and Puppet, However, mostly, these tools use informal rules, and operate directly on source code.…”