💻 computer science

Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution

Dieses Paper präsentiert Cadre, ein kontextsensitives Framework, das durch statische Analyse einen kontextsensitiven Abhängigkeitsgraphen (Context-aware Dependency Graph, CDG) nutzt, um gezielte Patches zu generieren, die Dockerfile-Drift effektiv reparieren und dabei die bestehenden regelbasierten sowie LLM-basierten Baselines auf dem neu eingeführten $D^3$ -Benchmark mit 1.040 realen Drift-Instanzen übertreffen.

Ursprüngliche Autoren: Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

Veröffentlicht 2026-07-15

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie bauen in Ihrer Garage einen Roboter. Sie haben eine perfekte Bedienungsanleitung (das Dockerfile) geschrieben, die genau vorgibt, welche Teile der Roboter greifen soll, wo er sie platzieren muss und wie er sie zusammenbaut. Doch dann beschließen Sie, das Gehirn des Roboters aufzurüsten (den **Quellcode) und tauschen ein paar Kabel aus. Sie vergessen jedoch, die Anleitung an die neuen Teile anzupassen.

Nun, wenn Sie versuchen, den Roboter zu bauen, stottert er und stirbt ab. Die Anleitung ist nicht „kaputt“ im grammatikalischen Sinne; die Wörter sind korrekt. Aber die Anleitung driftet von der Realität weg. Sie versucht, ein Teil zu greifen, das nicht mehr existiert, oder ein Werkzeug zu benutzen, das ersetzt wurde. In der Welt der Software nennt man das Dockerfile-Drift, und es führt dazu, dass Computer lautlos versagen, was Entwickler tagelang ratlos zurücklässt.

Der alte Weg: Im Dunkeln stochern

Frühere Tools versuchten, dies zu beheben, indem sie einfach nur die Anleitung und die Fehlermeldung lasen. Es ist, als würde man versuchen, einen Automotor zu reparieren, indem man nur auf die Motorkontrollleuchte und das Handbuch schaut, ohne jemals die Motorhaube zu öffnen, um die tatsächlichen Kabel zu sehen.

Einige Tools nutzten starre Regeln (wie eine Checkliste), während andere superintelligente KI (Large Language Models) verwendeten, um die Lösung zu erraten. Aber hier liegt das Problem: Diese KI-Tools ertranken in Informationen. Man überreichte ihnen die gesamte Garage – jede einzelne Schraube, jedes alte Handbuch und jeden Kasten voller Schrott – zusammen mit der Fehlermeldung. Die KI wurde von der Menge an Informationen so überwältigt, dass sie entweder aufgab oder eine verrückte, nicht funktionierende Lösung halluzinierte. Tatsächlich konnten diese KI-Tools in etwa 41 bis 58 von jedem Satz an Problemen gar keine Antwort liefern, weil die „Anweisungsliste“ zu lang war, um sie zu lesen.

Der neue Held: Cadre (Der Detektiv)

Hier kommt Cadre ins Spiel, ein neues Framework, das wie ein brillanter Detektiv agiert. Die Autoren, Chengjie Wang und sein Team, erkannten, dass das Geheimnis zur Reparatur des Roboters nicht darin besteht, dem Detektiv mehr Material zum Lesen zu geben, sondern ihm die richtige Karte zu überreichen.

Ihre große Idee ist simpel: Struktur ist wichtiger als Volumen. Zu wissen, welcher spezifische Draht mit welcher spezifischen Schraube verbunden ist, ist viel wichtiger, als tausend Seiten unzusammenhängender Texte zu lesen.

Cadre erledigt dies in drei magischen Schritten:

