Application security, or AppSec, is hard. For development teams, it often comes into development late in a release cycle and demands changes to the software that seem unreasonable. For the AppSec team, being introduced to a project after the application has been designed and much of the code has been written means there will be a lot of code and configuration to go through, and a lot of issues to find and analyze.
The more established a product is when it is first audited for security, the harder it will be to find the time to fix problems and to refactor the software. This means that many products get put into production with known security defects in them.
DevSecOps was created in order to get AppSec practices into the development process as early as possible, with the goal of making AppSec practices easier and cheaper so that we can use them from the beginning of a project.
DevSecOps changes the application security value proposition by leveraging DevOps principles to shift security practices left by automating the collection of security-related data. The application security practices have been around for a while; the innovation of DevSecOps is incorporating security into the daily workflow of the team, rather than leaving them to the end of a release, like many legacy processes do.
Shifting security left is made possible by the ability to automate many aspects of security testing and verification. DevSecOps leverages DevOps practices to make application security a first-class citizen in the practices of modern software development. It all starts with a culture change of cross-functional teams creating software through collaboration and fast feedback cycles.
The security in DevSecOps starts before the code is written by using techniques like threat modeling and risk analysis to help figure out who might want to attack you and how they might do that. This often-ignored tactic can be enabled by following the DevSecOps practices of having a cross-functional team involved in the process from the beginning, including security professionals.
Next, DevSecOps maps application security practices into the build pipeline for a project in order to provide quick feedback about the security posture for any change made to the software.
By using automation to allow the team to move quickly while maintaining confidence in the health of the code base, DevSecOps extends that health check to include application security checks. These security checks can be used as DevOps quality gates that fail a build if certain thresholds are crossed, such as too many new critical security findings in the codebase or the inclusion of a library with a known security vulnerability.
While automation can be used to make security data collection easier, it is important to understand what security practices still require human beings. Humans need to take the data collected by the automation and decide what it means and how best to mitigate any issues in the software.
Just like in DevOps, DevSecOps allows computers to do what they do best: run repetitive tasks in the same manner as many times as needed. It also allows people to do what they do best: design the software and security systems of the software.
Originally published on TechWell Insights.
