The software development life cycle (SDLC) is a common sight for those who work on software projects. Whether you’re a developer or a security engineer or even a project manager or QA tester, you know all of the pieces by heart.
You begin by creating requirements so you know what the software should do. Then you develop the software, test it to make sure it meets the requirements, then deploy it. As users are using it, you receive feedback by automated and manual systems that can feedback into requirements and the cycle begins anew. In an agile environment, these things can all happen in small chunks for each user story, but the workflow remains in some capacity no matter what methodology you use.
There has been an industry push to add security to this life cycle. Recent security breaches have executives and developers alike nervous at the thought of being the next company hit. This has given rise to “DevSecOps” and “Rugged DevOps,” which aim to make security a core piece of the development puzzle. Automation of exciting new security tools into the development pipeline help developers find vulnerabilities and fix them before the deployment phase. These techniques are a great step forward.
But are tools enough?
Security tools have a built-in weakness in practice. They are reactive. You try to find what security vulnerabilities have already been introduced so you can chase down the development team to fix it. You’re playing catch-up constantly.
There is one tool that prevents security vulnerabilities instead of finding them after the fact: training.
Good training means the developers don’t write the insecure code in the first place. They know what security vulnerabilities are common and how to prevent them. Developers can spot the places in the code where security problems crop up and they know how to write them properly. They know how to design the system securely before any code is written. Training is valuable.
However, traditional methods of training don’t really mesh well with agile and DevOps environments. When and how do you do training? Is it when the developers want it? Do you train everyone when a project kicks off and then expect them to remember everything in the training for the next year or two until they move off the project? Does every developer get trained once per year with a week-long classroom training or awareness program?
DevOps environments don’t take well to stopping everything so the developers can go to training for a week or two. The business won’t appreciate that either. Features still need to be built and delivered while the developers continue to learn.
Training developers once per year also assumes they’ll remember what was in the training. They’ll forget most of it before they’ll ever actually need in in their day-to-day work. So we need frequency of training without getting in the way of the developers.
Training that works in a DevOps world
At times the training question may seem as unsolvable as P vs NP. But there is a way to train your developers in a way that won’t interfere with their work or slow down delivery. In fact, this training method will provide more secure software at the speed of delivery.
Continuous delivery is a software development practice in which program features are deployed as they are made. There are automated tests that run against the software and if they pass, the software is deployed for use. Training can be continuous as well. It’s possible to have training that is always on, always available, and ready when the developers need it.
Developers tend to learn best using just-in-time training. In other words, they encounter a problem, search for a solution, and learn how to be a better developer through the solution to the problem. Each new problem is an opportunity to learn something new. This style of learning is in contrast to traditional methods of sitting in a room for a week and cramming everything they need to know about a topic into their brains.
A developer introduces a security bug into an application through their code. That code is scanned by an automated tool or looked at by a human and the security bug is found. Typically, a ticket is created in a project management system explaining how to fix the security bug and then it’s assigned to the developer to work on. In a continuous training environment, a link to an interactive training lab is included in that ticket. The developer clicks the link and learns how the bug was introduced, why it’s dangerous (by exploiting it within the lab environment), and how to fix it. The developer completes a short, specific training lab for that one vulnerability instead of spending a day in a classroom. Once done, the developer doesn’t just fix the security bug. He learns why it is a problem and how to prevent it from happening again.
This method of training allows developers to keep working while steadily reducing the number of defects in an application over time.
Security training’s place in the SDLC
The SDLC is often portrayed as a cycle, as it is above. When training is added, however, we don’t want to squeeze it into the cycle to make it look like a concrete step in a sequence. Instead, think of the software development process as a set of gears. These gears are constantly in motion and work together to run the “machine” that makes great software.
Security training is the large gear that forms the foundation of every developer’s code and starts the process moving. The developer applies the training and turns the gear of the SDLC and leads to great, and secure, software.
The training gear should never stop moving, otherwise, the SDLC stops. No developer ever stops learning. But the SDLC gear doesn’t have to stop in order for the training gear to move. They move in concert. Similarly, your security training should work with your SDLC and not against it. Pick a training method that provides training to your developers when they need it.
On-demand. Just-in-time. Doesn’t get in the way.
This is the training that the SDLC is based on in today’s DevOps world. So get rid of the cycle of concrete steps and start shifting into gear. That’s how your developers will learn in the brave new world of DevSecOps.
Veracode's Security Labs provides such a continuous training environment. If you’d like to learn more, get in touch with us.
