Beyond the Tip of the Iceberg: Understanding SATD in Dockerfiles through the Lens of Co-evolution

• URL: http://arxiv.org/abs/2605.21238v1
• Date: Wed, 20 May 2026 14:26:56 GMT
• Title: Beyond the Tip of the Iceberg: Understanding SATD in Dockerfiles through the Lens of Co-evolution
• Abstract summary: We study self-admitted technical debt (SATD) in Dockerfiles alongside the related source code.<n>We find that approximately 27% of admission events and 40% of repayment events are coupled to non-Dockerfile artifacts.
• Score: 10.059038321113546
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: Dockerfiles enable the creation of portable container-based execution environments for the application code, and have become an important part of the modern software development process. As Dockerfiles are a form of Infrastructure-as-Code (IaC), they can include temporary workarounds and other suboptimal implementations, leading to the accrual of technical debt that affects their reliability, security, and maintainability in the future. Prior work characterized self-admitted technical debt (SATD) in Dockerfile comments and the surrounding file chunks. This single-file view is incomplete since source code evolution involves changes across different types of software artifacts such as production, test, build, and other configuration files. Thus, we address this gap by studying SATD events in Dockerfiles alongside the related source code. We find that approximately 27% of admission events and 40% of repayment events are coupled to non-Dockerfile artifacts, and coupling sources are subtype-specific. We also observed that coupled SATD in general are repaid significantly faster overall (p = 0.0201), while coupled SATD regarding missing functionalities persists longer than its isolated counterparts; Lastly, we conducted open and axial coding of coupled SATD events, and we observe that external dependency issues, more particularly regarding unreleased upstream packages and bug fixes, are the most common cause of admission triggers in the source code; we also observe that architectural refactoring is the most common prerequisite for the repayment of SATD in Dockerfiles. These findings indicate that both practitioners (e.g. developers and project managers) and SATD researchers should integrate the source code-side co-evolution, rather than the single-file view, as the primary unit of analysis.

Related papers

• LoopsBench: From Harness Engineering to Loop Engineering in Benchmarking Coding Agent [60.27239351179265]
  LOOPSBENCH is a benchmark for loop engineering in coding agent evaluation.<n>It comprises 112 tasks from authentic sources spanning 8 programming languages and 9 domains.<n>Its flow-aware runtime releases tests along the ready frontier and retains completed nodes as regression obligations.
  arXiv  Detail & Related papers  (2026-07-31T20:18:25Z)
• Specification-Driven DevOps for Multi-Service Environments [0.0]
  Large Language Models (LLMs) are increasingly used to generate executable software environments from repository artifacts.<n>This study investigates whether a frontier LLM can generate Dockerfiles and Docker Compose for multi-service applications using repository contents.
  arXiv  Detail & Related papers  (2026-07-27T23:22:44Z)
• Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution [52.50730821321986]
  Cadre is a context-aware framework for automated Dockerfile drift repair.<n>CDG maps each Dockerfile instruction to its file-level and inter-instruction dependencies.<n>DodeX mines real-world Dockerfile drift instances from GitHub Actions CI logs.
  arXiv  Detail & Related papers  (2026-07-14T09:12:26Z)
• Effective Strategies for Asynchronous Software Engineering Agents [52.76455094324273]
  We introduce a structured multi-agent coordination paradigm grounded in three core SWE primitives: centralized task delegation, asynchronous execution, and isolated workspaces.<n>We find that CAID improves accuracy over single-agent baselines by 26.7% absolute on paper reproduction tasks (PaperBench) and 14.3% on Python library development tasks (Commit0).
  arXiv  Detail & Related papers  (2026-03-23T02:26:35Z)
• It's Not Just Timestamps: A Study on Docker Reproducibility [0.3553493344868413]
  We build a Docker measurement pipeline and apply it to a sample of 2,000 GitHub repositories that contained a Dockerfile.<n>We found that only 56% produce any buildable image, and just 2.7% of those are bitwise reproducible without any infrastructure configurations.<n>We derive concrete Dockerfile guidelines from these patterns and discuss how they can inform future linters and Continuous Integration (CI) checks for reproducible containers.
  arXiv  Detail & Related papers  (2026-02-03T00:26:53Z)
• Docker Does Not Guarantee Reproducibility [8.363502352389188]
  Containerization technologies like Docker address the problem by encapsulating software environments into shareable snapshots known as images.<n>While Docker is frequently cited in the literature as a tool that enables in theory, the extent of its guarantees and limitations in practice remains under-explored.<n>First, we conduct a systematic review to examine how Docker is framed in scientific discourse on literature.<n>Then, we perform a large-scale empirical study of 5298 Dockerfiles collected from GitHub.
  arXiv  Detail & Related papers  (2026-01-19T08:16:43Z)
• NL2Repo-Bench: Towards Long-Horizon Repository Generation Evaluation of Coding Agents [79.29376673236142]
  Existing benchmarks fail to rigorously evaluate the long-horizon capabilities required to build complete software systems.<n>We present NL2Repo Bench, a benchmark explicitly designed to evaluate the long-horizon repository generation ability of coding agents.
  arXiv  Detail & Related papers  (2025-12-14T15:12:13Z)
• Refactoring for Dockerfile Quality: A Dive into Developer Practices and Automation Potential [0.0]
  This paper explores the utility and practicality of automating Dockerfile using 600files from 358 open-source projects.<n>Our approach leads to an average reduction of 32% in image size and a 6% decrease in build duration, with improvements in understandability and maintainability observed in 77% and 91% of cases.
  arXiv  Detail & Related papers  (2025-01-23T23:10:47Z)
• Codev-Bench: How Do LLMs Understand Developer-Centric Code Completion? [60.84912551069379]
  We present the Code-Development Benchmark (Codev-Bench), a fine-grained, real-world, repository-level, and developer-centric evaluation framework. Codev-Agent is an agent-based system that automates repository crawling, constructs execution environments, extracts dynamic calling chains from existing unit tests, and generates new test samples to avoid data leakage.
  arXiv  Detail & Related papers  (2024-10-02T09:11:10Z)
• Dockerfile Flakiness: Characterization and Repair [6.518508607788089]
  We present the first comprehensive study of Dockerfile flakiness, featuring a nine-month analysis of 8,132 Dockerized projects.<n>We propose a taxonomy categorizing common flakiness causes, including dependency errors and server connectivity issues.<n>We introduce FLAKIDOCK, a novel repair framework combining static and dynamic analysis, similarity retrieval, and an iterative feedback loop powered by Large Language Models.
  arXiv  Detail & Related papers  (2024-08-09T23:17:56Z)
• On the Security Blind Spots of Software Composition Analysis [46.1389163921338]
  We present a novel approach to detect vulnerable clones in the Maven repository. We retrieve over 53k potential vulnerable clones from Maven Central. We detect 727 confirmed vulnerable clones and synthesize a testable proof-of-vulnerability project for each of those.
  arXiv  Detail & Related papers  (2023-06-08T20:14:46Z)

This list is automatically generated from the titles and abstracts of the papers in this site.

This site does not guarantee the quality of this site (including all information) and is not responsible for any consequences.