Der Context Profiler (Der Zeitreisende): Bevor es versucht, etwas zu reparieren, simuliert Cadre den gesamten Bauprozess Schritt für Schritt. Es beobachtet genau, welche Dateien kopiert werden, welche Variablen gesetzt werden und welche Werkzeuge aufgerufen werden. Es baut ein mentales Modell des „Zustands“ des Projekts zu jedem einzelnen Zeitpunkt auf.
Das CDG (Die Abhängigkeitskarte): Miths dieser Simulation zeichnet Cadre einen Context-aware Dependency Graph (CDG). Denken Sie an diesen als eine U-Bahn-Karte für Ihre Software. Er zeigt genau, wie die „FROM“-Anweisung (die Basis) mit der „COPY“-Anweisung (die Teile) und schließlich mit der „RUN“-Anweisung (die Montage) verbunden ist. Wenn sich eine Datei ändert, zeigt die Karte genau an, welche Anweisungen dadurch Probleme verursachen werden.
Die Zwei-Schritt-Reparatur (Der intelligente Filter): Anstatt der KI die ganze Garage vor die Füße zu werfen, stellt Cadre ihr zuerst eine kluge Frage: „Basierend auf dieser Karte und dem Fehler, welche spezifischen Dateien musst du tatsächlich sehen?“
- Schritt 1: Die KI wählt nur die relevanten Dateien aus (die „Key Files“).
- Schritt 2: Die KI liest nur diese Dateien und schreibt die Korrektur.

Dies verhindert, dass das „Gehirn“ der KI überläuft. Während andere Methoden in 41–58 Fällen keine Lösung generieren konnten, weil der Prompt zu groß war, erstellte Cadre für jeden einzelnen seiner Versuche ein Patch.

Die Ergebnisse: Funktioniert es?

Das Team testete Cadre an 1.040 realen Beispielen, die sie aus der GitHub-Historie extrahiert hatten (ein Datensatz, den sie 𝐷3 nannten). Dies waren keine künstlichen Probleme; es handelte sich um tatsächliche Fehler, die in echten Softwareprojekten auftraten, inklusive der exakten Einstellungen, die zur Reproduktion nötig waren.

So schnitt Cadre ab:

Cadre behob 35,22 % der Probleme.
Die beste vorherige KI-Methode (ohin dieses smarte Mapping) behob 28,48 %.
Die alte regelbasierte Checklisten-Methode behob nur 9,34 %.

Das bedeutet, dass Cadre 1,24-mal besser ist als der beste KI-Wettbewerber und fast 3-mal besser als die alten regelbasierten Tools.

Doch die wahre Magie zeigt sich, wenn das Problem „veraltet“ ist. Stellen Sie sich einen defekten Build vor, der durch fünf oder sechs Updates hindurch niemand repariert hat. Die jüngsten Codeänderungen wirken völlig unzusammenhängend mit dem ursprünglichen Fehler. Die meisten Tools werden verwirrt und geben auf. Aber weil Cadre die CDG-Karte nutzt, kann es den defekten Draht bis zu seinem Ursprung zurückverfolgen, selbst wenn er tief in der Historie vergraben ist. Bei fünf oder mehr Updates entfernt konnte Cadre 25,9 % der Probleme lösen, während das nächstbeste Tool nur 19,7 % schaffte. Die Lücke wurde mit zunehmendem Alter der Probleme sogar noch größer, was beweist, dass die Karte ein dauerhaftes Signal ist.

Was es NICHT ist

Es ist wichtig zu wissen, was Cadre nicht leistet. Es ist kein Zauberstab, der alles behebt.

Es kann keine Probleme beheben, die durch eine Internetverbindung oder einen vollen Festplattenspeicher verursacht werden.
Es kann keine Bugs innerhalb der eigentlichen Codelogik beheben (wie einen Rechenfehler im Programm selbst); es repariert nur die Build-Anweisungen.
In etwa 65 % der Fälle, in denen es scheiterte, lag das Problem an einer komplexen Build-Tool-Beschränkung, die durch Ändern der Anleitung schlicht nicht lösbar war (wie ein fehlendes Paket in einem privaten Registry).

