When a vulnerability disclosure hits the news, you’ll always get the same recommended action: patch it. But for organizations running legacy Java applications, that’s a luxury they often can’t afford. Whether due to third-party vendor constraints, outdated frameworks, or tightly coupled systems too fragile to mess with, or simply prohibitive costs and lack of resources, many enterprises find themselves staring down compliance deadlines without a viable patching path. That’s when compensating controls become the best available option.
In security and compliance circles, a compensating control (as defined by the PCI Security Standards Council) is a temporary solution that “sufficiently offsets the risk” when an organization cannot meet predetermined requirements.” In other words, when you can’t patch, you have to prove to your auditor that you’ve mitigated the risk another way.
The problem is that not all controls are created equal, and auditors don’t sign off on just any workaround. A compensating control has to be equivalent in strength (to the patch), well-documented, and verifiable. That’s a tall order if your system is too complex or fragile to apply the patch in the first place.
Moreover, compensating controls can become a compliance risk in themselves. Poor documentation, inadequate enforcement, or insufficient visibility can all lead to audit failures—even if the technical risk has been reduced. The key to nailing compensating controls is getting them to be as easily demonstrable as they are technically effective.
The Unique Challenge of Legacy Java
Java has a long and storied history in enterprise ecosystems. That means that a lot of critical systems are still running on versions that are long out of support. For instance, a third of Java applications in production still utilize Java 8, which was first released in 2014. Upgrading from Java 8 to newer versions like Java 11 or Java 17 can be complex due to compatibility issues. For instance, Project Jigsaw, introduced in Java 9, modularized the Java platform, which broke backward compatibility for many applications relying on internal APIs.
This has made migration efforts more challenging for a lot of organizations. This reliance on legacy Java versions and outdated dependencies presents significant challenges when it comes to security and compliance. Many patches released by first party vendors like Oracle simply aren’t compatible with these older versions of the language. Even when they can be applied, they can often break other functions within the ecosystem.
In regulated industries like finance, healthcare, and retail, failing to patch known vulnerabilities can put you in violation of frameworks like HIPAA, PCI DSS 4.0, CCPA and GDPR.
Specialized problems like this require specialized solutions. In this case, organizations need a solution that effectively mitigates threats inside Java applications without requiring a specific patch. And they need that solution to provide comprehensive logging and reporting capabilities.
Most Workarounds Don’t Work
The default fallback options usually don’t measure up. Virtual patching at the network or WAF layer may offer partial protection, but they operate outside the application runtime. They can often block known exploit patterns, but they can’t stop internal method calls, deserialization flaws, or vulnerable logic paths that only exist inside the JVM. Worse, they often lack granularity or contextual awareness which can cause a lot of false positives or even break application logic if configured incorrectly.
Static code scanning tools offer visibility, but only for an organization’s proprietary code, which makes up about 20-30% of the entire app stack. And even for the code that is sourced internally, SAST tools will not offer any mitigation capabilities. They help identify the problem, but they don’t stop exploitation at runtime. And delaying a patch while relying solely on detection tooling doesn’t meet the bar for compensating control under most regulatory standards.
And none of these solutions offer the level of reporting that auditors will require to allow a compensating control to stand in place of a true patch.
Good Compensating Controls Require…
Not all compensating controls are created equal. A good one should meet three key criteria:
- Runtime protection that actively mitigates the vulnerability in the context it exists.
- Metadata that maps directly to the compliance framework requirements (e.g., CVE, CWE, CVSS).
- Auditability through logging and enforcement evidence that can be shown to internal and external assessors.
A compensating control that modifies application behavior in real time without code changes is rare. Waratek is designed specifically for this purpose.
Waratek: Compensating Controls That Actually Work
Waratek is a software-defined runtime application self-protection (RASP) product that delivers compensating controls purpose-built for legacy Java environments. This allows you to enforce runtime protections directly inside the JVM without requiring any code changes.
At the heart of Waratek’s approach is its Virtual Patch Rule capability. Security teams can deploy protections for known Java vulnerabilities (CVEs) that behave like traditional vendor patches but without modifying application source code or bytecode. These rules can be scoped to specific functions, libraries, or behaviors, giving teams precision control over exploit mitigation.
Each Patch Rule is accompanied by rich metadata, including CVE and CWE identifiers, CVSS scores and vectors, descriptions and timelines, and affected products and versions.
This metadata is fully parseable and loggable, making it straightforward to map controls directly to compliance frameworks. When a Virtual Patch Rule is triggered, Waratek’s engine logs the event in Common Event Format (CEF), with all the metadata required for reporting.
Waratek’s Threat Remediation Platform allows customers to apply only the CVE patches you actually need. Broad vendor updates like the Oracle CPU often include the full sweep of CVE patches, regardless of severity or relevance. Meanwhile, Waratek delivers targeted, bespoke patching. That means if you’re only concerned with vulnerabilities above a certain CVSS score, you can avoid applying low-risk patches that introduce unnecessary complexity. This means you get lower operational costs, fewer resource demands, and minimal risk of application interference. It’s patching that respects your environment.
What’s more, these protections are designed to fit seamlessly into your existing security workflows. Waratek’s logs flow directly into existing SIEM platforms, ensuring visibility without additional integration overhead. Its rules can be managed alongside broader application security policies, enabling centralized governance and consistent enforcement. For GRC and compliance teams, Waratek provides telemetry that clearly demonstrates security coverage across Java assets, making audit preparation more straightforward.
Get Started Today
You can’t just press pause on compliance when you have technical debt. Stakeholders and auditors alike will not accept any excuses when data privacy is on the line. So when patching isn’t an option, compensating controls are the only way to go. But to be effective, they need to go beyond vague policy documents or hopeful architecture diagrams. They need to work, log, and prove.
Waratek was built for this very scenario. In a world of aging Java systems and evolving compliance requirements, our platform offers organizations a way to achieve the necessary protections without rebuilding their system from the ground up.
