Does Runtime Topology Context Improve LLM-Generated Kubernetes Security Patches?

Farooq Shaikh

REVIEW 3 major objections 5 minor 33 references

Does Runtime Topology Context Improve LLM-Generated Kubernetes Security Patches?

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

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

Pith's one-line read Supplying live runtime topology to LLMs lifts Kubernetes patch correctness from 11% to 78%.

desk verdict A careful controlled study with a real, narrowly operationalized effect; the headline 78% is exact-value recovery, not measured blast radius, and the paper mostly says so. read the letter →

arxiv 2607.25995 v1 pith:H3QRYHLO submitted 2026-07-28 cs.CR cs.AI

Farooq Shaikh This is my paper

classification cs.CRcs.AI

keywords KubernetesLLMsecuritypatchesruntimetopologyservicecallgraphfunctionalblastradiusKSPMautomatedremediation

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 reason LLM-generated Kubernetes security patches break running clusters is a missing ingredient: the live service-call topology. By building a system that feeds the observed call graph, bound ports, and the service-account bindings a workload reads into the patch prompt, the authors raise correctness on topology-dependent findings from 11.1% to 78.0% across four models, while a topology-independent control shows no change. The result matters because it isolates the effect to topology context, ruling out generic prompt enrichment, and points to a concrete mechanism: a correct patch must transcribe cluster-observed values that scanner-only prompts cannot supply.

What carries the argument

The central object is a two-stage pipeline. It first assembles a live cluster context from service-mesh call telemetry, Kubernetes Security Posture Management findings, and the service-account bindings a workload reads, then ranks compliance-weighted attack paths over that context and conditions an LLM's remediation prompt on it. The mechanism that carries the argument is the delivery of cluster-observed values — exact secret names and keys, caller/callee labels, resourceNames, storage classes — that a correct patch must transcribe verbatim. Alongside this, a deterministic per-class scorer credits a patch only when it both clears the finding and recovers the hand-labelled cluster value, oper

What would settle it

Re-run the 248 trials but score by live cluster behaviour — whether the patched workload becomes ready and all observed call-edge traffic persists — instead of by exact-match to the hand-labelled value; if the aware arm's advantage collapses under that metric, the 78% figure is an artifact of the scoring proxy.

Watch

Extended reading notes

Core claim

On its own terms, the paper claims that conditioning LLM patch generation on live runtime topology — the service-call edges a workload actually uses, the ports it binds, and the secrets or configs its service account is scoped to read — changes what an LLM can fix. On the 31-finding purpose-built healthcare cluster, topology-dependent patch correctness rises from 11.1% (11/99 trials) under finding-only prompting to 78.0% (78/100) when the topology context is prepended, a gap of 0.669 that holds for every model tested and for six of seven dependency classes. The control arm establishes the critical contrast: six topology-independent findings show identical aware and blind correctness (23/24,

Load-bearing premise

The paper's headline number rests on a proxy that equates exact string recovery of a hand-labelled cluster value with a non-breaking patch, even though the paper itself concedes this proxy can reject a functionally safe paraphrased patch.

Editorial extensions

If this is right

LLM-based security remediation should be conditioned on runtime topology, not just scanner findings, for any finding whose correct fix depends on a cluster-observed value.
For credential, secret, and network-policy classes, where the required value is a single name, supplying the context is almost sufficient (0.95 gains).
RBAC patching remains error-prone even with context: models omit precise resourceNames, so generated RBAC patches need a post-generation validation gate.
Context can backfire when it includes values that tempt the model (e.g., an image digest that led models to repoint an image and sever edges), so blast-radius gating is a necessary safety net.
The effect is specific to topology-dependent findings; topology-independent findings see zero change, confirming the control.

Reading between the lines

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

The exact-value scoring proxy is conservative for the aware arm: the paper notes it can mark a functionally healthy but paraphrased patch as incorrect, so true safe-patch rates under live blast-radius observation could be higher than 78%.
The remaining aware-arm failures cluster in transcription (RBAC, POLICY, STORAGE), suggesting a cheap, testable extension: validate emitted values against the supplied context or slot-fill the patch template, which would likely close most of the gap.
The 25/6 TD/TI split is a construction choice; if real production clusters have far fewer topology-dependent findings, the practical benefit of adding topology context shrinks proportionally, a question the paper leaves open.
A testable extension would decompose the context: feed only call edges, only service-account bindings, or only bound ports, to measure which component carries the 0.669 gain.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

Short version: this is a solid, honest controlled study of a real question, and the central effect survives a close read. The headline number is not a measurement of functional blast radius, though; it is exact-match recovery of cluster-derived values, and the paper is upfront about that. The 78% should not be quoted as "verified non-breaking patches."

What is new: the first controlled TD/TI factorial evaluation of runtime topology context for LLM-generated Kubernetes patches, plus the VulnCare benchmark (31 findings, seven classes, released with scorers and results) and per-model replication across four models. The TI negative control showing Δ=0.0 is strong and rules out generic prompt enrichment. The POLICY inversion (Δ=-0.375) is a nice result — context can actively mislead, and the paper reports it rather than burying it. The false-negative bound on blind successes is also good discipline. Citation pattern looks fine.

Soft spots: the scorer equates exact-value recovery with safety. §4.5 says it is a mechanised proxy for functional blast radius, not an observed outcome. The stress-test note is correct that the proxy can err in both directions, and only the conservative direction is acknowledged. A patch that carries the right Secret name but also changes the image or drops a port-binding capability would still get α=1 if the per-class scorer only checks the finding-specific field. The functional-blast-radius gate is described but not separately measured — the contribution bullet says as much. So the claim "avoids destructive functional blast radius" is not directly supported; the claim "recovers the cluster-specific value" is. External validity is also thin: one author-built healthcare cluster, 25 TD findings, per-class n of 2–5, no confidence intervals. The paper admits the single-cluster limitation. The McNemar test ignores clustering by finding, but the effect is large enough that this is unlikely to reverse the conclusion.

Should it go to review? Yes. The design is thoughtful, the artifacts are public, and the question matters for LLM-based remediation. A serious referee should ask for a live validation or at least a targeted error analysis of false-positive patches, and for a second cluster or real-world findings. But the controlled comparison itself is a legitimate contribution and deserves referee time.

Referee Report

3 major / 5 minor

Summary. The paper introduces KuTIE, a system that conditions LLM-generated Kubernetes security patches on live runtime topology (Istio call edges, KSPM findings, service-account bindings) and evaluates whether this context improves patch correctness. The evaluation uses a purpose-built 36-deployment cluster (VulnCare) with 31 findings across seven dependency classes, four LLMs, and 248 trials. The central result is that topology-aware prompting raises topology-dependent patch correctness from 11.1% (99 blind trials) to 78.0% (100 aware trials), with a topology-independent control showing no effect (Δ = 0.0). The paper also describes a compliance-weighted attack-path prioritiser and a MITRE ATT&CK annotation step.

Significance. If the measurement is accepted, this is the first controlled evidence that runtime topology context materially changes LLM-generated Kubernetes security patches. The factorial design, per-model replication, and the topology-independent negative control are substantial strengths, and the release of the benchmark and evaluation framework supports reproducibility. However, the headline correctness metric is exact recovery of hand-labelled cluster values under a static scorer, not observed functional blast radius, and the evaluation does not apply patches to a live cluster. The safety-oriented interpretation of the 78% figure therefore rests on an unvalidated proxy.

major comments (3)

[§4.5, §6.1] The α=1 criterion is exact recovery of a hand-labelled cluster value, explicitly described as a 'mechanised proxy for functional blast radius' (§4.5). The paper acknowledges the conservative error (a healthy paraphrased patch is scored 0) but not the opposite error: a patch that contains the correct value can still introduce unrelated breaking changes and still receive α=1, because the scorer inspects only finding-specific fields. Since the abstract and conclusion interpret the 78% as avoiding destructive functional blast radius, this is load-bearing. The evaluation should either apply a subset of generated patches to a live cluster and verify call edges/readiness, or the claims should be reframed as exact-value recovery rather than functional correctness.
[§4.4, §3] The aware prompt contains the exact target values that the scorer rewards: the service-account section names the Secret/ConfigMap, the topology section lists observed callers/callees, and the storage context names the StorageClass. The result therefore measures, at least in part, whether LLMs transcribe values supplied in the prompt, not whether they reason from topology to preserve dependencies. The TI control rules out generic prompt enrichment, but it does not rule out answer leakage. This interpretation should be discussed explicitly; if the goal is to test the value of making cluster state available, the claim should be phrased accordingly.
[Table 4, §6.2] Per-class sample sizes are very small: CAP, POLICY, and STORAGE each have only 2 TD findings, and RBAC has 4. No confidence intervals are reported for the overall or per-class gaps. The 'six of seven classes' claim rests on small counts (e.g., CAP 7/8 vs 1/8). The paper caveats the single-cluster design in §7, but it should also quantify uncertainty around the reported gaps, or soften the per-class generalization.

minor comments (5)

[Abstract vs §1] The abstract presents the functional-blast-radius gate as an active component, while the contribution bullet in §1 correctly states that the gate is 'described but not separately measured'. Align the phrasing to avoid overstating the evaluation.
[§5.3] The path prioritiser results (33 paths, top score 0.74) are presented descriptively without comparison to a baseline or sensitivity analysis. Clarify whether these numbers are illustrative or evaluated.
[§6.1] The scorer's determination that a patch 'clears the KSPM finding' is not specified in detail. Describe the deterministic check for each class to allow replication.
[Figure 2] The figure legend uses 'solid = TD, dashed = TI, grey = none' but the overlay of classes and chains makes the encoding hard to read. Consider separating the class overlay from the chain overlay.
[Throughout] The term 'correctness' should be consistently qualified as 'exact-value recovery correctness' in the abstract and conclusion, to match the actual metric and avoid conflation with functional correctness.

Circularity Check

1 steps flagged · score 4.0 of 10

TD correctness is essentially defined by the same cluster values the aware prompt supplies and the scorer demands; the gap is partially built in, though the empirical details retain independent content.

self definitional [§4.3–§4.5 (definitions and scoring), §3 (aware prompt construction), headline result §6.2]
"A finding is TD when a correct, working patch requires a value discoverable only from cluster state... Eachclassvalue(Table2)iscluster-discoverablestate... a patch earnsα= 1only when the model itself selects and transcribes the correct value. Under blind prompting the model cannot access these values, the structural reason the blind condition fails on TD findings irrespective of model capability. ... assignsα= 1only when it clears the KSPM finding and carries the value ground truth records as dependency-preserving."

The TD label is defined as requiring a value available only from cluster state; the aware prompt explicitly contains that value (call edges, bound ports, Secret/ConfigMap names via service-account bindings); and the scorer grants α=1 only on exact recovery of that same value. The paper itself calls the blind failure 'structural.' Therefore the direction of the 11.1%→78.0% TD gap is a consequence of the benchmark's own definitions and scoring, making the aware-vs-blind contrast largely a test of whether the LLM can transcribe a supplied literal. The per-model/per-class variation, the POLICY reversal, and the TI control Δ=0.0 are genuine empirical results, so the circularity is partial rather than total.

full rationale

The paper is an empirical intervention study, not a formal derivation, and it does not fit a parameter and call it a prediction. The TI negative control (Δ=0.0) and the unexpected POLICY inversion (−0.375) show that not every outcome is forced: if the benchmark were purely circular, the aware condition would always dominate, but it does not. Nevertheless, the central TD metric is aligned with the aware prompt by construction: TD is defined as requiring a value that the prompt then supplies, and the scorer credits only that exact value. The paper openly states the blind failure is 'structural,' which is essentially an admission that the baseline gap is definitional. This reduces the headline claim to a measurement of literal-value transcription ability rather than an independent test of whether runtime topology is causally needed. Because the magnitudes, class ordering, and failure-mode analysis are not entailed by the definitions, I set the circularity score at 4 rather than 6 or higher.

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

The central claim is an empirical measurement on a purpose-built benchmark, so the main ledger items are measurement assumptions: the Istio-edge completeness, the exact-match proxy, and the author-assigned TD/TI labels. The graph-ranking constants are hand-chosen but not fitted to the correctness outcome.

free parameters (3)

Edge-weight severity thresholds = 0.4 / 0.7 / 1.0 / 1.5
Eq. (1); hand-chosen mapping from KSPM severity to graph edge weight. It affects attack-path ranking, not the patch-correctness measurement directly.
Reward blend coefficients = 0.6 / 0.4
Eq. (2); hand-chosen balance between node and neighbourhood severity in path scoring. Not fitted to the correctness data.
Retrieval and ranking constants = kt=7, kp=10, scrape window=5 min
§3 and §5; design choices for ATT&CK retrieval, top-k paths, and Istio scrape window. No sensitivity analysis is provided.

assumptions (4)

domain assumption Istio call graph observed over the scrape window captures every service dependency a correct patch must preserve.
§3 and §7; the authors themselves caveat that rarely exercised paths may be missing, yielding destructive patches.
domain assumption Exact recovery of the hand-labelled cluster value is a valid proxy for functional blast radius.
§4.5; the scorer explicitly uses exact-match as a mechanised proxy and does not re-observe cluster behaviour per trial.
ad hoc to paper The TD/TI labels assigned by the authors against cluster ground truth are correct.
§4.4; the taxonomy is purpose-built for this paper. If the labels are wrong, the isolated effect is an artifact of the construction.
standard math Bellman-Ford relaxation converges with nonnegative effective weights.
§5.1; weff >= 0 implies no negative-weight cycles, so the stated convergence guarantee is standard.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Does Runtime Topology Context Improve LLM-Generated Kubernetes Security Patches?." pith.science (2026). https://pith.science/paper/H3QRYHLO

@misc{pith2026260725995,
  author       = {Pith},
  title        = {Pith review of: Does Runtime Topology Context Improve LLM-Generated Kubernetes Security Patches?},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/H3QRYHLO}},
  note         = {Machine review of arXiv:2607.25995}
}

