Acronyms are not unique to cybersecurity, but they have become a hallmark of how we communicate with each other. Do we really need to add this layer of complexity to an already complex industry? Or are they just making our developers more depressed? Let’s make security accessible and viable.
The cybersecurity industry is experiencing record growth, with 20% year-over-year growth, built on the promise of greater productivity. And yet, developers often struggle to focus on what matters. Instead, they find themselves with another new acronym that makes them turn to that dictionary every time they want to do something. We’ve developed something unique in the cybersecurity industry: a language that no one speaks natively.
Security researcher and Aikido advocate.
The power of a common language
The root cause of all our communication problems is that we describe security tools by what they are and not by what they do.
Take “static application security testing” as an example; that doesn’t really mean anything to people who don’t know what it is yet. But what it really does is try to protect our code. With that knowledge, we can immediately try to understand what “dynamic application security testing” is. It’s semantics, not guesswork. (PS: the latter is like a hacker trying to find vulnerabilities in our applications).
My main frustration is that I can’t understand why we actually need an acronym for those things when we could simply describe what they do. When we create security tools, we should be able to easily describe what they do in non-technical terms, rather than trying to describe what they are.
As this communication barrier moves up the chain and crosses the technical divide, these problems are further amplified. At board level, security teams have their backs completely against the wall in terms of funding. We have this catch-22 situation where security teams aren’t getting enough funding, or at least they don’t think they’re getting enough funding, and we’re also experiencing a lot more security attacks. One of the biggest problems is that at the board level, decision makers don’t understand much of what is needed. Because they don’t understand what things really do. You can’t walk into the boardroom and ask the CEO to give you some money to buy a CNAPP.
The cynic in me also sees many of these acronyms as money printing machines. When we create new acronyms to replace old ones and say we need new tools for them, it seems like an upsell. And even when something might be necessary, it’s difficult to separate needs from deception.
The value of clarity.
There is a sense of disbelief that I will still be beating this drum in 2024, but we must address cybersecurity more comprehensively. We tend to protect entire applications or entire software developments in separate stages. They are in silos. What if we could leverage all this innovation to create an approach to security that feels like a natural part of development? These are the four key areas we need to focus on. In simple language, of course:
Securing our source code – This covers everything written in code, including infrastructure as code. It’s about writing secure code from the beginning.
Secure our application at runtime – This is about protecting our application while it runs. Can an attacker find vulnerabilities? This includes fuzzing tools (tools that try to break your application by throwing unexpected data at it), API testing, and what we typically call “dynamic testing.”
Protect our cloud environments – This means protecting the infrastructure on which everything works.
Secure our supply chain – This covers dependencies, open source components and third party elements.
Four areas. Clearly explained. And it’s much easier for developers to understand because, rather than being hit by an acronym that does something slightly different or combines two different functions, priorities are clearly established.
As former Ubisoft CISO Jason Haddix told me on my old Security Repo podcast, “being able to break down technical terms into non-technical terms really got me to where I got.” It confirmed to me that this is the skill you need to be successful, and the acronym doesn’t help at all. Even if we discard the acronyms, there is still a way to go. If you are talking about “we need a static application security testing tool” or “we need an infrastructure as a code testing tool”, what we should say in the boardroom is “we need these tools to protect our source code” and “We need these tools to protect our application.”
Here’s the reality: Acronyms are designed to be understood by a small subset of people. However, we have (at last count) over 300 of them. We need to move from a culture of complexity and exclusivity to one of clarity and inclusion. When we communicate effectively about security, we do more than transfer information: intelligent communication respects developers’ time and cognitive load. It also allows communication to move effectively up the chain, meaning it is no longer a misunderstood and underfunded part of the organization.
We have rated the best endpoint protection software.
This article was produced as part of TechRadarPro’s Expert Insights channel, where we feature the best and brightest minds in today’s tech industry. 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:
