In mature organizations, development teams are being asked to take ownership of integrating security earlier in the software development lifecycle. Likewise, security teams are more actively engaging on the development side, and there is less friction between the two than in the past. Chris Eng, Chief Research Officer, Veracode, says, “There’s a greater understanding of priorities between both teams. Developers want to create high quality, secure code. The problem we see most often is that developers have never had formal training in what secure coding is either in their education or while on the job.”
As development and release cycles speed up, developers are looking for ways to incorporate security testing in less intrusive ways. Eng shares some insights into how developers are moving to a DevSecOps model.
What are some of the challenges that can arise when incorporating security earlier in the development process?
Eng: The biggest challenge is that you’re asking developers to do something they weren’t doing before. It seems like they’re having to take on more work, but really what’s happening is that you’re replacing unplanned work with planned work. Instead of having to address defects late in the release cycle, you’re scanning for and addressing them early on. It’s a cultural shift, though, and often developers and development managers have a hard time understanding that embedding security this way will be more efficient — and safer — in the long run.
Giving development teams more autonomy over security tasks can also be daunting for security practitioners, but in order to facilitate shorter development iterations, security has to relinquish some control and also reconsider how they think about risk tolerance within the context of the business.
What can managers do to help adapt cultures to these new processes?
Eng: The most important thing for managers to do is to understand and support the shared goal of producing secure products. It’s convenient to lump security findings in with technical debt with the intention of getting to it someday. But it’s not practical to let security debt pile up like this.
An emerging pattern over the past five years or so is for product security to provide a structure for decentralizing security work. The basic idea is to have one or two people on each development team who serve as the eyes and ears of product security, taking ownership of some of the day-to-day tasks that would have previously been bottlenecked on the security team. So they might help with security code reviews or coach others on their team on how to fix security issues. We call these people security champions, but the terminology isn’t important. What is important is that development managers allow those people the nominal time they need to work on those tasks as opposed to fully loading them with development work. Managers should also help by keeping an eye out for developers on their team who have a natural aptitude or interest in learning more about security. Sharing responsibility for security in this way can further bridge the gap between security and development teams, reducing the workload of the security team while allowing development teams to be more self-sufficient.
What technical changes are necessary?
Eng: There are various automated testing solutions that should be run automatically to regularly provide feedback on security defects. Static analysis tests the application code for a broad range of security flaws, and it can be fully automated into both the integrated development environment (IDE) and continuous integration (CI) processes. In the IDE, it provides early security guidance and education to software engineers while they are coding by highlighting potential vulnerabilities and suggesting best practices.
Whenever introducing new security analysis tools to a development team, automation should be top of mind. Reduce friction by ensuring developers don’t have to go out of their way to run the security tool or to view and triage the results. Take advantage of plugins and/or APIs to integrate security tools seamlessly into toolchains that the development team is already using. This means there will likely be no one-size-fits-all approach that can be dropped into any dev team; rather, take the time to understand how that team works currently, and work with them to introduce the security tools in the least disruptive way.
How do DevSecOps processes impact development time/time to market?
Eng: The sooner a developer can identify, view and correct a flaw, the more efficient it becomes to fix in the software development lifecycle (SDLC). That ties back strongly to one of the underlying tenets of DevOps: the amplification of right-to-left feedback loops. Despite the somewhat negative connotation, failing early in development can be beneficial in deploying software to market more quickly. For developers (or anybody in the midst of solving a complex problem), context switching has a productivity cost. If they find out about a security defect while they are actively working on that particular feature or section of code, it’s only minimally disruptive and can be fixed quickly. By contrast, if they find out about the same security defect two weeks later, after they’ve moved on to a completely different feature, they’ll incur the cost of context switching back to the earlier feature before they can fix the flaw correctly. Over the long run, finding and fixing flaws early in the SDLC should not meaningfully delay time to market.
What is the most valuable advice you can give a developer transitioning to DevSecOps?
Eng: Be open to taking on more security responsibilities because it will reduce your dependence on the security team and result in more predictable development cycles. View the security team as a partner as opposed to an adversary — remember that you work for the same company, and everyone just wants to release quality products. Take advantage of the opportunity to build security expertise, as it can increase your market value. Learn a little about how security flaws are exploited, as it gives you a better context for understanding the importance of secure code. 
