Closing the Gap: Automated Discovery of Secure Dockerfile Reference Standards via Semantic Clustering in Enterprise Inner Source

Jessica Hösl; Benedikt Hofmann; Patrick Stöckle

Source-linked AI summary

Closing the Gap: Automated Discovery of Secure Dockerfile Reference Standards via Semantic Clustering in Enterprise Inner Source

Jessica Hösl, Benedikt Hofmann, Patrick Stöckle

arXiv:2608.25793v1Aug 26, 2026cs.CRcs.SE

TL;DR

Enterprise Dockerfiles often contain security misconfigurations and technical debt, but corporate inner-source environments are poorly characterized and cannot be directly represented by open-source findings. The paper uses a six-stage pipeline with semantic clustering and cluster-internal references to measure this debt and its remediable gap. In one industrial company, existing internal standards indicate a 60.4% relative security-posture improvement without new templates.

Problem
Corporate inner-source Dockerfile security debt is insufficiently characterized, while functional heterogeneity makes syntactic grouping inadequate for identifying relevant internal references.
Method
The paper crawls enterprise Dockerfiles, enriches them with security, quality, and lifecycle metrics, semantically clusters workloads, and compares files with cluster-internal reference implementations.
Results
60.4% of measured security debt is addressable from existing internal data without commissioning new secure templates.
Takeaways & Limitations
The enriched enterprise dataset provides a prioritization framework and retrieval corpus for context-aware automated repair based on internal best practices.
Takeaways & Limitations
The study uses a static snapshot from a single corporate environment, so debt distributions and the reported magnitudes may differ across organizations.

Abstract

from arXiv · show

Containerization dominates enterprise software delivery, yet Dockerfiles that assemble container images frequently harbor security misconfigurations and structural technical debt. This problem is poorly understood in corporate inner-source environments, where proprietary context and isolated governance prevent direct application of open-source findings. We present an automated, six-stage pipeline that: (1) crawls an enterprise GitLab instance, (2) enriches each Dockerfile with static security and quality metrics (Hadolint, ShellCheck, Trivy) and lifecycle data, (3) groups functionally identical workloads using LLM-generated semantic descriptions and HDBSCAN, and (4) quantifies the optimization gap against cluster-internal reference implementations. Applied to 11,470 Dockerfiles from over 6,200 repositories at a single large industrial company, we find a systemic deficit: 99\% of files contain at least one security misconfiguration, 80.8\% violate Dockerfile best practices, and the median artifact has not been revised for 838~days. Despite this, high-quality reference implementations already exist within 83\% of functional clusters. Adopting these internal standards would increase the average security posture score by 60.4\% without developing any new templates. These findings, grounded in one organization's inner-source ecosystem, provide a data-driven foundation for future automated, context-aware recommender systems targeting enterprise supply-chain security; whether the observed technical-debt distribution and optimization gap generalize to other enterprises remains an open question for future multi-organization study.

1 Introduction

Dockerfiles are central to modern software delivery but combine several technically demanding concerns, creating security and maintenance problems. Enterprise inner-source research lacks a method for grouping functionally equivalent Dockerfiles and identifying internal reference standards.

Over 90% of production environments use containerization, making Dockerfiles important blueprints for production, CI/CD, and development workloads.
Dockerfiles are difficult to secure and maintain because they combine system administration, shell scripting, and dependency management in one artifact.
Enterprise inner-source environments differ from public repositories through proprietary base images, organizational conventions, and isolated governance.
The paper addresses missing methodology for grouping enterprise Dockerfiles by functional intent and locating high-quality internal reference configurations.
11,470 Dockerfiles across 251 functional clusters reveal a 60.4% optimization gap addressable through existing internal data.

2 Background and Related Work

Prior Dockerfile research largely studies open-source repositories, while enterprise environments introduce distinct tools, policies, workload heterogeneity, and governance constraints. The paper therefore targets semantic grouping and internal reference discovery as complementary to existing security scanners and repair systems.

Open-source studies report widespread Dockerfile smells, vulnerability inheritance, outdated parent images, and documented optimization strategies.
Corporate inner-source environments may have different debt distributions because of proprietary base images, organizational standards, licensing requirements, and isolated development silos.
Rule-based correction tools address specific smells, whereas LLM-based systems target more complex, context-dependent configuration repairs.
Keyword retrieval and AST-based embeddings remain limited when functionally equivalent Dockerfiles use syntactically diverse implementations.
Commercial scanners detect vulnerabilities and suggest individual image or dependency fixes but do not identify internally vetted references across equivalent workloads.
The paper addresses contextual, semantic-grouping, and reference-extraction gaps in enterprise remediation.

3 Industrial Context and Problem

The study examines an inner-source ecosystem in which autonomous teams share code but often maintain divergent Dockerfile configurations. This creates security, maintenance, and duplication costs that motivate automated measurement and remediation.

