What Is Exploitability? Understanding Its Role in Risk Management

Exploitability refers to the potential for an attacker to use a vulnerability to harm an organization. Not all vulnerabilities are exploitable; vulnerabilities have varying levels of exploitability; and not all easily exploitable vulnerabilities are actually used by cybercriminals in the wild.

Understanding exploitability is critical to evaluating the risk that a potential vulnerability poses to the organization. Even the most severe vulnerability poses little or no real risk to the business if an attacker can’t or won’t exploit it.

Vulnerability vs Exploit

On one hand, a vulnerability is a security weakness that an attacker might be able to take advantage of. Many vulnerabilities are bugs in software code, but organizations can also be vulnerable due to misconfigurations, insecure processes, or social engineering.

On the other hand, an exploit is the act of an attacker taking advantage of a vulnerability to target an individual or organization. For example, a glass window in a door to a secure area might be considered a vulnerability. In this case, the exploit is someone smashing that window so that they can open the door using the inside handle.

The distinction between vulnerability and exploit is important to determining the risk posed to an organization. The fact that a vulnerability exists doesn’t mean that an attacker has the means to exploit it. A vulnerability that can’t be exploited poses no real risk to the organization.

Exploitability lifecycle

As we discussed above, not all vulnerabilities are exploitable, and not all exploitable vulnerabilities are actively targeted. In most cases, the lifecycle of an exploited vulnerability includes the following stages:

1. Vulnerability Disclosure: A vulnerability is identified in a piece of software and disclosed to the vendor. Ideally, this is done confidentially via a responsible disclosure process, or the vulnerability is discovered in-house by the vendor.
2. Patch Release: Once the vendor is aware of the vulnerability, they develop and release a patch that fixes the issue. Generally, this is when the vulnerability is publicly disclosed since users can apply the patch and remove their risk.
3. Proof of Concept (PoC): During or shortly after public disclosure, a Proof of Concept (PoC) exploit is published for the vulnerability. This can be useful for testing the patch, and, if the vulnerability was identified and reported by a third party, they might publish a PoC as part of an article detailing their research and findings.
4. Exploit Code Availability: PoC code demonstrates how a vulnerability works, making it easier to develop a workable exploit. At this stage, an attacker has the tools required to use the vulnerability as part of an attack campaign.
5. Weaponization: Just because an exploit exists doesn’t mean that it will actually be used. At this stage in the process, the exploit has been seen in the wild as part of an active cyberattack.

Only at the last stage of this process does a vulnerability pose a real risk to an organization. An exploit that is created and never used is no threat, and vulnerabilities for which no exploit is ever developed are even less dangerous. 

And the vast majority of vulnerabilities don’t even reach the last stage of this process. In theory, every vulnerability poses a potential risk to the organization and should be patched. In practice, nearly 100% of them are never exploited in the wild.

The need to validate the risk and not the remediation

Validation is a common component of a vulnerability management practice. If the security team puts time and resources into designing and deploying a fix for a vulnerability, it wants to make sure that remediation is successful. A failed update or a patch that introduces new security risks or fails to fix the original vulnerability can create a false sense of security.

However, this assumes that the vulnerability actually needed to be fixed in the first place. In many cases, the truth is that it doesn’t. Trying to remediate every vulnerability—or even every one with Critical or High CVSS scores—is unscalable and can be a waste of resources, especially as the number of newly discovered vulnerabilities climbs each year.

A better approach to vulnerability management is validation of the risk rather than the remediation. While CVSS scores may be a factor in risk prioritization, they should take second place to the vulnerability’s exploitability and potential impacts on important IT assets and business workflows.

Risk validation with IONIX

Risk validation is essential to a scalable and sustainable vulnerability management strategy. With vulnerability numbers on the rise, security teams should only attempt to address vulnerabilities that are exploitable. If a vulnerability is blocked from exploitation by existing security controls, then the resources needed to patch it could be better used elsewhere.

The IONIX platform supports effective exposure management via automated, non-intrusive testing of vulnerability exploitability. By automatically validating that a vulnerability is exploitable, the platform both eliminates the need for extensive manual testing and ensures that resources are focused on true threats to the business. To learn more about how IONIX can enhance your threat management process, sign up for a demo.