You're absolutely right. The key idea that's badly needed here is to build secure systems by design, building in security-critical features and design aspects f

You're absolutely right. The key idea that's badly needed here is to build secure systems by design, building in security-critical features and design aspects from the start. As you correctly say, this is the best way to do this and addresses what the clients want - just get it done. Having personally experienced several different aspects of this process, I've found that it's almost always much easier said than done. It's been my experience that clients/executives don't just want things done. They want security, but without impacting product roadmaps, development timelines, or design choices. Engineering rarely appreciates someone else trying to tell them how to make design tradeoffs. Product wants security, but this commitment often wavers in the face of increased development time or an ongoing vulnerability management effort. There's a target date to hit, and maybe security isn't viewed as part of the MVP... can't things just be done when they're shipped to prod? How do I, or another security specialist, get leadership of other parts of the organization to enable me to take care of it without wasting everybody's time? Or anybody's time? Generally a lot of people skills, negotiation, and prioritization effort. Security work, no matter how integrated into the overall effort or DevSecOps the implementation, is never completely without cost. Again, you're completely correct. The best way to do what the client wants and just take care of things is to use systems thinking and merge security work into every part of the product lifecycle. Do you think it is perhaps possible that there might be a place for human-wrangling skills in the complex human-computer system that controls how software is developed?