I'm one of the authors, a bit of context on what this actually was.
GlobaLeaks is one of the most heavily audited open-source projects out there: six independent reviews since 2013 (iSEC, Cure53, Least Authority, Subgraph, Radically Open Security, and us), and it had just been through an intensive hardening cycle, 183 commits in the month before the snapshot we read, including token hashing, full session-state resets on logout, and new audit logging. We looked at it close to its best-defended state on purpose. The question we cared about was how far a cheap, LLM-equipped reader gets against a hard target.
In code review, most of the cost is expert time: someone has to read everything, carefully, against every class of weakness. That reading is the part frontier models made cheap. The bugs were always sitting there; what changed is that turning them up no longer takes a specialist a month.
Rough economics: ~1.24B tokens, ~12,000 requests, ~$3,140 total model spend, ~$77 per confirmed finding before any human validation. 110 triaged records = 29 vulnerabilities, 12 DoS, 42 hardening notes, plus 27 retained non-findings (we left the discards in the report so you can see what got considered and dropped). Both High-severity findings sit in the same gap: holding a live session vs. actually owning the account.
A few things we're deliberately not claiming:
- The model didn't find anything on its own. Every candidate was a hypothesis until a human traced it through the source and reproduced it. Pulling 29 real bugs out of a much bigger pile of plausible-looking noise was where the work went.
- We had no human-only control group at the same time and budget, so we can't cleanly separate the model's contribution from reviewer skill and triage discipline.
- GlobaLeaks is public, so the models have almost certainly seen it and its prior audits in training. This shows what an attacker can do against a real target; it says much less about whether a model surfaces genuinely novel bugs on its own.
- An empty category doesn't mean the weakness isn't there. False negatives are entirely possible.
On disclosure: everything went to the project first, they ran a second triage, and the most critical items were fixed before we published. We didn't verify those fixes ourselves, the report describes the snapshot we reviewed rather than the current state of the code, so operators should track the project's own releases.
Happy to answer questions on the methodology (we used CWE-699 as a coverage scaffold and moved from component-focused prompts to category-driven, cross-file ones) or on any specific finding.