This is where large companies might trip and fall, if they expect their existing security analysts/teams to do this (or, as you say, if they try to offload it onto developers or ops people, even ones who are more interested in security). I don't like how this sounds, what I am about to type, but the majority of security people -- particularly the ones at the level where they are hired to run QA-type audits -- do not know how to review code. It really does make me uncomfortable to say this, but if that's the rock, the hard place is how many times I've had to tell someone they really need to learn to code if they want to "work in security."
So when you say, "good security people," what you mean is people who can read and write code, and also have enough experience to know when that code can be used in a way that the original author did not intend to. It's almost as if there's a misconception that being able to read and write code is what you do if you're a dev or devops. This mindset is odd to me in so many ways. It's like saying, "I don't need to know how to use a screwdriver or a hammer because I'm not a carpenter." Even better, someone who understands what it feels like to be under some pressure to roll out changes where there might not have been a lot of time to consider malicious behavior. Someone who has your back.
Just yesterday or the day before, I had this inexplicable crisis where I was concerned about the value I am providing. It's gone now. Thanks!