The changing landscape of DevSecOps part 1: tools and integration
Share on socials
The changing landscape of DevSecOps part 1: tools and integration
Jobin Kuruvilla
17 May 2023
7 min read
Jobin Kuruvilla
17 May 2023
7 min read
Shifting left to embed security practices earlier in the software development process is a hot topic, with no sign of cooling down. But what are some of the challenges organisations are facing when it comes to implementation? Is DevSecOps just for the cloud or is it happening on-prem as well? What tools support testing? And are integrations becoming easier?
At a recent roundtable, we brought together three of Adaptavist’s top DevSecOps experts – Principal DevOps Consultant, Peter Daugavietis, Principal DevOps Consultant, Timothy Chin, and Consulting Team Lead, Jason Spriggs – to address these questions. Here, we share their key observations and expertise about the rise of DevSecOps, top tools and integrations.
Is DevSecOps really on the rise?
Peter: Yes, and it can’t do anything but make everything better, having more secure pipelines, and more secure pathways and applications in general. Even if organisations aren’t actioning a lot of these things, the awareness level is going up.
Jason: It’s great that developers are more mindful of the infrastructure their code is running on, whether that’s in the Kubernetes space, making sure they’re developing for a particular ingress type, or if they’re using Amazon, expecting their service is going to be behind a load balancer. Whatever it is, they’re then developing with that in mind.
Peter: One of the more important aspects of DevOps, in general, is blamelessness. This idea is that we either pass or fail together. Adding the word ‘security’ conjures images of a tall guy carrying a very large stick with a threatening voice. But through awareness, through all the different DevSecOps practices, we are shifting left, implementing security right from the start.
What exactly does shift left mean?
Jason: Generally, trying to shift your processes left is all about having conversations, in this case regarding security, sooner in the development process. It’s making sure when you’re developing software, you have security-minded tools and processes earlier on. That way you catch things before they spiral into separate projects.
Is DevSecOps happening mostly around cloud migrations? Or is it as effective for on-prem as well?
Peter: I think it’s both. One of the easy paths is if you already have a pipeline – whether on cloud or on-prem – it’s relatively simple to start layering in some level of security scanning, vulnerability scanning, or dependency scanning, as part of your automated build and testing systems. But moving to the cloud gives you the opportunity to refactor and rethink the way you do things; it’s a much more holistic change.
Does it make sense then to take a step back and look at the solutions when you’re starting to implement DevSecOps?
Timothy: For sure. I’m working with one of the largest cosmetics companies to do a complete revamp from using on-prem legacy applications to Netlify and GitHub. It’s a great example of this in action. We’re not only re-architecting the platform but also taking the opportunity to implement security processes into the CI/CD flow. For example, using tools like Dependabot, Snyk, and Sentry – some of these are SAST and some are DAST.
The changing landscape of DevSecOps part two: implementation challenges
Adaptavist’s Head of Solutions Strategy, Jobin Kuruvilla, sat with our DevSecOps experts to discuss the current landscape.
What’s the difference between SAST and DAST?
Peter: SAST, which stands for static application security testing, is the scanning of files and the source code at static file time. DAST, or dynamic application security testing, will go through and test your code at runtime. So if you’ve got a web-based app you’ve deployed to dev, you can now apply a DAST tool to scan for vulnerabilities.
How easy is it to implement DAST and which tools can help?
Jason: For a lot of those types of environments, you would want to use a tool like GitLab that would either stand up a new environment per commit or every release, whatever you want the cadence to be. Once you have those running, if you’re developing with a framework – Springbok comes to mind as a major one that has DAST tools already out there – you can run a set of queries that are already against it for known vulnerabilities.
Timothy: GitLab has developed a set of preconfigured features and integrations called Auto DevOps. It’s just a simple import of yml files, which you can include into your CI/CD process. It takes into account the type of deployment that you are making, whether it’s a docker file, a container, or just a static deployment and takes care of SAST or DAST for you.
Atlassian Open DevOps has already integrated with a lot of tools like GitLab. Are integrations becoming easier?
Peter: One of the biggest shifts in general, is the rise of the API or application programming interface. If you don’t have an API for your tool, odds are it’s probably not going to get used that much. A lot of the tools coming out now have a rich API, which makes a tool available for anybody who wants to integrate it.
Common vulnerability and exposure (CVE) lists are integrated by all the different scanning tools, so they know what to scan for and report. They know how many vulnerabilities there are, and through that you’re able to triage and start making decisions about tackling the critical ones. It’s more proactive than reactive.
Our experts by your side
Want more expert advice and insight from Adaptavist? We can help you with all your security requirements, from assessing your maturity to DevSecOps consultancy, helping you protect your software, meet your business goals, and stay ahead of the curve.
Get in touch
Written by
Jobin Kuruvilla
Head of DevOps Practice
Jobin ia a DevOps expert and app developer, with certifications in Atlassian, GitLab PSE, AWS, Kubernetes, and Jenkins. He has led digital transformation initiatives for teams and enterprises and leads the DevOps practice at Adaptavist.