Pith. sign in

REVIEW 4 major objections 4 minor 33 references

A Defect Taxonomy for Infrastructure as Code: A Replication Study

T0 review · 4 major / 4 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A replication study confirms that the 'Gang of Eight' defect taxonomy, originally built from Puppet scripts, applies to programming-language-based IaC tools and to proprietary codebases.

desk verdict Solid replication with real artifacts, but the 'same eight categories' claim rests on three asserted name mappings that need independent validation or a softer conclusion. read the letter →

arxiv 2505.01568 v3 pith:UTPUNGTS submitted 2025-05-02 cs.SE

Wendell Oliveira , Filipe Paiva , Thiago Emmanuel Pereira , João Brunet This is my paper · ORCID
classification cs.SE
keywords infrastructureascodePL-IaCdefecttaxonomyreplicationstudyConfigurationDatadefectsACIDtoolidempotencycommit-levelclassification
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that the eight-category 'Gang of Eight' defect taxonomy, first derived from Puppet scripts, is not an artifact of that single tool. The same eight defect types, it claims, appear in programming-language-based Infrastructure as Code (PL-IaC) tools such as Pulumi, Terraform CDK, and AWS CDK, and also in proprietary codebases from two large companies. The authors manually classified 3,364 defect-related commits from 285 open-source repositories, mapped three of their own category names onto the original names, and ran an enhanced version of the ACID classifier over 541 total repositories. They found Configuration Data to be the most frequent defect category everywhere, with idempotency and security defects rare but persistent, and an overall defect proportion (16.8%) close to the original study's 15.3%. If the claim holds, IaC defect patterns are intrinsic to the practice rather than tool- or organization-specific.

What carries the argument

The argument is carried by two connected mechanisms. The first is the qualitative coding process: two researchers independently applied descriptive coding to Enhanced Commit Messages (commit messages joined with bug-report text), reaching a Cohen's Kappa of 0.78 before reconciling categories. The second is the ACID rule-based classifier, extended for PL-IaC with revised string patterns and three new detection functions (dataNetChanged, dataCredChanged, changedSecu); its validity was checked against an oracle of 22 raters and a 2,000-commit sanity check. The cross-study comparison rests on the mapping that treats the study's Logic, Configuration, and Cloud categories as equivalent to the original Conditional, Configuration Data, and Service categories.

What would settle it

An independent coding pass on the same 3,364 commits by raters who are shown only the original study's category definitions, with no supplied mapping, would settle the claim: if they produce more or fewer than eight categories, or put a category other than Configuration Data at the top, the replication's central confirmation fails. A complementary check is to run the updated ACID tool on the original 291 Puppet repositories; if the eight-category proportions do not reappear, the tool changes have made the two studies incomparable.

Watch

Extended reading notes

Core claim

On its own terms, the paper reports a successful replication of the 'Gang of Eight' defect taxonomy. A manual qualitative analysis of 3,364 defect-related commits from PL-IaC programs produced eight categories that, after mapping three of the study's own names onto the original names (Logic to Conditional, Configuration to Configuration Data, Cloud to Service), are exactly the original study's Conditional, Configuration Data, Dependency, Documentation, Idempotency, Security, Service, and Syntax. Running an enhanced ACID classifier over 447 open-source and 94 proprietary repositories showed Configuration Data as the most frequent defect category in every dataset, with network issues dominating its subcategories, and with idempotency and security defects present but infrequent. The total defect proportion of 16.8% closely matches the original study's 15.3%, which the authors take as evidence that the taxonomy and defect patterns generalize beyond Puppet and beyond open-source. The paper also proposes a minor extension: Service defects split into Resource and Panic subcategories.

Load-bearing premise

The replication's confirmation of the eight categories depends on the mapping of the study's Logic, Configuration, and Cloud categories to the original Conditional, Configuration Data, and Service categories; if those mappings are not faithful equivalences, the claim that the same eight categories were found weakens.

Editorial extensions

