There is history between developer and security teams. There’s always been tension between the need to deliver working software rapidly and the need to ensure that software operates securely. Today, organizations are under more pressure than ever to deliver applications quickly, and the tools available for development are geared towards supporting that velocity.
Specifically, the dramatic increase in APIs and programmatic connections has supported faster delivery in recent years. AI-assisted development is just the latest iteration of that velocity-driven toolset, touting increased developer productivity as a key benefit. It’s this drive for velocity that has allowed innovation to flourish.
At the same time, this obsession with speed comes with a cost. Security teams will tell you that cybersecurity is being left on the cutting room floor for the sake of expediency, ultimately at great risk and cost. And they have the receipts to prove it. Recently, we’ve seen significant incidents with MoveIt (affecting 60M+ people), Dell having millions of records compromised, Mercedes-Benz disclosing a GitHub token vulnerability, and more yet to be disclosed. While it’s easy to look at these individually, the collection of incidents together forms a pattern. The push for velocity delivers less secure code.
VP of Product at Wallarm.
Can these two disparate viewpoints be reconciled?
In order to understand this tension better, and perhaps view a path towards resolution, we can examine the specific topic of vulnerabilities. In this case, we’re talking about a flaw in software that allows an attacker to carry out an unauthorized action with malicious intent. If you’re in information security, you know there are essentially infinite vulnerabilities to be addressed with finite resources, with cyber adversaries waiting in the shadows.
These vulnerabilities exist because a developer created them, though not intentionally, and increasingly not directly. There’s rarely any argument over addressing vulnerabilities that are clearly high risk or have already been exploited, but there’s plenty of room for disagreement about what constitutes “high” risk, and the relative priority of fixing vulnerabilities that are lower on the risk index. In fact, there are whole companies dedicated to defining the priority of vulnerabilities.
Vulnerability prioritization is a microcosm of the larger cybersecurity environment. Principles are easy to agree to, but details are hard.
In the end, the path to resolution is for security issues to be prioritized based on their operational impact. In other words, both security and development have to give a little and agree that some issues are truly critical and some 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 drive 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-driven development directly supports this type of automation. Automating security testing as part of the CI/CD process, however, only addresses the process, not the mindset.
Technology alone just isn’t the answer
A cultural shift is also necessary. Developers need to be educated about how security issues impact the business, and training in best practices for writing secure code needs to be based on that business need. Security teams, in turn, need to understand the business pressure developers face and work to be 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.
Moreover, organizations need to adopt a business-risk-based approach to prioritization. Not all vulnerabilities are created equal, and prioritizing them based on the potential impact on the organization is critical. This involves assessing not only the technical severity of a vulnerability but also the business context. For example, a vulnerability in a business-critical API that handles sensitive customer data should be prioritized over an equally severe issue in a low-risk internal application. These problems aren’t easy to solve, however.
One of the aims of DevSecOps is to foster cross-functional communication. Effective communication between development and security teams is vital. Security teams must articulate the risks and potential impacts of vulnerabilities in a way that resonates with developers. This means going beyond technical jargon and framing the conversation in terms of business risks and operational impact, which requires that both teams have the same understanding of that business context.
The tension between developers and security teams is ultimately rooted in their differing priorities: speed versus safety. Establishing a common ground for prioritization around the 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 towards the same goal: delivering secure, high-quality software.
We’ve listed the best cloud antivirus.
This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro
