Pith. sign in

REVIEW 5 major objections 5 minor 1 cited by

Understanding Everything as Code: A Taxonomy and Conceptual Model

T0 review · 5 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read The paper claims that Everything as Code has a definite structure: 25 distinct as-code practices organized into six functional layers and two maturity classes, presented as the first taxonomy and conceptual model of the field.

desk verdict A solid, transparent taxonomy of Everything as Code that deserves refereeing; the 'first comprehensive' claim holds only within a vendor-influenced corpus the authors themselves acknowledge. read the letter →

arxiv 2507.05100 v1 pith:ORSDNPKP submitted 2025-07-07 cs.SE

Haoran Wei , Nazim Madhavji , John Steinbacher This is my paper · ORCID
classification cs.SE
keywords EverythingasCodeInfrastructurePolicyComplianceSecuritymultivocalliteraturereviewtaxonomyconceptualmodel
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 claims that Everything as Code is not a vague umbrella term but a field with a definite structure. By systematically reviewing 42 peer-reviewed papers and 86 grey-literature documents, it identifies 25 distinct as-code practices and organizes them into six functional layers and two industry-awareness tiers. It presents the result as the first taxonomy and conceptual model of EaC, with a map of how the six established practices relate and overlap across the software delivery lifecycle. If the claim holds, practitioners get a shared vocabulary and a placement guide for tools and practices, and researchers get a baseline for a domain that currently lacks standards.

What carries the argument

The machinery that carries the argument is a two-dimensional taxonomy built through a standard taxonomy-development method with top-down and bottom-up passes. Dimension one counts literature frequency and tooling availability to divide the 25 practices into six established practices and nineteen emerging ones, using post-hoc thresholds: upper band of 20 percent to 40 percent frequency and more than three documented tools. Dimension two uses thematic analysis anchored to an established industry tooling landscape to define the six functional layers. The conceptual model translates extracted relationships into directional edges, with lifecycle alignment placing practices into DevOps stages; the single most load-bearing relationship is that Policy as Code validates Infrastructure as Code, which lets the model explain overlaps among Policy, Compliance, and Security as Code.

What would settle it

A targeted check would be to run the same literature-frequency and tool-count analysis on a different corpus built from less vendor-centric sources, such as regional practitioner blogs, open-source documentation, and non-English technical writing. If any practice outside the 25 appears in the upper frequency band with more than three tools, or if one of the six established practices falls below those thresholds, the taxonomy's categories and boundaries fail their own test.

Watch

Extended reading notes

Core claim

The paper's central discovery is that Everything as Code decomposes into 25 discrete practices that can be sorted along two independent dimensions. The first dimension, industry awareness and tooling support, splits practices into Established and Emerging based on how often they appear in the literature and how many tools implement them; Infrastructure as Code is treated as an outlier at 71 percent frequency, and the remaining practices cluster into a 20 percent to 40 percent band versus a lower band. The second dimension, functionality and application, assigns each practice to one of six layers: Infrastructure Provisioning and Management, Platform and Orchestration, Application Design and Development, Data and Database, Security and Compliance, and Observability and Analysis. The conceptual model then adds directional relationships between the six established practices, such as Policy as Code validating Infrastructure as Code, and aligns them with DevOps lifecycle stages, while the paper gives explicit criteria for when a component belongs to Infrastructure as Code rather than Configuration as Code, using Kubernetes as the boundary case.

Load-bearing premise

The load-bearing premise is that the selected corpus of 42 academic papers and 86 grey-literature documents, gathered with the stated inclusion and exclusion criteria and with searches that favored leading cloud and DevOps vendors, fairly represents the whole Everything-as-Code conversation; if that corpus is skewed, the 25-practice scope and the established/emerging split inherit the skew.

Editorial extensions

If this is right

  • The taxonomy gives practitioners a checklist: any proposed as-code practice can be placed in one of the 25 slots or flagged as speculative until it gains literature and tooling support.
  • The established-versus-emerging split becomes an adoption roadmap: start with IaC, CaC, Pipeline as Code, Policy as Code, Security as Code, and Compliance as Code, which have tool ecosystems, before investing in emerging practices.
  • The IaC/CaC boundary criteria yield a concrete decision rule: configure a software component with IaC only when it is inseparable from infrastructure, foundational to applications, and part of a unified infrastructure unit; otherwise manage it as Configuration as Code.
  • The overlap analysis implies that one cloud resource may legitimately be scanned by security tools, validated by policy engines, and audited by compliance scripts in the same pipeline, each serving a different governance purpose.
  • The conceptual model's directional edges map directly to pipeline stages, so the model doubles as a design template for CI/CD automation.

Reading between the lines

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

  • A fair stress test of the taxonomy would be to apply the same frequency and tooling thresholds to a fresh, independently collected corpus: if the established/emerging split moves, the current categories are corpus-specific rather than field-wide.
  • The machine-readable JSON version of the taxonomy points toward a living registry where new practices are classified by semi-automated means; the paper only proposes this as future work, but it is the natural next step.
  • Because the conceptual model covers only the six established practices, the nineteen emerging practices remain unconnected; extending the same directional-edge notation to them would complete the picture.
  • The paper's Kubernetes boundary example suggests a testable principle: as more components become 'infrastructure to applications,' the line between IaC and CaC will keep shifting, so the taxonomy may need versioned updates tied to technology shifts.
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

5 major / 5 minor

Summary. This paper reports a multivocal literature review (MLR) of Everything as Code (EaC), synthesizing 42 peer-reviewed papers and 86 grey literature documents into a taxonomy of 25 EaC practices and a conceptual model of their relationships. The taxonomy has two dimensions: industry awareness and tooling support, which separates established from emerging practices, and functionality and application, which organizes practices into six layers. The conceptual model focuses on the six established practices and is validated, together with the taxonomy, through expert review with three practitioners from a single cloud provider. The authors claim this is the first comprehensive taxonomy and conceptual model of EaC and provide supplementary materials including extracted data, validation checklists, and code examples.

Significance. If the taxonomy and conceptual model are robust, they would provide a useful structured vocabulary for a fragmented and rapidly growing area of software engineering practice. The paper has genuine strengths: it follows established MLR guidelines, uses a recognized taxonomy development method, documents data extraction and validation steps, provides supplementary resources, and explicitly acknowledges several limitations. The distinction between established and emerging practices and the proposed relationship between Policy as Code, Compliance as Code, and Security as Code could be a helpful baseline for practitioners and researchers. However, the central claims of '25 distinct practices' and of an accurate industry-awareness classification depend on corpus construction and threshold choices that are not sufficiently auditable from the paper as written.

major comments (5)
  1. [Section III-A and Table V] The grey-literature arm of the corpus was explicitly constructed to prioritize sources from leading cloud providers, DevOps vendors, and technical blogging platforms, and the search was iteratively expanded from practices found in that same corpus. This creates a feedback loop in which vendor-marketed practices are more likely to be encountered, recursively searched, and hence counted as frequent, while less-marketed practices are under-indexed. The exclusion of Law as Code, Contracts as Code, and Management as Code on the ground that they 'lack sufficient literature support' (Table V) is therefore partly an artifact of the collection strategy rather than independent evidence of irrelevance. The paper should report per-practice literature frequencies and tool counts, and should demonstrate robustness by analyzing a non-vendor-prioritized sample or by explicitly bounding the claim to the vendor-oriented discourse it sampled.
  2. [Section IV-A] The classification into Established and Emerging Practices depends on two thresholds: a literature frequency in the 'upper frequency band (20% - 40%)' and 'more than three documented tools'. The paper does not report the exact frequency of each of the 25 practices, so the reader cannot determine why, for example, IAM as Code is Emerging rather than Established, or why the 20% and 40% boundaries were chosen. The violin plot in Fig. 4 is not a substitute for a data table. Please include the complete frequency and tooling table and a sensitivity analysis showing how the classification changes under reasonable alternative thresholds.
  3. [Section VI-A and Section VI-D] The validation stage involved only three engineers from a single cloud service provider, all with DevOps and cloud-native profiles. While the authors acknowledge this limitation in Section VI-D, the taxonomy's second dimension is explicitly called 'Industry Awareness and Tooling Support'; a three-person, single-organization panel cannot validate industry awareness across sectors. The claim that 'every element of the taxonomy and model had been explicitly ratified' should be toned down, or the panel should be expanded to include, for example, practitioners from enterprises without a cloud-vendor affiliation, plus researchers with relevant expertise.
  4. [Section IV-B, Table IV, and Fig. 6] The count of '25 distinct EaC practices' is internally inconsistent with the treatment of Storage as Code and Network as Code in Dimension 2. Section IV-B states that these practices 'were subsumed into Infrastructure as Code', yet they remain separate entries in Table IV and Fig. 6 and are counted among the 25. The paper should define whether the taxonomy enumerates leaf practices, umbrella practices, or both, and adjust the count and figures accordingly. This is load-bearing because the abstract promises '25 distinct EaC practices'.
  5. [Section V] The conceptual model is built only from the six established practices, as Section V states that it represents relationships between 'the established practices'. The other 19 identified practices are outside the model. Given that the title and abstract present the conceptual model as covering EaC as a whole, the model's scope should either be expanded to include emerging practices or the claims should be narrowed to a model of the established core. This distinction should be made explicit in the abstract and conclusion.