Das Fazkuma

Die Autoren legen nahe, dass wir für die Zukunft der Softwarewartung aufhören müssen, der KI einfach nur mehr Daten zuzumuten, und stattdessen lernen müssen, ihr die Struktur von Abhängigkeiten zu vermitteln. Durch den Aufbau einer Karte darüber, wie Dateien und Anweisungen miteinander verbunden sind, hat Cadre bewiesen, dass ein wenig smarter Kontext sehr viel bewirken kann. Es geht nicht darum, die ganze Bibliothek zu lesen; es geht darum, genau zu wissen, auf welche Seite man umblättern muss.

Der gesamte Code und der Datensatz der 1.040 realen Drifts sind offen zugänglich, damit jeder prüfen kann, dass dies nicht nur eine Theorie ist, sondern ein Werkzeug, das auf realen, reproduzierbaren Beweisen basiert.

Technisches Resümee: Taming the Drift: Kontextbewusste Reparatur von Dockerfile-Drift während der Software-Evolution

1. Problemdefinition: Dockerfile-Drift

Die moderne Softwareentwicklung stützt sich stark auf Continuous Integration und Continuous Deployment (CI/CD)-Pipelines, in denen Docker als De-facto-Standard dient, um reproduzierbare Build-Umgebungen zu gewährleisten. Ein kritisches Problem namens Dockerfile-Drift untergräbt jedoch diese Zuverlässigkeit. Drift tritt auf, wenn ein Dockerfile es versäumt, Änderungen am Quellcode der Anwendung zu absorbieren, was zu einer Diskrepanz zwischen dem Build-Skript und dem sich entwickelnden Repository-Zustand führt. Im Gegensatz zu Syntaxfehlern handelt es sich beim Drift um ein internes Ko-Evolutionsproblem, bei dem die Informationen zur Behebung innerhalb desselben Repositories liegen, das den Fehler verursacht hat.

Drift manifestiert sich als fehlerhafte Dateipfade, nicht übereinstimmende Umgebungsvariablen, veraltete Spezifikationen von Abhängigkeiten oder Plattformänderungen. Diese Fehler sind aufgrund von drei Kernherausforderungen besonders schwer automatisch zu reparieren:

C1 (Kontext-Extraktion): Der Build-Zustand (Arbeitsverzeichnis, Umgebungsvariablen, Dateiensätze) wird durch die kumulative Ausführung vorangegangener Anweisungen bestimmt, nicht nur durch den Text des Dockerfiles. Bestehende regelbasierte und LLM-basierte Methoden behandeln das Dockerfile oft isoliert und versäumen es, diese dynamischen Interaktionen zu modellieren.
C2 (Inter-Instruktions-Abhängigkeiten): Anweisungen hängen oft auf nicht offensichtliche Weise von Artefakten ab, die durch frühere Schritte erzeugt wurden (z. B. eine RUN-Anweisung, die auf Dateien operiert, die durch ein vorheriges COPY eingeführt wurden, oder Variablen, die durch ein ARG gesetzt wurden). Diese Abhängigkeiten sind isoliert betrachtet syntaktisch nicht sichtbar.
C3 (Lokalisierung der Ursachen): Fehlerprotokolle weisen zwar auf die fehlerhafte Instruktion hin, identifizieren aber selten die eigentliche Ursache, die aus einer Codeänderung in einem vorangegangenen Commit stammen kann.

2. Methodik: Das Cadre-Framework

Die Autoren schlagen Cadre vor, ein kontextbewusstes Framework, das darauf ausgelegt ist, Dockerfile-Drift durch die explizite Modellierung des Build-Kontexts zu reparieren. Die zentrale Design-Einsicht ist, dass die Kontextstruktur die Qualität der Reparatur mehr bestimmt als das Kontextvolumen. Cadre adressiert die drei Herausforderungen durch vier integrierte Phasen:

