Application Security Mistake No. 4: Ignoring AppSec Policies

We’ve been in the application security business for more than 10 years, and we’ve learned a lot in that time about what works, and what doesn’t. This is the third in a blog series that takes a look at some of the most common mistakes we see that lead to failed AppSec initiatives. Use our experience to make sure you avoid these mistakes and set yourself up for application security success.

Why policies matter

Ultimately, without an effective AppSec policy, you will be:

Ineffective

With the shift to DevSecOps, developers are moving fast, and if you don’t have a solid and manageable AppSec policy – your scan results will become “noise” that they will overlook or work around. Prioritization is the name of the game in a DevSecOps world. What is acceptable risk for your organization? What security-related defects absolutely must be remediated? What is OK to mitigate? What can be overlooked? If you don’t clarify these priorities, your development team will be spinning their wheels chasing down every flaw, or simply ignoring the results. One caveat: don’t set the bar too high; keep the policy achieveable for development teams. If necessary, you can increase the stringency over time as the team ups its skills and know-how. As our director of product management Tim Jarrett says, “Any policy should be only as complicated as it needs to be to deliver the necessary results, but no more than that.”

Insecure

Not every flaw is a vulnerability. A flaw is a weakness in an application that needs to be investigated. A vulnerability is a flaw that has a proven exploit. If you treat every flaw as a vulnerability, you’re neglecting the vulnerabilities that are increasing your risk, while wasting precious resource time on flaws that would never be exploited – you’re pursuing perfect code at the expense of good security.

Similarly, not all apps are created equal, so create different requirements for different apps. For instance, an application that has IP, is public-facing and has third-party components may require all medium to very critical flaws to be fixed. A one-page temporary marketing site may only require high/very high flaws to be fixed. Don’t leave yourself exposed while spending time trying to put the maximum security controls on apps with minimal risk.

Lacking support

When you establish an application security policy, you’re also outlining what you plan to accomplish with your AppSec program and, in turn, proving what you have accomplished. For instance, if your policy states: “we will identify and then remediate or mitigate any OWASP Top 10 flaws,” you will have documentation of flaws found during initial scan, how they were addressed, and flaws found on subsequent scans. You can then prove that your program is reducing risk and get the support and funding you need to continue and grow your program. Without a policy, it’s unclear what the goals of your program are and if your initiatives have produced any results.

Learn From Others’ Mistakes

Don’t repeat the mistakes of the past; learn from other organizations and avoid the most common AppSec pitfalls. Today’s tip: Don’t neglect to craft a solid, thoughtful, and achieveable application security policy. Get details on all six of the most popular mistakes in our eBook, AppSec: What Not to Do.

*** This is a Security Bloggers Network syndicated blog from RSS | Veracode Blog authored by [email protected] (sciccone). Read the original post at: http://www.veracode.com/blog/managing-appsec/application-security-mistake-no-4-ignoring-appsec-policies