In many companies, security engineers are part of a different department compared to developers. The thought behind this separation is that it is beneficial to have some distance between those who are writing the code (that is, the developers) and those who are checking it.

In the past, the same separation often existed between software developers and software testers. However, recent insights have shown that putting developers and testers closer together does not result in unwanted behaviors such as group thinking, only testing what is already known to be working, or trying to cheat the tests by developing only for known test cases. Both experience and research show that the opposite is true. Putting developers and testers together results in products of higher quality. It is for this reason that movements such as Agile recommend development teams to incorporate, among other things, the discipline of testing.

It is by this same reasoning that the call for integrating security engineering into DevOps development teams is becoming louder. This movement is often called "DevSecOps" or "rugged DevOps." Both movements advocate that using DevOps principles such as shifting left and automating as much as possible can help to increase security. They advocate that pen tests or vulnerability reviews of applications are no longer done manually, but that they are fully automated as part of the delivery pipeline. This enables automation, faster feedback loops, and continuous delivery and deployment practices.

It is also advocated that shipping software more often can also help to increase security further, for the following reasons:

• When a reliable mechanism for shipping software automatically is available, any change that addresses a security risk can be deployed within minutes or days. Being able to react quickly to a new finding is a great security improvement.
• Speed itself can be a security measure. If the working of a system changes multiple times a day, it is significantly harder to figure out what its inner workings are at any given time and to misuse them.
• Applying the principle of immutable deployments and using infrastructure as code ensures that the infrastructure that is running an application is refreshed pretty often. This is a good mitigation of advanced persistent threats.

One of the things this chapter will explore is how to configure delivery pipelines to add security scanning. Please note that running these tools from a pipeline is a different discipline, which ensures that these tools are properly configured and apply the correct policies and requirements. For these activities, a security background and a close collaboration with security engineers are still essential. This is just another area where close collaboration can make a difference. Particularly on the subject of security, collaboration with other disciplines will be necessary; not to introduce manual checks, but to automate them together.