If this is right

  • Teams building IaC quality tooling can adopt the eight categories as a shared vocabulary for defect triage across Pulumi, CDKTF, and AWS CDK.
  • Configuration Data defects are the most frequent and persistent category, so validation of configuration values, credentials, network settings, and paths would target the largest defect class in both open-source and proprietary IaC.
  • Idempotency and security defects are infrequent but never vanish, so they belong in review checklists even when observed counts are low.
  • The similarity of defect proportions between the original Puppet study and this PL-IaC replication supports transferring defect-prevention practices and training across IaC ecosystems.
  • The proposed Service subcategories, Resource and Panic, give practitioners a finer-grained way to record resource-definition failures versus deployment-time runtime failures.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural extension is to run the enhanced ACID tool on the original Puppet-based repositories from 2020; if the same eight-category proportions reappear, the replication is directly tool-comparable.
  • The persistence of Configuration Data defects in general-purpose programming languages suggests that type systems and IDE support do not catch wrong ports, paths, or credentials; a testable consequence is that schema- or property-based validation of configuration values would intercept a large share of these defects.
  • The rare-but-persistent idempotency defects suggest a tractable static-analysis target: detecting operations whose effects are not stable under re-execution, which the current string-pattern rules catch only when commit messages happen to mention them.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper reports a replication of Rahman et al.'s "Gang of Eight" defect taxonomy for Infrastructure as Code, extending it from Puppet scripts to programming-language-based IaC (PL-IaC) tools (Pulumi, Terraform CDK, AWS CDK). The authors manually analyzed 3,364 defect-related commits from 285 open-source PIPr repositories to derive a PL-IaC defect taxonomy, evolved the ACID defect-detection tool with new rules, and applied the tool to 447 open-source repositories and 94 proprietary projects from VTEX and Nubank. They report confirming the same eight defect categories as the original study and similar overall defect proportions (16.8% vs. 15.3%), with Configuration Data as the most frequent category and Idempotency and Security as infrequent but persistent categories.

Significance. If the claims hold, the study provides valuable evidence that a widely cited IaC defect taxonomy generalizes beyond declarative Puppet scripts to modern PL-IaC tools and to proprietary development environments, which would be a meaningful contribution to the IaC reliability literature. The paper has notable strengths: a large and diverse dataset including proprietary access, a replication package and use of the original analysis scripts, inter-rater reliability reported via Cohen's Kappa (0.78), an oracle study with 22 raters, and sanity-check precision/recall figures. However, the current validation gaps in the category-equivalence mapping and in the ACID rule-development process materially weaken the support for the headline conclusions, so the contribution is not yet fully established.

major comments (4)
  1. [Section IV-B, answer to RQ1.1] The claim that the same eight defect categories were confirmed rests entirely on three asserted semantic equivalences (Logic to Conditional, Configuration to Configuration Data, Cloud to Service), yet no validation of this mapping is reported: no independent raters applied the original category definitions to PL-IaC defects, no agreement metric is given for the mapping itself, and no test checks faithfulness in both directions. Because Table VI and the ACID rules in Table III inherit these mapped names, an invalid mapping would invalidate the replication claim rather than merely change labels. The authors should add a structured mapping validation, for example a blind re-coding of a sample of defects by raters unfamiliar with the original taxonomy, with the equivalence established by inter-rater agreement or expert adjudication.
  2. [Section V-A and Section VI-A] The ACID rule set was manually fitted to the 3,364 PIPr ECMs and then applied to the full PIPr corpus, including those same ECMs; the reported precision/recall (0.79/0.81 on the oracle, 0.88/0.87 in the sanity check) therefore do not rule out overfitting to the rule-development distribution. Since the empirical frequency estimates in Table VI are produced by this tool, the authors should report performance on a held-out set of commits or repositories not used for rule development, and should state whether the sanity-check sample of 2,000 ECMs overlapped with the 3,364 commits used for rule fitting.
  3. [Table VI and Section VI-B.2] The conclusion of 'highly similar distributions' is not supported by any statistical comparison; Table VI shows substantial cross-dataset variation (e.g., Dependency defect proportion 9.8% in PIPr versus 3.2% in Nubank, and Configuration Data script proportion 15.8% versus 32.8%). Because RQ2.1 is explicitly about comparing frequency and distribution, the authors should report confidence intervals, effect sizes, or formal tests (e.g., two-proportion z-tests or chi-square tests) for the category-level comparisons, and should discuss the practical significance of any observed differences.
  4. [Section IV-A.1 and Section VIII] The consolidation decisions (type errors merged into Syntax, concurrency errors merged into Configuration Data, cache errors retained) were made by the same researchers who were familiar with the original eight categories, and Section VIII frames that familiarity only as a positive for faithful replication. This is a genuine confirmation-bias risk for the central claim of category confirmation. The paper should add an independent audit, such as a separate coding of a sample of ECMs by a researcher not exposed to the original taxonomy, with the resulting category structure compared to the eight categories.
