Pith. sign in

REVIEW 3 major objections 5 minor 33 references

Supplying live runtime topology to LLMs lifts Kubernetes patch correctness from 11% to 78%.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

Providing LLMs with live cluster topology and service-account context raised correct Kubernetes security patches from 11.1% to 78.0% on topology-dependent findings, with no change on a topology-independent control.

T0 review reviewed 2026-08-01 challenge →

load-bearing objection 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. the 3 major comments →

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

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

Farooq Shaikh This is my paper
classification cs.CR cs.AI
keywords KubernetesLLMsecurity patchesruntime topologyservice call graphfunctional blast radiusKSPMautomated remediation
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

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.

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,

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

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.

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 this falsifier. Get emailed when new claim-graph text bears on it.

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.

Where Pith is reading between the lines

These are 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, simulated authors' rebuttal, and a circularity audit.

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)
  1. [§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.
  2. [§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.
  3. [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)
  1. [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.
  2. [§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.
  3. [§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.
  4. [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.
  5. [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

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.

specific steps
  1. 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.

Axiom & Free-Parameter Ledger

3 free parameters · 4 axioms · 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.
axioms (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.

reviewed 2026-08-01 · 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}
}
Share X Bluesky LinkedIn Reddit HN
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 Farooq Shaikh.

Figure 1
Figure 1. Figure 1: KuTIE pipeline: a live ClusterContext feeds path prioritisation, LLM anno￾tation, and functional-blast-radius-gated remediation. for Kubernetes failure diagnosis. Beyond remediation, intent-based configura￾tion 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 deploym… view at source ↗
Figure 2
Figure 2. 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… view at source ↗
Figure 3
Figure 3. 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 re￾… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

33 extracted references · 1 canonical work pages

  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

    Pith/arXiv 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

  9. [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. [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

    arXiv 2025

  11. [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. [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. [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

    arXiv 2022

  14. [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. [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

    Pith/arXiv arXiv 2023

  16. [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

    Pith/arXiv arXiv 2024

  17. [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. [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. [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. [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. [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

    arXiv 2025

  22. [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

    arXiv 2025

  23. [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

    Pith/arXiv arXiv 2025

  24. [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

    Pith/arXiv arXiv 2002

  25. [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

    arXiv 2026

  26. [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. [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. [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

    Pith/arXiv arXiv 2023

  29. [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. [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

    arXiv 2026

  31. [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

    Pith/arXiv arXiv 2025

  32. [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

    arXiv 2025

  33. [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 Kubernetes Security Patches 19 A Full Misconfiguration Taxonomy Identifiers are non-conti...

    Pith/arXiv arXiv 2024

This paper was first reviewed by deepseek-v4-flash on August 1, 2026.