How continuous delivery can help organizations in their application security efforts
The old model of developing secure applications followed a structured, siloed, step-by-step process—build, check, release. Organizations’ desire for speed has forced development teams to ramp up their release cycles by any means necessary, even if it means bypassing incremental scanning for flaws that could increase application risk. This philosophy of rapid innovation also comes with increased risk exposure.
Security and development teams need to find ways to keep up with the rapid development life cycle without sacrificing security with every update. The continuous delivery model has transformed application development, but to last, it must also transform application security. It may take a little extra time and effort, but it is possible to develop efficiently and securely.
The key is to make sure that security and developer teams understand each other’s priorities and needs. As DevOps began to catch on, the immediate reaction for many organizations was to make their developer team into a jack-of-all-trades unit. This began by adding operationalization to the developer job description and has only grown from there. Soon after, security, testing and monitoring functions joined the list as well. Recruiting teams are now struggling to find people who are qualified for this multifaceted role.
Teams operating on a continuous delivery model need to find a middle ground between the developer solely focused on coding versus owning every step in the development process. Developers should be at the center of everything—keeping the priorities of each role in mind and making sure each is involved in the final product, but focusing on their main job of development.
This philosophy goes both ways. Security teams and other specialties can always learn more about the intricacies of the development process, which will enable them to better integrate their functions into a continuous delivery cycle without disrupting it.
One way to encourage a unified team, specifically in regards to security, is to appoint a security champion for each development team. These advocates should be developers who have a special interest in or affinity for security. Their role is not necessarily to know how to solve every application security problem that arises in the development process, but to ask the right questions about security and interface with security teams.
Roles such as this create firms links between the different functions of DevSecOps practices, making it easier to realize opportunities for improvement under the new continuous release model.
One small change that can make a big impact is realigning review processes for continuous delivery by reviewing only the pieces that have changed instead of the whole application. Under traditional, linear development cycles, each new release requires a full assessment even if much of the code remains unchanged from previous versions. Applying the continuous delivery mentality to security testing can streamline and reduce the burden on security teams. Each new piece of code deployed in continuous release models is faster to scan, which makes flaws easier to find and fix.
The assembly line model of application development is no longer feasible. If security teams wait for the application to be complete before fixing vulnerabilities, they will never be able to keep up with the pace innovation and competition demands. Making the most of continuous delivery requires constant communication and collaboration across the full DevSecOps spectrum, along with a shift in thinking that allows developer and security teams to use the process to their advantage.