From Detection to Prevention: Explaining Security-Critical Code to Avoid Vulnerabilities

Security vulnerabilities often arise unintentionally during development due to a lack of security expertise and code complexity. Traditional tools, such as static and dynamic analysis, detect vulnerabilities only after they are introduced in code, leading to costly remediation. This work explores a proactive strategy to prevent vulnerabilities by highlighting code regions that implement security-critical functionality – such as data access, authentication, and input handling – and providing guidance for their secure implementation. We present an IntelliJ IDEA plugin prototype that uses code-level software metrics to identify potentially security-critical methods and large language models (LLMs) to generate prevention-oriented explanations. Our initial evaluation on the Spring-PetClinic application shows that the selected metrics identify most known security-critical methods, while an LLM provides actionable, prevention-focused insights. Although these metrics capture structural properties rather than semantic aspects of security, this work lays the foundation for code-level security-aware metrics and enhanced explanations.

💡 Research Summary

The paper tackles a fundamental shortcoming of current application security tooling: most static and dynamic analysis solutions detect vulnerabilities only after they have been introduced into the source code, which makes remediation expensive and often late in the development lifecycle. To shift the focus from detection to prevention, the authors propose an IntelliJ IDEA plugin that (1) automatically flags methods that are likely to be security‑critical and (2) generates natural‑language, prevention‑oriented explanations for those methods using large language models (LLMs).

Criticality assessment – The prototype relies on three classic, lightweight software metrics that can be computed instantly on a whole project: cyclomatic complexity (CC), lines of code (LOC), and lack of cohesion of methods (LCOM). These metrics are calculated with the CK tool, filtered to remove zero‑value methods, sorted in descending order, and then bucketed into High, Medium, and Low categories using quantile‑based equal‑frequency binning. The authors argue that while these metrics do not capture security semantics directly, they are strong proxies for code that is complex, large, or poorly organized—attributes historically correlated with defect‑proneness and, by extension, security risk.

Explanation generation – For each flagged method, the plugin constructs a zero‑shot role‑playing prompt consisting of a system instruction (acting as a security‑criticality expert) and a user instruction that supplies the method body, the metric name, and its value. The prompt explicitly asks the model to explain why the code is security‑critical and to list concise preventive steps. The implementation uses Azure OpenAI’s GPT‑5 (gpt‑5‑2025‑08‑07) as the primary model and GPT‑4o (gpt‑4o‑2024‑08‑06) for comparison. GPT‑5 yields richer, more context‑aware explanations but incurs higher latency (≈7.2 s per method), whereas GPT‑4 produces faster but more generic responses (≈1.3 s per method).

IDE integration – The plugin visualizes the assessment directly in the editor gutter: icons and color cues indicate the criticality level, and hovering over an icon shows a tooltip with the metric value, the LLM‑generated explanation, and a list of precautionary actions. Developers can toggle the visibility of Low‑criticality methods to reduce visual noise and can select which metric to use via the context menu.

Evaluation – The authors evaluated the prototype on the vulnerable Spring‑PetClinic application, which contains 99 methods and eight known vulnerable methods from prior work. Metric computation for the whole project took about 2 seconds. Using LOC, the plugin flagged all eight vulnerable methods as High or Medium; CC identified three, and LCOM identified one. This demonstrates that simple size‑ and complexity‑based metrics can surface many truly risky methods, but also that they generate a substantial number of false positives (non‑vulnerable methods marked as High/Medium).

Findings on explanation quality – GPT‑5’s explanations referenced concrete operations (e.g., database queries, authentication checks) and suggested specific mitigations (input validation, principle of least privilege). However, the model still failed to point to exact variable names or line numbers, limiting actionable precision. GPT‑4’s output was quicker but often generic, lacking the depth needed for developers to understand subtle security nuances.

Limitations – The primary limitation is the reliance on structural metrics that do not encode security semantics, leading to false positives and inconsistent ranking of truly vulnerable methods. The second limitation lies in the LLM’s dependence on those metrics; without semantic cues, the generated explanations can be overly broad or miss critical details. Additionally, the use of general‑purpose LLMs raises concerns about hallucination and reproducibility.

Future work – The authors outline several avenues: (1) design security‑aware metrics that directly capture dangerous operations (e.g., handling of secrets, privilege checks) and map methods to CWE identifiers; (2) fine‑tune LLMs on security‑focused corpora to improve contextual relevance; (3) implement validation guards (e.g., AWS Automated Reasoning Checks) to detect and mitigate hallucinations; (4) adapt explanation granularity to developer expertise; and (5) integrate the approach into AI‑assisted coding workflows, providing security guardrails for code generated by AI agents.

Conclusion – The paper demonstrates a feasible, proactive approach to software security: by quickly flagging potentially security‑critical code using lightweight metrics and enriching those flags with LLM‑generated, prevention‑oriented explanations, developers receive immediate, actionable guidance within their normal IDE workflow. While the current prototype’s reliance on generic metrics and off‑the‑shelf LLMs limits precision, the concept establishes a solid foundation for future research into security‑specific metrics and tailored language models that could make proactive security assistance a standard part of modern development environments.