3 Ways To Empower Developers to Actually FIX Security Vulnerabilities as Part of Their DevOps Workflows


Posted on by Eric Sheridan

Developers have a lot on their plates these days, trying to keep up with the rapid pace of Agile DevOps. With the recent emphasis on application security, organizations now strive to fix web app security vulnerabilities earlier in the SDLC, before apps are deployed in order to lower the risk of potential data breaches. This means that developers now need to fix security vulnerabilities in addition to other software flaws in their apps.

While these responsibilities may sound reasonable to some, developers may not necessarily have the security expertise to identify security vulnerabilities, let alone understand how to fix them. This security challenge is exacerbated by AppSec testing tools that produce a surplus of false positives, which effectively eat away more time from developers’ tight schedules.

So, what happens when a developer gets overwhelmed when trying to reconcile application security with their tight schedules? More often than not, engineering teams don’t patch security vulnerabilities. And as a result, insecure apps are routinely released into production, exposing organizations to potential data breaches. What makes this matter more troubling is when security vulnerabilities are identified in apps after they’ve been deployed; they’re not being fixed in a timely manner. According to WhiteHat Security’s Web Application Security Statistics Report (2016), “Critical” and “High” risk vulnerabilities take an average of 300 to 500 days respectively for organizations to fix.  Furthermore, nine of the twelve industries analyzed in the report have vulnerability remediation rates below fifty percent.

In order to stop the domino effect that leads to insecure applications, developers need to have application security testing seamlessly integrated in their DevOps workflows and processes. To do this, and to enable developers to actually fix security vulnerabilities, organizations must take the following three actions: 

1. Establish foundational security training, so developers are able to fix security vulnerabilities and adopt secure coding best practices. 

Developers often don’t know where to start, and that’s critical to know when it comes to learning about security. Some developers will go to SANS.org for formal security training and certification classes. Others may go to free resources, such as the OWASP Top Ten Cheat sheet or WhiteHat Security’s Certified Secure Developer program, which provides secure coding training and certification free of charge. Whether developers get security training through their organizations or do online training on their own, it’s important that they get solid technical training taught by experienced security experts. 

2. Use application security testing products that are integrated with Jenkins and other key developer tools to automate scanning and verification as part of the build pipeline.

WhiteHat Software

Developers don’t want to have to learn a new tool / interface in order to do application security testing. For AppSec products to be adopted and actually used on a daily basis, they must have integrations or plug-ins to popular IDEs (e.g., Eclipse, Visual Studio, Xcode or IntelliJ), bug trackers such as JIRA or Bugzilla and CI build tools such as Jenkins. AppSec products must fit into Agile DevOps workflows and CI/CD processes for developers to hit their daily or weekly app delivery milestones. 

3. Facilitate remediation through the identification and, in some cases, automated application of common security controls.

AppSec products must provide accurate identification of actual security vulnerabilities with clear descriptions and actionable remediation advice. Unfortunately, some AppSec products will generate lots of false positives, which are the bane of productivity for developers. This is especially true for developers who are new to security, who may struggle to fix real security vulnerabilities and don’t have the expertise to discern false positives. A much-needed capability is to combine automated scanning / identification of vulnerabilities with the application of common security controls to provide custom-generated code-level fixes for developers to evaluate and apply. This is the “Holy Grail” for AppSec products—to not only be able to identify a vulnerability but to also offer a code-level patch that can be easily applied with a single click of a mouse. 

In conclusion, for developers to be able to actually fix security vulnerabilities as part of their DevOps workflows, organizations must offer their developers access to the requisite security training they need, and adopt security testing tools that support CI/CD processes and provide accurate and actionable vulnerability results and remediation advice.


Contributors
Eric Sheridan

Chief Scientist, WhiteHat Security

DevSecOps

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.


Share With Your Community

Related Blogs