minor comments (5)
  1. [Section V-B-2] The text contains a typo: 'Y AML' should be 'YAML'.
  2. [Table IV] Several emerging practices are supported by a single grey-literature source (e.g., Storage as Code G57, IAM as Code G67, Privacy as Code G68). Please mark single-source practices as tentative or provide additional corroborating sources.
  3. [Section III-A] The statement that the selected literature is 'available in Section VII' is unclear because Section VII refers to supplementary resources rather than listing all documents; please clarify what is in the paper versus the online repository.
  4. [Fig. 4] The violin plot needs axis labels, a legend, and ideally a companion table of per-practice frequencies; the term 'trimodal distribution' cannot be inspected or verified from the figure as presented.
  5. [References] Some references, particularly the book chapters [13]-[15], lack complete bibliographic details such as page numbers or DOIs; please make the reference list consistent.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the taxonomy is an inductive literature synthesis, not a derivation from its own outputs.

full rationale

The paper makes no quantitative prediction or first-principles derivation; it is a multivocal literature review and classification exercise. The central artifacts—25 practices, six functional layers, and the established/emerging split—are inductive summaries of the 128 selected sources, subsequently refined through an external expert panel. The frequency-based thresholds in Section IV-A are descriptive cluster boundaries derived from the same corpus that defines the objects, which is normal for taxonomy development using the Nickerson et al. method and does not make any claimed output an input by construction. No load-bearing result rests on a self-citation: the authors' own contributions appear only as the supplementary repository link (reference [61]). The acknowledged limitations in Sections VI-C and VI-D—corpus time-sensitivity, small expert panel, and the vendor-prioritized grey literature strategy in Section III-A—are validity threats to generalizability, not circular reasoning. No specific reduction of a claimed result to an input can be exhibited, so the appropriate finding is no significant circularity.

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

The taxonomy rests on two free thresholds and three domain assumptions: that literature frequency measures awareness, that the corpus is representative, and that the chosen taxonomy method is appropriate. No new physical or mathematical entities are introduced.

free parameters (2)
  • Established practice frequency band = 20% to 40%
    Chosen to separate established from emerging practices after observing the frequency distribution; not predetermined.
  • Tooling threshold = more than three documented tools
    Used together with the frequency band to classify established practices; the cutoff is ad hoc.
assumptions (3)
  • domain assumption Literature frequency in the curated corpus is a valid proxy for industry awareness
    Section IV-A uses the frequency distribution to split practices into established and emerging categories.
  • domain assumption The search process captured a representative sample of EaC discourse
    Section III-A; Google-based grey literature search prioritized large cloud providers and DevOps vendors, which may bias the corpus.
  • domain assumption The taxonomy development method of Nickerson et al. is applicable to this domain
    The paper adopts this established method without questioning its fit for EaC; it underpins the entire classification process.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Understanding Everything as Code: A Taxonomy and Conceptual Model." pith.science (2026). https://pith.science/paper/ORSDNPKP

@misc{pith2026250705100,
  author       = {Pith},
  title        = {Pith review of: Understanding Everything as Code: A Taxonomy and Conceptual Model},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ORSDNPKP}},
  note         = {Machine review of arXiv:2507.05100}
}
read the original abstract

