Skip to main content
This is a preview/beta feature. Further changes are expected.

​
Overview

AI Code Analysis is a built-in Chainloop workflow that reads a repository’s own history of security fixes and turns it into a durable, machine-readable map of where that codebase tends to go wrong. Chainloop clones the connected repository into a sandbox it manages, walks its recent commits, keeps the ones that fixed a real security bug, and compiles them into an AI Security Context — a signed CHAINLOOP_AI_SECURITY_CONTEXT attestation stored alongside the rest of your evidence. That map is useful on its own — a reviewable record of what a project has had to fix, where, and what check made it right — and it doubles as the seed for an agent that hunts for the un-patched siblings of those fixes in the current code.

​
The Idea in One Paragraph

A codebase’s own history of security fixes is the highest-signal map of where its next vulnerability lives. Bugs cluster in the same components, the same kinds of dangerous operations, and the same vulnerability classes — and a guard added on one code path is very often missing on a sibling path. Rather than scanning a repository against a generic ruleset, AI Code Analysis learns from what this project has already had to fix, then points reviewers and agents at the places that pattern predicts.

​
Research Grounding

The “fix history predicts the next bug” premise is not new — it rests on several well-established lines of security and software-engineering research. AI Code Analysis operationalizes them and adds the step most of the literature leaves open: using that history to discover new bugs rather than only to detect past ones.
  • Defect clustering. Decades of defect-prediction work show that faults concentrate in a small minority of files, and that past fixes in a file predict future faults there better than size or complexity metrics do. This is why the context ranks hot components by recency-weighted fix history.
    Ostrand & Weyuker, “The Distribution of Faults in a Large Industrial Software System” (ISSTA 2002); Ostrand, Weyuker & Bell (IEEE TSE 2005).
  • Variant analysis. After a bug is fixed, the highest-yield next move is to systematically hunt the same pattern elsewhere — the practice Google Project Zero built much of its work around. AI Code Analysis automates the fingerprint-then-match step instead of relying on hand-written queries.
    Google Project Zero, “0-day In-the-Wild Exploitation…so far” (2022).
  • Incomplete-fix prevalence. A large share of vulnerabilities are follow-ups to earlier, partial patches — the same bug reachable through a path the original fix didn’t cover. Project Zero found that a significant fraction of in-the-wild 0-days were variants of previously disclosed and patched issues.
    Google Project Zero, 2022.
  • LLMs over commit history. A growing body of work shows that commit history plus an LLM is a productive substrate for reasoning about vulnerabilities. Most of it measures fix detection; AI Code Analysis leans on the same substrate for the harder half — new-bug discovery.
    LLM4VFD (arXiv:2501.14983), CommitShield (arXiv:2501.03626), Vercation (arXiv:2408.07321), PatchSeeker (arXiv:2509.07540).

​
How It Works

AI Code Analysis is a recall-first funnel: a cheap first pass casts a wide net over history, and progressively more careful stages do the precision work. The result is a compiled context, produced deterministically from what the earlier stages confirmed.
  • Classify. A lightweight pass reads each commit’s diff and asks a single question: did this fix a security bug? It is tuned for recall — deliberately over-including — because the base rate of security fixes in ordinary history is low (roughly 1–2% of commits).
  • Investigate. Each candidate is examined more carefully in an isolated, read-only pass that characterizes the fix: what class of bug it was, where it lived, what makes a call site safe, and how the claim can be checked. Candidates that turn out to be features, refactors, or unreachable hardening are dropped here.
  • Compile. A deterministic step — no model — groups the confirmed fixes and recency-weights them into the AI Security Context. Because it is deterministic and everything it emits is sorted, two runs over identical history produce identical output, so the material diffs cleanly across scans.
  • Hunt. The compiled context seeds an agent that reads the current code at HEAD and looks for the un-patched siblings the map predicts, returning findings it can back up.
Scans are incremental: a later run only walks commits it hasn’t seen, accumulating coverage over time rather than re-scanning from scratch.

​
What the AI Security Context Gives You

The context is a compiled view of a repository’s security history, organized so that both people and agents can act on it. At a high level it surfaces:
  • Hot components — the files and areas that have needed the most (and the most recent, most severe) fixes. This is defect clustering made concrete: where to look first.
  • Shared surfaces — a rule that must hold at every path reaching the same kind of dangerous operation, backed by the fixes that established it. This is the variant-analysis payoff: it points directly at the sibling path where the same guard may be missing.
  • Confirmed security fixes — each past fix with its class, severity, a plain-language summary, root cause, attacker preconditions, impact, and the components it touched.
  • Class distribution — how a project’s fixes break down across a stable set of vulnerability classes (access control, injection, cryptography, information disclosure, input validation, resource exhaustion, and so on), so recurring themes are visible at a glance.

​
Evidence, Not Assertion

What separates the AI Security Context from a model’s opinion is that its claims are independently verifiable. Each is tied to a byte-exact span of real source — a revision, a file, a line range, and a hash of the quoted code — so anyone can re-check that the cited code actually says what the context claims. Spans that couldn’t be verified are marked as such rather than quietly dropped. Because the whole thing is a signed Chainloop attestation, it carries the same provenance and tamper-evidence as any other piece of evidence in your supply chain.
These findings are AI-generated leads grounded in real history, not a guarantee of exploitability. They are meant to focus human review and downstream tooling on the highest-probability areas — not to replace triage.

​
Two Ways the Context Is Used

  • As evidence in its own right. The AI Security Context is a reviewable, signed record of a project’s security-fix history — useful for audits, security reviews, and tracking how a codebase’s risk profile changes over time.
  • As a seed for hunting. The same map drives the agent that looks for un-patched variants at HEAD, turning a backward-looking record into a forward-looking lead list.

​
In the Platform

The full artifact is stored in Chainloop’s evidence store. So the project Security tab can render without downloading the whole file, the backend also exposes a compact summary — class and severity distribution, peak severity, confirmed-fix count, and top risks — with links to deep-dive into the full material. The context is also queryable through Chainloop’s MCP tools, so an assistant can ask a project what it tends to get wrong.

​
Enable It

AI Code Analysis is a built-in workflow template, turned on per project like the other built-in scans. Chainloop runs it server-side in a managed sandbox against the repository connected to your project — no CI changes required. Enable it from the Create Project wizard or from a project’s workflow settings, and it needs a repository connected through a supported provider (GitHub or GitLab).

​
Further Reading