DevSecOps: Paradigm shifts are messy, but someone’s got to take the lead
Source:- infoworld.com
A perfect storm of factors brewing in the dev, ops, and security worlds have created a window of opportunity to embed security into the application delivery lifecycle, in a needle-moving kind of way. However, security teams need to be the ones driving the DevSecOps charge or that needle will barely wobble.
Given how many security practitioners spend their days putting out fires, adding “DevSecOps evangelist” to their job description is more likely to elicit groans than spur the desire to innovate application security. As understandable as that may be, unless security teams can create the groundswell needed for DevSecOps to stick, then another paradigm shift in computing will occur in which security gets left behind.
Paradigm shift? Gag me with a buzzword spoon
As annoying of a buzzword as “paradigm shift” is, it is an accurate description for what’s been happening in the application development world as it moves from a waterfall to an agile development model. Given how rarely radical process reengineering occurs in enterprise environments, it should come as no surprise that its ripple effect has been massive. It’s also worth noting that as fast-occurring as this shift might feel, given The Manifesto for Agile Software Development was first published in 2001, it’s been more than 15 years in the making but hit a tipping point when cloud-based software delivery models became enterprise-ready.
The move to Agile development was a process shift that gave rise to DevOps, an accompanying culture shift. As DevOps teams became more and more ingrained into enterprise culture, they started to build Continuous Integration/Continuous Delivery (CI/CD) pipelines as a way to automate process flows in order to speed up software delivery.
That brings us more or less to the present. As those CI/CD pipelines are built and automated, it’s hard to ignore the opportunity DevOps presents to innovate security. The whole point of DevOps and CI/CD pipelines is to release better code faster. With most companies operating in a business environment rife with data breaches, fraud, cyber attacks and other cyber security fails, what is the point of creating less buggy code if it’s loaded up with security vulnerabilities and bad security practices?
The answer is not much — hence the rise of DevSecOps.
DevSecOps: Shifting security to the left
Most security professionals are acutely aware of the fact that security was too often an afterthought in the software development lifecycle, and that it was not uncommon for security teams to be seen as a roadblock to the launch of new software. With DevOps forging new, common ground between Dev and Ops teams, adding security into the mix is a logical next step, and doesn’t feel impossible.
DevSecOps will certainly require development and operations teams to familiarize themselves with security concepts, processes, and even some tools, so they have the capacity to identify and fix vulnerabilities and prevent process-level security flaws from occurring. Even so, because the security operations team is ultimately responsible and accountable for application security (think: who gets the call when there’s a breach?), the burden should rightfully fall on them to craft and execute an organization’s DevSecOps strategy.
In fact, DevSecOps presents a huge opportunity for security teams to shed the perception that they are business-inhibitors by facilitating security’s “left shift” to the beginning of the development cycle. The term “left shift” may be a DevOps phrase, but the concept is not new to security — in fact, infosec leaders have been advocating for decades now. The dangers of “bolting security on” after-the-fact are widely understood, as is the idea that security is a strategic business imperative that is everyone’s problem.
That said, at the end of the day, whenever a major security fail occurs, regardless of whoever else might be to blame, it’s the security person’s job that’s on the line.
Ironically, some security experts believe that the biggest roadblocks to DevSecOps are security folks who “have never worked in software development and who don’t understand how a sprint team delivers software.” While that’s just one perspective, it’s one I’ve seen more than once over the course of my career as a developer. As someone who’s spent years with one foot in the App Dev world and the other in Security, I am acutely aware of how beneficial it would be to forge some much needed common ground between dev, ops, and security.
For security professionals with an eye towards the future, a successful DevSecOps initiative can be a career maker, enhancing the credibility and profile of the security organization, which can then be used to justify further investment in security. The actual work involved in breaking down corporate silos and getting people to partner that historically have been unreceptive to working together is often frustrating and thankless, but at least with DevSecOps, the end result will be a major step forward for enterprise cyber security.