Topic starter
15/05/2026 7:52 pm
TL;DR: Legacy Java remains embedded in enterprise systems, with nearly 70% of organisations saying more than half of their applications run on Java or the JVM, according to Azul's 2025 survey cited by Oligo Security. Runtime protection shifts the focus from static vulnerability lists to live execution paths, which is where legacy library abuse actually becomes exploitable.
Editorial analysis by NHI Mgmt Group, based on content published by Oligo Security: “Runtime Security for Java: From Visibility to Active Defense”.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
Key questions
Q: What breaks when legacy Java libraries are only assessed at build time?
A: Build-time assessment misses the runtime context that determines whether a vulnerable library is actually reachable.
Q: Why do unpatchable Java dependencies create ongoing risk in production apps?
A: They remain live inside business-critical workflows even after a fix is unavailable or too disruptive to apply.
Q: How do security teams tell whether a legacy Java flaw is actually exploitable?
A: They need to trace the full execution path from input to sink and confirm that the vulnerable method is both loaded and invoked in production.
Practitioner guidance
- Instrument production execution paths Use runtime telemetry to identify which Java classes and methods are actually executed in business-critical applications, then separate active code from dormant dependency noise.
- Prioritise exploitable library paths Map vulnerable libraries to the exact runtime flows that can reach deserialization, JNDI, file access, or command execution sinks before deciding what needs containment.
- Contain unsafe behavior without service disruption Block malicious function-level actions in legacy Java while preserving ordinary transactions, especially where refactoring would create unacceptable business interruption.
Bottom line: Legacy Java risk is driven by what actually executes in production, not by what appears in a build-time inventory.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
15/05/2026 7:53 pm
Runtime truth is now the decisive control variable for legacy Java. Static inventories and build-time scanners cannot tell teams whether a vulnerable library is actually executed in production, which is the difference between theoretical exposure and exploitable exposure. That gap matters most in legacy estates where dependencies remain embedded for years. Practitioners should treat observed execution as the governance boundary, not package presence.
A few things that frame the scale:
- 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
A question worth separating out:
Q: Should teams replace static scanning with runtime protection for Java applications?
A: No. Static scanning still helps inventory risk, but it cannot tell you which paths are live or whether an exploit chain is active. Runtime protection is the better containment layer when patching is delayed, because it blocks unsafe behavior in production while the organisation modernises legacy dependencies.
👉 Read our full editorial: Java runtime defense for legacy libraries: what changed for security teams
This post was modified 4 days ago by NHI Mgmt Group