The Precision Gap in .NET Static Analysis
Static analysis has matured for decades in ecosystems like Java, supported by a long history of open research and independent tooling. Go, though younger, was designed as open source from the start and quickly developed strong native analysis tools. The .NET world, by contrast, has long lacked precision and diversity in static analysis. This comes from its closed-source origins and slower adoption of open research.
Extending Hopper’s function-level reachability analysis to ASP.NET is a breakthrough. Unlike package-level approaches, where an entire namespace or assembly is flagged once a single entry point is invoked, Hopper pinpoints reachability down to the individual function. The result is less noise and greater confidence in what is truly exploitable.
Why ASP.NET is Uniquely Challenging
ASP.NET applications are not simple console apps. They are rich, service-oriented systems with dynamic wiring and runtime behaviors that push static analysis to its limits. To understand why, let’s look at a few characteristics that make ASP.NET uniquely complex for precise reachability analysis.
Dependency Injection (DI)
Microsoft.Extensions.DependencyInjection powers nearly every ASP.NET app. Controllers, services, and middleware are resolved through DI containers rather than manual instantiation. This creates complex chains of registrations, lifetimes, and interdependencies. Without modeling DI, analyzers either miss critical services or assume everything is reachable.
Reflection
ASP.NET apps often rely on reflection, from Activator.CreateInstance to dynamic controller discovery. Reflection blurs the line between code visible at compile time and code invoked at runtime. A precise analyzer must resolve these calls to concrete targets or risk losing entire call chains.
Database APIs and Async Workflows
Modern ASP.NET apps depend on Entity Framework, ADO.NET, and LINQ providers. These APIs generate queries dynamically, translating expression trees at runtime. Combined with async/await, thread pools, and background services, execution flows can jump unpredictably across methods and threads.
Generics
ASP.NET embraces generics, from middleware to repository patterns. Generics multiply call graph complexity since Foo<T> may be instantiated in dozens of ways. Conventional analysis either explodes in complexity or sacrifices precision.
Together, these factors make precise reachability in ASP.NET uniquely difficult.
Hopper’s ASP.NET Breakthrough
Dependency Injection Modeling
Hopper simulates the entire DI pipeline. Registrations like services.AddSingleton<IFoo, Foo>() are captured as call-graph edges, ensuring injected services resolve to their concrete implementations. Built-in ASP.NET services such as logging, configuration, and hosting are also modeled so controllers and middleware wire up without false positives.
Reflection-Aware Analysis
Hopper resolves common reflection patterns, from dynamic controller discovery to MethodInfo.Invoke and Activator.CreateInstance, and links them back to their concrete targets.
Database and Async APIs
Hopper models how LINQ queries translate into execution paths in Entity Framework and similar APIs. For async code, it reconstructs continuations across await, Task.Run, and thread-pool scheduling so reachability follows the actual runtime flow of ASP.NET apps.
Generics and Runtime Types
Hopper extends reachability into generic instantiations, tracing real type parameters and substitutions. Generic services, repositories, and middleware are treated as concrete reachable functions, not abstract placeholders.
“Dependency Injection, reflection, async workflows, and generics are no longer blind spots. Hopper models them all.”
Zero-Effort Onboarding
Bringing this precision to .NET could have required heavy setup, but Hopper’s onboarding is zero-effort. Customers provide a Version Control System (VCS) token, and Hopper pulls repositories, compiles them in a controlled environment that supports both .NET Core and .NET Framework, and analyzes the IL (Intermediate Language) directly. The result is accurate, framework-aware reachability without manual configuration, annotations, or developer time.
Why This Matters for ASP.NET Teams
Legacy SCA and static analysis tools struggle to handle the dynamic nature of ASP.NET. They flag every dependency as risky, miss runtime behaviors like dependency injection or reflection, and overwhelm developers with alerts that lack context. The result is noise, false positives, and wasted time chasing issues that don’t actually affect production.
Hopper changes that by bringing precision, context, and automation to .NET analysis.
- Noise reduction: Function-level reachability filters out non-exploitable vulnerabilities, eliminating the false positives that plague legacy tools.
- True ASP.NET coverage: Hopper models DI, reflection, async workflows, database APIs, and generics, giving teams visibility into code paths that other analyzers miss.
- Confidence across runtimes: Whether running modern .NET 8 or maintaining legacy .NET Framework apps, Hopper delivers consistent, framework-aware analysis.
- Speed to value: With zero-effort onboarding, teams see accurate, prioritized results in hours instead of weeks, without any CI/CD or DevOps changes.
Finally, Precision for ASP.NET
ASP.NET applications are among the most complex and dynamic systems in production. Hopper is the first platform to deliver function-level reachability with ASP.NET-specific modeling, closing the precision gap that has long existed compared to Java and Go.
If your team builds on ASP.NET, Hopper now gives you the visibility and confidence you have been missing.
Itai is a Senior Software Engineer on the Reachability team at Hopper. He specializes in code analysis solutions—both dynamic and static—with over a decade of hands-on experience across a wide range of technologies. Outside of work, Itai enjoys watching anime, playing bass, and occasionally cooking something tasty.
.png)
