If you have worked in security as long as I have, you have seen that vulnerabilities persist, despite years of attempts to fix them without changing how the organization operates. One of my all-time favorite leadership quotes comes from the first stockholder meeting after Robert Iger, the CEO of Disney, bought Pixar. “The riskiest thing we can do is just maintain the status quo,” he said. This quote has stuck with me and I feel that the shift to DevSecOps can be many teams’ “Pixar moment.”
In recent years, there has been a push to shift to a DevSecOps model that has the potential to make a drastic change in the way an organization operates. But unless these shifts are planned well, they often fall apart without having made a meaningful impact.
The root cause is often the inability or unwillingness to do the in-depth planning and testing required to make sure everything will move to a DevSecOps smoothly. The failure to plan leads to underwhelming returns and low morale with the organization will slowly slide back to the old “status quo.”
Moving to DevSecOps is often more about changing an organization’s cultural identity than any technical changes. I’ve have seen it happen successfully in several places. Here’s what they had in common:
They Defined, Discussed and Documented the Old and New Build Process
A successful move to an end-to-end CI/CD system normally starts with one thing: a whiteboard. Organizations bring representatives from every existing team (systems, networking, security, development) to form the new DevSecOps team and build an end-to-end diagram of what it takes to build and maintain the system immediately. For many, this meeting is often the first time they have seen a true end-to-end view of the system.
Then the new team commits resources to discuss the standards and policies they need and want the new system to be built to. They discuss methodologies, deployment schedules, SLAs, business requirements and overall system architecture and security. This is where the team must come to an agreement on the right way to build and where the security team is likely to see their first big win on improving the “status quo.”
This round ends with something that no one on the new team will likely enjoy, but is crucial to the shift moving forward: a document of all of the decisions made that can be easily shared within their organization.
They Built a Strong Team and Platform
The next step is normally everyone’s favorite part—at least at the start. The team gets to walk into a greenfield environment and move one application to their new DevSecOps flow. Essentially, each team member has the opportunity to bring their ideas and thoughts about modern security, architecture and deployment processes and see if they can apply them. However, the honeymoon period of this process often ends quickly and becomes the most challenging segment of the whole process. The switch from theory to practice isn’t as clear as many DevSecOps teams think, and it’s common for teams to struggle while working with new products with which they likely have not had much organizational experience.
Buy-in from leadership is critically important here and without it, these projects can quickly go awry. I have heard executives complain that their DevSecOps team is “just playing around,” “wasting company resources” or “learning skills that will just let them get a better job somewhere” when a new system seems to take longer to be built than originally expected. Supporting this team throughout the build process is one of the most important leadership roles in a move to DevSecOps and plays a crucial part in aiding this team and reinforcing its culture within your company.
Continual Incremental Improvements
Once you have your first DevSecOps flow created, it is important to remember that you are not done, as you would be in a traditional build model. Of course, you want to celebrate this success, but you also need to start answering these questions:
- What can we do to increase the deployment frequency and speed?
- Can we do anything to lower the failure rate of the new releases?
- Are there any steps that could be more automated?
If you continually ask and answer these questions, you will never be done, but you will continue to make incremental improvements that will help your organization become more agile over time.
Rinse and Repeat
Once you have built your first DevSecOps workflow, you now have a good baseline on what to do (and not to do) when you move your next application to this model. Hopefully, you’ll be ready to move the DevSecOp culture that has taken hold in your organization to the next team.