The company’s self-hosted GitLab ecosystem spans autonomous departments sharing code through inner source.
Approximately 44,000 repositories were accessible to all employees, but teams rarely re-synchronize Dockerfiles with functional peers.
Containers running as root or inheriting unpatched base images create potential lateral-movement entry points.
Dormant Dockerfiles increase hidden liability as upstream packages accumulate CVEs while configurations remain static.
Functional clusters contain many independent reimplementations, so standardization can reduce the number of configurations requiring audit and maintenance.
Before this work, no tooling quantified this debt, mapped its distribution, or extracted remediation targets from internal repositories.

Research Questions

The study asks how to measure Dockerfile security posture, cluster workloads by functional intent, and quantify remediation available through internal knowledge transfer. Its pipeline persists intermediate artifacts to support reproducibility.

RQ1 — Ecosystem State: RQ1 establishes the current security posture of corporate Dockerfiles using static-analysis metrics and lifecycle data.
RQ2 — Semantic Clustering Quality: RQ2 tests whether LLM-generated functional descriptions and density-based clustering produce tighter workload grouping than syntactic baselines.
RQ3 — Addressable Remediation Potential: RQ3 quantifies how much security debt can be addressed by promoting configurations already present within the same functional cluster.
The six-stage pipeline persists intermediate results as Parquet snapshots for independent validation and reproducibility.

4 Approach

The approach combines enterprise Dockerfile collection, parser-backed feature extraction, weighted posture scoring, and semantic clustering to compare functionally related workloads. It then identifies cluster-internal references and estimates remediable optimization gaps while accounting for workload-specific image footprints.

Pipeline Overview: Six sequential stages orchestrate GitLab crawling, Dockerfile parsing, metric extraction, semantic clustering, and reference-based optimization analysis.Intermediate results are persisted as Apache Parquet snapshots for validation and reproducibility.
Data Collection and Preparation: 11,470 cleaned Dockerfiles were collected from 6,247 repositories after integrity checks removed empty, malformed, and invalid-syntax records.The raw dataset contained 12,002 unique Dockerfiles before cleaning.
Data Collection and Preparation: Dockerfiles are parsed into ASTs with the official Moby/BuildKit parser, while CI/CD variables resolve unresolved base-image references and normalized AST strings support downstream analysis.Comments are stripped and multiline RUN blocks are concatenated for normalization.
Feature Extraction and Scoring: Six normalized metrics combine linting, security scans, update frequency, image size, and recency into a weighted Security Posture Score.Trivy and Hadolint each receive weight 0.25, update frequency 0.20, base image size 0.15, recency 0.10, and ShellCheck 0.05.
Feature Extraction and Scoring: Relative Security Posture Score normalizes base image size within each cluster’s 5th–95th percentile bounds, separating configuration debt from architectural footprint.This adjustment is intended to avoid systematically penalizing machine-learning or robotics workloads with larger inherent images.
Semantic Clustering: LLM-generated workload descriptions are embedded and clustered with UMAP and HDBSCAN, which supports unknown cluster counts, imbalanced densities, and explicit noise labels.Descriptions omit operating-system and version details to reduce implementation-driven clustering.
Reference-Based Comparison: Within each functional cluster, the highest-scoring Dockerfile defines the golden reference, while a conservative P90 target limits dependence on extreme architectural configurations.The P90 target replaces the single maximum when the highest score may not generalize across the cluster.

5 Evaluation

Evaluation of 11,470 enterprise Dockerfiles reveals widespread lifecycle neglect, quality violations, and security misconfigurations, while semantic clustering exposes substantial within-workload optimization opportunities. Existing higher-quality implementations could materially improve scores across clustered files and the wider ecosystem.

Clustering Validation: 251 semantic clusters cover 83% of the dataset, reducing global dataset entropy by 62% while leaving 17% of files as noise.Semantic clustering intentionally accepts heterogeneous base images to group implementations by workload function; raw-content clustering produces 21% noise.
Clustering Validation: Semantic clustering groups functionally coherent workloads despite syntactic differences, including .NET implementations with security posture scores ranging from 0.07 to 0.87.Node.js frontend, backend, and build workloads are separated into semantically distinct groups.
Security Debt and Optimization Gap: Within-cluster score variation is widespread: a small subset of high-scoring files coexists with many lower-scoring peers across most functional groups.The weighted within-cluster standard deviation averages 0.13, and this intra-cluster spread is identified as the primary driver of the optimization gap.
State of the Ecosystem: 838 days is the median time since a Dockerfile was revised, and 70.2% of files are dormant or abandoned under the study’s maintenance taxonomy.Only 23.4% are actively maintained, while 6.4% are stable or new; the top 10% exceed 9.8 revisions annually.
State of the Ecosystem: 99% of Dockerfiles contain at least one security misconfiguration, with missing HEALTHCHECK and root execution appearing together in 81.7% of files.The pair produces exactly two misconfigurations in 42.4% of the dataset.
Security Debt and Optimization Gap: 60.4% relative improvement is available for the average clustered Dockerfile by adopting practices already present within its functional cluster.The mean optimization gap is Δopt = 0.29, equivalent to a 29-percentage-point absolute increase; the lowest-performing 10% face gaps exceeding 0.53.
Security Debt and Optimization Gap: Resolving all clustered debt would raise the global mean score from 0.48 to 0.72, a 50.6% improvement across all 11,470 files.A conservative P90 target still yields a 28.75% global improvement.

