KubeCap, a framework for Kubernetes capability minimization, is proposed and Evaluation on 10 representative Go-based Kubernetes projects shows an average capability reduction rate of 54.97%, outperforming rapid type analysis and class hierarchy analysis baselines while maintaining practical analysis cost.
Abstract
As the most widely used container orchestration platform, Kubernetes provides flexible privilege configuration by allowing developers to manage Linux capabilities via manifest files. However, developers rely on default settings or coarse-grained security contexts in practice, violating the principle of least privilege and enlarging the attack surface of containerized workloads. Existing studies either detect vulnerable patterns in Kubernetes manifests or infer required capabilities for standalone Linux programs, but they do not directly address capability minimization in Kubernetes. To bridge this gap, we first conduct an empirical study on three open-source datasets, revealing that 74.67% of projects lack capability configurations. Motivated by our observations, we propose KubeCap, a framework for Kubernetes capability minimization. KubeCap translates deployment specifications into deterministic manifests, locates container entrypoints, performs reachability-guided system call analysis, and leverages LLM-assisted rule specification to derive syscall--parameter--capability relations from Linux kernel code. Based on these results, KubeCap infers the minimal capability set required by each workload and automatically generates repaired manifests. Evaluation on 10 representative Go-based Kubernetes projects shows an average capability reduction rate of 54.97%, outperforming rapid type analysis and class hierarchy analysis baselines while maintaining practical analysis cost. These results demonstrate KubeCap's effectiveness in enforcing least privilege in Kubernetes.
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, and improves remediation of topology-dependent findings well beyond scanner-only context.
The paper formalizes the underlying scenario-based evaluation model, details the design and implementation of the operator, and demonstrates its capabilities through a controlled benchmark experiment on the Online Boutique application, covering hundreds of automatically orchestrated evaluation scenarios across multiple workloads, failure levels, and retry configurations.
C. Aderaldo, N. C. Mendonça· Journal of Software Engineer...· 0 citations
The growing complexity of runtime management in containerized clusters makes manual fault debugging time-consuming and costly. Self-healing aims to automate fault detection and recovery. A recent approach is to use large language models (LLMs), but most existing systems rely on large proprietary models with high computational or service costs. This paper investigates the feasibility of using low-parameter, on-premise LLMs for self-healing of containerized applications in Kubernetes clusters. Our proposed prototype leverages prompt chaining by splitting failure management tasks into root cause analysis and auto-remediation prompts, where each prompt is augmented with in-context examples. We allow the LLM to iteratively refine its output based on cluster feedback until remediation execution and recovery are successful. Evaluated on a microservice benchmark system with 15 real-time faults, our prototype achieves 96.67% overall accuracy. Results show that prompt chaining and iterative refinement significantly improve recovery effectiveness, while in-context learning yields limited benefit.
Yann Wiesinger, M. Engelhardt, Roman Laas· SEAMS@ICSE· 0 citations
Vendors assessing Linux kernel CVEs need to know whether a bug is triggerable under production-tailored configurations, not merely whether a version is affected, yet upstream reproducers and vulnerability databases rarely provide configuration-level context. We study minimal trigger-configuration inference: given a CVE entry and a target kernel version (optionally a baseline .config), we synthesize a Kconfig-satisfiable option set that remains effective after make olddefconfig and, when a reproducer is available, still triggers under a specified evaluation protocol; we then prune it to a 1-minimal (subset-minimal) boundary for evaluation. Our framework FCC links vulnerability cues to build-system symbols, completes implicit prerequisites under olddefconfig feedback to avoid silent rollback, and performs runtime-validated minimization guided by dependency topology. We evaluate on KernJC and KernelCTF, totaling 88 CVEs across multiple kernel versions. On the 88-CVE set, FCC improves the post-make olddefconfig configuration success rate from 62.5% (55/88) to 96.6% (85/88) over an olddef-only injection baseline; on the KernJC set, FCC reduces the average candidate set size by 78.7% compared to KernJC (Avg. 14.72 vs. 69.00 options per CVE). A stage-wise analysis of time and token costs shows that Stage I dominates overhead, while CVE-focused evidence selection substantially reduces this cost. By returning an effective and auditable 1-minimal configuration boundary, FCC helps vendors scope triggerability against their deployment configurations with a clear, tool-supported decision line.
Tongjie Wei, Peng Zhang, Zhiwen Hu et al.· 0 citations
Java middleware may expose Java Management Extensions (JMX) through Jolokia’s Hypertext Transfer Protocol (HTTP) bridge. In affected ActiveMQ deployments, reachable Log4j 2 configuration managed beans (MBeans) become write capabilities and, with compatible triggers, enable remote code execution (RCE). We ask: in a specified product/version state, which writes and triggers compose into RCE, and which operational guard first fails or remains unresolved? We synthesize two published case studies into an evidence-coded method. Four write and four trigger classes recover four observed chains, isolate one model-implied pairing, and reject dependency-level candidates through failed or unresolved guards. It distinguishes ActiveMQ paths from documentation-limited Apache James, WildFly, Apache Karaf, and Red Hat AMQ cases. Egress filtering and static-file ownership do not stop every observed chain. Observed (O), derived (D), and model-implied (H) labels separate findings from hypotheses. The contribution is a falsifiable, product- and version-scoped management-plane instrument, not a new attack-stage sequence.
A. Caciulescu, Matei Badanoiu, R. Rughinis et al.· Computers· 0 citations
The Center for Internet Security (CIS) Benchmark for Oracle Database 19c defines 92 security controls whose remediation currently requires extensive manual effort from database administrators. Existing vendor tools—Oracle DBSAT, Data Safe, Enterprise Manager—identify deviations but produce only natural-language recommendations excerpted from the benchmark document. Recent work on large-language-model (LLM)-based security remediation for Kubernetes and embedded firmware has demonstrated that generative models can autoproduce configuration fixes, but no published framework addresses the specific challenges of relational database remediation: per-PDB state semantics, multi-instance Real Application Clusters topology, application dependency awareness, and the operational requirement of a provably invertible rollback. We present ORACLE-REMEDIATE, a context-aware, safety-verified LLM remediation framework for CIS compliance on Oracle Multitenant (CDB/PDB) deployments including RAC and Exadata. The framework grounds LLM generation in live database topology and dependency graphs obtained via retrieval-augmented generation, verifies each candidate remediation through a threelayer pipeline comprising static analysis, semantic invariant checking, and constrained behavioral equivalence, and automatically generates a matched rollback proven invertible through round-trip testing. We propose a comprehensive evaluation of the full CIS Oracle 19c v2.0.0 control set (92 controls) across three deployment topologies—single-instance, two-node RAC, and simulated Exadata—and three LLM backends. The study evaluates Pass@k correctness, safety-violation rates, rollback fidelity, and per-context-class ablation effects. This paper presents the motivation, system design, implementation approach, and evaluation methodology, and releases the benchmark and artifacts as open source.
Devendra Rajput, V. S. R. Dantuluri, Sanjay Bajaj et al.· International Conference on...· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.
