OpenJDK for telecom: carrier-grade JVM evidence

The next log4shell, across ten thousand JVMs

Your scanners told you what was in the images. That was not the question. Your BSS and OSS estate is a decade of accumulated Java: charging, mediation, provisioning, inventory, order management, some of it vendor-shipped as fat jars with shaded dependencies, much of it in long-lived processes that were last restarted in a maintenance window you would have to look up. A jar on disk tells you nothing about a class in a running process. Shading hides the version. Classloader precedence picks a winner you did not choose. A canary that rolled back is still serving traffic on the old code.

So teams did what teams do: they guessed, they restarted things defensively, and they wrote a remediation report that said "patched" when what they meant was "we believe patched".

Eliya's loaded-code attestation makes that a query. Signed by the runtime, about itself: class to jar-of-origin, classloader, load order, hashes. Not what shipped. What loaded. Targeted at 25.0.7.

To be straight with you: a JVMTI agent can already enumerate loaded classes. The inventory is commodity, and we will not sell it to you as though it were not. What an agent cannot do is attest: it can be left unattached, refused by -XX:-EnableDynamicAgentLoading, or have its output rewritten by in-process code. The differentiator is the signature and the non-defeatability, and at your estate size, the difference between "a tool reported" and "the runtime attested" is the difference between a report and evidence.

Evidence that never leaves the operator perimeter

Eliya sends nothing outward. No telemetry. No SaaS dependency.

Heap dumps, Flight Recorder files, GC logs, crash logs: every diagnostic artifact stays inside your network, because there is no mechanism to send it anywhere. For an operator subject to lawful-intercept obligations, national data-residency rules, or a regulator who takes a dim view of subscriber data transiting a vendor's cloud, this is not a preference. It is a precondition.

And your diagnostics carry subscriber data. A heap dump of a charging system holds MSISDNs, IMSIs, call detail, and in a converged BSS, payment card data. Which brings the other problem.

Your charging system is in PCI scope

Operators tend to discover this late. If your BSS handles card payments (top-ups, subscriptions, device financing), the JVMs that touch that data are in PCI DSS scope, and PCI DSS 3.5.1 says PAN must be rendered unreadable anywhere it is stored.

A heap dump is storage. So when a charging node OOMs at peak and writes a dump, that file holds card numbers in cleartext, and none of your at-rest encryption touched it, because the value was live in memory at the instant of the write.

The usual answer is to disable heap dumps across the estate and lose the forensic evidence exactly where you most need it: in the high-volume, hard-to-reproduce failures that only happen under real load. Eliya redacts at the serialisation boundary, inside the VM, as the stream is written (25.0.4), so you keep the dump and lose the PAN.

What else the outside cannot close

The problem	Why an outer layer cannot fix it	Eliya
Subscriber data and PAN in heap dumps, crash logs and JFR files	The writer is native and inside the process, emitting cleartext as the stream is written. Scrubbing acts on a file that already holds the data.	25.0.4
Which code is actually running across the estate	"Installed" is not "loaded": shading, classloader order, unrestarted processes.	25.0.7
Audit trails on nodes an attacker has reached	A SIEM seals what it received, and cannot detect a record suppressed before it left the host. Absence looks like quiet.	25.0.7
Config drift across thousands of nodes	An admission controller validates the spec it can see, not `JAVA_TOOL_OPTIONS` in an image layer nor a value changed after startup.	25.0.5
TLS that a library quietly weakened	`java.security` is settable; a library building its own `SSLContext` makes it not enforceable. Your mesh does not see the call to a roaming partner's gateway.	25.0.6

Long-lived processes, and a cadence you can plan around

Telecom runs JVMs for months. That is a virtue for stability and a liability for patching, and it is exactly why "installed" versus "loaded" bites operators harder than anyone else.

What ships today is the thing you can build a maintenance calendar on: a quarterly security refresh within about two weeks of upstream OpenJDK, critical CVEs targeted inside a week, committed through the JDK 25 LTS window (September 2029). Signed releases with checksums and an SBOM, so your supply-chain review has something real to look at.

What we do not claim

Eliya is a JDK. It will not do network security, it will not do lawful intercept, and it will not do your NIS2 governance. Your platform team owns segmentation, your KMS owns keys, your SIEM owns retention and correlation. Those are the right owners.

We also have not yet decomposed telecom-specific frameworks (TM Forum, NIS2, the ETSI security specifications) the way we have decomposed PCI DSS. If your estate is blocked on a specific control, tell us which one. That is how the next round of the knowledge base gets written, and it is how we would rather build than by guessing at a slide.

Telecom is also where Asymm Systems builds Dial, its build-time TMF Open Digital Architecture (ODA) conformance work, so the runtime and the ecosystem share the same compliance-conscious premise.

Talk to the Chief Architect about the CVE you could not answer. Or download Eliya, or read the policy point.