OWASP Proactive Controls

I presented the results of an applicaition security effectiveness study with John Benninghoff at the Secure360 Conference on May 10. The main things we learned from the study are:

• Developers need to understand application security bugs and how to prevent them. In the study, we focused on the OWASP Top Ten Risks and OWASP Proactive Controls.
• Security champions across the enterprise are essential. Especially everyone on the development teams, including the Product Owners.
• A SAST tool, we used CheckMarx, needs to be available to every team, and needs to be integrated into the development process. We used Jenkins to automatically run CheckMarx during builds.

These three steps are the starting-point for delivering more secure code. After the team is comfortable with understanding the data the SAST tool is creating, and they have cleaned up the false positives, the team should setup their automation server to start breaking builds when critical- or high-severity bugs are found.

Our setup allowed the team to override the SAST test and build anyway. But the team at least had the information they needed to make an informed decision on whether or not to create the build.

I am still working on the paper that documents the study and will pubish that it when it is finished.

In the meantime, check out an academic article I wrote that describes the Proactive Controls, beyond what you will find on the OWASP Proactive Controls page.

Download the proactive controls paper to get more information about the controls.

See you next time…