abstract

Kubernetes is central to the cloud-native ecosystem, orchestrating containerised workloads. Recent work suggests that large language models (LLMs) can automate cluster security remediation, generating configuration patches from Kubernetes Security Posture Management (KSPM) findings without human authoring. Such systems, however, prompt the model with each finding in isolation from the live service call graph, assuming general hardening knowledge suffices. This assumption breaks down whenever a patch must preserve a runtime service dependency invisible to the model: an otherwise compliant fix then carries a destructive functional blast radius, crashing downstream callers or silently severing call edges across the cluster. Whether live cluster context improves patch correctness has not been measured under controlled conditions across multiple dependency classes. We introduce KuTIE (Kubernetes Topology Intelligence Engine), which builds a live cluster context from Istio call edges, Trivy KSPM findings, and the service-account bindings a workload reads, and conditions LLM patch generation on it. It is evaluated on VulnCare, a purpose-built 36-deployment, four-namespace healthcare cluster with 31 injectable findings across seven dependency classes, each labelled by topology dependence against cluster ground truth. Across 248 trials, topology context raises topology-dependent patch correctness from 11.1% to 78.0% ($\Delta = 0.669$), a gap that holds for every model and for six of seven classes, from credential and network-policy ($\Delta = 0.95$) to role-based access control ($\Delta = 0.31$); a topology-independent control exhibits no such effect ($\Delta = 0.0$), isolating the result from generic prompt enrichment. Supplying the live service-call graph and the service-account bindings it exposes thus improves remediation of topology-dependent findings well beyond scanner-only context.

