Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Edge Articles

08:00 AM
Ericka Chickowski
Ericka Chickowski
Edge Features
Connect Directly

Developers: The Cause of and Solution to Security's Biggest Problems

The everything-as-code revolution requires cybersecurity to increasingly enlist the help of developers to solve the industry's most pressing issues.

When cybersecurity professionals look across the technology landscape and witness the crush of vulnerabilities, the risky configurations, the poorly protected APIs, and the insecure application architectures, it can be easy to blame developers for them all. 

In the wake of that finger-pointing, security pros tend to look for ways to work around developers, to build systems and procedures that are as likely to block devs from getting valuable work done as they are to protect these engineers from themselves. 

However, there's a sea change in the air.

Many veteran security pros who have been there and done that say the industry is looking at this in the wrong way. True, many security problems today arise as a by-product of a developer's work. But more than anything else, many of the issues have their roots in security's inability to adjust to a code-based world. 

"As security professionals, we've been trying to avoid applications and code for a long time. It was complicated. We didn't understand it. We didn't know what was going on inside it," says Hillel Solow, co-founder and CTO of Protego Labs. "We built an entire practice around, 'How do we build security controls around things without having to worry about what's happening inside them?' We put things in the front and the back, on the bottom and the top."

That approach is falling apart at the seams as security professionals deal with what Solow calls the "revolution of everything as code." The implications of poorly secured code creep far beyond the limited confines of Layer 7. With increasing enterprise reliance on cloud-native technologies like containerization and serverless deployments, the growing use of infrastructure-as-code to spin up and down new computing instances, the rise in software-defined networking, and the explosion in complexities from layering embedded systems upon embedded systems, everything always comes back to code. 

"We've moved over the past 30 years from hardware to software, layer by layer. And we're now at the point where the vast majority of what we deploy in our value is lines of code, whether it's, you know, C code, or Python code, or cloud formation templates, or Terraform, or something else," he says. "Those of us in security who don't understand code are really struggling to keep up."

Solow and many others like him believe the only way security can possibly keep up is if they stop blocking developers and start enlisting their help. Forward-looking technology experts predict that smart developers are the industry's best hope for solving some of the biggest security problems today. 

Making Developers Your Highest Hiring Priority
Seeking out developer assistance starts from within. Many longtime appsec advocates believe security managers need to kick off a change in tactics and strategy by putting developer resumes at the top of the stack for new hire candidates.

"Hiring developers on your team allows you to better speak the language of developers and better influence software development to positively impact security," says Zane Lackey, co-founder and CSO at Signal Sciences. As a former CISO at Etsy, Lackey says one of the best hires he ever made was when he snagged someone internally from his firm's software engineering team for the security crew to focus on development tasks that would positively impact security. 

These kinds of tasks can include building security tools and integrations, but they also extend far beyond that. 

Security developers can bring a fresh perspective to the table when the security team convenes to make policies and procedures — they'll help everyone line up security requirements with business priorities and development realities. They may also take a hand in transforming those developer-friendly policies into security-as-code and what Lackey calls a "golden path" of secure configurations, common libraries, or third-party code that can be shared across engineering projects, encryption standards, and so on. 

"Investing in bringing developers on those security teams can help them build things that are going to be directly consumed by engineers," Lackey says.

He is far from an outlier in this view that security needs to hire more developers. Hit up security and DevOps conferences today, and you'll increasingly run across security managers who are pushing hard for the industry to prioritize development experience.

"I only hire developers; I don't hire security people anymore," says John Melton, application security senior manager at Oracle NetSuite. "If you're a security person and you can't code, you should learn how, or you should hire people on your team who know how to code."

As Melton explains, the lack of development knowledge is endemic in the security world, and it's hurting security teams in so many ways. He's far from the only one to voice those concerns. According to Larry Maccherone, who runs the DevSecOps transformation at Comcast as senior director in the technology and product division's security and privacy group, a lack of developers on security teams does the most damage to the team's credibility. 

"I believe you can't keep telling developers how to do their job if you aren't also writing code," says Maccherone, who, similar to Melton, almost exclusively only hires developers these days. Maccherone says it is much easier to train a developer in security fundamentals and mindset than it is to teach a security vet how to code. He thinks the only way to bring the kind of street cred to the table necessary for eye-to-eye conversations between security and software engineers is to bring experienced devs into the security fold.  

In the process, the industry may well be able to kill two birds with one stone. With the industry struggling to make qualified security hires, it may be time to stop looking for security unicorn hires and start recruiting trainable developers to fill in some vital gaps. 

It doesn't even necessarily have to be as extreme as how Melton or Maccherone approach things. 

{Continued on next page}

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio
1 of 2

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
10/25/2019 | 7:15:10 AM
organizations don't care about security
In my book High-Assurance Design, I provided an Agile and application software-centric view of security. Instead of a top-down dot-every-i-up-front process like the security community was then advocating, I provided a set of design patterns and principles, as well as practices that could be adopted by Agile teams. That was in 2005. The book received rave reviews, but hardly anyone bought it - unlike my previous book on enterprise Java programming, which was a best-seller. Programmers are simply not interested in security. And that is because their managers are not asking for it. I do Agile and DevOps transformation consulting today, and security is never - never - a priority. It rarely even gets mentioned.

There is also a-lot that is broken about fundamental choices that the IT industry has made. I go into that somewhat in this Medium article: https://medium.com/@cliffberg/the-it-industry-is-a-disaster-42743c2921e0

Cliff Berg

Flash Poll