Pith. sign in

REVIEW 3 major objections 5 minor 2 cited by

LLMSecConfig: An LLM-Based Approach for Fixing Software Container Misconfigurations

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

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

Pith's one-line read The paper claims that pairing a static analysis tool with a large language model and retrieved security context can automatically repair Kubernetes misconfigurations, with a 94.3% pass rate on 1,000 real-world configurations.

desk verdict Makes Checkov pass on 94.3% of 1,000 real-world K8s configs, but the claim that operational functionality is preserved is untested; deserves peer review with a required revision. read the letter →

arxiv 2502.02009 v1 pith:7222FZUD submitted 2025-02-04 cs.SE cs.AIcs.CRcs.LG

Ziyang Ye , Triet Huynh Minh Le , M. Ali Babar This is my paper · ORCID
classification cs.SEcs.AIcs.CRcs.LG
keywords ContainersecuritymisconfigurationrepairKuberneteslargelanguagemodelsretrieval-augmentedgenerationstaticanalysisCheckovHelmcharts
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

The paper tries to close the gap between detecting container security misconfigurations and fixing them: static analysis tools can find problems, but repair is largely manual. It proposes LLMSecConfig, a pipeline that feeds the scanner's error output, the policy's source code, and security documentation into a large language model, then validates the rewritten YAML by parsing and rescanning it. On 1,000 real-world Kubernetes configurations, the framework with Mistral Large 2 repaired 94.3% of files so they passed every Checkov security check, averaging 3.06 repair steps and introducing only 0.024 new Checkov issues per file. If that holds in practice, teams could automate a large share of routine Kubernetes security remediation instead of doing it by hand.

What carries the argument

The central object is the three-part context assembly that feeds a prompt template: the Checkov scan output carrying policy IDs and failure details, the corresponding Checkov policy implementation source code, and Prisma Cloud documentation with fix recommendations and examples. For each detected issue, the framework retrieves these three pieces, injects them into the LLM prompt, and runs an iterative parser-and-rescan validation loop that retries on invalid YAML or unresolved issues. The per-policy source code is the highest-value single context component, raising the pass rate from 88.0% with scan output alone to 90.3% and cutting average repair steps, while documentation alone actually lowers the pass rate to 65.2%.

What would settle it

Run the original and repaired versions of a sample of the 1,000 configurations through a Kubernetes dry-run apply and compare the resulting resource sets; if a meaningful fraction of Checkov-passing repairs drop or alter needed fields, the reported success rate overstates real-world repairability.

Watch

Extended reading notes

Core claim

LLMSecConfig is an automated repair pipeline that combines static analysis with LLM-based generation and retrieval-augmented context. The central discovery is that feeding the LLM the Checkov failure message, the Python source of the failing policy, and the matching Prisma Cloud documentation lets Mistral Large 2 rewrite Kubernetes YAML so that 94.3% of 1,000 real-world misconfigured files pass all security checks, with a 100% parse success rate, an average of 3.06 repair steps, and 0.024 new Checkov issues introduced per file. Under the same pipeline, GPT-4o-mini reaches only a 40.2% pass rate, showing that model capability, not just the prompt structure, determines repair success. The result positions LLM-guided repair, not merely detection, as a viable layer in container security management.

Load-bearing premise

The framework counts a configuration as correctly repaired when it parses as valid YAML and passes every Checkov security check, without independently verifying that the repaired Kubernetes configuration still deploys and behaves like the original.

Editorial extensions

If this is right

  • Organizations using similar pipelines could automate most routine Kubernetes security remediation, reserving human review for complex network and privilege policies.
  • Model choice is a primary performance lever: the same pipeline with Mistral Large 2 achieves a 94.3% pass rate versus 40.2% with GPT-4o-mini.
  • Maintaining precise mappings between check IDs and policy source code should be a priority, because source-code context improves both success rate and repair speed.
  • The iterative repair-and-rescan loop, with a 100% parse success rate, shows that validator feedback can make LLM-generated YAML reliable enough for security-critical use.
  • The low introduced-error rate of 0.024 per file suggests the approach rarely creates new Checkov-visible misconfigurations while fixing existing ones.

Reading between the lines

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

  • An editorial extension: because the paper's success criterion is Checkov compliance plus parseability, a repaired file could in principle pass all checks while changing deployment semantics, so cluster-level application tests would strengthen the claim that operational functionality is preserved.
  • The same SAT-plus-LLM-plus-RAG pattern likely transfers to other container orchestrators and other static analysis tools, since the context assembly only depends on stable check IDs and accessible policy source.
  • A testable extension would sweep temperature and retry limits: the paper fixes temperature at 0.5 and maximum retry at 5, so it does not report how sensitive the 94.3% result is to those settings.
  • The introduced-error metric counts only issues Checkov can see, so security regressions outside Checkov's policy coverage would be invisible to the evaluation.
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.

