| In this longer blog post, I go over how I’ve finally come to think about what DevSecOps is.A summary of what the post covers: 1. A secure software supply chain – This is a fancy way of saying “we know all the components that went into building and deploying this software and trust those components.” It also includes the actual CI/CD pipeline that you trust and that’s resistant to third parties including malicious code, as we’ve seen happen in recent years. 2. Improved culture and collaboration – Increasing collaboration and understanding between developers and security staff. As with many governance practices, with security, the governed (developers) and the governors (security staff) usually have an antagonistic relationship. Developers see security as unstoppable masters of “no,” and security people see developers as clueless coders. Well, that relationship isn’t helpful! As with DevOps, transforming “culture” to be more helpful is part of DevSecOps. 3. Automation and guardrails – Automating security policy enforcement, and providing defaults and templates to make it as easy as possible for developers to write secure code and applications configuration from the start. Historically, verifying that developers are writing secure code has been a manual, error-prone process. Much of this can be automated now with good platforms. Read the rest! |
Coté 