Most discussions of DevSecOps include automation as a major component. In fact, Julien Vehent, Firefox’s Operations Security lead, defines DevOps this way in his book “Securing DevOps”:
“DevOps is the process of continuously improving software products through rapid release cycles, global automation of integration and delivery pipelines, and close collaboration between teams.”
He goes on to explain how moving from DevOps to DevSecOps integrates security into the design of all aspects of the DevOps pipeline. Automation is just as important in DevSecOps as it is in a DevOps environment, but it must be validated. The idea is that automation isn’t bad, but it also isn’t always good.
Teams that move from legacy software development and deployment processes toward DevSecOps often look to automation for its ability to remove mundane tasks from overworked personnel. While automation can carry out tasks reliably and without much human interaction, it won’t solve most process problems. Organizations can’t just automate bad processes and expect that problems will go away. The only way automation will benefit your team is when you automate verified and trusted procedures.
Let’s look at how automation is used in DevSecOps and how to implement automation without creating problems at a higher frequency than before.
Automation’s place in DevSecOps
Automation is a basic feature of DevOps, and it’s enjoying even greater prominence as more and more development organizations include security to form DevSecSops teams.
Automation can help streamline processes and workflows in today’s software development lifecycle (SDLC). Historically, promoting code through the SDLC workflow involved many manual steps. Developers had to notify someone when they finished modifying code. That code had to be reviewed and then retagged to move to the next step in the process. Many steps were (and in many teams still are) manual. Humans had to review, approve and take some action to promote code to the next step in the workflow.
Informal and manual workflows slowed down software development and made recreating success harder. A first step toward streamlining the whole SDLC was to impose standards. Although resistant at first, most software developers soon realized that coding standards, formal reviews, configuration management and process control aligned the SDLC with organizational goals and reduced rework. Streamlining may reduce some artistic expression, but it results in higher quality software.
As processes — especially code transitions from step to step in a workflow — became more standardized, the inevitable question arose: “Can we automate the boring stuff?”
Automation’s place in DevOps and DevSecOps is to help minimize delays by removing as many zero-velocity transitions as possible. Any time a step in a workflow has to stop and wait for a decision, that process screeches to a halt (zero velocity) until that decision is made. Replacing decision-making stoppages with autonomous algorithms is the main purpose of automation. In other words, making as many automated decisions as possible speeds up workflows. The only time a process should have to stop is in the case of some anomaly that truly requires human interaction to make a decision.
As DevOps grew into DevSecOps, the reliance on automation grew. Both types of team incorporate automated testing at multiple levels to avoid delays of manual testing. Developing functional, integration and security tests (and more types) throughout the SDLC takes more design and development time, but it increases quality and reduces implementation problems. In short, automation is a cornerstone of today’s SDLC.
Automation offers speed, not quality
Despite the previous section’s glowing description of automation, automation for the sake of automation doesn’t solve all SDLC problems. Automating a process increases the speed of that process, not its quality. That statement may seem contradictory to what you’ve heard, but automating a bad habit just helps you encounter problems faster.
Many people look at automation as being “on autopilot.” That’s a pretty good analogy, because autopilot is a feature most pilots use to reduce workload and increase safety during flight. The most common use of autopilot is after takeoff and before landing. (Yes, there are aircraft that use automation on takeoff and landing, but we’ll focus on the more common use of in-flight autopilot.)
Using an autopilot isn’t as easy as just flipping a switch. You have to provide some rules for the autopilot to follow. Depending on the autopilot’s sophistication, it may merely hold altitude or heading, or it may follow a flight plan to a destination. Regardless, the autopilot will only do what you tell it to do. If you tell it to fly straight and there happens to be a thunderstorm in your path, you may not have a good day. The key to a pleasant landing is to plan your flight, program the autopilot to do what you want, use it, and then know when to intervene if things go awry.
DevSecOps is really no different. Relying on automation can be a great benefit if you understand what automation can and cannot do for you. Just as an autopilot takes your plane where you tell it to go, automation will carry out any instructions you provide.
The main problem is that most automation techniques can’t refuse to carry out tasks that don’t make sense. They’ll just do what they’ve been told. Whether your automation involves simple shell scripts, custom-written programs, external APIs or automation suites like Jenkins, they’ll only carry out the instructions you give them.
Before you automate what you’re doing, see if it makes sense now. If a process is currently problematic, automation won’t make it better.
Process design matters
The moral of this story is that process design determines how well automation will work. Automation helps speed up and standardize processes, but it doesn’t address the process’s underlying quality. Automation just makes poor processes faster. In fact, automation removes human intuition from the equation. That means if your process depends on a human to detect and correct errors, that process may not be a candidate for automation. At least, not yet.
Automation can’t create quality. It can only provide speed and easy repeatability.
The real key to implementing automation well is to identify key transitions in your workflow and carefully articulate transition rules. When you can clearly document all the expected input to any process and the responses to all input, you’re ready to consider automating that process.
You don’t have to automate all input; some input values may still require human interaction. For example, if your promotion process encounters a strange multi-level version dependency exception that can’t easily be resolved automatically, flag it as an anomaly and let a human deal with it. Hopefully, such outliers are the exception and most of your code still gets promoted automatically.
Process design is more important in DevSecOps than ever. The need for automation to grease the wheels of the SDLC workflow requires reliable processes. Don’t automate bad habits. They’ll cause you grief and make your whole approach to DevSecOps look questionable. Plan well. Use automation well. And fly well.
