Skip to content

Back to the catalog

LLM-based Code Auditing by Inferring and Evaluating Developer Assumptions
arxiv.orgpaper

LLM-based Code Auditing by Inferring and Evaluating Developer Assumptions

Presents Creed, an LLM-based code auditing approach that infers a developer's security-related beliefs for a function, scores how reasonable each is, and derives the conditions under which it is violated. It catches domain-specific semantic flaws that syntactic static analysis misses, such as a timing side-channel that undermines user-enumeration protection. The paper also introduces two measures for explanation-based vulnerability detection, recall and overhead. On a recent real-world benchmark, Creed beats existing explanation-based tools on the effectiveness-effort trade-off.

TL;DR Creed uses an LLM to infer developer security assumptions and find where code violates them, catching semantic bugs like timing side-channels that SAST misses.
Also seen from another angle🧠 AI →
Document

What it is

Creed is an LLM-based, language-agnostic code auditing technique from Junming Liu (MPI-SP) and Marcel Böhme (CISPA). It works on a single function at a time. It makes the developer's implicit security beliefs explicit, then reports a finding when a belief is unreasonable or when it can be violated. The whole workflow is one prompt, with a verbatim prompt and output schema in the paper's artifact.

How it works

For each function, one LLM call walks five reasoning steps:

  1. Action identification, at two levels. Low-level actions (e.g. dereferencing a pointer) catch memory bugs. The function's overall purpose (e.g. canceling a payment) catches domain-specific flaws.
  2. Belief inference. One action can imply several beliefs. In cancel(), validating only siteId and payment status implies both "a matching siteId is sufficient authorization" and "siteId is a trusted server-side value".
  3. Sanity check. Is the belief consistent with standard security practice? An unreasonable belief is context-independent: any code relying on it is vulnerable.
  4. Violation check. Derive the specific conditions under which the belief fails, including for beliefs already judged unreasonable.
  5. Report. Each finding carries a root cause, symptoms and the context in which it is exploitable.
flowchart TD
    B[Inferred belief] --> S{Sanity check}
    S -->|Unreasonable| V1[Finding: context-independent]
    S -->|Reasonable| C{Violation condition triggerable?}
    C -->|Yes| V2[Finding: context-conditional]
    C -->|No| N[No finding]

Worked examples from the paper:

  • CVE-2026-25222 (PolarLearn, TypeScript). The function returns the same "invcreds" error for unknown user and wrong password. That belief is reasonable, but the extra hashPassword call on one path may create a response-time difference, a timing side-channel that undermines the user-enumeration protection.
  • CVE-2026-2010 (PublicCMS, Java). cancel() trusts siteId as authorization. Creed marks this unreasonable, because site-level and payment-level authorization differ. A same-site user could cancel a payment they do not own.

The paper also lists CVE-2026-28427 (path not limited to the allowed directory) and CVE-2026-22866 (missing signature verification) as the kind of flaw it targets.

Evaluation numbers

The benchmark is 50 recent CVEs from CVEfixes across 10 languages, 40 of them semantic flaws.

  • Recall is the share of vulnerabilities where Creed's explanation is consistent with the CVE description, patch commit message and patch diff. Creed scores 0.78 (39 of 50).
  • Overhead is the number of reports per expected vulnerability. Creed's is 7.9, against 11.3 for the strongest baseline (about 30% lower). Its recall is 10 points above that baseline's.
  • Under a tight inspection budget, it beats the recall any baseline reaches with unlimited effort.
  • It finds 15 of the 21 cases that cannot be expressed as general static-analysis patterns.

Caveats

  • Function-level scope. A violation condition may already be mitigated by upstream code, so Creed surfaces conditions for a human to verify rather than confirming exploitability.
  • Precision is not computed automatically. Many reports beyond the expected one look reasonable to the authors, so they only manually checked the first report per function.
  • Overhead is still high. About 8 reports must be inspected per true vulnerability.
  • Small benchmark. It is 50 CVEs, and the sampling is the authors' own. This is a v1 preprint, so it has not been peer reviewed.
  • The page text is truncated, so the baselines' names and the later sections (full evaluation setup, which LLM was used) are not covered here.

What to do

For an engineer evaluating this, the useful takeaways are:

  • The prompt structure is reproducible. Ask an LLM for action, belief, sanity and violation conditions per function, then triage the findings. The exact prompt is in the paper's artifact.
  • Treat the output as an audit aid for review of auth, crypto and path-handling logic, which syntactic tools miss. It is not a replacement for them.

Organisations named here

  • Creed
  • timing side-channel

Technologies named here

  • LLM

Techniques named here

  • Belief-guided program analysis for vulnerability detection
  • User enumeration attack
  • Explanation-based VD evaluation using two measures
  • User enumeration