3 tips for effective developer security training

“This is the golden era of application security,” says Founder of Manicode Security and secure coding trainer Jim Manico on episode 26 of The Secure Developer podcast.

Ten years ago, Manico says, security training was “a quirky thing to do — something to do on the side.” Now, assessment tools are mature, good literature on assessment makes knowledge more accessible, and a wide range of intelligent people are building secure applications.

Living in the golden era doesn’t mean security as a problem is solved; instead, it means we know what needs to be learned, and we have the resources and the willpower to provide that education.

In this article, we’ll dig into three tips that can make your developer security education program better and ensure that you’re reaping all the advantages of the golden era of application security.

1. Clear the way to learning with clear security requirements

Developer security education is impossible without a clear, shared understanding of what application security is.

That’s why, according to Manico, setting out clear security requirements is one of the most important things companies can do to educate their developers. “I want a clear definition of security requirements,” Manico says, “so we’re all on the same page of what this thing called application security really is.”

Though many would instinctively reach for the OWASP Top 10, Manico recommends steering clear. Instead, Manico recommends the OWASP application security verification standard, which comes with over 200 requirements. The best part of using this standard, Manico says, is that it pays off no matter how well the team eventually uses it.

“At the high level,” Manico says, “we have the requirements rolled out, and we’ve translated all those requirements into where it exists in the framework, where we need to do it ourselves manually, and where we have third party tools to help us.”

But even if teams don’t go that in depth, there’s still value to be found. “I’ve seen people roll out requirements, never read them, and still have that process be helpful because the tech leads were able to influence the lead developers for four or five hours just talking about what’s important for security,” says Manico.

Working through security requirements, then, provides a useful consensus on what developers and security teams need to do to achieve some level of application security. Even if teams don’t go as far as they can, reaching a consensus can help a lot.

“No matter how you roll them out, it’s going to be helpful in some way,” says Manico.

2. Make development teams self-sufficient with a security champion

Tears are shed at every high school and college graduation despite the fact that graduation is the goal. Eventually, even if it’s emotional, every educator wants to see their students become independent, self-sufficient, and successful.

The same goes for developer security education. Companies are right to bring in outside security consultants and educators, but they’ll want to select ones that think proactively about how teams will operate once the educator is gone.

Nick Vinson, DevSecOps Lead at Pearson, does just that. According to Vinson, on episode 84 of The Secure Developer podcast, the primary goal of his work is to “provide the team with the tools and the knowledge they need to be self-sufficient.”

To do so, Vinson’s team embeds expert security engineers into the teams they’re working with. Embedded engineers act as fully contributing team members with the ability to make, test, and deploy changes into production.

While on the team, these embedded experts perform threat modeling to identify security risks and vulnerabilities. They also implement automated security testing capabilities into the SDLC, all the while making sure, as Vinson says, that “the teams know what to do rather than just box-ticking.”

To make that new knowledge really stick, the embedded expert trains up an internal security champion alongside providing work and advice. “That’s our main responsibility,” says Vinson.

By embedding a security engineer, Vinson can achieve two goals in parallel: building up application security quicker and training up a security champion that can make those secure coding practices last.

3. Build credibility with developers to create trust

People are often cynical about the potential of educating developers about security. Won’t developers just treat security as a box-ticking exercise, a distraction from their main work?

Jet Anderson, Security Engineer at Amazon, reacts bluntly on episode 98 of The Secure Developer podcast: “That’s horseshit — I don’t think that’s true at all.”

Counter to these assumptions, Anderson finds passion for security among developers. “I find developers to be intimately aware of and desirous of good quality and they want to do the right thing,” says Anderson. And security is very much part of doing the right thing.

According to Anderson, the reason for the gap between developers and security engineers isn’t developer apathy — it’s a lack of mutual understanding.

“It’s not that developers don’t care,” Anderson says. “It’s that folks in information security don’t necessarily have the deepest knowledge of software development, so they may lack the credibility or even the language to accurately explain the risk or accurately explain the flaw.”

As an example, Anderson uses the term “vulnerability.” Among information security people, the term is common and used in a variety of contexts, but developers might better understand different terminology. Anderson says that what security folks are often finding can better be described as defects and that a defect should only be described as a vulnerability if an exploit is found for it.

“That small sort of minutia is part of the change of culture,” Anderson says. Though it might seem small, language changes like these repeated across many different contexts can create many more opportunities for shared understanding between security engineers and developers. With a shared understanding established, developer education can be much more successful.

Shifting left into the brains of developers

Shift left refers to the work of taking security, which traditionally takes place at the end of the SDLC, and moving it to the left, toward the beginning of the SDLC. But, according to Anderson, you can shift further left, beyond the first stage of the SDLC. “I couldn’t think of a place earlier in the SLDC than a developer’s brain,” says Anderson.

Organizations that want to shift left, that want to make security a part of fundamental application design, need to be aware of both the stakes of doing so and the starting points they may have. Many developers can graduate from college or get a certification without learning anything about security. If you want to shift left, developer security education is essential.

Get more expert security tips by subscribing to The Secure Developer podcast today.