There is a history between development and security teams. There has always been a tension between the need to deliver working software quickly and the need to ensure that software works securely. Today, organizations are under more pressure than ever to deliver applications quickly, and the tools available for development are geared toward supporting that speed.
Specifically, the dramatic increase in APIs and programmatic connections in recent years has supported faster delivery. AI-assisted development is just the latest iteration of that speed-driven toolset, which touts increased developer productivity as a key benefit. It’s this push for speed that has allowed innovation to flourish.
At the same time, this obsession with speed comes at a price. Security teams will tell you that cybersecurity is being left on the cutting table for the sake of convenience, ultimately at great risk and cost. And they have the receipts to prove it. Recently, we’ve seen significant incidents with MoveIt (affecting 60 million+ people), Dell compromising millions of records, Mercedes-Benz disclosing a GitHub token vulnerability, and more yet to be disclosed. While it’s easy to look at these in isolation, the collection of incidents together forms a pattern. The drive for speed is producing less secure code.
VP of Product at Wallarm.
Can these two divergent positions be reconciled?
To better understand this tension and perhaps see a path to resolution, we can examine the specific topic of vulnerabilities. In this case, we are talking about a flaw in software that allows an attacker to perform an unauthorized action with malicious intent. If you are in information security, you know that there are essentially infinite vulnerabilities that must be addressed with finite resources, with cyber adversaries waiting in the shadows.
These vulnerabilities exist because a developer created them, but not intentionally and increasingly not directly. There is rarely any debate about how to address vulnerabilities that are clearly high risk or have already been exploited, but there is plenty of room for disagreement about what constitutes “high” risk and the relative priority of fixing vulnerabilities that are lower on the risk index. There are even entire companies dedicated to defining the priority of vulnerabilities.
Vulnerability prioritization is a microcosm of the larger cybersecurity environment. Principles are easy to accept, details are hard.
Ultimately, the path to resolution is that security issues are prioritized based on their operational impact. In other words, both security and development need to give in a little and agree that some issues are truly critical and others are not. This requires a mindset shift on both sides and a commitment to collaboration.
And while it’s not intentional, this sounds an awful lot like DevSecOps. Integrating security practices into the DevOps pipeline is one way to bring these two groups closer together. Embedding security checks and balances throughout the development lifecycle, rather than treating security as an afterthought, sounds like a great plan, and API-led development directly supports this type of automation. However, automating security testing as part of the CI/CD process only focuses on the process, not the mindset.
Technology alone is not the answer
A cultural shift is also needed. Developers need to be educated on how security issues impact the business, and training in best practices for writing secure code should be based on that business need. Security teams, in turn, need to understand the business pressures developers face and act as enablers rather than gatekeepers. Cross-functional training sessions and collaborative workshops can help build this mutual understanding and foster a culture where security is seen as a shared responsibility.
Additionally, organizations should take a business risk-based approach to prioritization. Not all vulnerabilities are created equal, and prioritizing them based on their potential impact to the organization is critical. This means assessing not only the technical severity of a vulnerability, but also its business context. For example, a vulnerability in a business-critical API that processes sensitive customer data should be prioritized over an equally severe, low-risk issue in an internal application. However, these issues are not easy to fix.
One of the goals of DevSecOps is to foster cross-functional communication. Effective communication between development and security teams is essential. Security teams need to articulate the risks and potential impacts of vulnerabilities in a way that developers can relate to. This means moving beyond technical jargon and framing the conversation in terms of business risk and operational impact, which requires both teams to have the same understanding of that business context.
The tension between developers and security teams is ultimately rooted in their differing priorities: speed versus security. Establishing a common ground for prioritization around business needs can help bridge that gap. By adopting practices like DevSecOps, leveraging automation, fostering a collaborative culture, and focusing on business risk-based vulnerability management, organizations can bring development and security closer together. Both teams must recognize that they are working toward the same goal: delivering secure, high-quality software.
We have listed the best cloud antivirus programs for you.
This article was produced as part of TechRadarPro’s Expert Insights channel, where we showcase the best and brightest minds in the technology sector today. The views expressed here are those of the author and do not necessarily represent those of TechRadarPro or Future plc. If you’re interested in contributing, you can read more here:
