Notifications
Clear all
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.
NHIMG editorial — based on content published by Oligo Security: Runtime Security for Java: From Visibility to Active Defense
By the numbers:
- Nearly 70% of organizations report that more than half of their applications run on Java or the JVM.
- 19% of applications still run on Java 6 or 7, versions released nearly two decades ago.
- 13% of organizations still rely on vulnerable versions of Log4j in production, years after patches were released.
Questions worth separating out
Q: How should security teams prioritise legacy Java vulnerabilities?
A: Prioritise the vulnerabilities that are actually executing in production, exposed through reachable interfaces, and attached to high-value business functions.
Q: Why do legacy Java applications create a bigger security problem than patching alone?
A: Because patching is often slow, risky, or impossible when code is tightly coupled to business processes.
Q: What is the difference between static scanning and runtime protection for Java?
A: Static scanning predicts what could be vulnerable, while runtime protection shows what is actively happening in production and can stop abuse in real time.
Practitioner guidance
- Inventory runtime-executing Java paths Use runtime telemetry to identify which libraries, methods, and code paths actually execute in production, then prioritise only those paths for containment or remediation.
- Constrain workload privileges before patching lags Reduce the permissions held by service accounts and application tokens associated with legacy Java workloads.
- Block unsafe execution patterns at runtime Add protections for deserialization abuse, suspicious lookup behavior, and malicious class loading so exploit attempts are stopped before code execution completes.
Teams that already use the NIST Cybersecurity Framework 2.0 can map this work to protect and detect functions, while workload visibility should be aligned to the NHI Lifecycle Management Guide?
👉 Read Oligo Security's analysis of runtime defense for legacy Java applications →
Explore further
15/05/2026 7:53 pm
Runtime truth is the missing control plane for legacy Java security. Static inventories and vulnerability scanners tell teams what exists, not what executes. In tightly coupled Java estates, that distinction decides whether a finding is theoretical or exploitable. The field should treat live execution telemetry as a core security control, not an optional observability layer. Practitioners should prioritise runtime truth over dependency theory.
A few things that frame the scale:
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
A question worth separating out:
Q: How can organisations reduce blast radius in legacy Java environments?
A: Limit the privileges of the workload, monitor live code execution, and block unsafe actions before they complete. That combination reduces how far an attacker can move if a library is abused. Blast radius is controlled less by the number of vulnerabilities than by the trust granted to the running application.
👉 Read our full editorial: Java runtime defense for legacy libraries: what changed for security teams
