How Hopper Builds Fix Plans Developers Actually Use

Most security tools are great at pointing fingers. They can tell you that a vulnerability exists, but not whether it’s reachable, how it got there, what happens if you touch it, or what the fix will break. This leaves developers with a familiar and frustrating task: digging through unfamiliar code to assess risk, triage false positives, and guess at remediation.

At Hopper, we take a different approach. We believe security tooling should deliver fix-ready findings, not just alerts.  That means every issue includes:

• Reachability validation to prove exploitability
• Call graph evidence to show where and how the vulnerability is triggered
• Version upgrade guidance to suggest the safest path forward
• Fix-effort estimates to gauge remediation complexity upfront

It’s not just about identifying the problem, it’s about getting to the root cause, quickly. Here’s how we do it.

Step 1: Detect the Vulnerable Function

Before Hopper even looks at your code, it does something most tools don’t: it pinpoints the exact vulnerable function associated with every CVE.

Instead of generically flagging an entire package or version, Hopper’s proprietary vulnerability database maps known CVEs down to the function level within the affected libraries. For example, in the case of Log4Shell, Hopper identifies the lookup() function within the JndiManager class of the log4j-core library, not just the broader vulnerable version.

This precision ensures that when Hopper analyzes your codebase, it knows exactly what to look for. Not just whether you’re using a vulnerable package, but whether you’re invoking the function that actually introduces risk.

This step is foundational. It transforms CVEs from vague alerts into specific, traceable risk signatures that can be analyzed against your actual application behavior in the next steps.

Step 2: Determine Reachability in Your Code

Once the vulnerable function is identified, Hopper analyzes whether your code actually reaches it.

Rather than flagging vulnerabilities at the package or file level, Hopper performs function-level reachability analysis to determine if your application logic invokes the risky function, not just imports or includes it. This goes beyond surface-level matching to understand whether the vulnerability is truly part of your execution path.

This step narrows the field dramatically, filtering out non-exploitable issues and focusing attention only on those vulnerabilities your application can actually trigger. If a CVE isn’t reachable, we deprioritize it. This eliminates the guesswork.

Step 3: Prioritize with Effort and Enrichment

Understanding what to fix is important. But to make remediation actionable, teams also need to understand how much effort it will take and how urgent the risk is.

Fix-Effort Estimation

Hopper provides a fix-effort estimate based on the type of version bump required:

• Patch upgrades typically mean low effort and minimal risk
• Minor upgrades may introduce new functionality or deprecations
• Major upgrades are flagged as high effort due to likely breaking changes

This helps teams assess early whether a fix is simple and safe to implement or likely to require deeper evaluation.

Threat Context and Risk Enrichment

Effort alone is not enough. Hopper enriches each finding with external threat signals, including:

• EPSS (Exploit Prediction Scoring System) to assess the likelihood of real-world exploitation
• CISA KEV (Known Exploited Vulnerabilities) to identify actively exploited issues
• CVSS scores and severity ratings

This combined perspective of effort and enrichment enables security and engineering teams to align faster on what to fix first, based on both risk and resource cost.

Step 4: Show the Call Path

As part of its analysis, Hopper builds a call graph that traces the execution path from your application’s entry point to the vulnerable function. When a vulnerability is identified as reachable, Hopper shows this call graph as part of the remediation details. This visualization provides the critical context developers need to understand how and where a vulnerability is triggered.

The call graph reveals:

• Which service or component is using the vulnerable dependency
• Where the call is initiated in your own code
• Whether the flow is direct or transitive

Hopper also provides a direct link to the source code management (SCM) system for the first-party code involved in the call path. That means developers don’t have to search their entire codebase to locate the issue; they can jump straight to the relevant function and start triaging immediately.

Step 5: Remediate Where It Matters

Once a vulnerable path is confirmed, Hopper makes remediation straightforward.

Developers can follow the call graph to see exactly where the issue originates, then use the direct link to their SCM system to jump into the relevant line of code and fix it in place.

To simplify dependency upgrades, Hopper also suggests the nearest available version that is not affected by the vulnerability. This gives teams a clear and actionable starting point for remediation, without having to scan changelogs or release histories manually.

If the fix needs to be coordinated or tracked, Hopper supports collaborative workflows:

• Automatically generate Jira tickets with embedded call graphs and remediation context
• Send Slack alerts to the appropriate team, including SCM links and vulnerability details

Whether resolving the issue directly or handing it off, Hopper provides the context, version guidance, and integrations needed to take action quickly and confidently.

Why It Works: Developer-Centric Remediation

By combining reachability validation, actionable evidence, and effort-aware fix guidance, Hopper turns vulnerability alerts into tasks developers can actually act on.

This approach:

• Reduces triage cycles and back-and-forth
• Increases developer trust in security tooling
• Speeds time-to-remediation without forcing guesswork
• Enables security and engineering to align on what’s worth fixing

Security tools shouldn’t just report problems. They should help fix them. With Hopper, remediation isn’t an afterthought. It’s the product.