I’ve felt the pain myself. So I’m definitely in the sympathize camp.
Yeah, its a trade off.
We know developers are smarter than the analyzers. But rather than
developers working with the analyzers – like initializing a variable
even if it does not need to be done (and letting the optimizer do its
job) – they just dismiss all the results. They dismiss both the valid
ones and the noise. Its a very disingenuous strategy.
If you’re using cookie-based session storage with any version of the
Laravel Framework since 4.1 (inclusive), and you turned encryption off (I
can’t imagine why anyone would do that, but I’ve seen some weird setups),
you are vulnerable to PHP Object Injection.
Well, I can kinda sympathize. Somebody took one of my OSS projects
(p0f) and ran it through a static analyzer a while ago (the analyzer
shall remain nameless, but was one of the major ones). The results
were just pages and pages of nonsensical findings, interspersed with
non-specific style recommendations.
An experience like that can quickly divide developers into two camps:
the “not sure, but let me spend a week to address everything, just…
Yup. In addition to the crashes, I also sent them probably around
50-60 assert failures in debug builds, at their request. Most of them
are probably not security relevant, although it would be painful to
analyze them one by one. Nevertheless, the team is extremely
responsive (even over weekends :-).