The security assessments that are often conducted at regular intervals in the pre-DevOps era cannot be just left out when moving to a DevOps culture. This means that, instead of leaving them out, they must be conducted in some other way. There are two approaches for doing this.

The first approach is to keep doing pen tests, security reviews, and other security inspections at regular intervals just as before. However, instead of waiting for an OK from the tests before moving to production, the code is deployed to production separate from the security assessment(s). This implies that there is an accepted risk that there might be vulnerabilities shipped to production that are found only during the next security scan and will be addressed in the next release. Using this approach, it is possible to achieve speed, but then it also needs to be accepted that some vulnerabilities might exist for a while.

The second approach relies on making application security scanning part of the regular workflow for committing code to the source code repository. For example, security code reviews do not have to be done per increment or every two months. They can also be done per pull request—before the code gets merged. Now, all of a sudden, you are no longer detecting vulnerabilities but are instead preventing them. The same can be done with security vulnerability scans. They can become part of the delivery pipeline, or a full nightly QA build that reports back on the quality of development every morning.

Of course, it is often not as black and white, and many companies use a combination of these approaches. They use automated feedback mechanisms to detect whatever they can, make security code reviews part of the pull request workflow, and then combine this with manual pen testing at regular intervals. In this way, the speed of delivery is increased, while there is no increase or even a decrease in security risks, the last being the consequence of the speed at which vulnerabilities can be mitigated.