Dealing with the Disconnect Between Developers and Security

With the rise of DevOps initiatives, there is a risk that security might slip into a secondary concern as organizations demand action. A key part of reducing security risks is identifying where they might occur within an ecosystem, including when the exposure is self-made. Enterprises want to put digital transformation plans into action rapidly, but that could also lead to unsecure deployments that bad actors could exploit. Experts from GitLab and SiteLock examine ways to better identify this divide between security and development, and steps to take in response.

Developer GitLab conducted its annual global developer survey that calls out the divide between security concerns and whether developers have the skills to identify risks within their code.

Colin Fletcher, manager, market research and customer insights at GitLab, says that organizations that were early adopters with their DevOps investment have seen productivity gains and increased security. Not everything is perfect in the DevOps world though. “There’s a lot of work to be done,” he says. “There’s still significant barriers that need to be overcome to get beyond early benefits.”

Fletcher says significant roadblocks exist when it comes to security. While there is no dispute about whether security should be worked into the entire development lifecycle, he says there are questions about the ability of developers to dedicate skills and time to bolster security.

There can be signs of potential exposure that developers may pick up on even if they are not specifically trained in security monitoring. Blake Collins, research analyst for website security company SiteLock, says if developers encounter strange anomalies such as files popping up in their environment or resources being diverted elsewhere, it could indicate security is compromised. “That’s when some kind of automated scanning or process for identifying malware needs to be done,” he says.

Collins says that security still tends to be an afterthought among developers who might assume another crew will handle such concerns. In some instances, no one is overseeing security issues. “It’s a lack of resources,” he says. “I don’t think developers are given enough time to understand where the vulnerabilities are.” That includes sanitizing input or making sure the program is not exposed to local file inclusion, which would allow users to upload files that could be malicious to the server. The impact of such exposure might only be realized after harm is done. “The vulnerability may not be known until it’s been exploited,” Collins says.

How developers view security and vice-versa

According to GitLab’s survey, 69% of the more than 4,000 software professionals indicated that developers are expected to write secure code. Despite such expectations, 68% of responding security professionals indicated they believed fewer than half of the developers could identify security liabilities. “[Security professionals] feel they are better equipped to catch those vulnerabilities in production or testing phases,” Fletcher says.

On the developers’ side, 24% did not believe developers received and addressed feedback on potential security risks while the development process was underway. Organizations with seasoned DevOps personnel were believed to be three times as likely to catch many security risks before their code advances to the test environment.

Pressure to deploy is real

Fletcher says many developers are under the gun to focus on getting code related to new features and functions out the door quickly versus writing secure code. “There is an inherent tradeoff and balancing of priorities that complicates matters,” he says.

Image: Colin Fletcher, GitLab

Developers want to write secure code and catch vulnerabilities early on, Fletcher says, but they many not have the necessary skills or management support to focus on prioritizing security. “It is literally more work to do,” he says. There could be organizational challenges, for example, if development functions such as testing are handled in separate groups.

Those different groups could have separate charters and mandates to adhere to. “They’re not necessarily working off of the same page at the data level,” Fletcher says. “It becomes difficult to create a symbiotic relationship needed to get to that DevSecOps nirvana.”

It comes down to the handling of software

The disparity is particularly pronounced given the pace of DevOps deployment, compared with non-DevOps software rollouts. The narrow window of time for delivery of DevOps applications can leave little room for security screening. Fletcher says continuous delivery and continuous integration, where DevOps applications are built and delivered in an ongoing basis, can mean deployment of code several times per day. That compares with non-DevOps generated applications that might be released quarterly or biannually.

Some enterprises have built practices born out of their DevOps implementations that combine learnings from developers and security to create an educational, leadership program that shares their experiences across the organization, Fletcher says. There is hope for more mutual understanding between security and developers. “There is a growing of identification of similar issues that are seen as barriers,” he says. “That is an indicator that the conversation about what needs to be improved is starting to reach critical mass.”