Referee Report

3 major / 5 minor

Summary. The paper presents LLMSecConfig, an automated framework that combines a static analysis tool (Checkov) with large language models (Mistral Large 2 and GPT-4o-mini) and retrieval-augmented generation to repair security misconfigurations in Kubernetes YAML configurations. The framework detects issues with Checkov, retrieves the corresponding Checkov policy source code and Prisma Cloud documentation as context, generates candidate repairs via an LLM, and iterates with retry mechanisms until the configuration parses as valid YAML and passes all Checkov security checks. The evaluation uses 1,000 Kubernetes sub-configurations extracted from popular Helm charts on ArtifactHub, measuring Parse Success Rate, Pass Rate, Average Pass Steps, AUC metrics, Security Improvement, and Average Introduced Errors. The authors report that Mistral Large 2 achieves a 94.3% Pass Rate and 100% Parse Success Rate, with an average of 3.06 repair steps and 0.024 newly introduced issues, substantially outperforming GPT-4o-mini (40.2% Pass Rate). An ablation study (RQ3) shows that adding policy source code improves pass rate over Checkov output alone, while adding Prisma documentation alone degrades it.

Significance. If the claims are fully supported, the work addresses a real gap: static analysis tools detect container misconfigurations but rarely repair them automatically. The framework is a plausible instantiation of an LLM-plus-SAT repair loop, and the paper makes a useful reproducibility contribution by promising an open dataset and implementation. The clear definition of the metrics (PR, PSR, APS, AUC) and the ablation study are strengths. However, the headline claim 'while preserving operational functionality' is not validated by the evaluation, and the quantitative results come from a single stochastic run without variance reporting. The central contribution therefore needs additional validation and more careful framing before the reported 94.3% figure can be taken as evidence of real-world repairability.

major comments (3)
  1. [I, III-D, IV-B] The abstract and contributions claim the framework repairs misconfigurations 'while preserving operational functionality,' yet the validation described in Section III-D consists only of (i) successful YAML parsing and (ii) passing all Checkov security checks. Section IV-B states that each sub-configuration is isolated from the surrounding Helm-rendered resources, so the model can delete or empty the resource under repair (for example, removing the entire container spec) and still produce YAML that passes Checkov. No Kubernetes API validation (e.g., kubectl dry-run or kubeval), no runtime deployment test, and no field-level semantic comparison (image, command, args, ports, env, volumes, selectors) is performed. Consequently, the 94.3% Pass Rate measures 'makes Checkov pass after rewriting,' not 'fixes the misconfiguration while preserving deployment semantics.' I recommend either adding a concrete validation that repaired configurations remain valid, deployable Kubernetes resources with preserved operational intent, or explicitly re-scoping the claim to 'passes Checkov after repair,' which is a weaker but defensible contribution.
  2. [V-A, IV-C] The quantitative headline results (94.3% PR, 100% PSR, 3.06 APS) are point estimates from a single run per configuration, even though the LLMs are sampled with temperature 0.5 (Section IV-C), making outputs stochastic. The paper does not report variance, confidence intervals, or multiple independently sampled runs. For a claim that is central to the paper's value, the absence of any repeated-run analysis leaves the measured differences (e.g., Mistral vs. GPT-4o-mini) without a statistical grounding. I request either multiple runs with variance reporting, or a lowering of temperature to deterministic settings, or a clear statement that results are single-run observations and should be treated as such.
  3. [III-C, III-D] The repair loop is explicitly fed Checkov's error messages and the Python source code of the relevant Checkov policy, and it retries until Checkov passes. This makes the evaluation oracle and the repair target the same tool, so the Pass Rate is a measure of how well the LLM satisfies Checkov's policy implementation, not an independent security property. This is a valid design choice for an SAT-guided repair system, but the paper should acknowledge it as a limitation and avoid over-generalizing to 'security misconfigurations are fixed.' A concrete improvement would be to validate a sample of repaired configurations with a different tool (e.g., Trivy or kube-sec) and to manually inspect whether the repaired configurations preserve intended behavior.
