You wouldn’t be very effective if you didn’t prioritize your to-do list. Treating “prep for board meeting tomorrow” and “organize in-box” with the same level of urgency would slow you down at best, seriously impact your job performance at worst. Similarly, neglecting to prioritize your application security “to-do list” will slow your progress, or prevent it altogether. Even the best application security technology and scanning tools will become ineffective without any way to prioritize and manage test results. In my previous blog post, I outlined in general how AppSec policies need to adapt to a DevSecOps world. In this post, we dive deeper into the topic of managing test results as part of your policy.
A key element of that effort is ranking vulnerabilities so that you are focused first and foremost on those that are actually increasing your risk. For instance, it’s important to distinguish between flaws that represent a remote risk and those that represent more substantial, real-world risks. In some cases, the likelihood of a vulnerability being exploited may be low, but the potential damage might be great. In other instances, the chance of exploit might be high, but the damage may not be substantial.
In addition, your priority list will not be the same as another organization’s. Prioritization is impacted by the industry you’re in, the external regulations you are subject to, the types of applications you are developing, etc. But here are a few things to consider as you start to craft an AppSec policy that helps you fix what you find:
In its recent report, “Incorporate Application Security Throughout the Application Life Cycle,” Gartner recommends a hybrid approach to vulnerability prioritization that combines the following approaches:
“Threat-centric: This approach focuses on the vulnerabilities that are actively being targeted in the wild, such as vulnerabilities targeted by malware, ransomware, exploit kits and threat actors.
Vulnerability-centric: This approach prioritizes vulnerabilities according to the criticality of the vulnerability (i.e., ease of exploitation, exploitation impact, public exploit available).
Asset-centric: In this approach, the vulnerabilities associated with critical assets will be given highest priority, and then less critical and so on.”
We typically recommend starting an AppSec policy with a relatively attainable goal, such as eradication of certain categories of high-severity vulnerabilities, then becoming more stringent over time. It’s important to recognize that unrealistically high standards will encourage software development teams or third parties to find ways around the policy.
Regarding the “asset-centric approach,” we recommend creating 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.
Just as it’s important to take a nuanced approach to flaws and vulnerabilities, it’s crucial to allocate resources effectively by considering whether it’s necessary to mitigate a threat or remediate it.
In the same report, Gartner outlines the options for addressing vulnerabilities as follows:
“Remediation: This fixes the vulnerability by making code fixes and configuration changes, and by patching.
Mitigation: When the primary control is not available or not feasible to implement, compensatory controls (such as virtual patches with a WAF) are put in place to reduce or eliminate the exploitability of the vulnerability.
Acceptance: If remediation/mitigation is not possible, or the vulnerability is considered an acceptable risk, the vulnerability is accepted by the management along with the consequences. Approval is an exception on a case-by-case basis, and should be time-limited and tracked and reported on.”
We are seeing this idea of vulnerability prioritization becoming best practice among our customer base. Our most recent State of Software Security report found that organizations are wisely fixing the most serious flaws first. In fact, organizations are fixing the most serious flaws at 2x the overall fix rate. Specifically, 21 percent of high severity flaws were fixed in less than eight days, and 59 percent of closed high-severity flaws were fixed within 90 days.
Bottom line: Prioritize and be realistic when tackling your list of application vulnerabilities. Start by identifying vulnerabilities that are (1) truly increasing your risk and (2) can realistically be fixed. This tactic ensures you are using your resources wisely and getting the most from their efforts.
Get more details on application security policies in our Everything You Need to Know About Application Security Policies guide.