Background: Everything as Code (EaC) is an emerging paradigm aiming to codify all aspects of modern software systems. Despite its growing popularity, comprehensive industry standards and peer-reviewed research clarifying its scope and guiding its adoption remain scarce. Aims: This study systematically analyzes existing knowledge and perceptions of EaC, clarifies its scope and boundaries, and provides structured guidance for researchers and practitioners. Method: We conducted a large-scale multivocal literature review (MLR), synthesizing academic and grey literature sources. Findings were analyzed quantitatively and thematically. Based on this analysis, we developed a taxonomy and conceptual model of EaC, validated through collaboration with industry experts. Results: The resulting taxonomy comprises 25 distinct EaC practices organized into six layers based on industry awareness and functional roles. The conceptual model illustrates focus areas, overlaps, and interactions among these EaC practices within the software delivery lifecycle. Additionally, practical code examples demonstrating the implementation of these practices were developed in collaboration with industry experts. Conclusions: This work addresses the current scarcity of academic discourse on EaC by providing the first comprehensive taxonomy and conceptual model. These contributions enhance conceptual clarity, offer actionable guidance to practitioners, and lay the groundwork for future research in this emerging domain.

Figures

Figures reproduced from arXiv: 2507.05100 by the authors.

Figure 2
Figure 2. Infrastructure as Code (IaC) and Configuration as Code (CaC) [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 1
Figure 1. Numbers of publications on “Everything as Code” in major academic [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. illustrates our literature-collection process. Scientific studies were gathered from major academic databases—IEEE Xplore, ACM Digital Library, ScienceDirect, and Springer￾Link. Grey literature documents (e.g., white papers, re￾ports, and practitioner blogs) were collected through Google searches, prioritizing sources from leading cloud providers (e.g., AWS, Azure, and Google Cloud), DevOps vendors (e.g., HashiCorp,… view at source ↗
Figures from the paper (5 more)
Figure 5
Figure 5. Figure 5: The taxonomy development process: dimension 2. [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]
Figure 6
Figure 6. Figure 6: The taxonomy of EaC practices: Functionality and Application. [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: The conceptual model of EaC. 1) Policy as Code (PaC): Among the three as-code prac￾tices, PaC is the most recognized (see [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Policy as Code vs. Compliance as Code vs. Security as Code. [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 9
Figure 9. Figure 9: Overview of application and infrastructure Pipelines as Code, highlighting the integration of as-code practices within CI/CD stages. [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. A Technical Policy Blueprint for Trustworthy Decentralized AI

    cs.CY 2025-12 conditional novelty 4.0 of 10

    A reference architecture that decouples AI-policy verification — a Policy Engine issuing capability packages — from enforcement by Guardians, so governance rules can be updated without reconfiguring decentralized-AI i...

Reference graph

Works this paper leans on

65 extracted references · 57 canonical work pages · cited by 1 Pith paper

  1. [1]

    Adoption, Support, and Challenges of Infrastructure-as-Code: Insights from Indus- try,

    Mi. Guerriero, M. Garriga, D. A. Tamburri, and F. Palomba, “Adoption, Support, and Challenges of Infrastructure-as-Code: Insights from Indus- try,” in 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME), Sep. 2019, pp. 580–589. doi: 10.1109/IC- SME.2019.00092

    arXiv 2019

  2. [2]

    DevOps: Introducing Infrastructure-as-Code,

    M. Artac, T. Borovssak, E. Di Nitto, M. Guerriero, and D. A. Tamburri, “DevOps: Introducing Infrastructure-as-Code,” in 2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE- C), May 2017, pp. 497–498. doi: 10.1109/ICSE-C.2017.162

    doi:10.1109/icse-c.2017.162 2017

  3. [3]

    Toward Multiconcern Software Development With Everything as Code,

    V . Stirbu, M. Raatikainen, J. R ¨ontynen, V . Sokolov, T. Lehtonen, and T. Mikkonen, “Toward Multiconcern Software Development With Everything as Code,” IEEE Software, vol. 39, no. 4, pp. 27–33, Jul. 2022, doi: 10.1109/MS.2022.3167481

    work page arXiv 2022

  4. [4]

    What it means to do ‘everything as code’ in IT op- erations — TechTarget,

    C. Tozzi, “What it means to do ‘everything as code’ in IT op- erations — TechTarget,” Search IT Operations. Feb. 2022. Avail- able: https://www.techtarget.com/searchitoperations/tip/What-it-means- to-do-everything-as-code-in-IT-operations

    work page 2022

  5. [5]

    Everything As Code (EaC) What It Is and Why It’s Gain- ing Popularity? — LinkedIn

    “Everything As Code (EaC) What It Is and Why It’s Gain- ing Popularity? — LinkedIn.” Accessed: Apr. 15, 2025. [On- line]. Available: https://www.linkedin.com/pulse/everything-code-eac- what-why-its-gaining-popularity-/

    work page 2025

  6. [6]

    Everything as Code: The fu- ture of ops tools,

    HashiCorp, “Everything as Code: The fu- ture of ops tools,” Hashicorp.com, 2018. https://www.hashicorp.com/en/resources/everything-as-code-the-future- of-ops-tools

    work page 2018

  7. [7]

    Everything as Code: The Future of IT and Infrastructure,

    “Everything as Code: The Future of IT and Infrastructure,” Cloud4C,

    work page

  8. [8]

    Everything-as-Code: lessons from Applications-as-Code,

    Ruud Schoonderwoerd, “Everything-as-Code: lessons from Applications-as-Code,” Medium, Apr. 13, 2021. https://medium.com/nationwide-technology/everything-as-code-lessons- from-applications-as-code-952e94603b1e (accessed Apr. 24, 2025)

    work page 2021

Show all 65 references
  1. [9]

    Yin and V

    L. Yin and V . Filkov, ”Team discussions and dynamics during DevOps tool adoptions in OSS projects,” in Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering (ASE ’20), New York, NY , USA, 2020, pp. 1–12. doi:10.1145/3324884.3416640

    2020

  2. [10]

    A Secure Framework for Continuous Compliance across Heterogeneous Policy Validation Points,

    T. Yanagawa, V . Agarwal, Y . Watanabe, L. Degenaro, and A. Sailer, “A Secure Framework for Continuous Compliance across Heterogeneous Policy Validation Points,” in 2024 IEEE 17th International Confer- ence on Cloud Computing (CLOUD), Jul. 2024, pp. 176–182. doi: 10.1109/CLOUD...

    2024

  3. [11]

    Automating Cybersecurity Compliance in DevSecOps with Open Information Model for Security as Code,

    H. Haverinen, T. Janhunen, T. P ¨aiv¨arinta, S. Lempinen, S. Kaartinen, and S. Meril ¨a, “Automating Cybersecurity Compliance in DevSecOps with Open Information Model for Security as Code,” in Proceedings of the 4th Eclipse Security, AI, Architecture and Modelling Conference o...

    2024

  4. [12]

    Identifying the primary dimen- sions of DevSecOps: A multi-vocal literature review,

    X. Zhao, T. Clear, and R. Lal, “Identifying the primary dimen- sions of DevSecOps: A multi-vocal literature review,” Journal of Systems and Software, vol. 214, p. 112063, Aug. 2024, doi: 10.1016/j.jss.2024.112063

    2024

  5. [14]

    Enterprise Cloud Native Automation — SpringerLink

    “Enterprise Cloud Native Automation — SpringerLink.” Available: https://link.springer.com/chapter/10.1007/978-1-4842-7226-8 14

    doi

  6. [15]

    Pipeline Development — SpringerLink

    “Pipeline Development — SpringerLink.” Available: https://link.springer.com/chapter/10.1007/978-1-4842-9228-0 5

    doi

  7. [16]

    What questions do programmers ask about configuration as code?,

    A. Rahman, A. Partho, P. Morrison, and L. Williams, “What questions do programmers ask about configuration as code?,” in Proceedings of the 4th International Workshop on Rapid Continuous Software Engineering, in RCoSE ’18. New York, NY , USA: Association for Computing Machiner...

    2018

  8. [17]

    Ray, Policy as Code: Improving Cloud Native Security

    J. Ray, Policy as Code: Improving Cloud Native Security. O’Reilly Media, Inc., 2024

    2024

  9. [18]

    Compliance-as-Code for Cybersecurity Automation in Hybrid Cloud,

    V . Agarwal, C. Butler, L. Degenaro, A. Kumar, A. Sailer, and G. Steinder, “Compliance-as-Code for Cybersecurity Automation in Hybrid Cloud,” in 2022 IEEE 15th International Conference on Cloud Computing (CLOUD), Jul. 2022, pp. 427–437. doi: 10.1109/CLOUD55607.2022.00066

    2022

  10. [19]

    Labouardy, Pipeline as Code: Continuous Delivery with Jenkins, Kubernetes, and Terraform

    M. Labouardy, Pipeline as Code: Continuous Delivery with Jenkins, Kubernetes, and Terraform. Simon and Schuster, 2021

    2021

  11. [20]

    B. S. Das and V . Chu, Security as Code: DevSecOps Patterns with AWS. O’Reilly Media, Inc., 2023

    2023

  12. [21]

    Garousi, M

    V . Garousi, M. Felderer, and M. V . M ¨antyl¨a, ”Guidelines for including grey literature and conducting multivocal literature reviews in soft- ware engineering,” Information and Software Technology, vol. 106, pp.101–121, 2019

    2019

  13. [22]

    D. S. Cruzes and T. Dyb ˚a, ”Recommended steps for thematic synthesis in software engineering,” in Proceedings of the 2011 International Sym- posium on Empirical Software Engineering and Measurement (ESEM), Banff, AB, Canada, 2011, pp. 275–284. doi:10.1109/ESEM.2011.36

    2011 doi

  14. [23]

    A method for taxon- omy development and its application in information systems,

    R. C. Nickerson, U. Varshney, and J. Muntermann, “A method for taxon- omy development and its application in information systems,” Eur J Inf Syst, vol. 22, no. 3, pp. 336–359, May 2013, doi: 10.1057/ejis.2012.26

    2013 doi

  15. [24]

    An Update for Taxonomy Designers,

    D. Kundisch et al., “An Update for Taxonomy Designers,” Bus Inf Syst Eng, vol. 64, no. 4, pp. 421–439, Aug. 2022, doi: 10.1007/s12599-021- 00723-x

    2022 doi

  16. [25]

    Violin Plot

    “Violin Plot.” Wikipedia, 5 May 2020, en.wikipedia.org/wiki/Violin plot

    2020

  17. [26]

    CNCF Landscape

    “CNCF Landscape.” Landscape.cncf.io, landscape.cncf.io/guide. Ac- cessed 14 Apr. 2025

    2025

  18. [27]

    Provisioners, Terraform, HashiCorp Developer

    “Provisioners, Terraform, HashiCorp Developer”. Accessed: Mar. 13,

  19. [28]

    Production-Grade Container Orchestration,

    “Production-Grade Container Orchestration,” Kubernetes. Accessed: Mar. 13, 2025. [Online]. Available: https://kubernetes.io/

    2025

  20. [29]

    13, 2025

    Manage Kubernetes with Terraform, Terraform, HashiCorp Developer.” Accessed: Mar. 13, 2025. [Online]. Available: https://developer.hashicorp.com/terraform/tutorials/kubernetes

    2025

  21. [30]

    ”Kubernetes Management Design Patterns.” Apress, Berkeley, CA, 2017

    V ohra, Deepak. ”Kubernetes Management Design Patterns.” Apress, Berkeley, CA, 2017

    2017

  22. [31]

    An architecture for self-managing microservices,

    G. Toffetti, S. Brunner, M. Bl ¨ochlinger, F. Dudouet, and A. Edmonds, “An architecture for self-managing microservices,” in Proceedings of the 1st International Workshop on Automated Incident Management in Cloud, in AIMC ’15. New York, NY , USA: Association for Computing Mach...

    2015

  23. [32]

    Policy Language,

    “Policy Language,” Open Policy Agent. Accessed: Mar. 13, 2025. [Online]. Available: https://www.openpolicyagent.org/docs/latest/policy- language/

    2025

  24. [33]

    Decoder: Compliance as code,

    “Decoder: Compliance as code,” Thoughtworks. Accessed: Mar. 13, 2025. [Online]. Available: https://www.thoughtworks.com/insights/decoder/c/compliance-as-code

    2025

  25. [34]

    Compliance as Code - Complete Guide

    “Compliance as Code - Complete Guide.” Accessed: Mar. 13, 2025. [Online]. Available: https://www.xenonstack.com/blog/compliance-as-a- code/

    2025

  26. [35]

    ”Compliance as Code”, https://www.pwccn.com/en/issues/cybersecurity- and-data-privacy/compliance-as-code-sep2020.pdf

  27. [36]

    What Is Compliance as Code? Benefits, Use Cases and Tools,

    “What Is Compliance as Code? Benefits, Use Cases and Tools,” Con- tino — Global Transformation Consultancy. Accessed: Mar. 13, 2025. [Online]. Available: https://www.contino.io/insights/compliance-as-code

    2025

  28. [37]

    What is Policy as Code (PaC) & How Do You Implement It?,

    “What is Policy as Code (PaC) & How Do You Implement It?,” Spacelift. Accessed: Mar. 13, 2025. [Online]. Available: https://spacelift.io/blog/[slug]

    2025

  29. [38]

    Policy as Code vs Compliance as Code, Trend Micro (HK)

    “Policy as Code vs Compliance as Code, Trend Micro (HK).” Accessed: Mar. 13, 2025. [Online]. Available: https://www.trendmicro.com/en hk/research/23/c/policy-as-code-vs- compliance-as-code.html

    2025

  30. [39]

    OSCAL - Open Security Controls Assessment Language

    “OSCAL - Open Security Controls Assessment Language.” Accessed: Mar. 13, 2025. [Online]. Available: https://pages.nist.gov/OSCAL/

    2025

  31. [40]

    Policy as Code (PaC) — Cloud Native Glossary

    “Policy as Code (PaC) — Cloud Native Glossary.” Accessed: Mar. 13,

  32. [41]

    A look into Policy as Code: why now and how can it help?

    R. Henshall, “A look into Policy as Code: why now and how can it help?” 2024. Available: https://www.redhat.com/en/blog/look-policy- code-why-now-and-how-can-it-help

    2024

  33. [42]

    Requirements management in DevOps environments: a multivocal mapping study,

    R. Hern ´andez, B. Moros, and J. Nicol ´as, “Requirements management in DevOps environments: a multivocal mapping study,” Requirements Eng, vol. 28, no. 3, pp. 317–346, Sep. 2023, doi: 10.1007/s00766-023- 00396-w

    2023 doi

  34. [43]

    Available: https://glossary.cncf.io/policy-as-code/

    [Online]. Available: https://glossary.cncf.io/policy-as-code/

  35. [44]

    CVE: Common Vulnerabilities and Exposures

    “CVE: Common Vulnerabilities and Exposures.” Accessed: Mar. 13,

  36. [45]

    What is Infrastructure as Code (IaC) Scanning? — Wiz

    S. Sham, “What is Infrastructure as Code (IaC) Scanning? — Wiz.”

  37. [46]

    What is Security as Code (SaC)? - Check Point Software

    “What is Security as Code (SaC)? - Check Point Software.” Accessed: Mar. 13, 2025. [Online]. Available: https://www.checkpoint.com/cyber- hub/cloud-security/what-is-security-as-code-sac/

    2025

  38. [47]

    Rangnau, R

    T. Rangnau, R. v. Buijtenen, F. Fransen and F. Turkmen, ”Continuous Security Testing: A Case Study on Integrating Dynamic Security Testing Tools in CI/CD Pipelines,” 2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC), Eindhoven, Nether- land...

    2020

  39. [48]

    Available: https://www.cve.org/

    [Online]. Available: https://www.cve.org/

  40. [49]

    Intrusion Detection System,

    IBM, “Intrusion Detection System,” IBM, Apr. 19, 2023. https://www.ibm.com/think/topics/intrusion-detection-system

    2023

  41. [50]

    N. I. Daud, K. A. Abu Bakar and M. S. Md Hasan, ”A case study on web application vulnerability scanning tools,” 2014 Science and Information Conference, London, UK, 2014, pp. 595-600, doi: 10.1109/SAI.2014.6918247

    2014

  42. [51]

    Vulnerabilities Mapping based on OW ASP-SANS: A Survey for Static Application Security Testing (SAST),

    J. Li, “Vulnerabilities Mapping based on OW ASP-SANS: A Survey for Static Application Security Testing (SAST),” Annals of Emerging Technologies in Computing, vol. 4, no. 3, pp. 1–8, Jul. 2020, doi: https://doi.org/10.33166/aetic.2020.03.001

    2020 doi

  43. [52]

    GitOps vs. Traditional CI/CD: Choosing the Right Path for Modern Software Delivery,

    Walaa Elgenidy, “GitOps vs. Traditional CI/CD: Choosing the Right Path for Modern Software Delivery,” Medium, Jul. 15, 2024. https://medium.com/@walaaelgenidy/exploring-gitops-and-traditional- cicd-approaches-46a028947ded.( accessed Apr. 14, 2025)

    2024

  44. [53]

    A comparative study of vul- nerability reporting by software composition analysis tools,

    N. Imtiaz, S. Thorn, and L. Williams, “A comparative study of vul- nerability reporting by software composition analysis tools,” Proceed- ings of the 15th ACM / IEEE International Symposium on Empiri- cal Software Engineering and Measurement (ESEM), Oct. 2021, doi: https://doi...

    2021

  45. [54]

    Infrastructure Drift Detection — How to Fix It With IaC Tool,

    F. Dinu and J.-M. Fontaine, “Infrastructure Drift Detection — How to Fix It With IaC Tool,” Spacelift, 2024. https://spacelift.io/blog/drift- detection

    2024

  46. [55]

    Container scanning overview,

    “Container scanning overview,” Google Cloud, 2025. https://cloud.google.com/artifact-analysis/docs/container-scanning- overview (accessed Apr. 14, 2025)

    2025

  47. [56]

    CLOUD NATIVE SECURITY WHITEPA- PER VERSION 2

    S. Hadfield et al., “CLOUD NATIVE SECURITY WHITEPA- PER VERSION 2.” Available: https://www.cncf.io/wp- content/uploads/2022/06/CNCF cloud-native-security-whitepaper- May2022-v2.pdf

    2022

  48. [57]

    Nominal group technique: An ef- fective method for obtaining group consensus,

    N. Harvey and C. A. Holmes, “Nominal group technique: An ef- fective method for obtaining group consensus,” International Journal of Nursing Practice, vol. 18, no. 2, pp. 188–194, Mar. 2012, doi: https://doi.org/10.1111/j.1440-172x.2012.02017.x

    2012 arXiv

  49. [58]

    IaC Scanning: Concepts, Process, and Tools,

    S. Sham, “IaC Scanning: Concepts, Process, and Tools,” wiz.io, Oct. 30, 2024. https://www.wiz.io/academy/iac-scanning (accessed Apr. 14, 2025)

    2024

  50. [59]

    Infrastructure pipelines: How are they different from application CDs?,

    N. Aggarwal, “Infrastructure pipelines: How are they different from application CDs?,” Medium. Accessed: Jul. 07, 2025. [On- line]. Available: https://blog.runx.dev/infrastructure-pipelines-how-are- they-different-from-application-cds-ce4545763820

    2025

  51. [60]

    Infrastructure CI/CD — Pulumi

    “Infrastructure CI/CD — Pulumi.” Accessed: Jul. 07, 2025. [Online]. Available: https://www.pulumi.com/solutions/infrastructure-ci-cd/

    2025

  52. [61]

    From Code to Kubernetes: Building a Full GitOps Pipeline with GitLab CI and FluxCD,

    Bora K ¨ostem, “From Code to Kubernetes: Building a Full GitOps Pipeline with GitLab CI and FluxCD,” Medium, Aug. 23, 2024. https://medium.com/@fenari.kostem/from-code-to-kubernetes-building- a-full-gitops-pipeline-with-gitlab-ci-and-fluxcd-aa6188ca517f (accessed Apr. 14, 2025)

    2024

  53. [63]

    What is CI/CD?,

    “What is CI/CD?,” about.gitlab.com. Accessed: Jul. 07, 2025. [Online]. Available: https://about.gitlab.com/topics/ci-cd/

    2025

  54. [66]

    Supplementary resources associated with this paper., available at: https://github.com/weihoran/Everything-as-Code

  55. [2023]

    https://www.cloud4c.com/blogs/everything-as-code-future-of- infra-and-it-management

  56. [2024]

    Available: https://www.wiz.io/academy/iac-scanning

  57. [2025]

    Available: https://developer.hashicorp.com/terraform/language/resources/ provisioners/syntax

Pith tools

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