minor comments (5)
  1. [VI-B] Section VI-B states 'We also conducted extensive sensitivity analysis to understand the impact of key parameters on repair performance,' but no sensitivity results are reported anywhere in the paper, and the only tuning statement is that temperature 0.5 was chosen 'after experiments.' Either report the sensitivity analysis (e.g., temperature and max_retry sweeps) or remove the claim.
  2. [Abstract, V-A] The abstract says '94% success rate' while Section V-A and Table I report 94.3%; please use consistent precision throughout.
  3. [IV-B] The dataset link is provided as a Figshare URL, but the paper should state the exact version or persistent DOI and describe the dataset's schema (e.g., the mapping CSV for Checkov IDs to source files) to improve reproducibility.
  4. [IV-D, Eq. (6)] Equation (6) for Security Improvement is undefined if einit(d_i) = 0. Since the dataset only retains files with detected issues, this may not arise in practice, but the formula should be defined with a caveat or a convention for that case.
  5. [V-C, RQ3] In the RQ3 methodology paragraph, the description of how Prisma Cloud documentation is retrieved ('Prisma documents from URL') is underspecified; please clarify whether the content is fetched live, cached, or parsed from a local snapshot at evaluation time.

Circularity Check

1 steps flagged · score 6.0 of 10

The 94.3% repair success rate is measured by the same Checkov pass condition that drives the repair loop, so the headline result reduces to 'made Checkov pass'; the separate claim of preserving operational functionality is asserted but never validated.

  1. self definitional [Section III-D (validation loop), Section IV-D Eq. (2), Section V-A Table I]
    "Pass Rate = 1/N Σ Ipass(di) × 100% (2) ... Ipass(di) ... equal 1 if ... configuration di passes all security checks ... If the syntax is valid, the system proceeds to security validation, confirming that the repairs address the identified vulnerabilities without introducing new issues. ... to conform to specific SAT's security best practices, this iterative process continues until all issues are resolved, the maximum number of repair attempts is reached, or an unrecoverable error is encountered."

    The headline 'repair success rate' (Table I: 94.3% PR) is defined by Eq. (2) as the fraction of configurations that pass all Checkov security checks. The repair loop in Section III-D uses exactly the same Checkov scans both as the feedback signal to the LLM and as the termination condition ('continues until all issues are resolved'). Therefore the reported Pass Rate is, by construction, the proportion of configurations that reached the loop's own success criterion after up to five repair attempts. It does not measure whether the output is a valid Kubernetes resource or preserves operational functionality; those are separate claims that are not checked by the validation pipeline.

full rationale

The only serious circularity-relevant step is the identity between the repair target and the evaluation oracle: the framework feeds Checkov's error messages and policy source code into the prompt, retries until Checkov passes, and then reports the Checkov pass rate as the repair success rate. This makes the 94.3% figure a fit-to-validator measure rather than an independent assessment of misconfiguration repair. The paper also claims in the abstract and in Section III-D that repairs preserve 'operational functionality,' but the validation stage only checks YAML syntax and Checkov compliance; no Kubernetes API validation, cluster admission test, or semantic comparison of image, command, ports, volumes, or selectors is performed. That is a missing-support and construct-validity problem, and it is weighed here, though it is not itself a circular derivation. The paper's many self-citations (e.g., [18], [51], [56]) appear in related work and background and are not load-bearing for the framework's mechanism; no uniqueness theorem or ansatz is imported from prior work by the same authors. Accordingly, the central claim has some independent empirical content at the narrow level of 'prompting an LLM to make Checkov pass,' but the broader claim of repairing real-world misconfigurations while preserving operational functionality is not established by the reported metrics. This warrants a partial-circularity score of 6 rather than a higher score, because the numbers are not fabricated and the narrow Checkov-satisfaction task is a real, reproducible outcome.

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

No new physical or theoretical entities are postulated. The free parameters are LLM repair-loop settings chosen by hand rather than fitted constants. The main unstated costs are the domain assumptions that Checkov defines both the goal and the measure of success, and that YAML parsing plus Checkov pass implies operational correctness.

free parameters (3)
  • temperature = 0.5
    Set to balance output diversity and stability; chosen after experiments and cited to prior work in Section V-A, but no sensitivity analysis is reported.
  • max_retry_num = 5
    Outer loop limit for number of repair attempts per configuration; selected through experimentation (Section V-A) as a practical balance between success and cost.
  • max_parser_retry_time = 10
    Inner loop limit for retrying when LLM output fails YAML parsing; selected through experimentation (Section V-A), with no reported sensitivity results.
