The first rule of finding a solution to a problem is by acknowledging that it exists. In almost every organization, there’s an inherent disconnect between developers and security professionals, creating seemingly irreconcilable friction between two core teams that organizations rely on for secure production and efficient business operations. While often dismissed, ignored or generally accepted as a fact of life, this friction has potentially detrimental consequences on organizational output, culture, and security. As security professionals, we all should have a vested interest in finding creative ways to bridge this gap, whether by fostering constructive dialogue or by building innovative solutions.
A conflict of interests
This divide between security and developers dates back to when security teams were dubbed the “Departments of No,” alluding to the typecast of a traditionally obstructive security leader who prioritized security over business objectives or innovation. While this was never really the case, the chasm between those driving production (insecurely) and those attempting to secure the organization (unproductively) ran wide and deep.
As always, to find the root of the problem we have to look at the interests and goals of both sides. Developers have one overarching goal: develop features and products and release them to production quickly, for customers to use. The more output, the more revenue for the company. They are evaluated on their ability to run fast, focus on what matters, and leave everything else behind. Security, unsurprisingly, is part of “everything else.” Security teams have different – and practically opposing –performance metrics. They have to control the aforementioned output, review it and place guardrails on it to ensure its security. By nature, they have to slow the process down while developers have to speed it up. Herein lies the contrast.
The CISO evolution
In the past, security teams had security tunnel vision, with business objectives seemingly irrelevant to their core responsibilities. They used restrictions and guardrails that were incompatible with developers’ need for speed, but served the purpose of securing infrastructure and data. CISOs needed visibility into processes and workflows to control them, inevitably causing interruptions and delays that irked developers. The digital revolution led to tectonic shifts in the modern business environment, changing priorities and upending conservative conceptions. CISOs today help set, define, and implement business strategy. They are business leaders who provide boardrooms and C-suite executives with critical information on the company’s security posture and offer security teams critical business context to ensure alignment with company goals. Security today has become a collaborative, streamlined operation requiring the participation of various teams and elements within organizations. It’s a far cry from the siloed image of security in the past.
One would assume that this modernization and evolution would help close the gap between developers and security professionals, but it has actually increased friction. As cloud adoption soared and attackers grew in sophistication and scope, new cloud security products came onto the scene, offering automated visibility and producing an overwhelming number of alerts, vulnerabilities, and security issues for developers. With more and more security tools discovering issues, prioritizing them differently, generating duplicates from other tools and generally creating alert fatigue and lots of noise for developers, an already volatile situation only became worse. Beyond a general lack of trust between developers and security teams, this rift has additional repercussions that warrant a closer look.
We can work it out
Seeking to streamline integration with R&D tools and avoid incurring the wrath of developers who need to step away from their jobs to deal with alerts, security teams often choose to adopt tools that don’t require developer involvement at all. It’s a viable option, but once all organizations create such siloes we will all miss out on valuable, enriching collaboration. Security tools for developers are unfortunately a niche market because of this sentiment, but these tools have the potential to significantly help R&D velocity while integrating with the tools that developers use, benefitting both teams. Another unfortunate result of this friction: we all miss out on the ability to develop safer products from the get-go. The sheer amount of findings that are produced without fully context-aware prioritization makes this option unattractive for developers, leading to the development of products that are less secure.
Once organizations embrace the problem and address this friction as a priority, we could slowly, but surely, change the entire industry’s approach. Instead of moving towards security silos and a complete disconnect between two teams of paramount importance, we could move towards building products that integrate security and development, providing full context on the engineering side and full visibility and prioritization on the security side.
Four actionable steps that security leaders can take to help make the security-developer synergy a reality include the following:
- Align interests: Security leaders and developer team leads must establish a common goal and common interests to rally their teams to deliver secure products, fast. They need to align their objectives and key results and add productivity-based goals to security work plans and security-based goals to engineering.
- Communicate better: Keep open communication channels between both sides. Find effective ways for R&D teams to communicate with security teams and the other way around, fostering productive dialogue on priorities, concerns and needs.
- Reduce the noise: Security teams, take note. Instead of bombarding the engineers with tickets and tasks, some of which are unimportant, irrelevant, or identical to others, weed out the most critical, urgent tasks and prioritize, deduplicate and assess them before sending them to developers for fixing.
- Integrate early: If security was integrated with developers and embedded into their tools, we could improve the ability to reach acute findings earlier.
Here’s yet another opportunity for the cybersecurity community to pave the way. They need to build security tools that offer more valuable alerts that could not have been discovered without integration with R&D, or tools that decrease the number of findings by using comprehensive context to prioritize and freeing engineers to work on the product itself. Organizations should also invest in educating security and engineering teams using productive dialogue to encourage openness and communication. We can’t give up on the necessity of collaborative security processes because there’s simply too much at stake.
Nadav Lev, chief technology officer, YL Ventures
