Technical Track Business Insights

DevSecOps: what all DevOps should be

3 min read

Jul 31, 2018

Today the value of DevOps is well understood, at least by IT professionals. In the IT community, DevOps is almost universally accepted as being superior to traditional software development. By breaking down departmental silos, DevOps unifies development and operations teams in the goal of delivering better software products faster and more frequently. DevOps has been a dominant approach for almost ten years. More recently though, we’ve seen a growing interest in DevSecOps, and rightly so. By explicitly adding “security” to the DevOps philosophy and name, DevSecOps incorporates the necessary emphasis on defending against increasingly frequent and dangerous attacks on data security. How important is that emphasis? Important enough for us to suggest that all DevOps should involve at least some of the elements of DevSecOps. To be clear, improved security has always been part of the intention of DevOps. The methodology allows building, testing and deployment to happen faster and more often, and that alone should be a boon to security. Any approach that supports frequent iteration makes it possible to spot and fix vulnerabilities quickly. And the faster vulnerabilities are caught and corrected, the fewer points of exposure there will be for ransomware, intrusions and data leakage — at least in theory. In practice, though, DevOps’ reliance on velocity and automation can create its own Achilles’ heel when security teams are unable to keep up with the number of releases being shipped. Massive breaches still happen with frightening regularity, and they still happen at organizations large enough to have the wherewithal to defend themselves. This stark reality points to a need to prioritize security from the earliest stages of software development. Put another way, this reality is pointing to a need for the principles underlying DevSecOps. Think of DevSecOps as the logical and necessary evolution of DevOps. Like DevOps, DevSecOps combines the functions of an organization’s development and operations teams. On top of that approach, though, DevSecOps makes everyone responsible for security, and it incorporates security right from the start of the coding process (rather than attempting to apply it later, or worse yet, retroactively). Under DevSecOps, security has its own metrics and goals, and they become part of the same development pipeline used by both the development and operation teams. So now, Dev and Ops have to think about more than velocity and uptime. Under DevSecOps, every member of the team is graded on everyone else’s goals, including vulnerabilities detected within systems and code. This integration of security into the earlier stages of software development is what allows security to scale and keep up with the increased velocity achieved through traditional DevOps practices. DevSecOps is about improved tools, certainly, but it is more noticeably about building a culture that prioritizes security throughout the enterprise. Rather than centralizing control over security matters, DevSecOps empowers business operators with tools and processes that help with security decisions. And, in its purest form, DevSecOps asks security teams to “eat your own dog food” — in other words, to abide by the same security requirements that apply to teams across the organization. When, for example, a security practitioner has to ensure that their security controls are automated and capable of scaling with more frequent releases, he or she will quickly understand the pain points traditionally faced by their peers with regards to security. The DevSecOps culture also steps up the vigilance around exploitable vulnerabilities. While traditional security methods test hypothetical threats as suggested by (usually) a central authority, the DevSecOps practitioner prefers to think like the enemy. Under DevSecOps, systems are routinely exposed to mock attacks that mimic today’s real-world threats. Moreover, the DevSecOps philosophy accepts the reality that some security breaches will inevitably succeed. Thus, it thinks in terms of creating infrastructure and code that can be re-stacked quickly while still providing data security and availability. Much of DevOps’ success has stemmed from treating infrastructure as code. That revolutionary mindset allowed functional testing to “shift left,” or earlier in the development lifecycle, which in turn allowed bugs to be detected and fixed before they could make their way into production. DevSecOps improves on DevOps by ensuring that security gets shifted left, as well. By treating security as code, organizations can improve the defense of their data through automated testing. DevOps demonstrated an unprecedented strength in delivering better quality products faster. Under the DevSecOps philosophy, baked-in security is part of quality, and it will be tested just as rigorously as functionality. Learn how Pythian can help make DevSecOps part of your organization.

← The latest news from Google Cloud Platform

Cloudscape podcast: highlights from Google Next 2018 →

Get Email Notifications

No Comments Yet

Let us know what you think

DevSecOps: what all DevOps should be

Share this

You May Also Like

Difference between Oracle's table and Mongo's collection

Release Automation: The Key to Cloud Modernization

Identifying Data to Accelerate our Data Strategy

Get Email Notifications

No Comments Yet