🤖 AI

DualGauge: Automated Joint Security-Functionality Benchmarking of Specification-Only Code Generation by LLMs and Coding Agents

The paper introduces DualGauge, an automated framework and benchmark demonstrating that current LLMs and coding agents struggle to simultaneously generate code that is both functionally correct and secure, with joint success rates remaining below 15% across multiple languages and revealing that enhanced model capabilities or iterative scaffolding do not reliably resolve these security-functionality trade-offs.

Original authors: Rupam Patir, Keyan Guo, Suvadra Barua, Abhijeet Pathak, Dinesh Gudimetla, Jiawei Guo, Hongxin Hu, Haipeng Cai

Published 2026-06-16

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Rupam Patir, Keyan Guo, Suvadra Barua, Abhijeet Pathak, Dinesh Gudimetla, Jiawei Guo, Hongxin Hu, Haipeng Cai

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 hire a very talented, fast-talking robot chef to cook a meal based on a simple verbal description: "Make a sandwich."

For a long time, we've only checked if the robot followed the recipe. Did it put bread on the plate? Yes. Did it add ham? Yes. If the sandwich looks right, we say, "Great job!"

But this new paper, DualGauge, asks a much harder question: "Is the sandwich safe to eat?"

Maybe the robot followed the recipe perfectly, but it also accidentally sliced the ham with a rusty knife it found in the drawer, or it used a cutting board that was never washed. The sandwich looks like a sandwich, but it's dangerous.

Here is the story of what the researchers found, explained simply.

1. The Problem: The "Looks Good" Trap

The researchers discovered that current AI coding tools (like the robot chef) are great at making things that look like they work, but they are terrible at making things that are actually safe.

They built a new testing system called DualGauge. Think of this as a "Double-Check Kitchen."

The Old Way: You taste the sandwich. If it tastes like ham, you pass the test.
The DualGauge Way: You taste the sandwich (Functionality), AND you inspect the kitchen for rusty knives, dirty boards, and poison (Security).

2. The Benchmark: The "307 Sandwich Orders"

To test this, they created a massive menu of 307 different tasks.

Each task was just a simple sentence, like "Write a program that reads a file."
They didn't give the AI any hints, code snippets, or safety warnings. Just the order.
For every order, they created two sets of tests:
1. The Taste Test: Does the program do what it's supposed to do?
2. The Safety Inspection: Does the program try to steal files, crash the system, or let hackers in?

3. The Shocking Results

They asked 10 of the smartest AI models (the "chefs") to make these 307 sandwiches. Here is what happened:

The "Looks Good" Score was High: Many models got about 39% of the sandwiches tasting right. They followed the recipe!
The "Safe" Score was Low: When checking for safety, the scores dropped.
The "Perfect" Score was Tiny: When they asked, "Did you make a sandwich that tastes right AND is safe?" the best AI model got less than 15% right.

The Analogy: Imagine a student taking a math test. They get 90% of the answers right (Functional Correctness). But if you ask, "Did you also check your work for calculation errors?" they fail. The paper found that being good at coding does not automatically mean you are good at coding safely.

4. Why "Thinking Harder" Didn't Help

The researchers tried to fix the problem by giving the AI more tools, just like giving a chef better knives or more time to think. They tried:

Bigger Models: Using the "super-chefs" (larger AI brains).
Extended Thinking: Telling the AI, "Take your time and think step-by-step."
Specialized Training: Teaching the AI specifically how to be a coder.

The Result: None of these tricks reliably fixed the safety issue. Sometimes the AI got better at the recipe, but still forgot to wash the cutting board. Sometimes it got better at safety but forgot the recipe. Safety and Functionality are two different skills that don't always grow together.

5. The "Robot Assistant" Didn't Help Either

There are new AI tools that act like "agents." Instead of just writing the code once, they try to fix their own mistakes. They write code, run it, see an error, and try again.

The researchers found that on these "pure recipe" tasks, the agents didn't do any better than the simple robots.

Why? The agents spent all their time looking for tools in the kitchen (like searching for a specific file or setting up a server) instead of actually fixing the safety of the sandwich. They were busy "managing the kitchen" but not "cooking safely."

6. The "Hidden Danger"

The paper found a specific pattern in why the AI failed.

Functional Failures: The AI usually failed because it got the "shape" of the answer wrong (e.g., it returned the wrong type of data).
Security Failures: The AI usually did try to be safe, but it was incomplete.
- Example: The AI put a lock on the door (a security guard), but it forgot to lock the back window. The guard looked good, but the house was still unsafe.

The Bottom Line

The paper concludes that we cannot just trust AI because it writes code that "works."

Functional correctness is a bad lie detector for safety. Just because code runs without crashing doesn't mean it's secure.
We need a new standard. We need to test for safety and function at the same time, using the same rules.
Current AI isn't there yet. Even the smartest models are failing to consistently produce code that is both useful and safe.

In short: Just because the robot chef made a sandwich that looks delicious, doesn't mean you should eat it. We need to check the kitchen, too.

Technical Summary: DualGauge

Problem Statement

Large Language Models (LLMs) and LLM-based coding agents are increasingly used to generate code from natural-language specifications. While functional correctness has become the dominant criterion for evaluating these systems, it is insufficient for ensuring deployable software. Prior research indicates that AI coding assistants frequently generate insecure code, and developers often accept these suggestions while remaining confident in their safety.

Existing evaluation frameworks suffer from two primary limitations:

