Exploitability Isn’t the Answer. Breakability Is.

Source: Snyk Blog

The AppSec Paradox: Why Aren’t We Fixing More?

Why don’t developers fix every AppSec vulnerability the moment it’s found?
The most common answer is time. Modern security tools can surface thousands of vulnerabilities in a single codebase, and fixing them all would consume an entire development team’s capacity—often at the expense of feature work and other priorities.

Has the bottleneck changed?

• Then: Investigating a finding, learning the remediation, and manually changing code were all‑day tasks.
• Now: Automation and AI‑assisted tools handle much of that work, preparing code changes in the time it takes to make a cup of coffee. For SCA (Software Composition Analysis) vulnerabilities, remediation is often as simple as updating a package from a vulnerable version to a newer, patched one.

So, if time is no longer the bottleneck, what is?

Trust. Developers don’t ignore fixes because they’re unwilling to address security issues; they hesitate because they’re afraid of breaking their code.

Introducing Breakability – The Missing Link in Prioritization

To help teams prioritize with greater confidence, we’re adding a new capability to Snyk Open Source: Breakability Risk.

Why Breakability Matters

The first phase of Breakability tackles the question developers ask every day:

If I apply the fix Snyk recommended, will it break my app?

Every dependency update carries some level of risk:

• A “simple” package‑reference update may introduce API changes that cause compilation failures.
• Even if method signatures stay the same, subtle behavioral changes can make the code compile but fail at runtime.

The Dependency‑Hell Problem

Often, two or more direct dependencies share a transitive dependency. When multiple direct dependencies rely on the same underlying package, updating one part of your graph to fix a CVE can create a new incompatibility with another set of dependencies. This is the dreaded dependency hell scenario.

What Breakability Risk Does

• Identifies safe updates that can be applied immediately.
• Flags risky updates that require a deeper dive before merging.

By surfacing this information, Breakability Risk helps you decide what to fix now and what needs further investigation, enabling more confident and efficient prioritization.

Trust drives security

We’ve been running experiments on breakability analysis, and the patterns are consistent. When developers understand that the risk of breaking their applications is low, they are significantly more likely to merge a fix. In our experiments, low‑breakability updates were merged at four times the rate of higher‑risk changes.

Our analysis shows that about one‑third of all fixes fall into the low‑breakability category. For the average Snyk customer, prioritising these lower‑risk updates could translate into remediating thousands of additional vulnerabilities each year.

Breakability in action: Low vs. high risk

Snyk now provides a merge‑risk tag directly within your pull request to guide your prioritisation and accelerate fixing. Snyk Open Source also offers details, contextual risk scoring, and educational resources through Snyk Learn for developer upskilling.

Scenario 1 – “The Easy win”

[Image: Snyk PR showing a low‑risk merge suggestion]

In this scenario, Snyk Open Source has raised a pull request for a team to move to a newer version of [libxmljs2] in order to fix multiple regular‑expression denial‑of‑service (ReDoS) vulnerabilities.

• Analysis: The upgrade primarily drops support for end‑of‑life Node.js versions.
• Breakability risk: Snyk flags this as Merge Risk: Low, as there are no significant behavioural changes.
• Verdict: Press the button, secure the code, and move on.

Scenario 2 – “Proceed with caution”

[Image: Snyk PR showing a high‑risk merge suggestion]

Here, an update for [i18n] fixes prototype pollution but introduces an architectural shift from a global singleton to an instance‑based setup.

• Analysis: The library’s fundamental usage pattern has changed.
• Breakability risk: Snyk flags this as Merge Risk: High due to breaking architectural changes.
• Verdict: Don’t merge until you’ve reviewed your own code and made the appropriate changes.

A new hierarchy of remediation

We believe the first question in any remediation workflow should be simple:

Can I fix this problem with minimal effort and minimal risk?

If the answer is yes, do the fix. Breakability enables teams to address low‑risk updates first, opening the door to fixing a third—or even half—of a CVE backlog with a single click. Removing the fear of “breaking things” empowers teams to clear a significant portion of their backlog, reducing security debt without increasing engineering workload.

Snyk is not abandoning Reachability or the [Risk Score](https://docs.snyk.io/manage-risk/prioritize-issues-for-fixing/risk-score) lens.

While reachability is a valuable prioritisation lens, there’s a big difference between:

• “This vulnerability cannot be reached,” and
• “A reachable path for this vulnerability has not been found.”

The latter condition is far more common. It’s unsafe to assume that “no reachable path found” means “no reachable path exists,” especially today when attackers leverage AI‑driven hacking tools to discover and exploit weaknesses faster than ever. Instead of accepting package risk from potentially unreachable vulnerabilities, we’re making it easier for you to fix them—again, without the risk of negative side effects.

Breakability and the Snyk AI Security Fabric

This new remediation paradigm is key to driving the [AI Security Fabric](https://snyk.io/events/snyk-ai-fabric/). As described in the [Prescriptive Path to Operationalising AI Security](https://snyk.io/blog/prescriptive-path/), breakability helps you:

• Optimise risk reduction by building confidence in suggested fixes,
• Move beyond pure prioritisation lenses, and
• Create a predictable, confidence‑driven process that enables teams to merge more fixes faster, with less fear of breaking changes.

Get started with Breakability

The first phase of Breakability is available now as a Snyk Preview feature for all Snyk Open Source customers. Enable it to start seeing breaking‑change risk assessments on your Snyk‑generated pull requests today. We’d love for you to try it out and let us know what you think!

[Image: Breakability preview toggle in the Snyk UI]

Rethinking how to prioritise and remediate vulnerabilities with greater confidence? Learn how AI‑driven insights help teams move beyond detection toward predictable, scalable risk reduction. Download our eBook, From Shift Left to Secure at Inception, today.

New to CTFs?

Prepare for Snyk’s Fetch the Flag CTF competition on February 27 by watching our Capture the Flag 101 Workshop.