Let’s face it: software development is moving at warp speed. Between the explosion of AI and the ever-present flood of open source vulnerabilities, you’d think staying sharp with the latest cybersecurity skills would be priority number one for dev teams.
Apparently not.
New data from Snyk’s 2024 State of Open Source Security Report just dropped, and frankly, it’s raising some serious eyebrows. It shows companies are cutting back on investing in essential security tools and training.
Consider this stunner: the number of organizations actively training their developers on supply chain vulnerabilities plummeted from 53% last year to just 35%.
In a world grappling with sophisticated AI-driven threats and complex supply chain risks, this feels like companies are deciding to navigate a minefield without a map… or a minesweeper. If teams aren’t equipped to spot, understand, and tackle new threats, they’re flying blind.
Head of Developer Relations & Community at Snyk.
Is open source security hitting a wall?
It’s not just training that seems to be lagging. Efforts to improve open source security – and even broader DevOps efforts – might be stalling out.
While more organizations now report tracking all their software dependencies, a sizable portion still only track direct dependencies. That leaves a massive blind spot for hidden risks. A small but significant minority aren’t tracking dependencies at all. Yikes.
Meanwhile, code ship frequency hasn’t budged. This suggests the industry might be hitting a plateau with current DevOps methods, potentially bottlenecked by security processes.
It seems teams are also struggling to adopt even the basic security toolkit. We looked at eight common AppSec methods, and each one fell worryingly short, including standard tools like Software Composition Analysis (SCA) and Static Application Security Testing (SAST). Worse still, essentials like license scanning, secrets scanning, supply chain security and dependency analysis are being used by less than half of the teams surveyed.
Are developers simply drowning?
Maybe this isn’t just about budgets. Maybe developers are overwhelmed. Why? The fact that companies are setting ambitious goals for fixing vulnerabilities (SLAs), but teams just can’t keep up, is a flashing red light.
In many cases, security SLAs now demand fixes within days or even hours. Yet despite these ambitions, it’s clear that teams often miss the mark.
Process, tech, and training issues are often to blame. If teams aren’t meeting SLAs or using fundamental security tools, leaders need to ask: why? Is the tooling inadequate? Or are teams lacking the training to use what they have effectively, especially when buried under the sheer volume of open source packages?
The training gap: a foundational flaw
A lack of training is a foundational problem that makes everything else harder. Teams might be leaning too heavily on tools to automate security, perhaps without fully understanding the output or limitations. And with AI tools churning out potentially vulnerable code, a lack of training on how to validate and secure that output is just asking for trouble.
Without the right skills and facing buggy code from immature AI copilots, trust in the entire software supply chain – that complex web connecting tools and organizations – is at risk.
As security increasingly shifts left, developers are asked to shoulder responsibilities that previously belonged to dedicated AppSec teams. Yet many have had little formal education in secure coding practices or threat modelling, and most also need to focus on honing their use and understanding of evolving models.
Job roles are changing faster than titles, training programs, or even the experience needed to keep up. Do companies actually know how to properly support developers to succeed in these expanded roles?
Organizations could consider the evolving training and experience demands for their developer roles and regularly publish guidance on what new hires must aim for to succeed. When it comes to training, there needs to be a fast feedback loop as to what’s relevant and working for the business, and how it can be taken on board efficiently by busy developers. That may mean contextual, in-flow training, simulation-based learning, hackathons, or other alternatives to traditional education tactics.
Finally, who’s accountable for ensuring developers are adequately trained? Is it the CISO? The VP of engineering? Team leads closer to the action? Something to think about…
Time for a reality check: What companies need to do now
Ignoring this isn’t an option. Organizations need to take a hard look at their approach:
- Prevent burnout: Sustainable security practices are key. It’s a marathon, not a sprint. Re-evaluate workloads and processes.
- Prioritize smarter: Focus vulnerability management on the risks that matter. Not all vulnerabilities are created equal. Use holistic risk analysis when setting those SLAs.
- Nail the basics: Double down on adopting fundamental security measures like SCA, SAST, dependency tracking, and secrets scanning.
- Invest in your people: Seriously reinvest in relevant, up-to-date training. Equip developers for the threats they face today including AI risks.
- Be skeptical of AI code: Treat AI-generated code with extreme caution. Implement rigorous security reviews – don’t assume it’s safe. It needs at least the same level of scrutiny as human code, if not more.
The bottom line: a dangerous mix
Putting too much faith in immature AI, letting training slide, and skipping basic security checks? That’s a toxic brew. It creates a perfect storm for vulnerabilities to flood the software ecosystem. This isn’t just a technical footnote; it’s a real threat to the stability and security of our increasingly connected world. Cutting back on training might seem like saving money now, but it’s a gamble companies can’t afford to lose.
Check out the best online cybersecurity courses.
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
