Security

Reporting a vulnerability

Email security@asymm.systems. Responsible disclosure policy: acknowledgement within 72 hours, remediation target within 30 days for high-severity issues. Public advisories are published after fixes ship.

Do not file security issues as GitHub Issues on the public repo. Upstream OpenJDK vulnerabilities should be reported to the OpenJDK Vulnerability Group; Eliya-specific issues (patches, packaging, configuration) come to us.

Release signing & key fingerprint

Every Eliya release ships a detached GPG signature (SHA256SUMS.txt.asc) over the checksum manifest. The canonical Eliya signing-key fingerprint is:

Ed25519, UID Eliya Releases (Asymm Systems) <eliya@asymm.systems>, created 2026-05-19. This same value is published at key.asymm.systems, via Web Key Directory at openpgpkey.asymm.systems, and on the public keyservers keys.openpgp.org and keyserver.ubuntu.com. Cross-verify it across at least two independent channels before trusting the key. The fingerprint shown is the certify primary key; release signatures are produced by its dedicated signing subkey, which gpg --verify selects automatically. Step-by-step instructions are on the verify-download page.

Security inheritance from upstream

Eliya inherits upstream OpenJDK 25's security configuration unchanged. This is deliberate: JDK 25's java.security defaults already implement modern best practices:

Eliya does not re-declare these defaults as if they were its own. If you diff Eliya's conf/security/java.security against upstream OpenJDK 25, the result is empty for security configuration:

Eliya's contribution to operational security is observability, not duplicated java.security overlays. Heap dump on OOM and crash log artifacts today, plus continuous JFR recording and GC logging in Phase 2, produce audit-ready diagnostic trails for incident review, activated by -XX:EliyaProfile=Production.

Audit trail and diagnostic data attribution. Eliya's diagnostic path layout is designed as filesystem-encoded audit metadata. The three-level path ${ELIYA_DIAGNOSTIC_PATH}/${service_name}/${replica_name}/${category}/ provides service-level grouping (compliance queries scoped to a service return all artifacts under one tree), per-replica attribution (each subdirectory's name identifies the specific pod, container, or systemd unit that produced its contents), and lifetime disambiguation (PID-bearing filenames within each replica directory distinguish multiple JVM processes across the replica's lifetime). For regulated workloads, this preserves the chain of custody from incident to artifact to producing replica without requiring correlation with external systems. For full path strategy and resolution algorithm, see flags reference Diagnostic paths section.

For environments where SaaS APM is prohibited by data-egress policy (BFSI settlement systems, healthcare integrations under HIPAA, telecom BSS/OSS platforms, government and defence deployments, sovereign-cloud workloads under data-localisation laws), Eliya provides forensic capture capability previously inaccessible without violating compliance. The architectural distinction between APM observability platforms and local-only JVM forensics is documented in JVM forensics vs APM.

Full enumeration of how Eliya's binary differs from a vanilla OpenJDK 25 build: Differences from upstream OpenJDK 25.

If you need vanilla java.security (rare)

If a specific deployment genuinely needs to roll back to a different security configuration (legacy interoperability), use:

The double == overrides; a single = appends. Not recommended for general use.

Patch commitment

• Quarterly CPU: Eliya publishes within two weeks of each upstream OpenJDK CPU (third Tuesday of January, April, July, October).
• CVE-triggered rebuild: If upstream releases an out-of-cycle patch for a critical CVE, Eliya targets one week to ship.
• No SLA: Eliya does not today offer commercial support SLAs. The target windows above are commitments, not contractual guarantees. Enterprise support is a Phase 2 consideration.

See the lifecycle page for the forward CPU calendar.

Advisories

Each Eliya release documents the upstream CVEs it addresses plus any Eliya-specific patches. Canonical advisory list: PATCHES.md on GitHub.

FIPS 140-3 variant: Phase 2

A FIPS 140-3 compliant Eliya variant (eliya-25-fips.tar.gz) is a Phase 2 deliverable. The standard eliya-25.tar.gz distribution ships with SunJCE (not FIPS-validated). The FIPS variant will ship with the Bouncy Castle FIPS provider (CMVP cert #4943) pre-installed and registered, with java.security configured for FIPS-mode operation.

If your organisation requires FIPS-validated cryptography for procurement (BFSI, healthcare, government), join the early access list to be notified when the FIPS variant is available.

Security roadmap

Eliya's security posture is phased. Phase 1 (today) is upstream-aligned. Phases 2–4 add deliverables for customers with specific requirements. Full trajectory and demand-gating mechanics: roadmap.

Phase 4: compliance-aligned profiles

Compliance-aligned profiles activate stricter-than-upstream defaults via opt-in profile values. Phase 4 will expand the EliyaProfile enum with framework-aligned values:

• -XX:EliyaProfile=PCIDSS: PCI DSS Section 10-aligned settings
• -XX:EliyaProfile=HIPAA: HIPAA Technical Safeguards-aligned
• -XX:EliyaProfile=SOX: SOX IT general controls-aligned
• -XX:EliyaProfile=FedRAMP: FedRAMP-aligned settings
• -XX:EliyaProfile=GDPR: GDPR data-handling-aligned
• -XX:EliyaProfile=ISO27001: ISO 27001-aligned settings
• -XX:EliyaProfile=SOC2: SOC 2-aligned settings

Each profile adjusts java.security and JVM defaults for framework-aligned restrictions (algorithm allow-lists, key size minimums, certificate validation strictness, audit logging extensions).

For industries needing the union of multiple frameworks (healthcare payment processors needing PCI DSS + HIPAA, financial SaaS needing SOC 2 + ISO 27001, defence contractors needing FedRAMP + CMMC), Phase 4 will ship explicit combined profiles as distinct enum values:

• -XX:EliyaProfile=Healthcare-Payment: PCI DSS + HIPAA combination
• -XX:EliyaProfile=Financial-SaaS: SOC 2 + ISO 27001 combination
• -XX:EliyaProfile=Federal-Defense: FedRAMP + CMMC combination

Combined profiles are designed explicitly, not stacked from single-framework values. Profiles are mutually exclusive by design; only one profile value is active at runtime. Each combined profile activates the documented union of capabilities from its component frameworks plus any framework-specific JVM settings the combination requires. The auditor sees one profile name in asymm --info output; the capability list is documented; compliance attribution is unambiguous.

Phase 4 is demand-gated. Each profile ships when at least 5 enterprise prospects have signed up with a specific framework requirement and provided usable use-case descriptions. PCI DSS, HIPAA, and SOX are the most-requested profiles based on early waitlist signals; FedRAMP, ISO 27001, SOC 2, and GDPR follow based on the demand mix.

Activating a compliance profile aligns JVM defaults with framework requirements. It does not certify the application or the organisation as compliant; compliance is a holistic posture across application code, infrastructure, processes, and controls. The profile reduces JVM-level audit findings; the rest of the compliance posture remains the organisation's responsibility.

Why this is opt-in

Eliya never coerces users into stricter security posture. Stricter-than-upstream restrictions can break enterprise integrations with legacy systems (older TLS endpoints, weaker certificate chains, deprecated algorithms in supplier ecosystems). Compliance profiles activate explicitly so teams consciously accept the compatibility trade-off.

The architectural pattern matches -XX:EliyaProfile=Production: opt-in, never coercive, same trade-off framework: accept some constraint in exchange for a specific operational property.