assumptions (4)
  • domain assumption Checkov's built-in policies are an accurate and complete representation of Kubernetes security misconfigurations.
    Checkov is used both to select the vulnerable dataset (Section IV-B) and to validate every repair (Section III-D), so all success metrics are measured against Checkov only.
  • domain assumption Retaining only files that trigger Checkov issues yields a representative sample of real-world Kubernetes misconfigurations.
    Section IV-B drops all files without detected issues, conditioning the dataset on Checkov's detection ability and potentially overrepresenting easy or common rule violations.
  • ad hoc to paper A repair is operationally correct if it parses as YAML and passes Checkov.
    The pipeline validates syntax and security only (Section III-D), yet the abstract and contributions claim operational functionality is preserved; no deployment, dry-run, or runtime testing is described.
  • domain assumption Converting Helm charts to raw Kubernetes YAML preserves the semantics of the original configuration.
    Section IV-B describes the conversion but provides no verification that template values, dependencies, or defaults remain semantically equivalent.

how reviews work

0 comments
Cite this review

Pith. "Pith review of LLMSecConfig: An LLM-Based Approach for Fixing Software Container Misconfigurations." pith.science (2026). https://pith.science/paper/7222FZUD

@misc{pith2026250202009,
  author       = {Pith},
  title        = {Pith review of: LLMSecConfig: An LLM-Based Approach for Fixing Software Container Misconfigurations},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7222FZUD}},
  note         = {Machine review of arXiv:2502.02009}
}
read the original abstract

Security misconfigurations in Container Orchestrators (COs) can pose serious threats to software systems. While Static Analysis Tools (SATs) can effectively detect these security vulnerabilities, the industry currently lacks automated solutions capable of fixing these misconfigurations. The emergence of Large Language Models (LLMs), with their proven capabilities in code understanding and generation, presents an opportunity to address this limitation. This study introduces LLMSecConfig, an innovative framework that bridges this gap by combining SATs with LLMs. Our approach leverages advanced prompting techniques and Retrieval-Augmented Generation (RAG) to automatically repair security misconfigurations while preserving operational functionality. Evaluation of 1,000 real-world Kubernetes configurations achieved a 94\% success rate while maintaining a low rate of introducing new misconfigurations. Our work makes a promising step towards automated container security management, reducing the manual effort required for configuration maintenance.

Figures

Figures reproduced from arXiv: 2502.02009 by the authors.