2.1 Dockerfile Drift Extractor (DodeX)

Um den Mangel an realistischen Benchmarks zu beheben, haben die Autoren DodeX entwickelt, eine Pipeline, die reale Drift-Instanzen aus GitHub Actions CI-Logs extrahiert. Im Gegensatz zu statischen Snapshot-Datensätzen erfasst DodeX die vollständige Build-Konfiguration, einschließlich dynamischer Build-Argumente, Zielplattformen und der exakten Code-Diffs, die den Fehler ausgelöst haben. Dies stellt sicher, dass jede extrahierte Instanz lokal reproduzierbar ist.

2.2 Instruktionsbasierter Kontext-Profiler

Um C1 zu lösen, führt Cadre eine zustandsorientierte Simulation des Docker-Build-Prozesses durch. Es durchläuft das Dockerfile Instruktion für Instruktion und pflegt dabei einen Kontext-Zustand ( $\sigma$ ), der Folgendes verfolgt:

Das aktuelle Arbeitsverzeichnis ( $\delta$ ).
Aufgelöste Umgebungsvariablen ( $\varepsilon$ ).
Den Satz der im Container vorhandenen Dateien ( $\Phi$ ).

Entscheidend ist, dass der Profiler build-system-bewusste Parser für 11 große Ökosysteme (z. B. Go, Python, npm, Maven) verwendet. Anstatt RUN-Befehle als opake Strings zu behandeln, inferieren diese Parser implizite Datei-Abhängigkeiten (z. B. inferiert der Parser, dass go build von go.mod und allen *.go-Dateien im Verzeichnis abhängt). Dies erzeugt eine Instruction Context Map (ICM), die jede Instruktion mit ihrem präzisen Build-Zeit-Zustand verknüpft.

2.3 Kontextbewusster Abhängigkeitsgraph (CDG)

Um C2 zu lösen, wird die ICM in einen Context-aware Dependency Graph (CDG) umgewandelt, einen gerichteten azyklischen Graphen ( $G = (V, E)$ ), der die Inter-Instruktions-Abhängigkeiten explizit macht:

Knoten: Umfassen Instruktionsknoten ( $V_I$ ) und Dateiknoten ( $V_F$ ).
Kanten: Umfassen sequentielle Kanten ( $E_S$ ), die den Kontrollfluss repräsentieren, und Datenfluss-Kanten ( $E_D$ ), die "Read-from"-Abhängigkeiten zwischen Dateien und Instruktionen darstellen.
Dieser Graph ermöglicht es dem System, die Ausbreitungspfade von Fehlern über Instruktionsgrenzen hinweg zurückzuverfolgen und zu identifizieren, wie eine Änderung in einer Quelldatei (z. B. go.mod) eine spezifische RUN-Instruktion über zwischengeschaltete COPY- oder ARG-Schritte invalidiert.

2.4 Kontext-verfeinerter Reparatur-Workflow

Um C3 zu lösen und Token-Limits zu verwalten, nutzt Cadre einen zweistufigen agentischen Workflow anstelle eines Single-Shot-Prompts:

Kontext-Anfrage (Context Inquiry): Dem LLM werden das Fehlerprotokoll, der Code-Diff und eine reduzierte Version des CDG präsentiert. Es wird angewiesen, den minimalen Satz relevanter Dateien und Grep-Keywords auszuwählen, die für die Reparatur erforderlich sind. Dieser Schritt filtert irrelevanten Kontext heraus, bevor die Dateiinhalte geladen werden.
Reparatur-Generierung (Repair Generation): Das System ruft nur die ausgewählten Dateien ab und generiert einen gezielten Patch.
Dieser Ansatz verhindert Prompt-Overflow (ein häufiger Fehlermodus konkurrierender LLM-Methoden) und stellt sicher, dass sich das Modell auf kausal relevante Evidenz konzentriert.

3. Kernbeiträge

