CodeCrucible: A blueprint for LLM-driven SAST

Clinton Carpene, Alex Rosenzweig and Andrew Kitis on the design decisions behind CodeCrucible, Block’s open-source LLM-driven SAST tool. The post is deliberately written as a blueprint rather than a product pitch:

The version you should build will not look exactly like ours and that’s the point.

The central bet is whole-repo concatenation: flatten the whole codebase into one model call rather than feeding the model snippets that a rule engine has already picked out. Their argument against retrieval is that snippet-anchored systems only show the model what the upstream engine already knows to look at. If no rule fires, the LLM never sees the code. They also think the field underrates how much context modern models can hold, noting that a 200K-token window on a 50K-token repository is well inside its comfort range, and that code compresses far better than the prose RAG systems were tuned for. Chunking is only a fallback, and when it happens it keeps file boundaries and imported files together rather than slicing to fit a token ceiling.

The rest works through the other three questions: how to identify vulnerabilities (open-ended prompting versus CWE-specific passes), how to screen real findings from hallucinations, and how to force determinism out of a nondeterministic model with JSON Schema constraints and repair tiers. The line justifying that last effort is a scanner is only useful if people trust it enough to keep it turned on.

The worked example is CVE-2026-31431 in the Linux kernel crypto subsystem, where the tool flagged that AF_ALG accepts read-only pages into TX scatterlists without validating writability. It ran in seven minutes for about $9 of tokens, at 78% confidence, but it did not get the whole exploit chain: it missed the exploitable sink and the 4-byte write primitive. A partial hit on a hard target, not a clean win. Compare Ramp’s more aggressive pipeline in ~100 security issues in 6 days.