💻 computer science

Leveraging Large Language Models for Trustworthiness Assessment of Web Applications

This paper proposes an empirical methodology that leverages Large Language Models to automate the trustworthiness assessment of web applications by verifying secure coding practices and integrating their outputs into a hierarchical Quality Model to generate a holistic trustworthiness score.

Original authors: Oleksandr Yarotskyi, José D'Abruzzo Pereira, João R. Campos

Published 2026-03-26

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Oleksandr Yarotskyi, José D'Abruzzo Pereira, João R. Campos

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the manager of a massive, bustling restaurant (the Web Application). Your customers (users) expect the food to be safe, the service to be smooth, and the kitchen to be spotless. If a single chef cuts their finger and doesn't wash their hands, or if a waiter forgets to check a customer's ID, the whole restaurant could get shut down or lose its reputation.

In the digital world, this "safety" is called Trustworthiness.

For years, checking if a restaurant is safe has been like hiring a team of super-expert health inspectors to walk through the kitchen, taste every dish, and read every recipe book. This is slow, expensive, and hard to scale. If you open 1,000 new restaurants a day, you can't hire 1,000 inspectors.

This paper asks a big question: Can we use a super-smart AI (a Large Language Model or LLM) to act as our health inspector?

Here is the story of how they tried it, what went wrong, and what finally worked.

The Problem: The "Checklist" is Too Hard

Traditionally, security tools look for specific "bugs" (like a broken lock on a door). But what if the lock is fine, but the chef is just lazy and leaves the back door open? That's a Secure Coding Practice issue.

Checking these practices usually requires a human expert to read code and say, "Yes, this chef followed the rule," or "No, they didn't." This is too slow for the modern internet.

The Experiment: The AI Inspector

The researchers decided to test five different AI "inspectors" (like GPT-4, Gemini, etc.) to see if they could read the code and check if the chefs were following the rules. They focused on one specific rule: Input Validation (making sure no one sneaks a dirty ingredient into the kitchen).

They tried four different ways to talk to the AI (called Prompting Strategies):

1. The "Just Ask" Approach (Baseline)

The Analogy: You walk up to the AI and say, "Is this code safe?" without giving it any context.
The Result: The AI guessed okay for simple things, but it was often confused. It was like asking a tourist if a building is structurally sound without showing them the blueprints. It worked for obvious things but missed the tricky details.

2. The "Show Me the Bad Examples" Approach (Few-Shot)

The Analogy: You show the AI a picture of a chef who didn't wash their hands and say, "Don't do this."
The Result: This helped the smartest AI (GPT-4) get even better. But for the smaller, cheaper AIs, it was like giving a toddler a textbook on advanced chemistry—they got overwhelmed by the extra information and made more mistakes.

3. The "Show the Whole Kitchen" Approach (Structural Context)

The Analogy: You think, "Maybe the chef is safe, but the helper they talk to isn't!" So, you give the AI the code for the main chef plus the code for every helper they talk to.
The Result: Disaster. The AI got confused. It was like giving a detective a library of books instead of just the crime scene. The extra information was "noise." The AI couldn't find the needle in the haystack. It actually performed worse than when you gave it less info.

4. The "Strict Rulebook" Approach (Rule-Based)

The Analogy: Instead of showing examples or huge libraries, you give the AI a simple, strict checklist:
- Rule 1: If the input comes from a user, it MUST be checked.
- Rule 2: If it's not checked, mark it as FAIL.
The Result: This was the winner. By giving the AI clear, step-by-step instructions (like a recipe), even the smaller, cheaper AIs became surprisingly good inspectors. They stopped guessing and started following the rules.

The Final Score: The "Trust Score"

The researchers didn't just want the AI to say "Yes" or "No." They wanted a Trust Score (from 0 to 100) for the whole application.

Attempt A: They asked the AI, "Give me a score from 0 to 100."
- Result: The AI was terrible at math. It gave random numbers. It couldn't weigh the importance of different mistakes.
Attempt B: They used the AI to check the checklist, and then used a Math Formula (called a Quality Model) to calculate the score based on the AI's "Yes/No" answers.
- Result: Perfect. The AI did the hard work of reading the code, and the math formula did the work of calculating the score. This created a reliable, scalable way to tell if a web app is trustworthy.

The Big Takeaways

More Info isn't Always Better: Giving the AI too much code (the "Whole Kitchen" approach) confused it. Sometimes, less is more.
Rules Beat Examples: For security checks, giving the AI a strict rulebook works better than showing it examples of bad code.
AI + Math = Trust: You shouldn't ask the AI to be the mathematician. Let the AI be the reader, and let a formula do the scoring. This combination creates a system that can check thousands of apps quickly and accurately.

Why This Matters

In the future, instead of waiting months for a human security team to check your app, you could plug your code into this system. It would instantly tell you, "Your app is 85% trustworthy, but you missed one rule in the login section." This makes the internet safer, faster, and cheaper to build.

1. Problem Statement

The security of web applications is critical, yet traditional assessment methods face significant limitations:

Vulnerability-Centric Limitations: Existing tools (SAST, DAST) focus on detecting known vulnerabilities. They often fail to identify latent weaknesses or guarantee reliability if no specific CVE is found.
Scalability Issues: Assessing adherence to secure coding practices (a proactive approach to trustworthiness) currently relies on manual code reviews by experts. This is time-consuming, subjective, and difficult to scale for modern CI/CD pipelines.
Contextual Gaps: Static analysis tools often lack the semantic understanding required to verify complex coding practices (e.g., input validation logic spanning multiple functions), leading to high false positives or negatives.

