DevOps has not yet become DevSecOps, leaving DevOps unsecured. Everyone speaks of it, but very few organizations have mastered it. This begs the question, why is adoption so low?
There are five main myths about DevSecOps that hinder its adoption. Let’s take a look at each one and find out the truths behind the myths and define the capabilities that application security (AppSec) should have to make DevSecOps a reality:
It’s often believed that DevSecOps is enabled by culture. That’s simply not true. In fact, DevSecOps is based on and enabled by technology. Culture follows. Attempts to put culture first tend to fail because you need to have an appropriate AppSec foundation. We see organizations that structure DevSecOps teams, train them in methods adopted from DevOps, chant mantras of continuous and rapid secure releases and end up with nothing.
You can’t have a DevSecOps culture without security-enabling technologies. If you have only manual security code reviews, you won’t establish a DevSecOps culture of speed. If you have only manual penetration tests, you won’t build a culture of security at scale. And you won’t build a culture of multiple daily security tests if you don’t have technologies such as static application security testing, dynamic application security testing, software composition analysis and web application firewalls.
Technology is the basis for the culture, not the other way around. And DevSecOps is a technological phenomenon. So, make sure to lead with the right technologies and the culture will adapt around it.
This myth leads DevOps professionals to choose the wrong AppSec technologies — “traditional” AppSec technologies built in a pre-DevSecOps era — to transform DevOps into DevSecOps. Because of this, results are usually disappointing.
The reality is that only specially designed AppSec technologies can enable DevSecOps. Traditional AppSec technologies don’t cover the entire software life cycle (SLC), which is needed for successful DevSecOps execution. Most AppSec checks run just before application deployment and, occasionally, after deployment, which isn’t a fit for DevSecOps. These traditional technologies require specialized AppSec human efforts to onboard, configure and operate.
Another challenge is that traditional AppSec technologies run much slower — taking hours or even days for testing — than DevOps, which releases units of code in seconds or minutes. Additionally, AppSec technologies are built for proprietary platforms, so they aren’t compatible with modern, cloud-native or community-native paradigms, such as GitHub or Postman. Moreover, traditional AppSec technologies have not been built to natively test APIs, single-page applications and microservices.
All of these considerations make it important to choose the right, specially designed AppSec technology that will enable DevSecOps. If you need help, an AppSec provider will be able to guide you in selecting the best technology for your needs.
It’s thought that AppSec invocation and execution along the SLC must be automated, so AppSec technologies will automatically run along the continuous integration/continuous delivery (CI/CD) process, and that without AppSec automation, DevSecOps is impossible. The truth is that automation is necessary, but not for all AppSec technologies.
Automating the integration of traditional AppSec in the CI/CD process should be a low(er) priority because, as previously discussed, they’re seldom used. The primary subject for automation should be specially designed technologies that truly enable DevSecOps and are useful in the hands of developers and operations specialists. With those technologies in hand, application testing for security can occur a dozen times a day and hundreds of times throughout the SLC.
A shift to the left has been announced as a security panacea for DevOps. But how realistic is it? It’s true that AppSec technologies should be shifted to the left. But they also should be shifted to the right and to the middle. A programmer needs security on the left, a build engineer needs security in the middle in the CI/CD pipeline and an operation professional needs security on the right.
“Shift left” is an exaggeration that de-emphasizes the criticality of security coverage across the entire SLC. A shift-left directive changes the balance in favor of “left-side” security code analysis at the programming phase, ignoring the fact that most of the SLC is a runtime process (either test or production runtime), during which static code analysis is not applicable. Therefore, runtime AppSec technologies are critically important in the middle and right, too — at build, as well as pre- and post-deployment.
DevOps’ highest priority is to deliver application functionality on time and under budget. The next priority: assure quality and performance. Security is DevOps’ distant, trailing goal. Because AppSec technologies are complex, DevOps professionals don’t have the time, skills or desire to adopt and operate AppSec technologies, and these efforts take them away from their primary goals.
The new AppSec for DevOps should be application-architecture agnostic: It should automatically test any application architecture, whether it’s a single page application or multi-page application, a microservice or an API. It should be purposely built to be cloud-native and community-native. AppSec should not require any sizable efforts for onboarding and configuration, nor should it require customized login/credential handlers or any other heavy human involvement. It should cover the entire SLC. It should be able to test any business increment, not just a particular URL or IP address.
AppSec should cater to DevOps requirements, user experience and “speak the language” of developers, quality assurance and operation specialists, not the other way around. Although DevOps people should learn best security programming and operation practices, they should not be required to learn how to operate AppSec technologies.
While traditional AppSec is not a good fit for DevSecOps, new technologies are entering the market. Watch for them, as they will be able to transform DevOps into DevSecOps.
This article originally appeared in Forbes