Testing: the security team run a few ad hoc tests, or only run the app team's automated security tests, or not at all.
Models: Once I built a threat model interactively with a security team member, but most times they'd ask the app team to put it together and send it to them. Usually would be reviewed with a few questions.
Paperwork: most of the is spent filling out forms, looking at automated tool results and addressing as needed, providing spreadsheets with new features or changes and their security requirements.
Code analysis: I don't think I've ever had a security team member read source code. Maybe I'm not remembering, but I genuinely can't think of one. I would love to have this happen though.
So, I guess I haven't had a good experience with security teams overall. I don't generally attribute that to the team itself though. They're often way over taxed and trying to oversee upwards of 10 projects with tons of reporting requirements and deadlines for releases. There's really no way in their structure or funding they _could_ do more than this. It's kinda amazing they even get this much stuff done now that I think about it! But yeah, I've never had an experience like you describe.
I left security a few years ago because I saw the industry turning to shit. It's gotten worse since then, IMO.
What I see as the contributors to this, in no particular order:
- Computer security is growing much, much faster than software in general. This has attracted a lot of snake-oil salespeople, bullshit artists, and gold-rush types.
- The genuine security talent pool is very small, and not growing nearly fast enough to meet the genuine need. A lot of organizations end up staffing their security teams with incompetents because their only other option is not hiring anyone at all.
- Security education, training, and mindsets all seem stuck in the '00s. People who make the effort to learn about security end up learning a bunch of stuff that's simply not applicable to modern software, and they miss a bunch of stuff that turns out to be really important.
I can go on.
Even with this, they should be having a conversation with the dev team to understand the intricacies and to double check that the documentation matches the current system (can't tell you how often old docs are used and were missing something).
The issue with security is there is literally unlimited work and only a certain amount of budget to work through it. So CISOs are constantly looking for tools to automate or reduce the dependence on people and to be frank, they are all pretty shitty. Then what happens is the CISO has blown his budget on tools that supposedly automate all this work and designed his program so they don't need "rockstars", because they are expensive (aka people who know what they are doing).
Whats happening right now is that the only companies that can afford or attract competent people in the industry are large tech companies (and even some of those have incompetent leadership and can't attract decent people). Really good security people are basically consolidating at a few dozen companies and are kind of handcuffed there because other places are terrible to work at/don't pay as well.
So basically you see this massive delta between the people who know what they are doing and the ones who have gotten into the industry in the last 3-5 years. One of the massive downsides to this consolidation is the places that are willing to hire early in career positions don't have experienced staff to mentor these new folks. And since there aren't good mentors, people aren't picking up the skills you would want/expect from them.
Those automated tools are better than ever. Manual code reviews are very important, but automated tools at this point can stand in for "over the fence" pre-production code reviews, as long as periodic reviews occur. In particularly sensitive contexts, especially finance, code is always signed off on by security before release when it can have impact on anything important. It's all about risk management.
Additionally, the cloud and SaaS is nothing like it was a decade ago. Security is now more focused on compliance due to the nature of building software today. You used to maybe provision a handful of nodes on EC2, use an autoscaling group if you were super fancy, and probably integrate into a handful of third party APIs. Every business is different, but that was the core of running a workload. Now, I can delegate specific responsibilities to third parties and reduce both people and operating costs. But with that comes massive risk since you just transferred an internal business function to a third party you have no control over. The most common approach to that risk is through process: vendor reviews, compliance and cloud posture security management.
And then there's DevOps who ends up being ad-hoc security way too often with no relevant background (or interest).
All that to say, good, compassionate security teams do exist.
Also, this isn't really new. When I worked as a more Junior person about a decade ago, lots of decisions came down to what was cheaper or faster, not what was secure.
To have good security, it's a cultural and organizational thing where the people at the top have to be on board.
The latest though... just good at creating documents, because he came from government background and all they care about is checking boxes. An absolute wizard at absolving himself of responsibility, very jealous.