Eyes Wide Open: Building Hopper in a Crowded Market

Eyes Wide Open

When we started Hopper, we went in with our eyes wide open. We were not naïve. 

We knew application security was already layered with years of hard work. 

• Software Composition Analysis (SCA) has become an industry standard.
• Application Security Posture Management (ASPM) was gaining momentum.
• Runtime Application Security Protection (RASP) was growing.
• And the big cloud security providers were moving deeper into AppSec.

The landscape was crowded, and the challenges were real. We saw the good work that was already out there. Smart solutions. Mature ideas. We respected it all.

And we still chose to dive in because we believe the opportunity ahead is even bigger than what exists today.

Respect First

Before we share anything about our journey, it is important to be clear.

We have deep respect for the teams building cybersecurity products. Period.

The companies shaping this space — Snyk, BlackDuck, Semgrep, Endor Labs, and others — are backed by some of the best technical minds in the industry. They have pushed the industry forward, raised the bar for what security products can do, and helped make application security part of the mainstream conversation.

We are not here to take anything away from that. We are here because of it.

Why We’re Sharing This

This post is not a product launch or a teardown. It is a window into Hopper’s journey. The decisions we made. The tradeoffs we faced. What makes Hopper different. Who we are building for. And how we ended up where we are today.

But it is more than that.

We believe sharing our journey gives prospects and customers a glimpse into how we think. It helps you understand whether Hopper is the right fit for your needs. It also gives us a chance to share what we believe, encourage feedback, and keep learning, the same way we have from the very beginning.

Some of what we believed at the start did not survive first contact with customers. Other ideas became the foundation for what Hopper is today. We are sharing it all, not just the highlights.

If you have built in this space, you will probably recognize some of the challenges. 

If you are thinking about starting, maybe this will help you. 

And if you are on a similar journey, we would love to hear your story too.

Listening Before Building

Before we wrote a single line of code, we spent our time listening.

We listened to what customers asked for.  We listened even more carefully to what frustrated them, what slowed them down, and what made them hesitant to trust new tools.

The conversations were not always easy. They challenged our assumptions and forced us to think differently about what it would take to build something that actually worked.

The journey went something like this:

Customer: I have a noise problem with my SCA!

Hopper: Have you heard of reachability analysis?

Customer: Quite a lot. But I’m still not 100% sure what that actually means.

Hopper: Fair. It is a confusing term. (Thanks to James Berthoty for helping explain the differences so clearly.) Let’s start with the basics.

You can think about three types of analysis: Package, Function, and Internet. Each comes with its strengths and tradeoffs, depending on what you need.

Which one would be most helpful for you?

(We will touch on static versus runtime analysis in a second. Bear with us.)

Customer: Got it. Function-level sounds like the right way to cut through the noise.

Hopper: Quick question. Are you only worried about direct dependencies, or do transitives matter as well?

Customer: Transitives are a must. Over 90% of my vulnerabilities are in transitive dependencies.

Hopper: Understood. Here you go. Just install this tiny eBPF agent on your cloud native workloads, and you are done.

Customer: Agent? Nope.

Also, I am not just cloud native. What about on-prem? Client-side? Serverless? Windows workloads?

And by the way, my friend tried an eBPF-based approach and still had to rely on their SCA tool to triage and fix issues back in the repository.

Hopper: Here you go. Just add a small step in your CI pipeline and you are good to go.

Customer: Step? CI? I have hundreds of pipelines, owned by different teams. Most of our tooling is unified, but not everywhere. Some teams still use GitHub Actions, Jenkins, CircleCI, or GitLab CI/CD, depending on where they sit.

Even when the tooling is similar, every integration takes time, coordination, and requires chasing different owners. Our DevOps and R&D teams are already stretched thin, and honestly, every time a tool promises to help, it just adds more work.

Hopper: Right. Another question: How sensitive are you to accuracy metrics? Especially false negatives?

Customer: False negatives? No tolerance. I cannot afford them.

Hopper: It’s that bad? Is any vendor of yours accounting for false negatives?

Customer: Not really. I get that no tool is perfect, but I need misses to be rare and non-critical.

Hopper: Got it. 

Quick technical note: We noticed your Java workloads are mostly Spring-based, and your .NET workloads are based on ASP.NET. Both frameworks are highly dynamic, which makes static analysis much more prone to accuracy issues if not handled carefully.

Would you still be comfortable if false negatives affected critical parts of these frameworks? 

When you say you can tolerate some false negatives, where do you draw the line?  Would double-digit rates still be a dealbreaker?

Customer: Hell no. Double digits? Are you crazy?

Hopper: Ok, we heard you loud and clear. Check out this GitHub App. It only needs read-only access to your source control, no agents, no pipelines, no runtime dependencies. Would that work better for you?

Conversations like this and the hard questions behind them pushed us to be sharper, more thoughtful, and more deliberate about what Hopper needed to become.

Where That Took Us

Those early conversations did more than challenge us. They clarified what mattered and set the foundation for everything we built into Hopper. 

• Function-level reachability became our core.
• Transitive dependency coverage was non-negotiable.
• Agentless, runtime-free analysis became a guiding principle.
• Read-only SCM integration made onboarding simple and accessible across teams.
• Accuracy without false confidence was prioritized over perfect but impractical promises.

We did not design Hopper in a vacuum. We designed it side-by-side with the real-world teams who would have to live with our decisions every day.

Still Building with Eyes Wide Open

Today, Hopper looks very different than it did when we first started sketching ideas on a whiteboard. But one thing has not changed: we are still building with our eyes wide open.

We are still listening. Still learning. Still working to solve problems the right way, even when it is harder. 

We are proud of what we have built and even more excited about where we are heading.

If you are facing these challenges too, we would love to hear your story.

Because at Hopper, every good idea starts the same way: By listening.