I'm going to disagree on the basis that segmenting your security personnel creates a lot of difficult social dynamics. However the model is structured, "securit

I'm going to disagree on the basis that segmenting your security personnel creates a lot of difficult social dynamics. However the model is structured, "security" becomes a pain point, and no one wants to see the security guy coming around the corner. The default interpretation (which is basically the only one that counts) is that this guy is coming around, tearing down _your_ work, and making you look bad in front of everyone, and what does he even know about this thing? Some people will chicken out, not press the matter, and then the "security people" are just the fall guys, unable to do anything other than take the blame for the other peoples' screw-ups. In my experience, a lot of internal security people end up stuck in that position whether they're trying to fight the good fight or not. The dynamic is similar to the corrosive POV that sees "dev" and "ops" as orthogonal concerns to segment out, and we all know how well that's gone over. Anyone looking forward to hearing all about "DevSec" in the next 10-15 years, once some startup finds a way to put a cute icon on it and gets a big pile of investor money to burn (cf. Docker)? Rather than create a tense segmentation, it's better to just hire competent developers who know security well from the get-go. Maybe they can rotate weeks doing security reviews or something like that. I don't know, I don't really have a good solution. I just know that making someone the enemy by labeling them "security personnel, here to block your deploys, tell you you're doing your job wrong, and generally just embarrass you in front of your peers and superiors" is not going to help much.