The core challenge is to automate the assessment of trustworthiness—defined as the degree of adherence to secure coding standards—without sacrificing accuracy or scalability.

2. Methodology

The authors propose an empirical framework that integrates Large Language Models (LLMs) with a hierarchical Quality Model (QM) based on the Logic Score of Preference (LSP).

A. Dataset and Scope

Dataset: The study uses the WSVD-Bench, a public benchmark containing 21 Java web services with 80 operations and 158 documented SQL Injection vulnerabilities. It includes secure (Vx0) and vulnerable (VxA) variants.
Focus: The evaluation is scoped to OWASP Input Validation practices (16 specific practices from the OWASP Secure Coding Practices Quick Reference Guide), a critical domain for preventing injection flaws.
Ground Truth: A manually curated dataset was created by security experts, labeling 42 functions for 16 practices with three states: Followed (1), Not Followed (0), or Not Applicable (NA).

B. Experimental Design

The study evaluates five state-of-the-art LLMs (gpt-3.5-turbo, gpt-4o-mini, gpt-4.1-mini, gpt-4.1, gemini-2.5-flash) using four distinct prompt engineering strategies:

Baseline (Zero-Shot): Provides only the practice description and code.
CWE + Bad Examples (Few-Shot): Adds Common Weakness Enumeration (CWE) mappings and negative code examples to guide pattern recognition.
Function Call Context: Augments the prompt with source code of called helper functions (extracted via Joern) to trace inter-procedural logic.
Rule-Based: Replaces open-ended questions with strict, step-by-step binary decision logic (e.g., "If X, then Followed; else Not Followed").

C. Trustworthiness Aggregation

To move beyond binary classification, the study employs two approaches for RQ3:

LLM-Driven Estimation: Asking the LLM to directly generate a scalar trustworthiness score (0–1).
QM + LSP Aggregation: Using the LLM's binary outputs as inputs for a formal Quality Model. The model uses the Logic Score of Preference (LSP) with a "weak simultaneity" operator ( $r = -1$ ). This ensures that missing a critical security practice significantly lowers the overall score, reflecting the "weakest link" principle. Weights for practices are derived empirically from real-world vulnerability data (CVE counts).

3. Key Contributions

Systematic Prompt Engineering Comparison: A comprehensive evaluation of how semantic enrichment, structural context, and explicit instructions affect LLM performance in security assessment.
Hybrid Automation Framework: A novel pipeline combining LLMs for practice detection with a deterministic LSP-based QM for holistic scoring, bridging the gap between AI inference and formal security metrics.
Empirical Validation of Feasibility: Evidence demonstrating that LLMs can replace manual expert review for scalable trustworthiness assessment when guided by the correct prompting strategies and aggregation models.

4. Experimental Results

RQ1: Baseline Performance

Findings: Baseline (zero-shot) performance varies significantly by model. gpt-4.1 achieved the highest Macro F1-score (0.89), while smaller models like gpt-3.5-turbo struggled (F1 ~0.52).
Limitation: Baseline models perform well on local syntactic checks but fail on tasks requiring control-flow reasoning or architectural context (e.g., verifying if validation logic terminates execution).

RQ2: Impact of Prompt Strategies

Semantic Context (Prompt 2): Improved performance for high-capacity models (gpt-4.1 F1 increased to 0.93) but caused regression in smaller models (e.g., gemini-2.5-flash dropped to 0.68) due to "contextual overload."
Structural Context (Prompt 3): Negative Impact. Adding raw helper function code introduced noise, reducing recall across all models. Even gpt-4.1's F1 dropped from 0.89 to 0.75. The models failed to filter relevant code, leading to missed detections.
Rule-Based Prompting (Prompt 4): Most Robust Strategy. Explicit, step-by-step instructions significantly improved performance for mid-tier and smaller models.
- gpt-4o-mini saw the largest gain (+0.1288), reaching an F1 of 0.74.
- gpt-4.1-mini improved to 0.84.
- This strategy effectively compensated for lower reasoning capabilities, making lightweight models viable for security assessment.

RQ3: Trustworthiness Scoring Reliability

Direct LLM Scoring: LLMs failed to generate reliable holistic scores directly (Mean Absolute Error 0.40–0.60). They could not implicitly synthesize multi-criteria weights or importance.
QM + LSP Aggregation: When LLM binary outputs were fed into the formal LSP model, the system successfully discriminated between secure and vulnerable code.
- Statistical Significance: Mann-Whitney U tests confirmed that the Rule-Based strategy (Prompt 4) created a statistically significant separation between secure and vulnerable distributions ( $p < 0.05$ ).
- Discriminatory Power: The LSP approach minimized dispersion and eliminated overlap between secure and vulnerable score distributions, unlike the unstructured context approach.

5. Significance and Conclusion

Scalability: The study proves that trustworthiness assessment can be automated and scaled to modern development pipelines, removing the bottleneck of manual code review.
Cost-Efficiency: By demonstrating that rule-based prompting allows smaller, faster, and cheaper models (like gpt-4o-mini) to achieve accuracy comparable to larger models, the approach is economically viable for continuous integration.
Methodological Shift: The paper advocates for a shift from "vulnerability counting" to "practice adherence assessment" using a hybrid AI-Formal method.
Future Work: The authors plan to extend this framework to other programming languages, vulnerability types, and integrate it directly into CI/CD pipelines for continuous security monitoring.

Conclusion: LLMs alone are insufficient for direct trustworthiness quantification due to hallucination and inconsistency. However, when used as deterministic inputs for a structured Quality Model (QM) and guided by rule-based prompts, they enable a scalable, reliable, and context-aware assessment of web application security.