@readmodelmag
MODEL

AI News

Hot take: 'the tests pass' is not a security check, and a new preprint shows why

SummaryA.S.E 2.0 (CASE-Bench), a preprint posted to arXiv on Nov 4, built 145 coding tasks from real CVEs. Context tuned for working code lifted functional pass rates up to 8.2 points but secure pass rates by at most 3.7. Coding agents saw the relevant safeguard in only 27-36% of runs.

· MODEL Editors · 2 min read

Some links may be affiliate links. Disclosure

MODEL hot take card on a cream background. Small red label: HOT TAKE. Large red words: 27-36%. Black headline: Agents rarely look for the safeguard. Bottom left: MODEL. Bottom right: Source: arXiv 2611.06294 (preprint).
Card by MODEL from figures in arXiv 2611.06294. MODEL did not run this study. Illustration by MODEL. Original. Image source.

The take. Green tests tell you the code works. They do not tell you it is safe. A new preprint from researchers at Nanyang Technological University, Tencent and Zhejiang University measures the gap on real vulnerabilities, and the numbers are blunt.

What the researchers did. They built CASE-Bench: 145 repository-level coding tasks taken from 144 real CVEs in 51 open-source projects. Each task runs in Docker with functional tests and a proof-of-concept exploit. A generation counts as "secure" only if it passes the tests and the exploit then fails. They compared 13 ways of assembling repository context across six LLMs, with the task and prompt held fixed.

What they found (all from the paper's abstract and text):

  • Context built for functional correctness raised the functional pass rate by up to 8.2 percentage points, but the secure pass rate by at most 3.7.
  • Withholding a safeguard (such as an authorization check) lowered the secure pass rate by up to 8.1 points.
  • Inserting one insecure example raised correct-but-exploitable code by 6.3 points, even with the safeguard still present.
  • Coding agents observed the relevant safeguard in only 27-36% of their runs. In the paper, 71% of agent search queries named functional things such as a file format and only 9% named security concepts.
  • In the paper's agent table, Claude Code with Sonnet 4.5 passed 74.0% of functional checks and 18.4% of secure checks, and 55.6% of its generations passed every test but were still exploitable.

Why it matters. The code that gets merged is the code that passes tests. If an agent never looks at the check that protects an endpoint, it can write a working endpoint without it. The paper's pattern is that agents and retrieval tools search for what code does, not for the rule that constrains it.

Our verdict. Treat green tests as the floor. Before merging agent-written code that touches auth, parsing or user input, find the project's existing guard yourself and confirm the new code uses it. Agent scaffolds that go looking for safeguards would be worth trying; the paper suggests the direction but does not validate it.

Caveats. This is a preprint and has not been peer reviewed. The tasks ask a model to rewrite a masked region of real vulnerable code, and "secure" means the specific exploit failed, which does not rule out other flaws. Six projects supply 67 of the 145 tasks, and the authors say differences below about 5.6 points may go undetected. The agent figures come from restricted runs with a step and cost cap. Some of the context effects are not statistically significant after correction, and the authors say so.

Disclosure: MODEL did not run or test this study; every figure comes from the authors' paper at arxiv.org/abs/2611.06294, which we read in full text. Not sponsored. No affiliate links.

MODEL Editors

Sources

  1. A.S.E 2.0: Understanding How Repository Context Impacts the Security of LLM-Generated Code

    arXiv (preprint)

FREE · EVERY WEEK

The top AI tools this week, tested.

Every week MODEL's editors pick the AI tools worth your time, try them hands-on, and tell you what's good, what's not, and who it's for. Free, in your inbox.

Free. Unsubscribe anytime. Our picks are editorial and can't be bought.