Modern Software Development

Software development is undergoing fundamental changes that are completely changing the face of the application attack surface. Modern software teams are moving faster and their development patterns are shifting dramatically. Developers favor assembling together microservices and open source software components into smaller applications. Those are then bound together with more API integrations and abstraction layers than ever. This is contributing to new kinds of vulnerabilities, as well as recombined — and sometimes more toxic — versions of the same old types of vulnerabilities that application security teams have been dealing with for years.

Security experts and development professionals generally agree that the only way that the industry will solve the appsec problem is through more effective security training of developers. The trouble is that even before the advent of the modern DevOps and continuous integration/continuous delivery (CI/CD) movements, dev training has been nonexistent to nominally effective at best. Now with things changing so quickly, the traditional appsec training regimes that orgs have in place are not in line with the tools or processes that engineering teams engage in.

"Traditional developer security training has never been as effective as it needs to be; take a look at the OWASP Top 10 to see that we are still suffering from the same common issues as a decade ago," says Fletcher Heisler, CEO and founder of Hunter2, on the trouble with traditional developer security training. "We give the same generic advice in our training while development frameworks have continued to evolve."

Heisler is teaming up with Mark Stanislav, head of security engineering for Duo Security, now part of Cisco, to present at Black Hat on August 8 on how organizations need to change in order to equip their developers with the knowledge they need to build more secure software.

"It's often the case that generic education modalities — like recorded lectures and quizzes — are used for secure software development when that approach is fundamentally at odds with how software engineers generally learn: by writing code," Stanislav says.

Furthermore, as Heisler suggests, the content itself is often not in line with how the developer's fast-evolving set of tools actually work. 

"Secure code training should focus on how best to make use of modern web development tool sets," Heisler says, explaining that, for example, most modern web frameworks include some default protections against SQL injection. "The tools are already out there, but they're evolving rapidly, and we need to give developers practice writing modern secure code in their frameworks of choice." 

On the flip side, while many newer developer tools and methods do add opportunity for enhanced security, others do not come with prebuilt security guardrails — leading to developers sometimes assuming something is secure that is not. Which means security teams and engineering leads have a responsibility to stay on top of and communicate the new risks. 

"Modern application development is adding more abstraction to what a developer writes, to what it does," Stanislav says. "Engineers often believe a feature provides native security where it does not, leading to an assumption of creating safe code when in practice, it is vulnerable." 

Similarly, they should be providing enough of a security baseline education that developers can start sniffing out risks on their own, Stanislav explains.

"Educating software engineers at deeper levels will allow them to use their expertise to better discern where risk may exist, enabling them to be more defensive in development and lead to empowered work that yields better net security results," he says.

In order to get there, Stanislav and Heisler will suggest that security professionals tasked with developer training start to question the content and teaching methods of the past. This skeptical view should dig deep — perhaps even going so far as to question the industry's reliance on OWASP Top 10 as a teaching aid and safety checklist.

"The OWASP Top 10 serves a distinct purpose, which is to provide a two- to three-year lagging indicator of web application security. In practice, however, much of the industry has co-opted this resource as a de facto standard and often checklist of what issues must be fixed," Stanislav explains. "That has led to a reduction in awareness of the many vulnerability types not explicitly highlighted by the OWASP Top 10."

In order to help the community improve the way it trains developers, Stanislav and Heisler will be releasing at their talk a free training platform meant to be shared among development teams that includes interactive training labs designed to help engineers practice exploiting and patching up modern web applications in their framework of choice. 

"Deploying new code five times a day means you can't wait for an annual training on outdated topics. Instead, we need to be sharing the latest, up-to-the-day information on best practices and secure coding techniques," Heisler says. "That is what we hope to accomplish in releasing an open platform where teams can easily share their latest findings in interactive labs."