What is DevSecOps
Not too long ago, application security was the sole responsibility of the security team. It typically integrated at the end of the software development lifecycle (SDLC), being more of a burden and a slowing stage to the process. At most times, the long security review only created tension between the security and the software development teams, slowing down the software release process, adding unnecessary changes to the software after development has already been concluded.
In recent years,a new term has been coined - DevSecOps. It stands for Development, Security and Operations, and comes to address these concerns, to allow a swift, agile and most importan secured software development lifecycle.
In this article I will list the core principals of DevSecOps and how it can not only dramatically improve the agility of the software development lifecycle but also the security posture of the application.
The DevSecOps Culture
DevSecOps is first and foremost a culture that should be assimilated throughout the organization. This is often times achieved by appointing Security Champions in the different teams. Security Champions are responsible for the overall application security aspects within the team. They will integrate the relevant security testing tools into the development pipeline, and make sure other members of the team follow the DevSecOps practices. They will push security agendas into the team's backlog, be it an integration of a new security tool or a triage of vulnerabilities discovered by these tools.
On top of security champions, there is a need to raise awareness among development and QA teams. It has to be always in mind, at every stage of the software development lifecycle, from inception and design, through implementation and testing, and all the way to production. For years security was left out of the software development world, being someone else's problem. But with DevSecOps, security has to be a shared responsibility. For that purpose, security awareness and secure coding training is required to help development teams pay better attention to security issues while developing the application.
Shared Responsibility
DevSecOps promotes the shared responsibility of developers, devops and security teams on all security aspects. Application security is no longer bounded to the security team. Instead, it spans throughout the software development lifecycle, and all parties take part in it, from inception to design, development, testing, and deployment. It is an ongoing, continuous effort, and not a one time event at the end of development cycle.
The ownership on application security is now on the software development team, in a perception that the development team owns the application end to end, from planning to production deployment and maintenance. Devops and security teams serve as facilitators, defining the secured development pipeline, and assisting with security training, automation, and inspection. To enable the shared responsibility model, collaborative security tools, such as code and vulnerability scanners, are put in place across the CI/CD pipeline, to provide clear visibility to everyone involved, and allow a short feedback loop for the teams to triage security issues as they pop up, when it is easy to fix them.
Security Automation
With DevSecOps security has to be automated throughout the software development lifecycle. Nowadays, when development cycles are getting shorter, and deployments become continuous, application security must not slow down the development lifecycle. It has to keep up with the fast pace of the development lifecycle. Automated security tools should be integrated into the development pipeline, starting at the Integrated Development Environment (IDE), and continuing throughout the CI/CD pipeline, serving as security gates, providing feedback to the relevant stakeholders, be it developers, devops, or security engineers. These tools, such as vulnerability scanners, static code analysers and other automated security testing tools are helping development teams to respond quickly to security issues just as they are introduced into the application, making the triage and remediation easier and less costly. But also, security automation can prevent deployment of vulnerable applications, or even a merge of vulnerable code into the codebase.
With security automation we make security built in the SDLC. We can keep security standards and meet for application security KPIs continuously, seamlessly and with less room for human errors.
What's Next
Adopting DevSecOps is not a one time effort. It isn't a framework you put in place once, and enjoy its fruits from that moment onwards. It is an ongoing continuous effort that involves various different functions across the organization. It requires sponsorship from higher management, but also to have lower management onboard so that everyone will see themselves as part of the effort - developers, testers, operations and security teams. Making a cultural change is by no mean an easy task, but once you have succeeded making it, you will see a significant improvement in both the agility of your teams, their velocity, and of course the security posture of your application.