Developers Remediate Less Than a Third of Vulnerabilities

Developers are regularly ignoring security issues as they deal with an onslaught of issues from security teams, even as they are expected to release software more frequently and faster than ever before.

In addition, developers fix just 32% of known vulnerabilities, and 42% of developers push vulnerable code once per month, according to Tromzo’s Voice of the Modern Developer Report.

The report, based on a survey of more than 400 U.S.-based developers who work at organizations where they currently have CI/CD tools in place, also found a third of respondents think developers and security are siloed.

Tromzo CTO and co-founder Harshit Chitalia pointed out the top security vulnerabilities of the past few years—Log4j, SolarWinds, Codecov—have all been supply chain attacks.

“This has made AppSec an urgent and top priority for CISOs worldwide,” he said. “In addition, everything as code with Kubernetes, Terraform and so on have made all parts of the development stack part of AppSec.”

From his perspective, the only way this big attack surface can be overcome is with security and development teams working hand in hand to secure the application in every step of the development cycle.

He added developers ignoring security issues is one of the fundamental issues AppSec engineers have with security.

“Security teams put their blood, sweat and tears into finding different vulnerabilities in code through orchestrating scanners and manual testing,” he said. “After all the work, seeing the issue on Jira queue for months is disappointing and quite frustrating.”

Fighting Friction

On the other hand, he pointed to developers who are now asked not only to develop features and fix bugs but also look at DevOps, performance and security of their applications.

“This leads to friction in priorities and, if unresolved, leads to unhappy employees,” he said. “The C-suite is very much aware of this problem, but they are stuck with security tools which are not created for developers. As application security is going through a big transformation, we believe the tooling will also shift.”

He explained there were several concerning findings from the survey but that two, in particular, stood out.

The first thing Chitalia found deeply concerning was the fact that 62% of developers are using 11 or more application security tools.

He said application security has evolved in recent years with AppSec teams now responsible for source-code analysis, DAST, bug bounty, dependency, secrets scanning, cloud scanning and language-specific scanners.

“This means developers are constantly fed information from these tools without any context and they have to triage and prioritize the workload these tools generate for them,” he said. 

The second big worry was the fact that a third of vulnerabilities are noise.

“If someone told you that a third of the work you did needs to be thrown away every single day, how would you feel about that?” he asked. “But that’s the current state of application security.”

False Positives a Big Negative

Chitalia explained that this is not a problem with one security scanner giving out false positives, but the lack of context these scanners currently have and provide—or don’t provide—to developers.

“In addition, a critical vulnerability for one company may not necessarily have the same level of impact for another one,” he said. “Each one needs to be viewed in the context of the application it is affecting and its attack vector, which makes triaging and prioritization such a hard problem.”

From his perspective, companies need to take a multi-step approach to this complex problem, with a particular focus on visibility and governance. 

“You cannot fix something you cannot see,” he said. “Organizations must have real-time visibility of the overall security posture of the application from all the different scanners. That means you need the ability to triage, prioritize and assign vulnerabilities with custom rules specific to the organization.”

Another key approach to making security easier for developers is a cultural change that includes a shift left mentality. 

Chitalia explained that for many years, developers were told that their primary role at their organizations was to quickly build and deploy apps; to move fast and break things.

The faster developers could code and the more features they could deploy, the more valuable they were seen in terms of their performance reviews.

“However security was never part of the discussion,” Chitalia said. “This needs to change. Security should not be an afterthought but something which is ingrained into the development life cycle,” he said. “Every step of the SDLC needs to be secured.”

Finally, it will be imperative for organizations to build a security community through security champions and rewarding teams.

“Establishing a community of security champions within the developer workforce enables AppSec engineers to communicate faster and creates a community of developers eager to make applications secure,” he said. “In addition, we have to start tracking progress and metrics for teams with leaderboards and gamification.”

Nathan Eddy

Nathan Eddy is a Berlin-based filmmaker and freelance journalist specializing in enterprise IT and security issues, health care IT and architecture.

nathan-eddy has 253 posts and counting.See all posts by nathan-eddy