Is security in DevOps a necessary evil?

As more organizations move to establish DevOps techniques into their Software Development Life Cycle, the need of security becomes even more evident when so much application development is going on. But…

Security and DevOps aren't natural companions

The idea of security in DevOps or DevSecOps doesn’t go very well with classic DevOps process that insists on continuous integration, delivery, and deployment. When at production you're constantly releasing smaller bits of your code and application using DevOps pipeline, introducing security to DevOps can slow down the process significantly. You can't just pass that through a security team that takes several weeks bringing the new release out to production.

It is against the very idea of continuous integration and delivery and lengthens DevOps pipeline. Before DevOps took off, we had six month or three months release cycles. Security team would come in at the end of the release cycle to review the application, run their scanners, and approve and certify that release.

DevSecOps is a necessary evil

Now that DevOps has taken off and DevOps teams are introducing new releases every week, day, and even hour in some cases, the security team can't just do the same reviews they did twice a year every day.

In a nutshell, the entire model, especially how the security teams engage with the development teams, has to change.

Shifting security 'left'

In DevOps, we often talk about shifting ‘testing’ left in the pipeline and doing it at each commit rather than per release. Security teams can implement the same philosophy in case of security in DevOps. Rather than doing security checks per release, they can do it per commit and build up a security pipeline.

The security team that would usually review and certify each release; they're not looking at every release or every change instead they care about the pipeline. The developers can build security checks, analyzers, and other measures ‘left’ into the pipeline. The security team trusts the pipeline as long as they can ensure that those measures are in place, they are working, and they can audit and review them anytime they want.

Concisely, the security team with DevOps team can build a series of security checks ‘left’ of the pipeline to automate majority of security tests and make them run very early on in the development process.

For instance, developers can build all sorts of functional tests into the pipeline. Security team can audit those tests to ensure applications and people can sign in and out properly and the platform is secure.

In addition, DevOps team can write tests to learn more about known vulnerabilities and shortcomings. Security team can run a quick audit to detect the tests can log weak ciphers and security misconfigurations.

The ‘shift left’ methodology and a bunch of security tools can also automate penetration tests for them allowing security team to check the integrity of the application and the operating system against various types of attack.

DevSecOps presents business opportunities

In DevOps code is constantly generated, integrated, and tested before being deployed to the central repository alongside everybody else’s code and moved to production. With so much already going in the DevOps space, shifting security checks ‘left’ into the pipeline presents unparalleled opportunities. DevSecOps or Secure DevOps is all about making the most of these opportunities to accelerate SDLCs, shorten deadlines, lower business costs, improve application security and bring more automation.