How the need to speed application creation and subsequent iterations has catalyzed the adoption of the DevOps philosophy
By Dwight B. Davis, Writer, Symantec
The sharp rise in cyber security attacks and damaging breaches in recent years has driven a new mantra among both application developers and security professionals: “Build security in from the ground up.” Although it’s hard to argue with that commonsense objective, actually achieving it has proven to be far from straightforward.
Traditionally, of course, developers have focused on delivering reliable software that first and foremost provided the desired functionality. Security was largely an afterthought, if a thought at all – something that was to be layered on top of the application once it hit production. When, inevitably, applications were found to have code vulnerabilities, developers crafted and distributed patches to fix them.
Never ideal, the patch and update model has become untenable as security threats have escalated and software development cycles have accelerated. Much of this acceleration has been driven by public cloud computing, which has fostered the rise of a continuous integration/continuous delivery (CI/CD) development model.
At a more macro level, the need to speed application creation and subsequent iterations has also catalyzed the adoption of the DevOps philosophy. The fundamental basis for this movement is to better integrate developer and operations teams, thus ensuring that each side has a better understanding of the other’s needs and constraints.
By some estimations, DevOps and CI/CD can inherently aid in the creation of more secure software. Why? Because, thanks to the rapid application iterations, software flaws can be more quickly identified and more swiftly patched.
The problem with this supposed benefit is that it doesn’t alter developers’ build/patch mentality. Vulnerability fixes may indeed occur more quickly, but security still isn’t a core developer concern or responsibility.
Spanning the development & deployment cycle
To truly deliver on the “security from the ground up” objective, DevOps teams need to blend in a security component that spans the entire software development and deployment lifecycle. That need has resulted in the notion of a DevSecOps paradigm or culture. Here again, though, the concept is easier to grasp than to achieve.
The challenges associated with DevSecOps range from cultural to technical. Developers long disinterested in security issues need to change their mindsets and expand their skillsets. Development and security teams that have largely operated in their own isolated domains need to learn how to tightly collaborate. Developers who already have tools for code production and management now need tools for building secure apps. For their part development team managers need tools to give them visibility into the security of the code each developer is producing.
When it comes to implementing DevSecOps, there is no one-size-fits-all guidebook. Cloud native and more entrepreneurial firms may be able to mesh their developer, operations and security teams more quickly and easily than more mature organizations that must break down existing functional silos. Even though there will be a gradient in how tightly integrated the various teams become in different organizations, however, there is a fundamental need to move security beyond its own isolated domain.
“The goal is to decentralize and democratize security,” explains Hardeep Singh, cloud security architect at Symantec. “Having centralized security and decentralized development and operations is a recipe for disaster.”
Although developers must become more conversant and capable regarding security issues and approaches, the degree of their security expertise will vary considerably. Likewise, security pros typically aren’t going to become coding wizards. That said, each group needs to better understand the other’s worlds, and how the two must intersect.
Often, the security members within DevSecOps environments will set high level priorities and best practices, while the developers will be tasked with implementing them.
“You can’t expect app developers to know the best practices to secure IP data or to identify a SQL injection,” says Raj Patel, Symantec’s VP of Cloud Platform Engineering. “But you can train them on safe development practices and techniques.”
There may be some resistance among developers asked to take more responsibility for building secure code, just as some security experts may balk at bringing developers more fully into the security lifecycle process. Most often, though, these two groups are happy to share the burden of producing secure applications, since doing so not only reduces cyber security risks but also makes their own work lives easier.
DevSecOps can also drive a meeting-in-the-middle truce between the historical – and polar opposite – attitudes of developers and security pros. The bias of developers has been to say “Yes” to user requests, while that of security experts – prioritizing security over functionality and ease-of-use – has been to say “No.”
“In some ways, DevSecOps can be how security teams move to ‘Yes,’ because they’ve helped developers address security needs right from the start,” says Patel.