minor comments (4)
  1. [Section II-A.1] There are two small text errors: 'According Pulumi’s oficial reports' should be 'According to Pulumi’s official reports', and 'Y AML' should be 'YAML'.
  2. [Section IV-A.1] The text refers to 'the PIPs dataset'; the dataset is called PIPr throughout the rest of the paper. Please correct this for consistency.
  3. [Section III] The justification for omitting the original study's practitioner-perception research question is thin: the statement that 22 participants 'indirectly validated' the framework by not raising concerns is not a measurement. Please either restore the RQ or provide a more rigorous rationale for this deviation from the original methodology.
  4. [Figure 6] The panel labels use 'CONDITION' while the taxonomy in Section IV uses 'Conditional'; please align the labels in the figure with the category names used in the text.

Circularity Check

1 steps flagged · score 4.0 of 10

RQ1.1's 'same eight categories' confirmation is established by renaming three discovered categories to original names, making the generalizability claim definitional rather than independently validated.

  1. renaming known result [Section IV-B, answer to RQ1.1 (second and third paragraphs)]
    "Three of our categories, despite having different names, are semantically equivalent to those in the original study. We mapped them without compromising our taxonomy. Our Logic category corresponds to Conditional in the original study, while our Configuration category aligns with Configuration Data. We classified cloud service-related defects as Cloud, which maps to the Service category in the original study. From now on, we will use the terms chosen by the original work, i. e., Conditional, Configuration Data, and Service."

    The conclusion that the same eight Gang-of-Eight categories were confirmed is obtained by renaming three discovered categories to the original names: Logic becomes Conditional, Configuration becomes Configuration Data, and Cloud becomes Service. No independent validation of these semantic equivalences is reported: no blind raters applied the original category definitions to PL-IaC defects, no agreement metric is computed for the mapping itself, and no bidirectional faithfulness check is performed. Once the mapping is accepted, the equality of the eight category names follows by construction, so the RQ1.1 answer is a restatement of the mapping rather than an independent test of generalizability.

full rationale

Most of the empirical machinery is genuinely independent: manual coding of 3,364 defect-related ECMs with substantial inter-rater agreement (Kappa=0.78), a 22-rater oracle for ACID validation, and sanity checks on 2,000 randomly selected ECMs with reported precision/recall provide external checks that do not simply echo the paper's inputs. The defect-frequency results (RQ2/RQ2.1), including the 15.3% vs 16.8% comparison, are not forced by the taxonomy construction because ACID's classifications are evaluated against a held-out-style oracle and sanity samples. However, the load-bearing generalizability conclusion in RQ1.1 is established by renaming three discovered categories to match the original Gang-of-Eight names, with no independent validation of the semantic equivalence. Consequently, the statement 'we identified the same eight defect categories' is true by construction once the mapping is accepted, making that portion of the central claim partially definitional rather than independently measured. The ACID rule set was also manually fitted to the same 3,364 ECMs later classified in the full PIPr corpus, an in-sample concern, although the independent sanity check and oracle limit its circular import. On balance, the paper contains substantial independent evidence, but the central taxonomy-confirmation claim has a definitional component, warranting a score of 4 rather than 0 or 6.

Assumptions & free parameters 2 free parameters · 4 assumptions · 3 invented entities

The paper is an empirical replication; there are no numerical fits in the physics sense. The central results rest on hand-derived classification rules and manually chosen sample criteria. The most consequential assumptions are the semantic mapping to the original taxonomy and the reliability of commit messages as defect signals.

free parameters (2)
  • ACID detection rule set = Rule set in Table III, including hasDefect and category-specific functions; removals and refinements described in…
    The rules were manually derived from all 3,364 defect-related PIPr ECMs and then applied to the full PIPr dataset, making PIPr prevalence estimates in-sample with respect to rule construction.
  • Repository inclusion thresholds = 11% PL-IaC ratio, at least 2 commits per month, and at least 10 contributors; the contributor criterion was dropped…
    These hand-chosen thresholds determine sample composition and therefore all prevalence estimates; changing them would change the defect proportions.
