DevSecOps is in its “awkward teenage years,” says Matt Rose, Global Director of Strategy at Checkmarx. But with new tooling and automation – particularly when it comes to application security testing (AST) tools - he sees the practice maturing quickly and delivering improved outcomes.
We sat down with Matt to discuss his reasoning for this viewpoint, while also diving into the state of DevSecOps, how development teams are hindered by lack of automation, and how AST tools, combined with automation, can lead to better results and a more robust software security program.
DevSecOps has had an awful lot of attention in recent times, particularly the last couple of years. If you were to take a step back, how would you describe today’s state of DevSecOps?
Matt: It’s really interesting to watch the evolution of DevOps, or DevSecOps, in that everybody has an initiative around DevOps, but that initiative is in different phases. Some are just in initial discussions. Some are more concrete. Some people feel that they’re fully baked in their DevOps program, which is a false sense of security, because the technologies and tooling associated with DevOps are still catching up to the speed.
And every six months, there’s a new type of technology or tooling that allows DevOps to work even more effectively. As we move forward, there’s going to be additional automation and integration points that allow DevOps to become more mainstream. We’re still in the awkward teenage years associated with DevOps, and a year or two from now, we’ll start to be more of the college student, a little more focused on our goals in life associated with software delivery.
How do you find that development teams today are hindered by a lack of automation?
Matt: If you go online to search for software development lifecycles, they’re often depicted as linear; they had a beginning and an end. With DevOps, its just a process, a living breathing thing that’s constantly evolving, and it’s usually depicted by an infinity loop or bow tie type graphic. And there are different phases. When it comes to modern DevOps programs, the thing that you need to think about is that there is typically something happening at each one of those phases, all the time.
The only way to keep pace with the speed of DevOps is by automating the tooling. DevOps is an overarching group of tools that are automated to work effectively in a repeatable process.
People often don’t even know what’s happening behind the curtain. They hit a button, and that’s the assembly line or the automation of putting together the 10,000-piece jigsaw puzzle that is your software. So, automation truly is paramount to the success of DevOps in order to maintain both speed and security.
Let’s talk about application security testing tools. How can those that leverage automation lead to better results?
Matt: Security technologies need to complement DevOps. They need to work the way DevOps works. As DevOps started to evolve, security technologies were still a little ‘old school’ in terms of implementation. We needed additional steps to configure a security scan; we needed out-of-band processes to allow for security to happen. So, from that standpoint, security technologies for proper automation need to be complementing DevOps, not the other way around.
Using pop culture references from the movie “Usual Suspects” and paraphrasing one of the famous lines from that movie: “The greatest trick the devil ever pulled was to make the world think he did not exist.” That’s what security technologies need to do. They need to be in the process, but you don’t even know they’re there. They’re just baked into the process. They just follow the same flow of execution as the normal tooling associated with building software.
What kind of improved outcomes can we achieve by automating the vulnerability detection and triage?
Matt: From an application security standpoint, the biggest thing is that automation identifies the risk. You automate static analysis, scanning of the source code. You automate testing of a running application, as well as the scanning of open source packages.
Automation is now very fluid and producing a lot of data. The goal of any application security program is remediation – not just the automation of the identification of results but also circling that back to the people that are responsible for the remediation. And that’s taking automation a step further to integrate with the defect tracking or bug reports that people are used to using.
Automation could produce more results that you need to be able to facilitate in an efficient way, not just say, “Hey, we scanned all our applications for security. We found all this stuff. Great.” No, that’s just the beginning of the equation, the beginning of the story. You need to automate all the way through the path, back to the development from remediation. And then you just mix, wash, repeat and start though the flow again.
Click here to read the full version of the eBook, and learn how Checkmarx helps organisations to address the risks associated with application security at different stages of DevOps.
