DevSecOps - Baking in Cybersecurity
DevSecOps - Baking in Cybersecurity
DevOps is a set of practices that aims to shorten the systems development life cycle and provide continuous delivery with high software quality by combining software development (Dev) and IT operations (Ops). The process is complementary with agile software development; several DevOps aspects came directly from agile methodology. Stated another way, "DevOps is just the agile principle, taken to the full enterprise. DevOps is agile for the rest of the company."
Virtual machines and containerization allow DevOps automation to be achieved by repackaging platforms, systems, and applications into reusable building blocks.
DevSecOps adds security to the mix. According to Red Hat, "in the collaborative framework of DevOps, security is a shared responsibility integrated from end to end. It has always been ideal to include security as an integral part of the entire app life cycle. DevSecOps is about built-in security, not security that functions as a perimeter around apps and data. If security remains at the end of the development pipeline, organizations adopting DevOps can find themselves back to the long development cycles they were trying to avoid in the first place." Security can be "baked in" rather than "bolted on" using these processes.
A recent article by Lucian Constantin in CSO describes the challenges associated with adopting DevSecOps methods and their disruptions. DevSecOps, he says, "is a culture shift in the software industry that aims to bake security into the rapid-release cycles that are typical of modern application development and deployment, also known as the DevOps movement. Embracing this shift-left mentality requires organizations to bridge the gap that usually exists between development and security teams to the point where many of the security processes are automated and handled by the development team itself."
"Shift left" is an approach in which tests and fixes are performed earlier in the development pipeline, that is, "more to the left" when looking at a lifecycle diagram that flows from left to right. It enforces the agile principle "test early and often" by building testing into all stages of the SDLC.
A DevSecOps environment is "real" when the development team performs the security testing, issues found during that testing are managed by the development team, and the correction of those issues stays within the development team. Chris Wysopal, co-founder and chief technology officer of application security testing firm Veracode, is quoted by CSO saying, "The last one is going to take some time, but I think that's when application security truly becomes DevSecOps and there's no need for a separate team." He goes on to say, "the reason why achieving the last step is hard is because developers must build up the skill set required to fix security-related bugs without outside guidance and that takes time. Many teams get there by embedding a so-called security champion within their development teams. This is someone who has expertise in application security and has taken more advanced training in this field than most of the team, even though training the entire team on secure programming practices should also be part of the process."
However, most engineers and operations experts are not security experts, nor are security analysts knowledgeable in their understanding of development processes, tools, and tradeoffs. Overcoming this paradox by complementing each group with the opposite skill has tremendous value. Developers learn to understand security best practices and can start implementing them in every task. Security teams can make more informed suggestions, understanding the implications of specific changes to the software or environment.
This problem in the DevSecOps approach has prompted the development of a not-for-profit organization and at least one entity offering training and certifications. DevSecOps.org was, according to its web page, "founded by Security Practitioners dedicated to the science of how to incorporate Security within Agile and DevOps practices," and who "have continued to evolve our processes and practices to support Innovation ever since."
Tech companies led the way in early DevSecOps adoption, but the security testing tools available at the time were not developer-friendly. Developers want command-line tools that can be automated, allow them to tweak configurations, and whose output can easily be imported into bug trackers. In contrast, security scanners are designed with security teams and CISOs in mind. Their goals are governance, security policy compliance, and risk management. Vendors now try to provide both the analytics and reports needed by CISOs and have flexibility and ease of use expected by developers. Some providers of cloud-based services aimed at developers, such as GitHub, have started adding security testing directly to their services.
Many development tools are on the market to support DevSecOps. These include, for example, Aqua, Alerta, CodeAI, StackStorm, Veracode, and others. James A. Martin at CSO Online provides a more comprehensive and fairly recent list.
"DevSecOps is gaining traction because many organizations are developing applications frequently to satisfy customer or business partner demands," notes Michael Isbitski, senior director analyst, security technology and infrastructure at Gartner.
DevSecOps has a strong appeal as it promises "baked-in" security that shortens development time and reduces vulnerability. The challenges of implementing it are, however, daunting. General management fears that it may simply be a "flavor of the month" management fad, and the humans who implement it all add complexity to making the process work. DevSecOps has promise, but people have to make it happen.