Figure 1
Figure 1. Comparison of misconfigured (left) versus properly configured (right) Kubernetes security contexts. The misconfigured [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. This information provides a precise understanding of [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 2
Figure 2. Architecture overview of the LLMSecConfig framework for automated Kubernetes security configuration repair. The [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figures from the paper (6 more)
Figure 3
Figure 3. Figure 3: Example output from the Checkov security scanner, [PITH_FULL_IMAGE:figures/full_fig_p004_3.png]
Figure 5
Figure 5. Figure 5: Prisma Cloud security policy documentation for [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]
Figure 6
Figure 6. Figure 6: Distribution of security misconfiguration types in our dataset collected from ArtifactHub. The chart illustrates the relative [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: Step-wise performance metrics comparing GPT-4o [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Performance comparison of different Large Language Models (LLMs) (GPT-4o-mini and Mistral Large 2) in fixing [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: Ablation study results comparing different context [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

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

    cs.CR 2026-07 conditional novelty 6.0 of 10

    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.

  2. KubeGuard: LLM-Assisted Kubernetes Hardening via Configuration Files and Runtime Logs Analysis

    cs.CR 2025-09 conditional novelty 6.0 of 10

    KubeGuard generates and refines Kubernetes Roles, NetworkPolicies, and Deployments from aggregated audit, network, and provenance logs using prompt-chained LLMs, achieving F1 up to 0.96 with GPT-4o.

Reference graph

Works this paper leans on

60 extracted references · 40 canonical work pages · cited by 2 Pith papers

  1. [1]

    Container orchestration: A survey,

    E. Casalicchio, “Container orchestration: A survey,” Systems Modeling: Methodologies and Tools, pp. 221–235, 2019

    work page 2019

  2. [2]

    Xi commandments of kubernetes security: A systematization of knowledge related to ku- bernetes security practices,

    M. S. I. Shamim, F. A. Bhuiyan, and A. Rahman, “Xi commandments of kubernetes security: A systematization of knowledge related to ku- bernetes security practices,” 2020 IEEE Secure Development (SecDev) , pp. 58–64, 2020

    work page 2020

  3. [3]

    A survey of static analysis methods for identifying security vulnerabilities in software systems,

    M. Pistoia, S. Chandra, S. J. Fink, and E. Yahav, “A survey of static analysis methods for identifying security vulnerabilities in software systems,” IBM systems journal , vol. 46, no. 2, pp. 265–288, 2007

    work page 2007

  4. [4]

    Helm charts for kubernetes applications: Evolution, outdatedness and security risks,

    A. Zerouali, R. Opdebeeck, and C. De Roover, “Helm charts for kubernetes applications: Evolution, outdatedness and security risks,” in 2023 IEEE/ACM 20th International Conference on Mining Software Repositories (MSR), 2023, pp. 523–533

    work page 2023

  5. [5]

    ‘under-reported’ security defects in kubernetes manifests,

    D. B. Bose, A. Rahman, and S. I. Shamim, “‘under-reported’ security defects in kubernetes manifests,” in 2021 IEEE/ACM 2nd International Workshop on Engineering and Cybersecurity of Critical Systems (En- CyCriS), 2021, pp. 9–12

    work page 2021

  6. [6]

    Centralized defense: Logging and mitigation of kubernetes misconfigurations with open source tools,

    E. Russell and K. Dev, “Centralized defense: Logging and mitigation of kubernetes misconfigurations with open source tools,” 2024. [Online]. Available: https://arxiv.org/abs/2408.03714

    arXiv 2024

  7. [7]

    Systematic literature review on application of learning-based approaches in contin- uous integration,

    A. K. Arani, T. H. M. Le, M. Zahedi, and M. A. Babar, “Systematic literature review on application of learning-based approaches in contin- uous integration,” IEEE Access, 2024

    2024

  8. [8]

    Deep learning for source code modeling and generation: Models, applications, and challenges,

    T. H. M. Le, H. Chen, and M. A. Babar, “Deep learning for source code modeling and generation: Models, applications, and challenges,” ACM Computing Surveys (CSUR) , vol. 53, no. 3, pp. 1–38, 2020

    work page 2020

Show all 60 references
  1. [9]

    Large language models for software engi- neering: A systematic literature review,

    X. Hou, Y . Zhao, Y . Liu, Z. Yang, K. Wang, L. Li, X. Luo, D. Lo, J. Grundy, and H. Wang, “Large language models for software engi- neering: A systematic literature review,” ACM Transactions on Software Engineering and Methodology , vol. 33, no. 8, pp. 1–79, 2024

    2024

  2. [10]

    Purple llama cyberseceval: A secure coding benchmark for language models,

    M. Bhatt, S. Chennabasappa, C. Nikolaidis, S. Wan, I. Evtimov, D. Gabi, D. Song, F. Ahmad, C. Aschermann, L. Fontana, S. Frolov, R. P. Giri, D. Kapil, Y . Kozyrakis, D. LeBlanc, J. Milazzo, A. Straumann, G. Synnaeve, V . V ontimitta, S. Whitman, and J. Saxe, “Purple llama cybe...

    2023 arXiv

  3. [11]

    Cyberseceval 2: A wide-ranging cybersecurity evaluation suite for large language models,

    M. Bhatt, S. Chennabasappa, Y . Li, C. Nikolaidis, D. Song, S. Wan, F. Ahmad, C. Aschermann, Y . Chen, D. Kapil, D. Molnar, S. Whitman, and J. Saxe, “Cyberseceval 2: A wide-ranging cybersecurity evaluation suite for large language models,” 2024. [Online]. Available: https://ar...

    2024 arXiv

  4. [12]

    Cyberseceval 3: Advancing the evaluation of cybersecurity risks and capabilities in large language models,

    S. Wan, C. Nikolaidis, D. Song, D. Molnar, J. Crnkovich, J. Grace, M. Bhatt, S. Chennabasappa, S. Whitman, S. Ding, V . Ionescu, Y . Li, and J. Saxe, “Cyberseceval 3: Advancing the evaluation of cybersecurity risks and capabilities in large language models,” 2024. [Online]. Av...

    2024 arXiv

  5. [13]

    The state-of-the-art in container technologies: Application, orchestration and security,

    E. Casalicchio and S. Iannucci, “The state-of-the-art in container technologies: Application, orchestration and security,” Concurr. Comput. Pract. Exp. , vol. 32, 2020. [Online]. Available: https://api.semanticscholar.org/CorpusID:211264375

    2020

  6. [14]

    Security challenges in the container cloud,

    Y . Yang, W. Shen, B. Ruan, W. Liu, and K. Ren, “Security challenges in the container cloud,” in 2021 Third IEEE International Conference on Trust, Privacy and Security in Intelligent Systems and Applications (TPS-ISA). IEEE, 2021, pp. 137–145

    2021

  7. [15]

    Container security: Issues, challenges, and the road ahead,

    S. Sultan, I. Ahmad, and T. Dimitriou, “Container security: Issues, challenges, and the road ahead,” IEEE access, vol. 7, pp. 52 976–52 996, 2019

    2019

  8. [16]

    A comprehensive feature comparison study of open-source container orchestration frameworks,

    E. Truyen, D. Van Landuyt, D. Preuveneers, B. Lagaisse, and W. Joosen, “A comprehensive feature comparison study of open-source container orchestration frameworks,” Applied Sciences, vol. 9, no. 5, p. 931, 2019

    2019

  9. [17]

    ’under-reported’security defects in kubernetes manifests,

    D. B. Bose, A. Rahman, and S. I. Shamim, “’under-reported’security defects in kubernetes manifests,” in 2021 IEEE/ACM 2nd International Workshop on Engineering and Cybersecurity of Critical Systems (En- CyCriS). IEEE, 2021, pp. 9–12

    2021

  10. [18]

    Kgsecconfig: a knowledge graph based approach for secured container orchestrator configuration,

    M. U. Haque, M. M. Kholoosi, and M. A. Babar, “Kgsecconfig: a knowledge graph based approach for secured container orchestrator configuration,” in 2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2022, pp. 420– 431

    2022

  11. [19]

    Software for improve the security of kubernetes-based ci/cd pipeline,

    R. Shevchuk, M. P. Karpinski, M. Kasianchuk, I. Yakymenko, A. Melnyk, and R. Tykhyi, “Software for improve the security of kubernetes-based ci/cd pipeline,” 2023 13th International Conference on Advanced Computer Information Technologies (ACIT) , pp. 420–425,

    2023

  12. [20]

    Integrating static analysis into a secure software development process,

    D. N. Kleidermacher, “Integrating static analysis into a secure software development process,” in 2008 IEEE Conference on Technologies for Homeland Security, 2008, pp. 367–371

    2008

  13. [21]

    Evaluation of static analysis tools for software security,

    H. H. AlBreiki and Q. H. Mahmoud, “Evaluation of static analysis tools for software security,” in 2014 10th International Conference on Innovations in Information Technology (IIT) , 2014, pp. 93–98

    2014

  14. [22]

    Implementing a security framework for container orchestration,

    Z. Moric, V . Dakic, and M. Kulic, “Implementing a security framework for container orchestration,” in 2024 IEEE 11th International Conference on Cyber Security and Cloud Computing (CSCloud), 2024, pp. 200–206

    2024

  15. [23]

    Containers: Security challenges and mitigation strategies: A systematic literature review,

    L. Al Mashta, “Containers: Security challenges and mitigation strategies: A systematic literature review,” 2024

    2024

  16. [24]

    A large-scale study of security vulnerability support on developer q&a websites,

    T. H. M. Le, R. Croft, D. Hin, and M. A. Babar, “A large-scale study of security vulnerability support on developer q&a websites,” in Proceedings of the 25th International Conference on Evaluation and Assessment in Software Engineering , 2021, pp. 109–118

    2021

  17. [25]

    (2024) Checkov

    Bridgecrew. (2024) Checkov. Prisma Cloud. Accessed: 2024-05. [Online]. Available: https://www.checkov.io/

    2024

  18. [26]

    (2024) Trivy

    Aqua Security. (2024) Trivy. Aqua Security. Accessed: 2024-05. [Online]. Available: https://github.com/aquasecurity/trivy

    2024

  19. [27]

    (2024) Terrascan

    Tenable. (2024) Terrascan. Tenable. Accessed: 2024-05. [Online]. Available: https://runterrascan.io/

    2024

  20. [28]

    (2024) Kubesec

    controlplane. (2024) Kubesec. controlplane. Accessed: 2024-05. [Online]. Available: https://kubesec.io/

    2024

  21. [29]

    (2024) Prisma cloud

    Palo Alto Networks. (2024) Prisma cloud. Palo Alto Networks. Accessed: 2024-11-09. [Online]. Available: https: //www.paloaltonetworks.com/prisma/cloud

    2024

  22. [30]

    Retrieval-augmented generation for large language models: A survey,

    Y . Gao, Y . Xiong, X. Gao, K. Jia, J. Pan, Y . Bi, Y . Dai, J. Sun, and H. Wang, “Retrieval-augmented generation for large language models: A survey,” arXiv preprint arXiv:2312.10997 , 2023

    2023 arXiv

  23. [31]

    Corrective retrieval augmented generation,

    S.-Q. Yan, J.-C. Gu, Y . Zhu, and Z.-H. Ling, “Corrective retrieval augmented generation,” arXiv preprint arXiv:2401.15884 , 2024

    2024 arXiv

  24. [32]

    Cncf survey report 2020,

    Cloud Native Computing Foundation, “Cncf survey report 2020,” The Linux Foundation, Tech. Rep., 11 2020, accessed: 2024-11-09. [Online]. Available: https://www.cncf.io/wp-content/uploads/2020/11/ CNCF Survey Report 2020.pdf

    2020

  25. [33]

    (2023) Kubernetes adoption statistics

    EdgeDelta. (2023) Kubernetes adoption statistics. EdgeDelta. Accessed: 2024-11-09. [Online]. Available: https://edgedelta.com/company/blog/ kubernetes-adoption-statistics

    2023

  26. [34]

    (2024) Kubernetes

    The Kubernetes Authors. (2024) Kubernetes. The Linux Foundation. Accessed: 2024-05. [Online]. Available: https://kubernetes.io/

    2024

  27. [35]

    A critical review of intrusion detection systems in the internet of things: techniques, deployment strategy, validation strategy, attacks, public datasets and challenges,

    A. Khraisat and A. Alazab, “A critical review of intrusion detection systems in the internet of things: techniques, deployment strategy, validation strategy, attacks, public datasets and challenges,” Cybersecurity, vol. 4, 2021. [Online]. Available: https://api.semanticscholar...

    2021

  28. [36]

    Detection, analysis and countermeasures for container based misconfiguration using docker and kubernetes,

    V . Mahajan and S. B. Mane, “Detection, analysis and countermeasures for container based misconfiguration using docker and kubernetes,” 2022 International Conference on Computing, Communication, Security and Intelligent Systems (IC3SIS) , pp. 1–6, 2022. [Online]. Available: ht...

    2022

  29. [37]

    Automated software vulnerabil- ity assessment with concept drift,

    T. H. M. Le, B. Sabir, and M. A. Babar, “Automated software vulnerabil- ity assessment with concept drift,” in2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR) . IEEE, 2019, pp. 371–382

    2019

  30. [38]

    (2023) Artifact hub

    Cloud Native Computing Foundation. (2023) Artifact hub. The Linux Foundation. Accessed: 2024-11-09. [Online]. Available: https: //artifacthub.io/

    2023

  31. [39]

    (2023) Cncf projects: Artifact hub

    ——. (2023) Cncf projects: Artifact hub. The Linux Foundation. Accessed: 2024-11-09. [Online]. Available: https://www.cncf.io/projects/ artifact-hub/

    2023

  32. [40]

    Data quality for software vulnerability datasets,

    R. Croft, M. A. Babar, and M. M. Kholoosi, “Data quality for software vulnerability datasets,” in 2023 IEEE/ACM 45th International Confer- ence on Software Engineering (ICSE) . IEEE, 2023, pp. 121–133

    2023

  33. [41]

    Automatic data labeling for software vulnerability prediction models: How far are we?

    T. H. M. Le and M. A. Babar, “Automatic data labeling for software vulnerability prediction models: How far are we?” in Proceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement , 2024, pp. 131–142

    2024

  34. [42]

    (2023) Large enough

    Mistral AI Team. (2023) Large enough. Mistral AI. Accessed: 2024- 11-09. [Online]. Available: https://mistral.ai/news/mistral-large-2407/

    2023

  35. [43]

    (2023) Gpt-4o mini: Advancing cost-efficient intelligence

    OpenAI. (2023) Gpt-4o mini: Advancing cost-efficient intelligence. OpenAI. Accessed: 2024-11-09. [Online]. Available: https://openai. com/index/gpt-4o-mini-advancing-cost-efficient-intelligence/

    2023

  36. [44]

    Reasoning with large language models on graph tasks: The influence of temperature,

    Y . Wang, Z. Zhang, H. Chen, and H. Shen, “Reasoning with large language models on graph tasks: The influence of temperature,” in 2024 5th International Conference on Computer Engineering and Application (ICCEA), 2024, pp. 630–634

    2024

  37. [45]

    Mitigating data imbalance for software vulnerability assessment: Does data augmentation help?

    T. H. M. Le and M. Ali Babar, “Mitigating data imbalance for software vulnerability assessment: Does data augmentation help?” in Proceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement , 2024, pp. 119–130

    2024

  38. [46]

    Are latent vulnerabilities hidden gems for software vulnerability prediction? an empirical study,

    T. H. M. Le, X. Du, and M. A. Babar, “Are latent vulnerabilities hidden gems for software vulnerability prediction? an empirical study,” in 2024 IEEE/ACM 21st International Conference on Mining Software Repositories (MSR). IEEE, 2024, pp. 716–727

    2024

  39. [47]

    V . Bandari, “A comprehensive review of ai applications in automated container orchestration, predictive maintenance, security and compli- ance, resource optimization, and continuous deployment and testing,” International Journal of Intelligent Automation and Computing , vol. ...

    2021

  40. [48]

    Intelligent orchestration of containerized applications in cloud infrastructures,

    J. Farkouh, A. A. Donwoung, and A. Nazim, “Intelligent orchestration of containerized applications in cloud infrastructures,” in 10th Inter- national Workshop on ADVANCEs in ICT Infrastructures and Services (ADVANCE 2023), 2023

    2023

  41. [49]

    Modeling and discover- ing vulnerabilities with code property graphs,

    F. Yamaguchi, N. Golde, D. Arp, and K. Rieck, “Modeling and discover- ing vulnerabilities with code property graphs,” in 2014 IEEE symposium on security and privacy . IEEE, 2014, pp. 590–604

    2014

  42. [50]

    Automated software vulnerability detection with machine learning,

    J. A. Harer, L. Y . Kim, R. L. Russell, O. Ozdemir, L. Kosta, A. Rangamani, L. H. Hamilton, G. I. Centeno, J. R. Key, P. M. Ellingwood, M. W. McConley, J. M. Opper, P. Chin, and T. Lazovich, “Automated software vulnerability detection with machine learning,” ArXiv, vol. abs/18...

    2018 arXiv

  43. [51]

    Deepcva: Automated commit-level vulnerability assessment with deep multi-task learning,

    T. H. M. Le, D. Hin, R. Croft, and M. A. Babar, “Deepcva: Automated commit-level vulnerability assessment with deep multi-task learning,” in 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2021, pp. 717–729

    2021

  44. [52]

    Deep learning based vulnerability detection: Are we there yet?

    S. Chakraborty, R. Krishna, Y . Ding, and B. Ray, “Deep learning based vulnerability detection: Are we there yet?” IEEE Transactions on Software Engineering , vol. 48, no. 9, pp. 3280–3296, 2021

    2021

  45. [53]

    A survey on data-driven software vulnerability assessment and prioritization,

    T. H. M. Le, H. Chen, and M. A. Babar, “A survey on data-driven software vulnerability assessment and prioritization,” ACM Computing Surveys, vol. 55, no. 5, pp. 1–39, 2022

    2022

  46. [54]

    Towards an improved understanding of software vul- nerability assessment using data-driven approaches,

    T. H. Le, “Towards an improved understanding of software vul- nerability assessment using data-driven approaches,” arXiv preprint arXiv:2207.11708, 2022

    2022 arXiv

  47. [55]

    Linevul: A transformer-based line- level vulnerability prediction,

    M. Fu and C. Tantithamthavorn, “Linevul: A transformer-based line- level vulnerability prediction,” in Proceedings of the 19th International Conference on Mining Software Repositories , 2022, pp. 608–620

    2022

  48. [56]

    On the use of fine-grained vulnera- ble code statements for software vulnerability assessment models,

    T. H. M. Le and M. A. Babar, “On the use of fine-grained vulnera- ble code statements for software vulnerability assessment models,” in Proceedings of the 19th International Conference on Mining Software Repositories, 2022, pp. 621–633

    2022

  49. [57]

    Vulre- pair: a t5-based automated software vulnerability repair,

    M. Fu, C. Tantithamthavorn, T. Le, V . Nguyen, and D. Phung, “Vulre- pair: a t5-based automated software vulnerability repair,” in Proceedings of the 30th ACM joint european software engineering conference and symposium on the foundations of software engineering , 2022, pp. 935– 947

    2022

  50. [58]

    Automated code-centric software vulnerability assessment: How far are we? an empirical study in c/c++,

    A. T. Nguyen, T. H. M. Le, and M. A. Babar, “Automated code-centric software vulnerability assessment: How far are we? an empirical study in c/c++,” in Proceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement , 2024, pp. 72–83

    2024

  51. [59]

    Software vulnerability prediction in low-resource languages: An empirical study of codebert and chatgpt,

    T. H. M. Le, M. A. Babar, and T. H. Thai, “Software vulnerability prediction in low-resource languages: An empirical study of codebert and chatgpt,” in Proceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering , 2024, pp. 679– 685

    2024

  52. [2023]

    Available: https://api.semanticscholar.org/CorpusID: 264294763

    [Online]. Available: https://api.semanticscholar.org/CorpusID: 264294763

Pith tools

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