Cadre-Framework: Ein neuartiges Reparatur-Framework, das auf der Erkenntnis basiert, dass die Kontextstruktur wertvoller ist als das Kontextvolumen. Es integriert einen zustandsorientierten Kontext-Profiler, einen Abhängigkeitsgraphen und einen zweistufigen LLM-Workflow.
DodeX und $D^3$ Benchmark: Die Erstellung von DodeX, einer Pipeline zur Extraktion von Drift-Instanzen mit vollständigen Build-Konfigurationen, und $D^3$ , dem ersten Dockerfile-Drift-Benchmark, bei dem alle 1.040 Instanzen unter Verwendung der exakten Parameter aus den ursprünglichen CI-Läufen lokal reproduzierbar sind.
Empirische Evaluierung: Eine umfassende Evaluierung von Cadre gegenüber regelbasierten Baselines (Parfum), retrieval-basierten Baselines (FlakiDock) und Vanilla-LLMs.

4. Experimentelle Ergebnisse

Das Framework wurde auf dem $D^3$ -Benchmark evaluiert (653 ausführbare Instanzen nach Filterung auf Netzwerk-Timeouts).

Reparatur-Effektivität: Cadre erreichte eine Reparaturrate von 35,22 % und übertraf damit die regelbasierte Baseline (Parfum, 9,34 %) um das 2,78-Fache sowie die beste LLM-basierte Baseline (Vanilla-LLM, 28,48 %) um das 1,24-Fache.
Token-Effizienz & Robustheit: Cadre eliminierte Prompt-Overflow-Fehler vollständig ( $|F_r| = 0$ ) und hielt 95,25 % der Prompts unter 30k Tokens. Im Gegensatz dazu scheiterten konkurrierende LLM-Methoden in 41–58 Fällen an der Überschreitung der Kontextlimits.
Robustheit gegenüber veraltetem Drift (Stale Drift): Wenn Drift-Instanzen "veraltet" wurden (über mehrere Commits hinweg bestehen blieben), verschlechterte sich die Leistung von Diff-only-Ansätzen signifikant. Bei einem Abstand von 5+ Commits behielt Cadre eine Erfolgsrate von 25,9 % bei, verglichen mit 19,7 % für die beste Baseline, was zeigt, dass der CDG ein strukturelles Signal liefert, das gegenüber der Commit-Distanz robust ist.
Ablationsstudien: Das Entfernen des CDG reduzierte die Reparaturrate um 4,29 Prozentpunkte, während das Entfernen des zweistufigen Workflows die Rate um 3,67 Punkte senkte und Prompt-Overflow-Fehler wieder einführte. Die Komponenten erwiesen sich als sich gegenseitig verstärkend.

5. Bedeutung und Ansprüche

Das Paper behauptet, dass die explizite Abhängigkeitsmodellierung ein dauerhaftes Reparatur-Signal ist. Die Autoren argumentieren, dass sich der Vorteil kontextbewusster Ansätze gegenüber Diff-only- oder Retrieval-basierten Methoden vergrößert, wenn der Drift über Commits hinweg altert. Die Studie legt nahe, dass die kontextbewusste Wartung von Infrastructure as Code (IaC) eine produktive Richtung für die zukünftige Werkzeugentwicklung ist.

Die Autoren merken bescheiden die Limitationen an: Der CDG basiert auf statischer Analyse und kann regulatorische Runtime-Faktoren wie den Zustand von Paket-Registries oder Netzwerkbedingungen nicht vollständig erfassen, was einige ungelöste Fehler erklärt. Zudem ist der Benchmark auf öffentliche GitHub-Repositories beschränkt. Dennoch etabliert die Arbeit, dass die explizite Modellierung des Build-Kontexts – insbesondere der Fluss von Daten und Kontrolle über Instruktionen hinweg – entscheidend für die Automatisierung der Reparatur sich entwickelnder Softwarekonfigurationen ist.