DevOps is fundamentally about collaboration and agility. Unfortunately, when we add security and compliance to the picture, the message gets distorted.

The term “DevSecOps” has come into fashion the past few years with the intention of seamlessly integrating security and compliance into the DevOps framework. However, the reality is far from the ideal: Security tools have been bolted onto the existing DevOps process along with new layers of automation, and everyone’s calling it “DevSecOps.” This is a misguided approach that fails to embrace the principles of collaboration and agility.

In an ideal world, all developers would be trained and experienced in secure coding practices from front end to back end and be skilled in preventing everything from SQL injection to authorization framework exploits. Developers would also have all the information they need to make security-related decisions early in the design phase.

If a developer is working on a type of security control they haven’t worked on before, an organization should provide the appropriate training before there is a security issue.

Once again, the reality falls short of the ideal. While CI/CD automation has given developers ownership over the deployment of their code, those developers are still hampered by a lack of visibility into relevant information that would help them make better decisions before even sitting down to write code.

The entire concept of discovering and remediating vulnerabilities earlier in the development process is already, in some ways, out of date. A better approach is to provide developers with the information and training they need to prevent potential risks from becoming vulnerabilities in the first place.

Consider a developer that is assigned to add PII fields to an internet-facing API. The authorization controls in the cloud API gateway are critical to the security of the new feature. “Shifting left and extending right” doesn’t mean that a scanning tool or security architect should detect a security risk earlier in the process — it means that a developer should have all the context to prevent the vulnerability before it even happens. Continuous feedback is key to up-leveling the security knowledge of developers by orders of magnitude.