[UncleMeat]

Static analysis as a bugfinding tool has proven to be insufficient, especially for large C++ binaries and JS programs. Both languages are nightmares for precise and scalable analysis.

Coverity exists. They've got a great product. But it doesn't solve the problem.

[pjmlp]

It doesn't solve everything, it solves even less when it isn't used.

[UncleMeat]

Of course. But these issues will remain near the top of the list indefinitely if people just leverage traditional analysis tools.

I love static analysis. I did my PhD in it. But we'll still be talking about use after free in 2073 if we just try to chase higher K in our analysis implementations.

[pjmlp]

Naturally static analysis alone doesn't fix use after free in all possible cases, however it already does fix several of them when the analyser can see everything on the existing source code.

The main issue is the community sub-culture of not adopting tooling as it isn't perfect 100% of the time.

Many of the C++ security conscious folks end up being polyglot, as this subculture eventually wears one out.

[UncleMeat]

Having spent well over a decade in this space, I assure you that the root cause of limitations for static analyzers doing lifetime analysis in C++ is not separate compilation or partial program analysis caused by shared libraries.

[pjmlp]

Naturally it isn't.

Again, even if not perfect, and doesn't cover all use cases, what about people would actually use something at all?

During that decade, how much time did you spent looking at the human side of the problem instead of what the tools can achive?

[UncleMeat]

Nowhere did I suggest that we shouldn’t use these tools or spend time improving them. UX for tools more powerful than local AST matching indeed tends to be quite bad because explaining the chain of reasoning for an alarm is difficult.

My only point is that without a different approach we will continue to have the same problems in 2073.