Your Next Security Hire Might Need to Be a Developer – InApps 2022

Recently, a colleague working in a large company told me that his CISO boss would not hire any new security personnel unless they had spent time developing software. This was seriously offensive to this friend, who is the consummate security professional, with years of experience protecting the largest of companies from the risks of cyber attacks. While I don’t condone telling your best employees that they might lack the credentials to do their own jobs, it’s worth understanding the motivations behind this boss’s pep talk.

For a long time, security people have tried to avoid the applications they protect. The prevailing theory among security teams is that developers are reckless and unredeemable, and they have the statistics to back that up. The frequency of developer mistakes that create security risks had been about the same for about 15 years. We’re not really getting better at this, for myriad reasons I won’t speculate here.

This view of developers has left security teams with two basic strategies. Try and engage with what’s happening inside the application, or try and secure it from the outside without knowing what was happening on the inside. As you might have guessed, the latter strategy is far more common than the former.

A Sandbox for Everyone

Our security strategy has usually boiled down to trying to insulate the application from its own stupidity. We throw a web application firewall (WAF) and some network security in front of the application, some sort of agent in the operating system below it, and maybe a database firewall behind it. If it goes rogue, we figure we can keep the damage contained.

This strategy hasn’t been particularly effective in general, but it’s getting far worse as we shift to cloud native applications and serverless computing. That’s because by and large, we’ve shifted ownership, control, and management of these layers to the cloud providers. We don’t handle the network configuration the way we used to. We don’t manage the operating systems anymore. Our applications comprise of code and APIs, and if we’re going to secure them, we’d better start understanding them.

DevSecDevOps

The CISO in the story may have been brutally blunt, but I can understand where the sentiment comes from. As security people, we need to engage with the application, not avoid it. We need to understand what happens inside the application, so we can protect ourselves from risk. Security teams need to understand the ramifications of design and programming language choice. They need to be able to do security code reviews with developers. They need to be able to properly configure security tools based on this information, and prioritize risks based on where they are in the code and how likely they are to be exploited.

In short, security can no longer avoid code. Honestly, this is a good thing. Security will become much more effective when it becomes code-centric. At the same time, if you hire a bunch of developers to handle your security, you’re going to be in for a rude awakening. Just because doing security well requires understanding the mindset and world of a developer, does not mean that all the collective wisdom we’ve amassed on how to do security goes out the window. You need both in order to have balance.

Can I Clone My Security Team?

Unfortunately, the idyllic solution of security people who know how to read python and rust doesn’t actually work on its own. That’s because doing security at the level of code and APIs doesn’t just require a better understanding of the programming stack. It also translates into an insurmountable number of decisions that need to be made. Making code-level security decisions, such as provisioning IAM roles, ensuring your code doesn’t contain risky flows, and ensuring third-party components are risk-free is an endless (and thankless) task.

Here is where automation isn’t just “nice to have” but a full-on requirement. If you can’t get most of these processes automated, in CI/CD and during production, you’re never going to keep up, even if all your developers are Linus Torvalds and Guido van Rossum. But if you can, you’ll never look back.

Feature image via Pixabay.