Why this matters
If you pick a scanner because of its Python score and point it at a TypeScript codebase, what should you expect? With nine scanners now covering both RealVuln corpora on identical prompts and harnesses, we can start to answer that with data rather than intuition. The short version: expect the same recall from the strong scanners, noticeably less from the mid-tier, and a lot more false positives from everyone — for a reason that says as much about TypeScript codebases as it does about the scanners.
What we did
We compared every scanner with full coverage of both languages on its Python tab and its TypeScript / JS tab, using the same strict F3 that ranks the leaderboard. Nothing about the scanners changed between the two runs except the code they were pointed at: same model, same prompt template with the file-listing wording swapped for the language, same effort setting where the model exposes one. Kolega DevSec Max, Daybreak Blue, GPT-5.6 Sol, GLM-5.3, GPT-6 Astra, Claude Sonnet 5, DeepSeek V4 Flash, DeepSeek V4 Pro and Semgrep are the nine.
What we observed
Precision falls for every LLM scanner, without exception. Kolega DevSec Max goes from 70.1% precision on Python to 44.5% on TS/JS; Daybreak Blue from 75.0% to 57.0%; Sol from 70.6% to 52.0%; GLM-5.3 from 59.7% to 35.3%; Astra from 57.2% to 38.6%; Sonnet 5 from 69.3% to 40.5%; DeepSeek V4 Flash from 77.5% to 41.6%; DeepSeek V4 Pro from 78.5% to 45.2%. In raw counts, false positives roughly double to quadruple: Kolega reports 721 on Python and 2,556 on TS/JS, Sol 624 and 1,558, Sonnet 5 434 and 1,147. Semgrep is the one scanner whose precision holds, at 12.9% and 11.0%, because it was already reporting almost entirely false positives on Python.
Recall splits the field. The three leaders hold or improve: Kolega 88.8% to 91.5%, Daybreak Blue 80.5% to 82.8%, and Astra — the one model whose F3 actually rises — 48.6% to 56.9%. Sol slips a little, 78.7% to 75.4%. The middle of the table drops hard: GLM-5.3 63.8% to 49.3%, Sonnet 5 51.5% to 34.8%, DeepSeek V4 Flash 49.9% to 32.8%, DeepSeek V4 Pro 48.3% to 26.3%. Semgrep's recall rises from 7.0% to 12.3%, which says more about its TS/JS rule set than about the corpus.
Put together, F3 moves the way you would expect from a recall-weighted metric. The leaders barely move: Kolega 86.4 to 82.7, Daybreak Blue 80.0 to 79.2, Sol 77.8 to 72.1. The mid-tier falls by 16 to 23 points: GLM-5.3 63.3 to 47.4, Sonnet 5 52.8 to 35.3, Flash 51.7 to 33.5, Pro 50.2 to 27.5. Astra rises, 49.4 to 54.3. F3 weights recall nine times over precision precisely so that a scanner is not punished into silence for being noisy; the precision collapse shows up in the numbers, but it does not decide the ranking.
Why we think that happened
The precision story has a simpler explanation than "LLMs are worse at TypeScript". The TS/JS corpus is 607,252 lines of code carrying 2,236 scoring vulnerabilities — about 3.7 per thousand lines. The Python corpus is 133,782 lines carrying 2,182 — about 16.3 per thousand. TypeScript applications in this benchmark are four and a half times sparser in real vulnerabilities than the Python ones, largely because so much of a modern web application is framework plumbing, typed models, and component markup that has no security-relevant behaviour at all.
The scanners did not become noisier per line of code. Kolega reports about 5.4 false positives per thousand lines on Python and 4.2 on TS/JS; Sol 4.7 and 2.6; Sonnet 5 3.2 and 1.9; DeepSeek V4 Pro 1.9 and 1.2; even Semgrep drops from 6.8 to 3.7. Every scanner is less noisy per line on TypeScript. But a scanner that keeps flagging at its usual per-line rate in a codebase with a quarter of the real vulnerabilities per line will see its precision fall by construction, because the denominator of precision is what it reported and the numerator is capped by what was actually there. That is a property of the corpus as much as of the scanner, and anyone comparing scanners across languages should expect it.
The recall drop in the mid-tier is the part we do not yet have a clean explanation for, and we are treating it as an open question rather than a finding. The candidates are the ones you would guess: more code per repository to read within a fixed budget, vulnerability patterns that are framework-specific and less represented in training data, and the split between server and client code. Only Astra bucks the trend, and one model rising is not a pattern.
What's next
Two things would sharpen this picture. False-positive traps for the TS/JS corpus would let us distinguish a scanner that flags safe code from one that flags code we simply have not labelled — today every unmatched TS/JS finding counts as a false positive, which is the conservative reading but not the only one. And more model families on both corpora would tell us whether the mid-tier recall drop is about those particular models or about TypeScript. Both are in progress. All figures here are from the frozen 3.0.0 release at realvuln.com/v/3.0.0/.