Can some infosec person speak to her strongest claim, that static analysis gives "basically 100% false positives" and wastes the team's time?
The statement itself is basically 98% false. I've been a Coverity user since very early days, and have used a few other static-analysis tools as well. Every such tool that I've seen runs multiple separate kinds of checks. Yes, the false positive rate for some of those checks can be alarmingly/annoyingly high. OTOH, any software developer with half a brain can see that other checks are much more accurate. Some are dar…
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.