@0xabad1dea Just before they did the ‘security’ stuff, someone sent me a ‘comprehensive code review’ of one of my projects. Most of the performance things were lifted directly from open issues I’d written, but one that it flagged as high importance was an intentional design decision.
It pointed out that one operation does a broadcast cache invalidation that invalidates all caches, rather than the subset that it actually needs to. The recommendation was to switch to having fine-grained cache state tracking. The problem is, that actually made cache accesses more expensive on the most performance-critical path in the system. Cache invalidations happened less than once every million accesses in typical programs, so this was an incredibly unusual case and optimising for it hurt performance everywhere else.
But, because it didn’t actually understand the code or the context, it saw a pattern that was slow and matched it to a high-severity warning.
I would expect it to do exactly the same thing with security reports. Memory-safety bug in a code path that can be reached only via trusted data? Highest severity!