SAN FRANCISCO -- So what exactly is DevOps? A next-generation development framework? An emerging software security paradigm? An existential state of being?
None of those descriptions are quite accurate, according to a pair of DevOps proponents who spoke at RSA Conference 2015 last week. While some see DevOps as a traumatic, frightening shift for IT professionals, the two speakers at RSA said it is proving to be a transformative movement for anyone involved with software security and that it will eventually become the default methodology for developing and updating software.
Speaker David Mortman, chief security architect and distinguished engineer for Dell, headquartered in Round Rock, Texas, described DevOps as a philosophy and a culture that fosters rapid, continuous iteration in software development, emphasizes data analysis and information sharing to identify software architecture problems, streamlines process bottlenecks and quickly implements software changes.
Mortman said that DevOps is meant to be an alternative to traditional waterfall-style development, a thorough process heavy on quality control, but that moves at a measured pace that typically limits major software releases to once every 18 to 24 months.
Joshua Corman, chief technology officer of application security vendor Sonatype Inc., based in Fulton, Md., said DevOps builds on the recent agile development paradigm by not only focusing on rapid software development and deployment, but also fostering collaboration between developers and IT operations teams.
"DevOps allows you to go fast, try new things, fail and iterate quickly -- be more efficient, profitable and competitive," Corman said. "There's more velocity, which is why developers love it, and operations teams get to be more efficient, release more break-fixes, offer faster mean-time to repair and roll out more new features."
Busting DevOps security myths
Mortman said many seem to believe that DevOps hinders security by breaking down separation of duties, limiting code checks and pushing software iterations into production without proper quality control.
These, though, all are myths, Morman said: With DevOps, software security improves if it's done right, most notably because code "almost never" goes out into a live environment without testing, but developers aren't forced to log in manually to test it; the testing happens automatically.
"Instead, they're using tools to automate testing, so fewer people are involved and tweaking individual configurations," Mortman said. Because less manual code auditing and documentation is needed, he added, "when there is an issue, you can have a higher confidence factor you know what's going on in that [server]."
Another common myth, Mortman explained, is that some organizations believe they don't need to implement DevOps because they already use the ITIL framework to ensure software development processes are aligned with business needs.
However, Mortman said, the process methodology of DevOps is largely borrowed from ITIL; in fact, the term DevOps was even coined at an ITIL conference.
"DevOps is ITIL without the paperwork," Mortman said. "It's a process that works every single time, and that's the holy grail of ITIL."
Mortman also addressed how some security pros familiar with DevOps believe that there is a lack of maturity with the most popular DevOps software configuration and deployment tools, such as Chef, Puppet, Rudder and Docker.
He admitted there is some truth to reports of issues like tricky integration with corporate directory services, a lack of role-based access control and, especially, weak configuration checks that result in faulty builds being propagated without proper validation. Mortman said, though, that new tools are emerging to solve some of those problems, such as a Chef tool that validates test cookbooks (configuration and policy distribution elements) for builds before distributing them.
"We don't mean to stand up here and say [DevOps] is perfect," Corman said, "but in a way you don't have a choice because the status quo isn't working."
More specifically, Corman referenced the estimated $40 billion enterprises spend annually on information security; he noted that -- even though research shows attackers target software more than networks, hosts, data and people -- software security receives a relatively miniscule $500 million of that spending.
Adding to the software security dilemma is that, instead of writing their own code, Corman said, enterprises increasingly assemble code from existing building blocks, much of it from unvalidated open source elements.
"That's why Shellshock and Heartbleed and issues with software supply chain have been killing us: because our software's been assembled from code of unknown origin with unknown risk," Corman said. "This is one of the reasons why it's open season on open source."
Security and DevOps: An opportunity
Mortman said, at its core, DevOps is intended to make software development processes far less complex, and complexity is the enemy of security.
"The more complex your code is," Mortman said, "the more security vulnerabilities you're going to have, the more unstable your code is going to be, and harder it will be to make changes without breaking things."
In addition to being able to identify software security flaws and roll out fixes more quickly, both speakers emphasized that DevOps offers security teams plenty of benefits in the way of change management, simplified inventorying of both applications and software components, and ultimately a larger window into the software development process and more opportunities to influence it.
"We as security teams don't typically have any way to affect the choices of IT or operations or developers," Corman said, "so you may not have control of SaaS provider or a data center, but DevOps gives you that entry point, and when you're spinning within their culture, you have a much more extended sphere of influence."
Corman noted that, apart from security, DevOps is gaining traction in the enterprise for a variety of reasons, so it's to infosec pros' advantage to join the "DevOps tribe" while it's still in its early days.
Added Corman, "You can take the initiative and lead the first pilot implementation, wait for it to happen in your organization and engage early, or you can pretend it won't happen and be replaced."
Is DevOps going mainstream? Learn why it's no longer a niche approach to software development.