eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
There is no shortage of data breaches and exploits reported in any given week, with many of them having a root cause in some form of application code vulnerability.
There are many reasons why developers don’t always write secure code, and conversely there are many ways that security professionals can help developers, according to Tanya Janca. Speaking at the SecTor conference in Toronto on Oct. 3, Janca who is a lead developer of the OWASP DevSlop project and a senior cloud advocate at Microsoft, explained what can be done to enable secure coding practices.
“I feel like it’s really hard right now to make secure software,” she said. “My goal is to make the default way the easiest way to do secure coding.”
In her experience working as a developer in different organizations, Janca said security and developer teams were often confrontational. Developers would build code and security professionals would tell them do things a certain way, with little or no explanation.
She said that the lack of coordination and integration between security and development teams leads to developers feeling insecure. When a developer, or any employee for that matter, feels insecure, it leads to disengagement, reduced job involvement and ultimately poorer outcomes, she said.
The Plan
Janca outlined a basic two-step plan to improve and enable secure software development processes.
Step 1: Support dev and security teams with processes, training and resources so they can confidently get the job done.
Step 2: Initiate and then maintain the culture change.
As part of the first step, Janca said organizations should have application security (appsec) teams that work together. Netflix, for example, has a model called the Partnership Project where security people are “martrixed” in to provide developers with information and help on secure coding practices. As such, when a developer isn’t sure of the right security approach to take, he or she is mentored and helped along the way by a security person.
“They have a security person that is assigned to each developer, and that person goes and finds all the answers,” Janca said.
Shift Left
Security often comes at the end of a development process that is at the right side of a chart on a chain of operations. The development process typically includes requirements, design, code, testing and then release.
Rather than leaving security until late in the process at the testing or pre-release stage, Janca advocates for security to be “shifted left” to be an integrated part of the earliest stages of the development process.
“When you get development requirements, check them out and make sure they have security requirements,” she said.
Another benefit of “shifting left” is that rather than security being some big final exercise at the end of a development process, security activities can be broken up into smaller pieces that are integrated throughout the development life cycle.
In Janca’s experience, security people will often run some form of code scanner and then simply pass off the results to developers to interpret. As part of an integrated process, she suggests that security professionals validate scan results first, to identify any potential false positives, before sending to developers.
Training
Having security professionals work with developers is a good process, but what is equally important is to provide security training to developers, so they can help themselves. Janca said organizations should provide free secure coding training for developers on a regular basis to enable and encourage a proactive secure development culture.
“If you write code every day, you should have secure coding training,” she said. “If you design software, you have secure design and threat modelling training.”
Tools
There are myriad tools that developers already use for coding, and there are multiple tools that can be used by developers to improve software security as well. Janca recommends that developers look at tools from the Open Web Application Security Project (OWASP), including her own DevSlop set of tools, that provide a free starting point for developers.
Overall, Janca emphasized that developers, not necessarily dedicated security professionals, are the key to improving software security. She said that in her experience there are often 100 times more developers in an organization than dedicated security professionals. While there is time and financial cost to training and improving developers’ secure software development practices, Janca said the cost is worth it.
“A breach will cost more than doing secure development,” she said.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.