What Is Risk?
Let’s be frank. Risk represents the possibility of loss.
In business terms, loss is in the form of cash, customers, partners, revenue, IP, corporate data, and brand loyalty.
Global Risk & Compliance (GRC) teams calculate, manage, and mitigate the possibility of loss across the business (and IT).
So, what’s the role of risk in software delivery? Risk has a linear relationship with change. If nothing changed in IT, risk would be static. With DevOps and CI/CD, software changes multiple times a day, and so does an organization’s risk posture.
Risk ≠ CVSS Score
As an industry, we’ve become obsessed with vulnerabilities. Software Composition Analysis (SCA) tools exist to find vulnerabilities within open-source software libraries that developers reference in their applications. Cloud security tools (CSPM, CNAPP) also scan file systems and storage devices for files, folders, and packages that contain vulnerabilities. The criticality (and priority) of these vulnerabilities is measured using an industry-standard Critical Vulnerability Scoring System (CVSS).
However, as NIST clearly acknowledges:
“CVSS is not a measure of risk.”
CVSS is simply a qualitative measure of severity relating to a known vulnerability.”
Despite this, our industry prioritizes what to fix first based on a CVSS score. This is wrong.
Vulnerabilities only pose a risk if they: a) threaten the business and b) are exploitable.
Here’s a simple example:
- A retail application contains a payment service has a critical 9.3 vulnerability, processes PCI, and is internet-facing
- A separate marketing application contains a customer account management service that contains the same critical 9.3 vulnerability, but it is connected only to an internal network.
Using CVSS, both services get prioritized the same, and this is why security engineers have to deal with thousands of critical vulnerabilities every day. Business context and exploitability matter.
Calculating Business Criticality
A modern cloud-native application in 2023 has hundreds to thousands of services, dependencies, and attack surfaces. Knowing which ones impact the business starts with asking two fundamental questions:
- What does it do? That is, what is the business function of each service, API, and dependency?
- What data is at stake? Meaning which services, APIs, and dependencies process sensitive data (e.g., PII, PCI, PHI)?
To answer these questions at scale, teams need a reliable programmatic way to establish business and data flow context inside their running applications. Here is an example of what business and data flow context look like from an ASPM solution.
In the above example from Bionic, you can quickly understand what business function an application service provides, how a service depends on other services, and if data is connected to the service.
Calculating Exploitability
The final part of evaluating risk is whether a vulnerability is truly exploitable.
CVSS touches on exploitability in its scoring system but is general and primitive. For example, if an application uses a common code library (e.g., log4j), the vulnerability may be more exploitable than a code library that is less common in applications.
It’s important to note that just because an application references a code library does not mean the code library is active, used, or exploitable in the application. Developers need to reference and use APIs from the code library inside their running application logic.
To understand whether a vulnerability in an application is exploitable, you should ask a few simple questions:
- Is the impacted service, API, or dependency internet-facing?
- Is the impacted service, API, or dependency internal or from a third party?
- Does the impacted service, API, or dependency require authentication?
Here is an example of how an ASPM solution can help identify whether a vulnerability is exploitable.
In the above example, we have a log4j vulnerability that connects to a database with PII, the internet, a third-party service, and multiple internal services. Based on these factors, Bionic ASPM determines that this vulnerability is highly exploitable. Consequently, the Business Risk Score is 100.
Example of Risk Scoring in the Wild
A Fortune 100 technology company approached Bionic to help them surface the most exploitable vulnerabilities so they could focus their security and engineering teams’ time and effort on the riskiest issues.
Bionic found over 1,000 vulnerabilities across a single application with over 70 microservices. With Bionic’s ability to determine exploitability and prioritize vulnerabilities based on business risk, the customer’s vulnerability count decreased to just 28. Even more impressive, only 1 out of 28 was found to be critical.
The customer now has a risk-based view of vulnerabilities that have freed up hundreds of hours to help the company innovate faster and more securely.
The Bottom Line
In conclusion, risk is everything when managing application security at scale. No application is free of vulnerabilities, and there are limits to the capacity of security and development teams.
Chat with us today to learn more about how Bionic ASPM automatically discovers and calculates risk across your deployed applications.