DevSecOps (or rugged DevOps) is a new way to look at integrating security into the application development pipeline. Learn about what this means and what goals to have when integrating security into the DevOps environment.
- [Instructor] Now let's talk a little bit about DevSecOps and how to integrate security into the DevOps world. The definition of DevSecOps really is, how you take security and put it into the DevOps process? How do you merge the two together and still make sure that, from a security perspective, you have all the checkpoints that you need implemented. When you're developing a plan of how to do this, the goal really should be to, how can we make the dev teams have more ownership of the process? It's not all about automation, but it's about ownership and accountability, and how can we get the dev teams to take more of it? Integrating automation into every step of the process is going to be key.
One point I'd like to bring up is the distinction between the terms DevSecOps and Rugged DevOps. Many times they are used interchangeably, but there is a distinction. DevSecOps focuses on the whole development lifecycle and the security automation that supports it. Rugged DevOps is more specific to developers and supports developers doing extreme testing on their code to ensure it's protected once it's released to production. For the purposes of this course, we will focus more on DevSecOps. As with all of DevOps, automation is key to DevSecOps.
It's how you are going to be quick and agile and get away from all of the manual processes that you had. There's a good change that when you move over to DevSecOps, some of the tools that you've used for years with your existing process won't work. Even if you can automate the tools, the amount of false positives that come with them won't make them worthwhile in a DevOps pipeline. Everything has to happen quickly. So, with static scans it used to take hours, these won't work anymore and we really have to rethink how do we do it, how do we automate it, and what tools can we use? The automation of security tools doesn't mean automating pushing a button.
It doesn't mean taking your dynamic scanner and automating clicking of run scan. What automation means in security tool world is that you can put something in a script and have it run in the background and push meaningful results to your developers. Not a PDF, not a document, but actual results in the developers and the results should be pushed into a tool that they use, not a security tool that the security team uses, but something that is meaningful to them, like a JIRA or a quality center that they're in and out of all day long, that's meaningful to them, and that is real-time so that they can act on it.
And even taking that one step further, one of the best ways that you can enable the development team to have the results in real-time is through ChatOps, so instead of sending them PDFs, send them notifications via Slack or HipChat or some other immediate notification mechanism that they have to be able to act on the results quicker. And one of the more popular quotes that I've seen and that I really like is by Rod Michael and he says, "If you automate a mess, you get an automated mess." So, make sure that when you do your security automation, that you do it in a way that helps the developers, not hinders them, and provides them good results that they can act on.
The second part of DevOps I want to talk about is education. The developers need to be educated on the security basics. In the 15 years that I have been doing application security, I have seen the same security defects over and over and over again. SQL injection was a problem 15 years ago, SQL injection is a problem today, so helping the teams understand the security basics will really help to speed up the development process and the DevOps process by having them know upfront what they need to be coding for.
Ensure that they have the resources to be able to fix any defects that they may find. The idea here isn't that security is not going to play a part, but the idea is that we will give them the information that they need through training, through help, through conversations so that they can fix any of the defects that come to them. And just like with all of DevOps, the key to DevSecOps is to really let developers own their own security and be responsible for their security. The last point to be made for DevSecOps is that we need to empower the dev team.
Give them the tools, let them hold the tools, let them put them in their pipeline the way that they can use them. Put them in their Jenkins build or put them in their IDE so that when they're building an application, they can see the results in real time. Ultimately, they should be responsible for the security of the app, not the security team. The goal here really is to flip the security team to being an auditor and not a tester so that we make sure as a security team that the testing is done, but we aren't the ones actually doing the testing, that is the development team.