Replying to @elle@weathered-steel.social
@GrapheneOS to clarify the other methods I'm referring to are symbolic analysis, fuzzing, and static analysis tools.
I think this post from @david_chisnall puts it very well: https://infosec.exchange/@david_chisnall/117183568828323924
RE: https://beige.party/@gildilinie/117182364841041560
This is really key for a lot of ‘AI’ success stories. The baseline is always not trying a thing. It’s never trying a different technique and allocating the same amount of compute power specialised for the task to it.
Vulnerability discovery is like this. We currently limit static analysers for C/C++ to a single compilation unit because the memory and CPU requirements for that work on a laptop or cheap cloud VM, whereas doing cross-compilation-unit analysis can require hundreds of GiBs of RAM and many hours of CPU time. Yet, when people are talking about the LLMs doing vulnerability discovery, they’re comparing against the run-on-a-cheap-laptop version, not the costs-as-much-to-run-as-LLM-inference model.
If you were willing to throw a huge amount of compute at static analysis, then generate coverage points for the paths in the predicted bug and use guided fuzzing techniques to create a reduced test case, I suspect you’d get higher success rates than LLM-based approaches. But VCs are willing to throw tens of thousands of dollars of compute per bug at the LLM approach because it makes the companies that they’ve invested in look good.