[TobyTheDog123]

Definitely totally 100% unrelated, but do people notice that their security teams often focus on minuscule unlikely scenarios instead of potentially-company-ending bugs and exploits?

Things like your MacOS install being on 12.3.1 instead of 12.3.2, blindly listing off AWS/GCP recommendations without any consideration to how the service is implemented and/or how the infrastructure is used, or making engineering teams jump through seventeen hoops to deprecate an endpoint..... all while there's like a SQL injection in the primary public-facing customer API or something.

[staunton]

Security teams focus on requirements and objectives which are set by far removed entities and at vastly different generality and abstraction levels, often with objectives other than "make sure we and our customers don't get hacked", such as limiting legal liability and navigating a complex landscape of regulation and best-practice recommendations, ignoring which can also lead to legal liability. It should be no surprise that these have little overlap with actual security problems arising in their particular context.

A good security team will manage to find the time to also identify and address the actual concrete security issues.

[vasco]

Yes same issue in all my jobs. I've found that security and compliance standards for technology companies are created and maintained by accountants, not engineers. In a way this is good because if the engineers fix "the real issues" and the accountants focus on the "generic list that doesn't matter", you still end up catching some different things. Problem is the amount of fake work, as well as slowdowns created in exchange for no extra security.

[klooney]

Well, comparing version numbers is easy, and analyzing code is hard, so...

[deely3]

We have to have some level of trust. Otherwise we will need to manually and personally verify each line of each software that we use. And unfortunately this is impossible.