SecDevOps: Injecting Security Into DevOps Processes
SecDevOps: Injecting Security Into DevOps Processes
A high-level overview of the emerging SecDevOps, which aims to integrate security into IT as tightly as DevOps wants Dev integrated with Ops.
Join the DZone community and get the full member experience.Join For Free
By now, just about everyone in IT is familiar with the concept of DevOps and its promise to unite dev and ops teams to help organizations create better software faster and more efficiently. But in a world where code changes frequently, attack surfaces and risk profiles can change just as quickly. So now, the emerging field of “SecDevOps” seeks to leverage the DevOps approach to bake security directly into development and production workflows. An extra bonus is the chance to include some of those features the security team was begging for, but that too often got dropped at the end of a waterfall development process.
Think of SecDevOps—sometimes called “Rugged DevOps” or “security at speed”—as a set of best practices designed to help organizations implant secure coding deep in the heart of their DevOps development and deployment processes. The goal is to automate secure coding and security tests and fixes within the workflow, making secure software an inherent outcome of DevOps approaches.
In addition to merging operations and development teams, DevOps is intended to minimize coding faults and omissions by automating development to remove human error. And when errors do occur, DevOps helps organizations fail fast and repair any damage more quickly. That lowers the risks associated with software innovation and makes continuous deployment more feasible. In fact, using DevOps, “high-performing organizations are deploying code 30 times more frequently, with 50% fewer failures than their lower-performing counterparts,” says the 2014 State of DevOps Report from Puppet Labs. But in many cases, according to CloudWedge and others, traditional DevOps doesn’t address the shortcomings of traditional security models.
SecDevOps vs. DevOps
SecDevOps seeks to embed security inside the development process as deeply as DevOps has done with operations. Classic DevOps is designed to automate software development, accelerating and honing the craft to satisfy the needs of operations to acquire code that immediately works in production. SecDevOps, in contrast, automates the secure coding component of development to satisfy the needs of the security team to establish and maintain software that is immediately secure in production.
SecDevOps is hot right now, with plenty of press coverage, its own Twitter hashtag(#SecDevOps), and even a new sub-Reddit. Corporate security teams have made no bones about their interest in targeting development and developer tools and skills to secure coding as a part of DevOps. Perhaps that’s why, according to CSO Online, SecDevOps is already becoming a top security strategy driver for information security officers.
But SecDevOps is no overnight sensation. For almost 15 years, security and development teams have attempted to comingle. In the most recent push, DevOps guru Gene Kim and others have pressed for DevOps to include SecDevOps. Security-related development testing tool and framework startups are gaining visibility, offering products designed to integrate security into DevOps. Meanwhile, enterprises great and small are working to add SecDevOps to their existing development processes.
Why the Fuss Over SecDevOps?
One reason for the attention is that information security missteps are becoming astronomically costly, ranging in the hundreds of billions of dollars per year in the United States alone, according to CSO Online. Yet while enterprises spend massive amounts of money to fight information attackers, TechTarget reports that they spend far less on software supply chain security when compared to other major security measures.
DevOps presents a highly intuitive solution to this security situation. Since DevOps demonstrates promise for fixing pretty much everything else about software, why not leverage it to address security concerns with natively automated solutions? Or to look at it another way, why adopt DevOps in the first place only to encounter last-minute changes to meet security requirements down the road?
Connecting SecDevOps to DevOps
To successfully hook SecDevOps into classic DevOps development processes, the key is to add risk modeling, threat assessment, and penetration testing as early as necessary/possible. SecDevOps practitioners look for the most comfortable and expedient places to inject security concerns into the existing development workflow. This helps capture and nullify security flaws at their earliest ingress point, while providing feedback about vulnerabilities at their first appearance.
To hook SecDevOps into your deployment process, ensure that risk modeling, threat assessment, and pen testing appear again at the first instance of binary compiling. Any executable code could ultimately be deployable and so should be tested from that point on until just prior to deployment. This includes prior to and upon entry into preproduction staging environments. (Security Intelligence offers additional tips on building security thinking into every stage of development.)
DevOps is remaking the process of software development implementation, but to date, security has largely remained a bolt-on, after-the-fact consideration. Including security in DevOps processes isn’t always easy, requiring dev and ops to pay more attention to security from the beginning, even as security pros confront the DevOps-style lean/agile/automated culture shifts. But SecDevOps’ promised payoff of more secure applications created more quickly seems compelling enough to get increasing numbers of organizations to do just that.
- Cognitive Dissidents, Josh Corman’s security blog
- How Netflix Manages Security in the Age of DevOps—DZone
- OWASP Top 10 Project
This article orginally appeared on the New Relic blog from Stevan Arychuk
Published at DZone with permission of Fredric Paul , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.