The golden age of DevOps software best practices has settled upon us like a cozy blanket of consistency. Within this utopia of perfect change management and well-oiled industry standards, a natural progression toward airtight cybersecurity called DevSecOps emerged. 

Of course, when I say, “golden age” I really mean “Wild West.” And by “cozy blanket of consistency” I really mean “cold paper sheet of uncertainty.” Across the tech industry, DevOps implementation means different things to different companies—even within some companies, it means different things to different teams. 

Untangling DevSecOps

Since the term was coined a decade ago, the meaning of DevOps has remained cloudy, and today’s landscape represents a hodgepodge of DevOps workflows. Staples like CI/CD tools have seen widespread adoption, while products like value stream management software are scattered across a few select companies.

In the tech world, that means it’s the perfect time to cause a disruption—and DevSecOps is just the thing. 

What is DevSecOps? 

DevSecOps, which stands for Development Security Operations, presents a needed call to action packaged as an insufferable buzzword. The underlying message is urgent and poignant: Cybersecurity, too, must be a default in the DevOps (development and IT operations) workflow. Given the nature of continuous delivery software environments, it’s become increasingly difficult for cybersecurity professionals to clean up after developers. DevSecOps aims to create highly secure code by design, rather than after the fact. 

(As for the term itself, well...it sets an interesting precedent for naming conventions. There are plenty of beneficial principles that can—and should—integrate with successful DevOps processes, but let’s not call it DevSecPrivMindfulnessAIOps.) 

It remains to be seen if the term DevSecOps sticks, but for now it does its job, sending shivers down the industry’s spine. Maybe that has more to do with the nauseating terminology than its implications, but it still serves as a wake-up call for development teams about the very real need for secure code. How do companies and teams answer that call? 

DevSecOps tools

DevOps teams need the right software stack to fully realize DevSecOps, or security by design. Furthermore, these tools must smoothly integrate with pre existing pipelines. 

In an ideal world, the perfect product for the job would also automate the brunt of the workload. Developers aren’t going to step to the tune of strong cybersecurity unless the solution is headache-free. Other than a few firm training sessions and a steady supply of ibuprofen, what are the options? 

Finally finding some footing in the market after a few years of stagnation, software composition analysis (SCA) tools present a seamless, automated solution for developers to manage the open-source and third-party elements of their applications. The application development process has a tendency to rapidly accumulate an impressive pile of third-party dependencies and components. SCA tools integrate with preexisting DevOps workflows to constantly scan these components for vulnerabilities and updates, ensuring comprehensive security amid the spaghetti of API calls. These products then go one step further and even suggest vulnerability remediations upon detection, making them a necessity to any emerging DevSecOps space.
Other legacy tools that can be used and combined to craft an airtight DevSecOps environment include vulnerability scanner software, dynamic application security testing (DAST) software, static application security testing (SAST) software, or penetration testing software...look, there are many solutions to choose from. All contribute unique value to a DevSecOps workflow.

DevSecOps methodology is far from standardized 

The abundance of different solutions that address DevSecOps, if we’re really calling it that, seems great. However, the industry hasn’t agreed on a standard mix of tools for a “best practice” DevSecOps work environment. As a result, we wind up with a wishy-washy workplace philosophy, rather than a specified set of procedures to actually implement. Sound familiar? 

If companies want to avoid repeating the implementation circus we call DevOps, they’re off to a bad start. Just look at the usage spread on this survey of 57 cybersecurity professionals across industries conducted by ZeroNorth.

These results don’t exactly evoke phrases like “industry standard” or “all is well.” Out of seven possible scan and test tools, only one sees enterprise-wide use by anything more than a quarter of professionals surveyed. Which is particularly troublesome when you realize that’s not even the complete dataset.

This particular graphic had to be split across two different pages of ZeroNorth’s report. And sure, maybe they could have made the font a little smaller. But that’s still a grand total of 12 different types of viable cybersecurity tools—all with extremely varied implementation across the industry. 

That same report found that 98% of professionals regard cybersecurity in DevOps as either “extremely important” or “very important.” Everyone generally agrees that DevOps teams must adopt cybersecurity best practices, but everyone has different ideas of what that means. This issue is inherent to vague philosophies like “DevOps” and “DevSecOps”: every team is going to interpret these philosophies based on their own internal workflow and culture. 

The future of DevSecOps in DevOps and CI/CD initiatives

Based on industry-wide sentiment for better security in the age of digital transformation, it seems likely that the DevSecOps philosophy is here to stay. The question is whether that philosophy will lead to standardized application—and how long that will take. If the past decade of DevOps is anything to go on, we’ll likely see a patchwork of implementation fueled by buzzwords and dreams. 

However, it’s possible that the industry-wide experience with DevOps has primed for more effective digital transformation efforts in the future. Now that companies have gotten their footing with cloud, DevOps, and CI/CD initiatives, a shiny new addition to the work environment may prove less ethereal. Perhaps the crucial urgency for security will motivate a unified front.

Whatever form it takes, we can expect to see major shifts toward DevSecOps across industries in the future. There may be growing pains along the way, especially if developers and business partners view new security initiatives as obstacles within efficient workflows. However, companies must find ways to make secure DevOps work if they want to avoid the risk of costly security fiascos.