I could keep going. All of these things could have some software engineering component, such as with identity management: there is a component there that deals with (for example) writing code to integrate your web app with multi-factor authentication, but identity management also encompasses things like writing good access control policies, managing the legal requirements for access, training people on how to use that multi-factor auth, etc.
Engineering skills are of course of great use if you are talking about the security of a specific codebase or doing penetration testing or doing the nitty-gritty customization of a security application, but "cybersecurity" is much more than that.
I know cybersec is extremely broad, but I think software engineering plays an extremely important role.
Speaking practically, the vast majority of companies that experience one of the vulnerabilities you are referencing are not going to be patching the code themselves - they're going to be updating their infrastructure with code that was written by someone else. And before they even get to that point, they are going to have to have policies/procedures that alert them of that vulnerability, that assess how important patching that vulnerability is, that determine cost of patching/not patching, that determine how to receive that patch, and that determine how to apply that patch. And all of those things involve much more than programming.
One of the other largest parts of defending a company from being hacked is training and protecting employees from social engineering/phishing attacks, and that's something that doesn't involve writing any code (or even knowledge of code) at all.
I didn't say there weren't?
> In my experience, the companies with the worst security are ones that primarily employ current or former software engineers as leaders of their security teams with a misguided mentality that security is just a subset of software engineering.
Wasn't what I was advocating for.
I'm advocating for learning security after you have a base of software development. Not leading a security team with no experience learning or practicing security. Also, this is a huge and growing field, so I'm speaking generally, but I'm sure there are sub-areas where there are counter examples.
Can you elaborate? I know a lot of security teams will have large amounts of machine data thrown into ELK or Splunk, but that seems like qualitative data and so there's not a lot of number-crunching to do.
Graph Analysis => Saw some guys turn the Android codebase into a graph and use that to turn a dozen minor exploits into a chain that gave them root. Pwn2own IIRC.
Statistics => Great for detecting anomalies / understanding how to evaluate manipulation of cyber adjacent systems. For example, understanding the beta distribution lets you figure out how someone will game ratings in your app store to beat out legitimate apps with similar sounding ones. And of course all of these things cut both ways: if you're on red team it helps you masquerade more effectively.
Recommenders => Obviously useful to understand from attack detection, spam filter evasion, etc.
Linguistic analysis => De-anon attackers by the language they use. Figure out automatically which email accounts have been owned by sudden changes in speech usage.