assumptions (4)
  • domain assumption Commit messages and diffs are reliable evidence for detecting and categorizing defects.
    Both the manual coding (Section IV-A) and ACID (Section V-A) rely on commit messages; poor messages could bias categories and prevalence.
  • ad hoc to paper The category equivalences (Logic/Conditional, Configuration/Configuration Data, Cloud/Service) are semantically valid.
    Stated in Section IV-B without a systematic validation; the 'same eight categories' conclusion depends on these mappings.
  • domain assumption The original Gang of Eight taxonomy and its definitions are correct.
    The replication validates the original without re-deriving it; the original's validity is an input.
  • domain assumption The oracle produced by 22 raters is an accurate ground truth.
    Disagreements in the oracle were arbitrated by the first author, which may bias the ground truth used to score ACID (Section V-B).
invented entities (3)
  • Service subcategory 'Resource'
    purpose: Classifies misconfigured or misplaced infrastructure resources within the Service category
    Proposed based on recurring defect patterns in the studied commits; no external validation or falsifiable prediction outside this study.
  • Service subcategory 'Panic'
    purpose: Captures edge-case runtime failures (reboots, failed health checks) despite correct configuration
    Proposed based on a few examples and community reports; no external validation or independent prediction.
  • Configuration subcategory 'Cache'
    purpose: Classifies caching-related defects
    Introduced after one rater identified it; its distinctiveness from other Configuration subcategories is asserted rather than externally validated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Defect Taxonomy for Infrastructure as Code: A Replication Study." pith.science (2026). https://pith.science/paper/UTPUNGTS

@misc{pith2026250501568,
  author       = {Pith},
  title        = {Pith review of: A Defect Taxonomy for Infrastructure as Code: A Replication Study},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UTPUNGTS}},
  note         = {Machine review of arXiv:2505.01568}
}
read the original abstract

Background: As Infrastructure as Code (IaC) becomes standard practice, ensuring the reliability of IaC scripts is essential. Defect taxonomies are valuable tools for this, offering a common language for issues and enabling systematic tracking. A significant prior study developed such a taxonomy, but based it exclusively on the declarative language Puppet. It remained unknown whether this taxonomy applies to programming language-based IaC (PL-IaC) tools like Pulumi, Terraform CDK, and AWS CDK. Aim: We replicated this foundational work to assess the generalizability of the taxonomy across a broader and more diverse landscape. Method: We performed qualitative analysis on 3,364 defect-related commits from 285 open-source PL-IaC repositories (PIPr dataset) to derive a PL-IaC-specific defect taxonomy. We then enhanced the ACID tool, originally developed for the prior study, to automatically classify and analyze defect distributions across an expanded dataset-447 open-source repositories and 94 proprietary projects from VTEX (e-commerce) and Nubank (financial). Results: Our research confirmed the same eight defect categories identified in the original study, with idempotency and security defects appearing infrequently but persistently across projects. Configuration Data defects maintain high frequency in both open-source and proprietary codebases. Conclusions: Our replication supports the generalizability of the original taxonomy, suggesting IaC development challenges surpass organizational boundaries. Configuration Data defects emerge as a persistent high-frequency problem, while idempotency and security defects remain important concerns despite lower frequency. These patterns appear consistent across open-source and proprietary projects, indicating they are fundamental to the IaC paradigm itself, transcending specific tools or project types.

Figures

Figures reproduced from arXiv: 2505.01568 by the authors.