6 Lessons Learned and Industrial Implications

Enterprise Dockerfiles show uneven maintenance and substantial optimization potential, while semantic clustering exposes internal references that can support downstream automated remediation.

Maintenance activity: 70% of inner-source Dockerfiles remain dormant despite the top 10% receiving nearly 10 revisions per year.The higher-maintenance files are closely coupled to production workloads.
Knowledge propagation: High-quality hardened configurations exist within 83% of functional clusters, indicating that the optimization gap reflects propagation failure rather than absent expertise.Teams writing functionally equivalent containers often do not discover these internal standards.
Addressable debt: Semantic clustering identifies 30% more addressable debt per file than the syntactic baseline.Existing internal best practices are sufficient to address most identified debt, while semantic grouping surfaces more valid references.
Downstream automation: The enriched, clustered dataset supports LLM-based repair through golden-reference demonstrations, workload-aware retrieval, and prioritized intervention lists.The Optimization Gap ranks files for automated remediation.

7 Threats to Validity

The study’s validity is constrained by proxy-based scoring, implementation choices, incomplete parser coverage, and a single-organization static snapshot.

Construct: The Security Posture Score measures configuration hygiene rather than runtime CVE counts.Equal warning weights and expert-selected thresholds may change absolute scores under alternative configurations.
Internal validity: 5.1% of base-image definitions remained unresolvable, while omitted Git history and Hadolint parsing may affect recency and corpus coverage.Unresolvable files were retained, but some buildable non-standard Dockerfiles may have been discarded.
External validity: The dataset comes from a single corporate environment, so debt distributions, workload mixes, and governance postures may differ elsewhere.The study is also a static snapshot rather than a longitudinal analysis of debt accumulation.
Clustering: No labeled ground truth exists for clustering, and heuristic hyperparameters plus fixed models may alter cluster granularity and the measured Optimization Gap.The study does not compare alternative clustering algorithms on the same semantic embeddings or test alternative embedding and language models.

8 Future Work

Future work will turn the analysis into an operational remediation process, address missing references, study longitudinal change, and test clustering robustness.

Automated refactoring: Golden reference Dockerfiles will provide enterprise-native few-shot examples for LLM-based automated refactoring.The proposed repair system could integrate into CI pipelines or process files broadly.
Missing references: 17% of clusters without viable internal exemplars will receive secure baseline configurations created through manual engineering.These baselines will serve as golden references for automated remediation.
Longitudinal evolution: The static snapshot will be extended into a recurring process with periodic full re-clustering as the ecosystem evolves.Future work will account for newly added, edited, and periodically updated Dockerfiles and base images.
Deployment and adoption: Clusters with the largest cumulative optimization gaps and viable references will be prioritized for outreach through existing inner-source channels.Teams will receive golden references and per-file diffs rather than centrally mandated adoption.
Robustness ablations: Robustness studies will compare clustering algorithms, embedding models, and language models using cohesion, noise, and overlap measures.The planned comparisons target methodological gaps identified in the validity analysis.

9 Conclusion

The pipeline identifies substantial Dockerfile security debt and shows that existing internal reference implementations can address much of it without new templates. The findings also establish a prioritization and retrieval foundation for enterprise remediation while remaining bounded by the single-organization setting.

60.4% relative improvement in security posture is achievable by propagating internal best practices already present within functional clusters.A conservative P90 target still yields a 28.75% global improvement.
The precise percentages are not transferable a priori because the study reflects one company’s technology mix, governance posture, and technical-debt distribution.The authors expect the qualitative pattern of latent internal references to recur, but call for comparable studies in other ecosystems.
99% of Dockerfiles contain at least one misconfiguration, 80.8% contain smells, and median recency is 838 days, indicating pervasive technical debt.The mean composite security posture score is 0.48.
LLM-semantic clustering reduced global base-image entropy by 62% with 17% noise and outperformed content-based and HLS syntactic baselines in functional cohesion.The force-directed graph confirmed workload isolation across six technology stacks.
The findings provide infrastructure teams with a data-driven prioritization framework and establish the enriched dataset as a retrieval corpus for automated repair.The framework quantifies the scale of container security debt addressable through automated software engineering in this enterprise context.

Data Availability Statement

The analyzed Dockerfiles and metadata come from a proprietary enterprise inner-source environment and cannot be publicly accessed. The pipeline itself is also not publicly released because it contains proprietary integrations and restricted implementation details.

The study’s data and implementation therefore remain bounded by the company’s proprietary inner-source environment.
The dataset is unavailable for review or public access because licensing restrictions and confidentiality agreements prohibit external distribution.
The analysis pipeline is not publicly released because it includes proprietary GitLab integrations, credential management, and internal toolchain orchestration.