Isolation of Metrics: Functional benchmarks (e.g., HumanEval, LiveBench) and security benchmarks (e.g., SecurityEval, CodeLMSec) typically evaluate correctness and security in isolation or on different datasets. A program that passes functional tests but contains vulnerabilities, or vice versa, is not useful.
Evaluation Oracle Challenges: Security evaluation cannot rely solely on exact output matching. As illustrated by path-traversal examples, a secure and a vulnerable implementation may produce identical outputs and exit codes on adversarial inputs. The distinction often lies in the execution trace (e.g., whether a file was accessed before a check failed), requiring semantic reasoning over runtime behavior rather than simple output comparison.
Context Limitations: Most benchmarks rely on code completion, repository context, or framework scaffolding, overlooking "specification-only" generation where a model must implement a function from a natural-language description alone.

Methodology: DualGauge and DualGauge-Bench

The authors present DualGauge, a fully automated framework for the joint evaluation of security and functionality in specification-only code generation, supported by DualGauge-Bench.

DualGauge-Bench

This is a language-agnostic benchmark comprising 307 coding tasks.

Task Design: Each task consists of a natural-language specification without code snippets, function signatures, or language-specific constraints.
Paired Testing: Every specification is paired with two test suites derived from the same prompt:
- Functional Tests: Guided by boundary value analysis and equivalence-class partitioning to verify behavioral correctness.
- Security Tests: Guided by OWASP and CERT principles to verify the absence of insecure behaviors (e.g., input validation failures, access control issues).
Coverage: The benchmark spans seven functionality domains and 90 Common Weakness Enumeration (CWE) categories, covering intraprocedural and interprocedural tasks.
Construction: Prompts were curated from existing datasets (CodeGuard+, SecurityEval, Purple Llama CyberSecEval) and converted to pure specifications. Test suites were created via a human-LLM co-creation process, where LLMs proposed candidates and human raters validated and extended them.

DualGauge System

The system operates in four phases to automate the evaluation pipeline:

Sample Generation: The target LLM or agent generates $k$ code candidates for a given specification.
Agentic Execution: An LLM-guided executor runs the candidates in an isolated environment. It classifies failures into environment, script, or code issues. It repairs environment and script issues (e.g., missing packages, invocation errors) but does not alter the candidate code itself. This ensures the program is executable without artificially fixing the model's logic.
LLM-Based Runtime Evaluation:
- Functional Oracle: Uses exact output matching against expected outputs.
- Security Oracle: Uses an LLM to perform semantic judgment. It analyzes the candidate code, execution outputs, and coverage traces against expected security behaviors. If the code uses unfamiliar libraries, a resolver model with web-search capabilities retrieves documentation to aid the evaluation. This step determines if the code implemented a genuine defense rather than just failing by accident.
Result Aggregation: Computes metrics including functional pass rate ($PR$), secure pass rate ($SPR$), and the joint metric secure-pass@k (the probability that a single sample is both functionally correct and secure).

Key Results

The authors evaluated 10 representative LLMs (including GPT-5, Claude Opus/Sonnet, Llama, Qwen, and Gemma families) across Python, C++, and JavaScript, as well as 3 agentic coding systems (Codex, OpenHands, Claude Code).

1. Functional Correctness Overestimates Reliability

Even the strongest models achieved a functional pass rate of nearly 39% on Python tasks, but the joint security-functionality success rate (secure-pass@1) remained below 15% in every language. This indicates that functional correctness is a poor proxy for safe code generation.

2. Model-Side Factors Do Not Reliably Improve Joint Performance

The study swept four factors: scale, extended thinking, quantization, and instruction/code specialization.

Scale: Increasing model size improved functional fluency but security coverage plateaued well before the largest sizes.
Extended Thinking & Specialization: These factors shifted functional and security metrics differently depending on the model family and did not reliably improve the joint metric.
Conclusion: Secure-and-correct code generation does not simply emerge from stronger coding capability; it requires the consistent application of security knowledge across all requirements.

3. Agentic Systems Offer No Advantage

Iterative scaffolding by coding agents (Codex, OpenHands, Claude Code) provided no advantage over direct generation for specification-only tasks.

Mechanism of Failure: Agents spent significant effort on repository-oriented overhead (e.g., listing directories, searching for config files) which yielded no signal in an empty workspace.
Feedback Loop: Agents often relied on self-generated tests rather than ground-truth benchmarks. Partial defenses that passed the agent's internal checks but failed the benchmark's security tests were not revised. Consequently, agents inherited the same failure modes as direct generation without closing the coverage gap.

4. Failure Modes

Functional Failures: Concentrated at the output contract boundary (e.g., wrong JSON structure, incorrect CLI vs. service), not algorithmic errors.
Security Failures: Characterized by partial defenses. Models often implemented guards (regex, type checks) that looked reasonable but failed to cover the specific attack vector or were applied at the wrong abstraction level.
Joint Gap: A program could pass functional tests while being insecure, or pass some security tests while failing others. Only joint benchmarking reliably exposed these "silent" failures.

Significance and Claims

The paper claims to present the first fully automated framework for jointly evaluating security and functionality in specification-only code generation. Its significance lies in:

Revealing the Gap: Demonstrating that current state-of-the-art models and agents struggle to satisfy correctness and security simultaneously, with joint success rates remaining critically low (<15%).
Methodological Shift: Arguing that security evaluation requires semantic reasoning over execution traces rather than output matching, and that benchmarks must pair functional and security tests for the same specification.
Agent Limitations: Showing that multi-turn refinement and tool use do not yet automatically overcome the core challenge of producing secure code when no existing codebase or test runner is available to guide the agent.
Benchmark Standard: Providing a language-agnostic, reusable benchmark (DualGauge-Bench) that moves beyond code completion to test the fundamental ability of models to translate natural-language intent into secure, correct code.

The authors conclude that secure code generation requires the consistent application of security knowledge across the full space of requirements, a capability that current models and agents have not yet mastered. They emphasize that their results are scalable benchmark estimates and that human security review remains necessary.