Figure 1
Figure 1. Example Pulumi IaC program in TypeScript [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Methodology to Develop Defect Taxonomy similar to or different from those documented in the original study? • RQ2.1: How do the frequency and distribution of PL-IaC defect types compare with those observed in the original study? We omitted addressing the original study’s question about practitioner perceptions of IaC defect categories for two key reasons: First, IaC importance and development practices are now well-… view at source ↗
Figure 3
Figure 3. provides an example of a Configuration defect reported and fixed by a practitioner in the shapeshift/unchained repository3 . The figure shows a code diff where the port number for the daemon-rpc service is changed from ’8332’ to ’9650’. This type of modification alters the service’s network configuration, impacting how components communicate and how external systems connect. 3https://github.com/shapeshift/unchained/… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: illustrates the process we carried out to evolve ACID rules to automatically classify defects. We preserved most of the original workflow while specifically targeting the 6Our enhanced version of the ACID tool is available at https://figshare.com/s/22f9887a3c3b318a67d5…
Figure 5
Figure 5. Figure 5: ACID Validation illustrates these steps. We established an oracle dataset through 22 independent raters who were not authors of this paper, maintaining the exact number of evaluators as in the original research. These raters performed closed coding [32] to map the defe…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

33 extracted references · 29 canonical work pages

  1. [1]

    AWS Cloud Development Kit

    Amazon Web Services. AWS Cloud Development Kit. https://aws. amazon.com/cdk/, 2024. Retrieved March 26, 2025

    work page 2024

  2. [2]

    AWS CDK Customers

    Amazon Web Services. AWS CDK Customers. https://aws.amazon.com/ cdk/customers/\#culture amp, 2025. Retrieved March 26, 2025

    work page 2025

  3. [3]

    Replication Package for ”A Defect Taxonomy for Infras- tructure as Code Scripts: A Replication Study”

    Anonymous. Replication Package for ”A Defect Taxonomy for Infras- tructure as Code Scripts: A Replication Study”. https://doi.org/10.5281/ zenodo.15276124, 2025. Retrieved April 25, 2025

    work page 2025

  4. [4]

    Ansible - Automation for Everyone

    Ansible, Inc. Ansible - Automation for Everyone. https://www.ansible. com/, n.d. Retrieved April 25, 2025

    work page 2025

  5. [5]

    On the prevalence, co-occurrence, and impact of infrastructure-as-code smells

    Narjes Bessghaier, Mahi Begoug, Chemseddine Mebarki, Ali Ouni, Mohammed Sayagh, and Mohamed Wiem Mkaouer. On the prevalence, co-occurrence, and impact of infrastructure-as-code smells. In 2024 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), pages 23–34. IEEE, 2024

    work page 2024

  6. [6]

    Characterizing co- located insecure coding patterns in infrastructure as code scripts

    Farzana Ahamed Bhuiyan and Akond Rahman. Characterizing co- located insecure coding patterns in infrastructure as code scripts. In Proceedings of the 35th IEEE/ACM International Conference on Auto- mated Software Engineering , pages 27–32, 2020

    work page 2020

  7. [7]

    Terraform: up and running: writing infrastructure as code

    Yevgeniy Brikman. Terraform: up and running: writing infrastructure as code. ” O’Reilly Media, Inc.”, 2022

    work page 2022

  8. [8]

    Chef - Automate Infrastructure, Security, and Compliance

    Chef Software, Inc. Chef - Automate Infrastructure, Security, and Compliance. https://www.chef.io/, n.d. Retrieved April 25, 2025

    work page 2025

