5 Steps to Rethink High Severity to Save Developer Productivity

Sev-1s are sapping developer productivity. Security remediations occupy a growing portion of developers’ time. For their part, developers often resent spending time on code fixes rather than adding new features or shipping new versions. Their concern is justified. In 2021, nearly 35% of all published Common Vulnerabilities and Exposures (CVEs) were classified as critical (Sev-1). The volume of all vulns published continues to skyrocket. Over 18,000 were published in 2022, the fourth record year in a row.

The dirty secret? A Sev-1 that might be an existential threat for one organization may represent a very low risk to another. For example, let’s consider a vulnerable logging component. In one company, it’s used in their most critical customer-facing app. In another, it is nested in an application in a test environment not connected to enterprise networks. In the first organization, the Sev-1 is a juicy target. In the second organization, it is unreachable and largely irrelevant. Or, in another example, the developers overseeing that same logging component running on finance apps may have sanitized potential data pathways to the logging component, reducing attackability.

In this light, sometimes a developer is better off deprioritizing a Sev-1, even if it might have a negligible impact on their application or infrastructure. With roughly 50 new CVEs published per day on average, a knee-jerk policy to fix all Sev-1s present in an organization's code base creates an impossible task for development teams.

The upshot? We can reframe how we define "critical" and ask a better question: Is a vulnerability attackable? Meaning, can attackers’ malicious inputs reach a vulnerability given the structure and logic of an application? There are many instances where vulns are not attackable and thus do not present any real risk to the app or its data. This means you can deprioritize them in favor of other vulnerabilities which are attackable. This is a better way to triage and prioritize Sev-1 vulnerabilities to ensure higher developer productivity while delivering better security and more stable applications.

Step 1: Refactor Criticality Rankings to Factor in Attackability

The current way that criticality ratings of CVEs are determined relates to the theoretical impact of the vulnerability on systems based on arbitrary risk guidelines. For example, a remote takeover exploit is generally Sev-1. This definition is useless at the local level because application architecture and logic do not exist in a vacuum and organizations deploy layers of security controls. An AppSec team should determine whether any given Sev-1 can attack critical systems in their particular application infrastructure. This can be done manually through code path analysis or through automated solutions that digest all potential paths and compare them against target value and criticality of affected systems. 

Step 2: Structure Issue Burn-Downs So That Attackability Is the Primary Weight

Next, make attackability the primary weighting factor in issue prioritization. This is actually not very complicated and involves just adding a flag or another field that is simply “yes” or “no” to SIEM, SOAR, or vulnerability management packages. In fact, once this filter is applied, then all of a sudden the security workload begins to look manageable because, our research has found, the majority of relevant Sev-1s are actually not attackable in the average organization. (Note: this also explains the exceptionally high false-positive rate suffered by many SCA tools and the reason why so many developers don’t trust their code scan results.) By adding attackability as a gating factor, the issue queue will likely fall by 90% or more, making the entire exercise of application security less daunting.

Step 3: Determine the Best Remediation Path

Once an application component is determined to be attackable, then the security engineers should perform a deeper dive to understand the details of attack paths and determine the best remediation path: sanitize, remediate (meaning, write fix code), or reconfigure security controls. While fixing at the code level is always the most durable, constantly shipping code fixes can break applications and bog down productivity with constant QA and testing. 

Step 4: Scan Continuously to Prevent Attackability Drift

We all know about “security drift” when changes to networks and APIs over time render security controls less effective. “Attackability drift” is similar, except it relates to vulnerabilities that become attackable due to changes in application architecture and business logic or data paths which may happen over time. 

For example, an organization may switch from a RESTful API to a GraphQL structure, which could open a pathway that previously did not exist and enable horizontal traversal. A Sev-1 that was previously judged not attackable could become attackable. For this reason, code scans (including SCA and SAST) must be run continuously and include CVEs deemed previously not relevant. To scan continuously, the scanning and automated security testing solutions must run efficiently and quickly. Otherwise, scan latency would make it impossible to ship code in a timely manner while screening for attackability drift. 

The best solutions today can scan large applications in a matter of minutes, even in more complex languages like Kotlin. What’s more, the scans must cover nested functionality and obscured code, like what you might find in JAR files or other hidden dependencies. 

Step 5: Restructure Reporting and Metrics to Emphasize Attackability 

The final step is to make sure everyone is on the same page about how AppSec teams are approaching security through the attackability lens. Initially, this may require educational work to explain the large decline in potential vulnerabilities remediated and the divergence in numbers reported versus what an executive might be reading in terms of broader vulnerability trends. To make this most effective, the AppSec and development teams should collaborate on new metrics that reflect the benefits of using attackability as the key filter. 

For example, you might be able to chart a direct correlation between new features shipped and focusing down only on attackable Sev-1s. Developer satisfaction, the efficiency of test and QA, and security posture will — ideally — all be positively impacted once attackability filtering becomes the touchstone of remediation processes.

You Can’t Fix Every Vulnerability. So Prioritize.

The number of Sev-1s reported is likely to continue increasing for the foreseeable future. ATPs and sophisticated cybercriminals are working to automate many types of attacks and even rent out attack capabilities as a service. The growing diversity and complexity of applications, CI/CD pipelines, cloud computing, and more generate an ever-expanding attack surface. 

AppSec teams do not have unlimited budgets and already struggle to hire enough security engineers to fill existing headcounts. Developers are already tasked with more and more responsibilities as they shift left. Creating an application security remediation rankings and process around attackability can address all of these challenges by enabling security engineers and devs to focus on what matters, to work together, and to maximize their security efficiency while shipping better code, faster.