Figures

Figures reproduced from arXiv: 2607.25995 by the authors.

**Figure 1.** KuTIE pipeline: a live ClusterContext feeds path prioritisation, LLM annotation, and functional-blast-radius-gated remediation. for Kubernetes failure diagnosis. Beyond remediation, intent-based configuration applies LLMs to generate manifests from natural-language operator intent: Sacco et al. [21] fine-tune open-source models for this task and evaluate them with text-similarity metrics, leaving deployment-based … view at source ↗

**Figure 2.** VulnCare call graph with the per-workload misconfiguration overlay and the four api-gateway-rooted exploit chains C1–C4 (§4.2); encodings in the legend beneath the graph. The Trivy finding text for all 31 is supplied to the LLM verbatim under both prompt conditions; the per-finding taxonomy, naming the exact cluster value each TD finding requires, is given in Appendix A ( [PITH_FULL_IMAGE:figures/full_fig_p009_2.png] view at source ↗

**Figure 3.** Per-finding patch correctness. Tile colour is the α=1 rate over the four models (cividis, lighter is higher); the printed digit is how many of the four produced a correct patch. Columns are the 31 findings grouped by class; rows are aware vs blind prompting. by name coincidence. RBAC benefits least among positive classes (∆ = 0.31): even with the binding supplied, models emit a Role scoped to the right resource typ… view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

33 extracted references · 1 canonical work pages

[1]

https://github.com/madhuakula/kubernetes-goat (2021), accessed: May 2026

Akula, M.: Kubernetes goat: Interactive kubernetes security learning playground. https://github.com/madhuakula/kubernetes-goat (2021), accessed: May 2026

2021
[2]

https://github.com/ aquasecurity/trivy (2022), accessed: May 2026

Aqua Security: Trivy: Comprehensive vulnerability scanner. https://github.com/ aquasecurity/trivy (2022), accessed: May 2026

2022
[3]

arXiv preprint arXiv:2509.02449 (2025), https://arxiv.org/abs/2509.02449

Ardebili, M.S., Bartolini, A.: KubeIntellect: A modular LLM-orchestrated agent framework for end-to-end Kubernetes management. arXiv preprint arXiv:2509.02449 (2025), https://arxiv.org/abs/2509.02449

arXiv 2025
[4]

https://huggingface

BAAI: BGE small english v1.5 sentence embedding model. https://huggingface. co/BAAI/bge-small-en-v1.5 (2023)

2023
[5]

https:// github.com/bridgecrewio/checkov (2021), accessed: May 2026

Bridgecrew: Checkov: Static code analysis for infrastructure as code. https:// github.com/bridgecrewio/checkov (2021), accessed: May 2026

2021
[6]

Bufalino, J., Martin-Navarro, J.L., Di Francesco, M., Aura, T.: Inside job: De- fending Kubernetes clusters against network misconfigurations. Proc. ACM Netw. (2025). https://doi.org/10.1145/3749220

work page doi:10.1145/3749220 2025
[7]

https://www.cisecurity

Center for Internet Security: CIS kubernetes benchmark. https://www.cisecurity. org/benchmark/kubernetes (2023), accessed: May 2026

2023
[8]

Cesarano, C., Natella, R.: KubeFence: Security hardening of the Kubernetes attack surface. Proc. IEEE/IFIP Int. Conf. Dependable Systems and Networks (DSN) (2025). https://doi.org/10.1109/dsn64029.2025.00054

arXiv 2025

Show all 33 references

[9]

https://github.com/ Checkmarx/kics (2021), accessed: May 2026

Checkmarx: KICS: Keeping infrastructure as code secure. https://github.com/ Checkmarx/kics (2021), accessed: May 2026

2021
[10]

arXiv preprint arXiv:2509.25894 (2025), https://arxiv.org/abs/2509.25894

Chen, S., He, Y., Jana, S., Ray, B.: Red teaming program repair agents: When correct patches can hide vulnerabilities. arXiv preprint arXiv:2509.25894 (2025), https://arxiv.org/abs/2509.25894

2025
[11]

https://github.com/ DataDog/KubeHound (2023), accessed: May 2026

DataDog: KubeHound: Kubernetes attack graph tool. https://github.com/ DataDog/KubeHound (2023), accessed: May 2026

2023
[12]

https: //github.com/GoogleCloudPlatform/microservices-demo (2020), accessed: May 2026

Google LLC: Online boutique: Cloud-native microservices demo application. https: //github.com/GoogleCloudPlatform/microservices-demo (2020), accessed: May 2026

2020
[13]

Haque, M.U., Kholoosi, M.M., Babar, M.A.: KGSecConfig: A knowledge graph based approach for secured container orchestrator configuration. Proc. IEEE Int. Conf. Software Analysis, Evolution, and Reengineering (SANER) (2022). https: //doi.org/10.1109/saner53432.2022.00057

2022
[14]

https://github.com/cilium/tetragon (2022), accessed: May 2026

Isovalent: Tetragon: ebpf-based security observability and runtime enforcement. https://github.com/cilium/tetragon (2022), accessed: May 2026

2022
[15]

arXiv preprint arXiv:2312.13119 (2023), https://arxiv.org/abs/2312.13119

Jin, X., Katsis, C., Sang, F., Sun, J., Bertino, E., Kompella, R.R., Kundu, A.: Graphene: Infrastructure security posture analysis with AI-generated attack graphs. arXiv preprint arXiv:2312.13119 (2023), https://arxiv.org/abs/2312.13119

2023 arXiv
[16]

arXiv preprint arXiv:2405.19954 (2024), https://arxiv.org/abs/2405.19954

Malul, E., Meidan, Y., Mimran, D., Elovici, Y., Shabtai, A.: GenKubeSec: LLM- based Kubernetes misconfiguration detection, localization, reasoning, and remedi- ation. arXiv preprint arXiv:2405.19954 (2024), https://arxiv.org/abs/2405.19954

2024 arXiv
[17]

https://attack.mitre.org/ matrices/enterprise/containers/ (2021), accessed: May 2026

MITRE Corporation: ATT&CK for containers matrix. https://attack.mitre.org/ matrices/enterprise/containers/ (2021), accessed: May 2026

2021
[18]

https://media.defense.gov/ 2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_ GUIDANCE_1.2_20220829.PDF (2022), accessed: May 2026

NSA, CISA: Kubernetes hardening guidance. https://media.defense.gov/ 2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_ GUIDANCE_1.2_20220829.PDF (2022), accessed: May 2026

2022
[19]

https://docs.oasis-open.org/cti/stix/v2.1/ stix-v2.1.html (2021), accessed: May 2026 18 F

OASIS Open: STIX 2.1 specification. https://docs.oasis-open.org/cti/stix/v2.1/ stix-v2.1.html (2021), accessed: May 2026 18 F. Shaikh

2021
[20]

In: Proc

Ou, X., Govindavajhala, S., Appel, A.W.: MulVAL: A logic-based net- work security analyzer. In: Proc. USENIX Security Symposium (2005), https://www.usenix.org/conference/14th-usenix-security-symposium/ mulval-logic-based-network-security-analyzer

2005
[21]

Sacco, A., Zilli, C., Marchetto, G.: Intent-based Kubernetes configuration via LLMs: Current trends and open challenges. Proc. IEEE Conf. Local Computer Networks (LCN) (2025). https://doi.org/10.1109/LCN65610.2025.11146359

2025
[22]

arXiv preprint arXiv:2507.02976 (2025), https://arxiv.org/abs/ 2507.02976

Sajadi, A., Damevski, K., Chatterjee, P.: How safe are AI-generated patches? a large-scale study on security risks in LLM and agentic automated program repair on SWE-bench. arXiv preprint arXiv:2507.02976 (2025), https://arxiv.org/abs/ 2507.02976

2025
[23]

arXiv preprint arXiv:2509.04191 (2025), https://arxiv.org/abs/ 2509.04191

Sgan Cohen, O., Malul, E., Meidan, Y., Mimran, D., Elovici, Y., Shabtai, A.: KubeGuard: LLM-assisted Kubernetes hardening via configuration files and run- time logs analysis. arXiv preprint arXiv:2509.04191 (2025), https://arxiv.org/abs/ 2509.04191

2025 arXiv
[24]

In: Proc

Sheyner, O., Haines, J., Jha, S., Lippmann, R., Wing, J.M.: Automated generation and analysis of attack graphs. In: Proc. IEEE Symposium on Security and Privacy. pp. 273–284 (2002). https://doi.org/10.1109/SECPRI.2002.1004377

2002 arXiv
[25]

Sun, W., Wang, T., Tian, X., Lan, W., Feng, X., Li, H., Wang, F.: MetaKube: An experience-aware LLM framework for Kubernetes failure diagnosis. Proc. ACM Web Conf. (WWW) (2026), https://arxiv.org/abs/2603.23580

2026
[26]

https://falco.org (2022), accessed: May 2026

The Falco Project: Falco: Cloud-native runtime security. https://falco.org (2022), accessed: May 2026

2022
[27]

https://istio.io (2023), ac- cessed: May 2026

The Istio Authors: Istio: An open source service mesh. https://istio.io (2023), ac- cessed: May 2026

2023
[28]

arXiv preprint arXiv:2307.14114 (2023), https://arxiv.org/abs/2307.14114

Unger, S., Arzoglou, E., Heinrich, M., Scheuermann, D., Katzenbeisser, S.: Risk assessment graphs: Utilizing attack graphs for risk assessment. arXiv preprint arXiv:2307.14114 (2023), https://arxiv.org/abs/2307.14114

2023 arXiv
[29]

https://github.com/ microservices-demo/microservices-demo (2017), accessed: May 2026

Weaveworks: Sock shop: A microservices demo application. https://github.com/ microservices-demo/microservices-demo (2017), accessed: May 2026

2017
[30]

arXiv preprint arXiv:2603.01257 (2026), https: //arxiv.org/abs/2603.01257

Xu, Q., Sheng, Z., Chen, Z., Huang, J.: A systematic study of LLM-based archi- tectures for automated patching. arXiv preprint arXiv:2603.01257 (2026), https: //arxiv.org/abs/2603.01257

2026
[31]

arXiv preprint arXiv:2502.02009 (2025), https://arxiv.org/abs/2502.02009

Ye, Z., Le, T.H.M., Babar, M.A.: LLMSecConfig: An LLM-based approach for fix- ing software container misconfigurations. arXiv preprint arXiv:2502.02009 (2025), https://arxiv.org/abs/2502.02009

2025 arXiv
[32]

arXiv preprint arXiv:2511.01166 (2025), https://arxiv.org/abs/2511.01166

Zhang, L., Zhai, Y., Jia, T., Duan, C., He, M., Pan, L., Liu, Z., Ding, B., Li, Y.: MicroRemed: Benchmarking LLMs in microservices remediation. arXiv preprint arXiv:2511.01166 (2025), https://arxiv.org/abs/2511.01166

2025
[33]

Zhang, Y., Du, T., Ma, Y., Wang, X., Xie, Y., Yang, G., Lu, Y., Chang, E.C.: AttacKG+: Boosting attack knowledge graph construction with large language models. arXiv preprint arXiv:2405.04753 (2024), https://arxiv.org/abs/2405.04753 Topology Context for LLM-Generated Kubernete...

2024 arXiv

Pith tools

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

[1] [1]

https://github.com/madhuakula/kubernetes-goat (2021), accessed: May 2026

Akula, M.: Kubernetes goat: Interactive kubernetes security learning playground. https://github.com/madhuakula/kubernetes-goat (2021), accessed: May 2026

2021

[2] [2]

https://github.com/ aquasecurity/trivy (2022), accessed: May 2026

Aqua Security: Trivy: Comprehensive vulnerability scanner. https://github.com/ aquasecurity/trivy (2022), accessed: May 2026

2022

[3] [3]

arXiv preprint arXiv:2509.02449 (2025), https://arxiv.org/abs/2509.02449

Ardebili, M.S., Bartolini, A.: KubeIntellect: A modular LLM-orchestrated agent framework for end-to-end Kubernetes management. arXiv preprint arXiv:2509.02449 (2025), https://arxiv.org/abs/2509.02449

arXiv 2025

[4] [4]

https://huggingface

BAAI: BGE small english v1.5 sentence embedding model. https://huggingface. co/BAAI/bge-small-en-v1.5 (2023)

2023

[5] [5]

https:// github.com/bridgecrewio/checkov (2021), accessed: May 2026

Bridgecrew: Checkov: Static code analysis for infrastructure as code. https:// github.com/bridgecrewio/checkov (2021), accessed: May 2026

2021

[6] [6]

Bufalino, J., Martin-Navarro, J.L., Di Francesco, M., Aura, T.: Inside job: De- fending Kubernetes clusters against network misconfigurations. Proc. ACM Netw. (2025). https://doi.org/10.1145/3749220

work page doi:10.1145/3749220 2025

[7] [7]

https://www.cisecurity

Center for Internet Security: CIS kubernetes benchmark. https://www.cisecurity. org/benchmark/kubernetes (2023), accessed: May 2026

2023

[8] [8]

Cesarano, C., Natella, R.: KubeFence: Security hardening of the Kubernetes attack surface. Proc. IEEE/IFIP Int. Conf. Dependable Systems and Networks (DSN) (2025). https://doi.org/10.1109/dsn64029.2025.00054

arXiv 2025