Show all 33 references
  1. [9]

    A coefficient of agreement for nominal scales

    Jacob Cohen. A coefficient of agreement for nominal scales. Educational and Psychological Measurement , 20(1):37–46, 1960

    1960

  2. [10]

    When your infrastructure is a buggy program: Understanding faults in infrastructure as code ecosystems

    Georgios-Petros Drosos, Thodoris Sotiropoulos, Georgios Alexopoulos, Dimitris Mitropoulos, and Zhendong Su. When your infrastructure is a buggy program: Understanding faults in infrastructure as code ecosystems. Proceedings of the ACM on Programming Languages , 8(OOPSLA2):2490...

    2024

  3. [11]

    Building the best infrastructure as code with $41m series c funding, October 2023

    Joe Duffy. Building the best infrastructure as code with $41m series c funding, October 2023. Accessed: 2025-04-25

    2023

  4. [13]

    Adoption, support, and challenges of infrastructure-as-code: Insights from industry

    Michele Guerriero, Martin Garriga, Damian A Tamburri, and Fabio Palomba. Adoption, support, and challenges of infrastructure-as-code: Insights from industry. In 2019 IEEE International conference on software maintenance and evolution (ICSME) , pages 580–589. IEEE, 2019

    2019

  5. [14]

    CDK for Terraform

    HashiCorp. CDK for Terraform. https://developer.hashicorp.com/ terraform/cdktf, n.d. Retrieved March 26, 2025

    2025

  6. [15]

    Continuous delivery: reliable software releases through build, test, and deployment automation

    Jez Humble and David Farley. Continuous delivery: reliable software releases through build, test, and deployment automation . Pearson Education, 2010

    2010

  7. [16]

    Panther: Cloud-native siem platform, 2025

    Panther Labs. Panther: Cloud-native siem platform, 2025. Accessed: 2025-04-25

    2025

  8. [17]

    Richard Landis and Gary G

    J. Richard Landis and Gary G. Koch. The measurement of observer agreement for categorical data. Biometrics, 33(1):159–174, 1977

    1977

  9. [18]

    Fuzzing mlir compilers with custom mutation synthesis

    Ben Limpanukorn, Jiyuan Wang, Hong Jin Kang, Eric Zitong Zhou, and Miryung Kim. Fuzzing mlir compilers with custom mutation synthesis. arXiv preprint arXiv:2404.16947 , 2024

    2024 arXiv

  10. [19]

    Infrastructure as code dynamic systems for the cloud age, 2021

    K Moris. Infrastructure as code dynamic systems for the cloud age, 2021

    2021

  11. [20]

    Curating github for engineered software projects

    Naveen Munaiah, Steven Kroh, Christian Cabrey, and Meiyappan Na- gappan. Curating github for engineered software projects. Empirical Software Engineering, 22:3219–3253, 2017

    2017

  12. [21]

    Adoption of infrastructure as code (iac) in real world; lessons and practices from industry

    Olga Murphy. Adoption of infrastructure as code (iac) in real world; lessons and practices from industry. 2022

    2022

  13. [22]

    Pulumi – Infrastructure as Code in Any Programming Language

    Pulumi. Pulumi – Infrastructure as Code in Any Programming Language. https://www.pulumi.com/, 2025. Retrieved March 26, 2025

    2025

  14. [23]

    Panther Labs: Increasing Velocity & Innovation

    Pulumi Corporation. Panther Labs: Increasing Velocity & Innovation. https://www.pulumi.com/case-studies/panther-labs/, 2025. Retrieved March 26, 2025

    2025

  15. [24]

    Pulumi raises series b to build the future of cloud engineering, October 2023

    Pulumi Team. Pulumi raises series b to build the future of cloud engineering, October 2023. Accessed: 2025-04-25

    2023

  16. [25]

    Puppet - Automate Infrastructure and Operations

    Puppet, Inc. Puppet - Automate Infrastructure and Operations. https: //puppet.com/, n.d. Retrieved April 25, 2025

    2025

  17. [26]

    Statically inferring usage bounds for infrastructure as code

    Feitong Qiao, Aryana Mohammadi, J ¨urgen Cito, and Mark Santolucito. Statically inferring usage bounds for infrastructure as code. arXiv preprint arXiv:2402.15632, 2024

    2024 arXiv

  18. [27]

    Characteristics of defective infrastructure as code scripts in devops

    Akond Rahman. Characteristics of defective infrastructure as code scripts in devops. In Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings, pages 476–479, 2018

    2018

  19. [28]

    Gang of eight: A defect taxonomy for infrastructure as code scripts

    Akond Rahman, Effat Farhana, Chris Parnin, and Laurie Williams. Gang of eight: A defect taxonomy for infrastructure as code scripts. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering, pages 752–764, 2020

    2020

  20. [29]

    The seven sins: Security smells in infrastructure as code scripts

    Akond Rahman, Chris Parnin, and Laurie Williams. The seven sins: Security smells in infrastructure as code scripts. in 2019 ieee/acm 41st international conference on software engineering (icse). IEEE, 164´s175, 2019

    2019

  21. [30]

    Security smells in ansible and chef scripts: A replication study

    Akond Rahman, Md Rayhanur Rahman, Chris Parnin, and Laurie Williams. Security smells in ansible and chef scripts: A replication study. ACM Transactions on Software Engineering and Methodology (TOSEM), 30(1):1–31, 2021

    2021

  22. [31]

    Characterizing defective config- uration scripts used for continuous deployment

    Akond Rahman and Laurie Williams. Characterizing defective config- uration scripts used for continuous deployment. In 2018 IEEE 11th International conference on software testing, verification and validation (ICST), pages 34–45. IEEE, 2018

    2018

  23. [32]

    Salda ˜na

    Johnny M. Salda ˜na. The Coding Manual for Qualitative Researchers . SAGE Publications, London, 3rd edition, 2016

    2016

  24. [33]

    Auto- mated infrastructure as code program testing

    Daniel Sokolowski, David Spielmann, and Guido Salvaneschi. Auto- mated infrastructure as code program testing. IEEE Transactions on Software Engineering, 2024

    2024

  25. [34]

    The pipr dataset of public infrastructure as code programs

    Daniel Sokolowski, David Spielmann, and Guido Salvaneschi. The pipr dataset of public infrastructure as code programs. In Proceedings of the 21st International Conference on Mining Software Repositories , pages 498–503, 2024

    2024

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.