Divide Between Security, Developers Deepens
Security professionals work hard to plan secure IT environments for organizations, but the developers who are tasked with implementing and carrying these plans and procedures are often left out of security planning processes, creating a fractured relationship between development and security.
This was the conclusion from a VMware and Forrester study of 1,475 IT and security managers, including CIOs and CISOs and managers with responsibility for security strategy and decision-making.
The report found security is still perceived as a barrier in organizations, with 52% of developer respondents saying they believed that security policies are stifling their ability to drive innovation.
Only one in five (22%) developers surveyed said they strongly agree that they understand which security policies they are expected to comply with and more than a quarter (27%) of the developers surveyed are not involved at all in security policy decisions, despite many of these decisions greatly impacting their roles.
The research indicated that security needs a perception shift and should be more deeply embedded across people, processes and technologies.
This means involving developers in security planning earlier and more often; learning to speak the language of the development team rather than asking development to speak security, sharing KPIs and increasing communication to improve relationships and automating security to improve scalability, the report recommended.
Set a Clear Scope for Security Requirements
Cody Michaels, application security consultant at nVisium, an application security provider, said a key best practice in integrating developer and software engineering teams with IT security is ensuring you’ve set a clear scope of security requirements during the development process—not after.
“Regardless of whether if it’s customer-facing functionality or a business logic concern, every line of code developed should prioritize security as a design feature,” he said. “Once security is taken as seriously as other drivers for DevOps adoption, then a fully holistic integration can be achieved.”
John Bambenek, principal threat hunter at Netenrich, a digital IT and security operations company, agreed; he said ultimately if the respective software engineering and security management teams don’t buy into the integration and work cooperatively, nothing else is going to work.
“Front-line staff will follow their management’s lead, so those managers need to sit down, define goals and objectives and then direct their people accordingly,” he said. “I’ve spent over 20 years in security, a good deal of which dealing with things put into production without any security review and then it gets popped and a big mess needs to be dealt with. As the old saying goes, an ounce of prevention is better than a pound of cure.”
Michaels also noted that failure to incorporate security in the software development life cycle will lead to a security solution being bolted on in the end.
“As anyone who has needed to fight with technical debt in the past can tell you, bolt-on security is much more difficult to modify and, ultimately, has a higher chance of breaking more areas of the total product,” he said. “Not only will this be built as quickly and cheaply as possible to avoid deployment delays, but this will rarely be an adequate solution.”
Even worse, Michaels added, this approach will often give the illusion of security, while having severe gaps in coverage, putting a company’s DevOps maturity level far behind their competitors.
Sharing Priorities and Engagement
Shared team priorities and engagement will pave the way forward, and the survey indicated there’s already progress being made on this front: More than half (53%) of respondents expect security and development teams to be unified within three years.
In addition, 42% of those surveyed said they expect security to become more embedded in the development process in that same period.
The study found there’s a broader acknowledgment that cross-team alignment empowers businesses to reduce team silos, create more secure applications and increase agility to adopt new workflows and technologies.
The Forrester study also indicated that ensuring security in the cloud and securing workloads and containers are the most challenging tasks, which Bambenek said made sense, since like all new technologies, it takes time to adapt security to work sufficiently.
“The traditional way of securing data center resources doesn’t work in the cloud. When you combine that with DevOps and Agile development, the cadence of operations doesn’t lend itself to the time needed to think about risk,” he said. “Cloud and container technology were adopted so quickly that security is still catching up with how to make it safe.”
Michaels added that ensuring security in the cloud as well as security workloads and containers is a huge challenge due to their fluid nature.
“Developing in the cloud has streamlined processes such that weekly—or even daily builds—are things of the past,” he said. “Security teams already struggle to meet the accelerated pace and without proper integration, they will fail to adequately secure each build.”
He warned that if policies detailing how to set up and secure these environments aren’t enforced, then poor security practices are inevitable.
“Add in human error, differing work styles and work fatigue, and you’ve got a recipe for disaster with security vulnerabilities slipping through the cracks,” he said.
However, the study found more than half of developers (52%) felt security policies stifle their innovation, indicating security needs to become an embedded service and business enabler that allows development teams to be more innovative while increasing compliance and business revenue.
Michaels agreed security policies can stifle innovation because, when it comes to development, creativity is oftentimes a huge component.
“On the surface, development and security seem diametrically opposed, in that one wants more features while the other wants to limit exposures,” he said. He said the reason developers feel security policies hinder innovation is they see it as a concrete block over which they have no control.
“This kind of mindset can be changed by understanding why the policy is there and then giving the developer the freedom to address the problem,” he said.
Shifting Ownership to Bridge the Developer Divide
From his perspective, this pervasive issue can also be resolved by changing ownership.
“Successful development teams raise security champions within development groups to address potential security issues while in development,” he said.
Bambenek agreed part of the issue is that developers think anything that slows them down or anyone that might tell them they can’t do things the way they want stifles innovation.
“When you’re a hammer, everything is a nail,” he said. “The core problem is that security is viewed as a specialization and not a core part of software engineering. There will always be a need for security specialists, but we need to start by training software engineers on security concepts as part of their formal education.”
