Helping developers prioritize the security backlog

Today, developers are increasingly stepping up to fix the vulnerabilities in their apps, which is amazing. However, when they do so, they're faced with a long backlog of vulnerabilities. Deciding which issue to address first is hard, requiring time and security expertise developers often don't have. This is a chance for the right tools to shine, providing the expertise to know which security questions to ask when prioritizing, and the technology to answer them quickly.

Tackling the vulnerability overload

The number of vulnerabilities in open source components is constantly on the rise, with thousands of new vulnerabilities disclosed every year. For perspective, consider the Snyk vulnerability database which has seen a total increase of 394% over the past four years. These continuously growing numbers are ultimately reflected in the vulnerability backlogs organizations are facing today.

Already stretched for resources, and under constant pressure to roll out functional and secure code rapidly and frequently to help their business stay competitive, the only way developers can tackle these backlogs is by prioritizing well. Since they cannot, realistically, fix all the vulnerabilities on the list, development teams need to decide which vulnerabilities offer the best return for time invested.

These decisions can have a huge impact on an organization’s effort to manage and reduce risk. Bad prioritization can allocate dev time to vulnerabilities that turn out to be false-positives, causing friction and reducing developer trust. Prioritizing a high severity vulnerability with no known exploit over a low severity vulnerability with an exploit in the wild could weaken the overall security posture of the organization.

Being able to ask the right questions

Effective prioritization requires expertise. Security expertise, that guarantees an accurate and deep assessment of the threat the vulnerability poses to the organization. Developers typically don’t possess such expertise, hindering their ability to prioritize risk well.

Effective security tools must, therefore, provide this missing expertise, surfacing the right questions at the right time. These questions can be tuned by security pros, and amplified through the product.

Setting priorities straight

The first question developers need to be able to ask is a seemingly simple one—what issue in the backlog should be tackled next.

CVSS was designed for this exact purpose but poses a set of challenges. Calculating a CVSS-based score is a task that requires security know-how. Even when provided with the score out-of-the-box, understanding how it was reached requires knowledge and sometimes additional research. And besides, the severity of a vulnerability isn’t the only factor when choosing which issue to tackle first.

Developers typically don’t have the security expertise to understand CVSS nuances. Nor can they afford to invest time in further investigating why a vulnerability received a specific severity. To help developers set priorities, scoring needs to be explicit and simple to use. Snyk, for example, processes severity, availability of a fix, exploit maturity, and the age of the vulnerability to calculate its priority score. The score is then presented in a way that makes it easy for developers to understand and use.

The difference between important and urgent

Once priorities have been set, an additional question that needs to be asked is which issues are more urgent than others.

Vulnerabilities with exploits in the wild, for example, should receive a high priority and be considered urgent enough to warrant immediate attention. The infamous Equifax breach originated from a known vulnerability for which there were exploits in the wild published only a few days before the attack. 

Knowing whether a vulnerability is exploitable is a partial solution though. Yes, this indicates the likelihood of exploitability, but like vulnerabilities in general, not every exploit is born equal. Some exploits are only theoretical and have never been weaponized. Others are much more mature and have exploit code published.  Mature exploits lower the bar for attackers, resulting in more attackers trying them out. More notably, mature exploits are quickly added to automated botnets, who constantly scour the web for easy-to-exploit weakness, regardless of the victim. If you leave such a hole open, these botnets are likely to find it quickly.

When dealing with a huge vulnerability backlog, developers need to be able to quickly identify the ones where exploits can be easily found and weaponized. With this knowledge in hand, the decision on whether to prioritize a vulnerability is much easier.

Fixing with the right context

A known vulnerability may have an exploit, but that doesn't mean it can be exploited in your app. Exploitability in your app depends on how your code—and the other libraries you use—interact with the vulnerable component.

Obtaining this context, though, requires not only security expertise but also analysis capabilities. Developers rarely have access to these two resources nor do they have the time to develop them on their own.  Tools with these capabilities baked in help developers ask themselves the question of whether a vulnerable method is actually included in an application’s execution path or not and prioritize accordingly.

Snyk, for example, pre-analyzes every component in the user’s environment and can monitor the running application, all to advise developers as to the reachability of the vulnerability by the application.

Fewer gates. More guardrails.

Developers are asked to assume more and more security responsibility, but can only do so if they know they’re spending their time and resources on the right vulnerabilities. Prioritizing well will also help reduce friction between developers and security teams—the fewer the false-positives entering the need-to-fix-now list, the more trust developers will have in the process.

For their part, security teams need to ensure developers can prioritize safely. By providing developers with guardrails, security teams can rest assured decisions are being made within safe boundaries. These guardrails should be set in place by the security teams with the help of policies that are granular enough to support governance at scale. The more automated these policies are, the better.  

To help developers ask the right set of questions needed to prioritize effectively, Snyk provides developer-first prioritization capabilities that propose the questions, find the answers, and simplify subsequent fix efforts. Learn more here, or get started yourself for free.