I think the impedance mismatch here might be that you're a software developer, and we're talking about security teams.

I don't know that anyone is arguing that static analysis is useless for developers. If you're intimately familiar with the code you're working on, there are probably a lot of ways to make static analysis results both valuable in every edit/compile/debug cycle, and an important part of your team's release process.

But when you're close to the code, it's easy to forget how much of the tool's output you're ignoring (either literally, by just skimming past findings you know don't matter, or implicitly, by configuring the tool to match your environment or subtly changing your coding style to conform to Coverity's expectations).

Security teams can't generally do this. They're stuck with the raw output of the barely-configured tool. The results of static analysis in these circumstances is nonsensical: memory leaks, uninitialized variables, race conditions, tainted inputs reaching SQL queries, improper cleanup of sensitive variables, 99.9% of which aren't valid findings, but all of which look super important, especially if you're consultant with 6 months of experience charging $150/hr to run Fortify on someone else's code, then petulantly demanding a response for every fucking issue the scanner generates.

They're fine dev tools, but they are terrible tools for adversarial inspection, which is what Davidson is talking about.