Prioritizing Remediation Based on Risk: The Power of ArmorCode’s Adaptive Risk Scoring

There are more software security findings than resources to address them. This is not going to change. On the contrary, as development accelerates and attack surfaces expand, technical security debt will accrue even faster as security teams must handle more data more often from more scanning tools covering more aspects of the ecosystem. Faced with this reality, it is not practical (or necessary) to address every vulnerability, weakness, and exposure. Instead, organizations need to prioritize based on risk. Adaptive Risk Scoring helps organizations achieve this. 

ArmorCode’s Adaptive Risk Scoring normalizes the technical severity of findings across testing sources, maps findings to assets, and assesses the business impact if an attacker successfully exploits the finding to calculate a risk-based score for visibility and triaging. This makes it possible for security and development teams to quickly identify where they need to focus remediation efforts. 
‍

The Risk-Based Prioritization Challenge: Identifying True Criticals in Total Chaos

Managing risk and improving security posture requires security and development teams to effectively answer the questions, “What should we do with the resources available to have the greatest improvement in security posture? What should we do first? What should we do next?”

However, answering these seemingly simple questions is incredibly complex for the following reasons:

1. There are too many findings to fix. The volume of security findings has become overwhelming. In the last decade, the number of CVEs increased nearly 500% from 5,297 in 2012 to 25,227 in 2022. Similarly, flaw detection has improved with both an expansion of security tooling to detect vulnerabilities across the software ecosystem and increases in scan frequency with automated testing built into CI/CD pipelines. Remediation resources and capacity, however, have remained relatively static. Prioritization is a clear and present need, but it’s easier said than done.
2. Complexity gets in the way of clarity. With expanding attack surfaces, the advent of new technologies, and an evolving threat landscape with novel attack vectors, there is more to secure and more tools to secure it. Security teams struggle to create clarity out of the complexity of findings across applications and infrastructure generated by a myriad of internal scanners, software supply chain disclosures, bug bounties, and more. On top of this, findings across different sources use similar labels with different implications. A critical static analysis code weakness is not synonymous with a critical cloud misconfiguration – let alone a critical software vulnerability with a known exploit. Manually aggregating vulnerabilities into spreadsheets, trying to normalize severity, and ranking issues for prioritization quickly becomes unmanageable at scale. 
3. Severity is not synonymous with risk. The technical severity of a finding is only half of the equation. The other half is the risk implications based on the affected asset. Addressing findings solely based on their technical severity leads to inefficient and ineffective risk management. For example, a critical finding in a backend application that isn’t publicly accessible and doesn’t contain protected information likely poses less risk than a high-severity finding in a public-facing application connected to sensitive user data. Moreover, backlogs of findings and alert fatigue from issues that don’t pose a substantive risk to the organization erode trust among developers who think findings amount to the proverbial cry wolf. 

Organizations need to navigate these challenges to optimize remediation resources and successfully manage a risk-based approach to software security. 
‍

Effective Risk-Based Prioritization: Going Beyond Severity with Adaptive Risk Scoring 

Severity is not sufficient to prioritize security findings, particularly across different scanning tools. To illustrate the challenge, let’s say a team is faced with three findings - a CVE with a known exploit, a manual penetration test finding of a misconfigured S3 bucket, and a cross-site scripting code weakness - and only has time allocated to remediate one of them. All three findings have a critical severity but otherwise were uncovered by different sources and affect different assets. 

At one extreme, the team could do nothing and allow the three findings to persist leaving the organization overexposed to cyber attacks. At the other extreme, they could fix all the issues, but that will cause delays and jeopardize strategic revenue-generating projects. They could fix what they have time to fix in no particular order. Or they could fix the finding with the greatest impact and make a risk-based decision about the remaining two issues. The last option seems optimal, but how would they do that?

ArmorCode solves this challenge by creating a level playing field to assess technical likelihood across tools and bringing in threat intelligence and the business context of the affected assets to calculate the greatest impact to the business.

To calculate a normalized finding score, ArmorCode looks at the base severity from the source tool, relevant variables for the finding category - for example, CVSS score, cyber threat intelligence, and exploit information - and user-managed variables like source tool weighting. This systematically calculates a normalized technical severity score across different tools and categories of findings.
‍

Normalizing the technical severity is only half the equation when it comes to risk. The other half is assessing the business context and impact. For this, ArmorCode leverages user-managed tags with associated risk weightings. For example, a public-facing asset connected to a database with personally identifiable information (PII) would have a greater asset score and risk weighting than a backend asset that does not connect with protected data. ArmorCode users can group tags into tiers and ingest data from an asset management system to facilitate asset scoring. 
‍

This approach to risk scoring provides a systematic mechanism to calculate the relative risk of findings while providing users both clarity into how the score is calculated and the ability to manage variables to configure and adapt the risk score calculation based on priorities and level of maturity. 

Applying ArmorCode’s Adaptive Risk Scoring to Improve Security Outcomes, Alleviate Remediation Workloads, and Build Trust Between Security Teams and Developers

You can leverage ArmorCode’s adaptive risk scoring in practice to prioritize findings, automate risk-based triaging and remediation workflows, and facilitate reporting and governance over application security and vulnerability management. 

Reduce Risk: Prioritize and remediate your highest-risk findings faster

The most direct application of risk scoring is for vulnerability triaging and prioritization. Manually assessing the relative risk of hundreds of thousands of findings rapidly becomes impractical. ArmorCode liberates security teams from the time and effort of trying to rationalize and prioritize findings across tools by automatically ingesting findings and applying risk scoring. In a study on an enterprise with 600 developers and 5 AppSec engineers (a typical developer-to-security ratio), ArmorCode reduced the AppSec team effort by 90%.

Release Faster: Reduce workloads and automate risk-based remediation workflows

By combining normalized severity with the impact of the affected asset, ArmorCode’s risk scoring distills thousands of findings into the few that pose the greatest risk and require remediation. In addition to reducing remediation workloads and delivering more trustworthy and high-context tickets to developers, risk scoring also makes it possible to automate risk-based triaging and remediation workflows. For example, users can create Runbooks that automatically generate tickets and notify asset owners when a finding exceeds a certain risk threshold to accelerate remediation and response.

Facilitate risk-based visibility, governance, and organizational alignment

While risk scoring occurs at the finding level, ArmorCode provides visibility into the distribution of risk across products, sub-products, and your organizational hierarchy to know the relative posture of different assets and business units. It also provides a key mechanism to govern risk-based remediation and vulnerability management practices. 
‍

Applying risk scoring to the three findings in the scenario above would allow the team to immediately identify which of the three findings to prioritize. However, there is a lingering question: What should they do about the other two findings? Should they fix them? When? Risk scoring makes risk-based vulnerability management possible by establishing SLAs based on risk. For example, the organization can establish an SLA dictating asset owners need to remediate vulnerabilities above a certain risk threshold within 14 days. With these SLAs in place and agreed upon at a cross-functional level, teams have clarity into their responsibilities, and the organization can track adherence.

Get started with adaptive risk scoring and establish risk-based prioritization.

These are just a few examples of how you can apply ArmorCode’s adaptive risk scoring to improve the performance of your application security and vulnerability management efforts. To dive deeper into risk scoring and how ArmorCode can fit into your secure software development ecosystem and process, schedule a free demo today.