You probably get a lot of email. Do you give every email the same level of attention? Do you read, craft a thoughtful response, and immediately complete any follow-on tasks for every single email message as it comes in? If you do, congrats – but you probably don’t spend your days doing much else! Whether you know it or not, you have a policy regarding your emails. Maybe you automatically route certain types of emails to folders, maybe you flag certain emails, maybe you immediately respond to certain types of email and set aside time to respond to others. Without categorizing and prioritizing your email messages, you would have a tough time being productive.
If you think you’re going to start scanning code, then immediately fix every issue you find, your plan is doomed. Just as you’d never get anything done if you give every inbox entry equal attention, you don’t have the time or the resources to investigate every security finding with the same level of attention. And if you try to do this, you’ll either miss critical vulnerabilities in the pursuit of fixing every flaw, or your developers will simply ignore the overwhelming results in the interest of getting code out the door. You need to simplify and prioritize security findings, which requires a solid plan for how you are going to handle all the results – what types of findings need immediate attention, what can go on the back burner, what needs no attention.
Don’t let the perfect be the enemy of the good. 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. Back to the email analogy: if you address every email as it comes in with equal urgency, you’ll most likely get bogged down with less-critical tasks, while neglecting the urgent request from the CEO.
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.
In the end, each organization needs to balance its priorities and initiatives to create its own version of “good” security and an AppSec policy that works for its particular situation. Need help putting your policy together? Check out our new guide, Policy Matters: How to Build a Robust Application Security Governance Framework.