@wrl @lumi

It looks as if LLMs find a somewhat different (not fully distinct, but mostly non-overlapping) set of vulnerabilities to traditional semantics-based static analysers. They’re closer to the Coccinelle-like approach that does fuzzy pattern matching to find other instances of the same bug class, but with bigger fuzzy patterns.

The industry goes through these phases periodically. To my recollection, Coverity (and then other static analysers), address sanitiser (couldn’t find much that valgrind couldn’t have found but was much faster so easier to run at scale), and then fuzzing with sanitisers all came with a big flurry of bugs that they discovered, many of which were security critical.

None of these were a ‘vulnpocalypse’. People had to spend a lot of time triaging false positives but then integrated them into their flows. At least, the people who cared about correctness did. As you say, that is often not the case.

The thing that annoys me about the LLM tooling hype is the lack of a good baseline. It’s costing tens of thousands of dollars of compute with systems with hundreds of GiBs of (fast) memory. That’s enough to enable a bunch of the cross-compilation-unit static analysis modes in the clang analyser that never get turned on because they’re too memory-hungry. It’s enough to take the static analyser output, make each of the branch points in the suspect trace a coverage point, and then use a guided fuzzer to try to reach those points and provide a test case. I strongly suspect that this would work at least as well as LLM-based approaches per dollar of compute time. But no one cares enough to give away free compute time to an approach like this because ‘a bunch of existing well-known techniques can find security problems!’ doesn’t unlock VC funding.