Our approach
Proportional patching: rigor where it matters, speed everywhere else
Full regression testing before every JVM patch is the main reason enterprise patch cycles take months. For most applications that ceremony costs more than the risk it removes. So we don't skip testing; for the right tier of apps we replace it with fast detection and fast rollback.
1. Classification
Criticality is scored, not self-declared
App owners have every incentive to call their app non-critical to avoid friction, and they rarely bear the consequences if they're wrong. So tiering can't be a gut call. We use a documented, repeatable scoring process backed by tooling.
Revenue and customer impact
What breaks, for whom, and what it costs per hour if this app is down.
Blast radius
Shared infrastructure, shared databases or a shared message bus with critical systems.
Regulatory scope
PCI, HIPAA, SOX and friends. Plenty of "internal tools" touch regulated data.
SLA and SLO commitments
Whether one exists, what tier it is, and who it is owed to.
Risk authority
Who can accept the risk, and whether they actually have that authority.
- 1
Automated intake
JVM version and vendor, exposure, dependency graph, embedded agents, SLA metadata and incident history come straight from discovery data.
- 2
Structured owner interview
A fixed, short question set captures what scanning can't: true business criticality, compensating controls and downstream dependents.
- 3
Weighted scoring
Inputs feed a documented, weighted model that produces a numeric score. The result doesn't depend on which consultant ran the interview.
- 4
Threshold routing
Fixed score bands route each app to Rapid Patch, Critical Patch Assurance, or manual review. The thresholds are set before any app is scored.
- 5
Sign-off and evidence
The tier, its inputs and the named risk-acceptor are recorded as a timestamped artifact your CAB signs.
- 6
Re-scoring
Criticality changes. Scores re-run quarterly and on triggers: a new regulated data flow, a traffic spike, an incident, a new CVE.
2. Segmentation
A "JVM patch" is three different things
Security updates within a release line, major version upgrades and vendor swaps carry very different risk. We price and run them as separate engagements.
| Change | Example | Risk | How we handle it |
|---|---|---|---|
| Same-major security patch | 17.0.15 → 17.0.16 | Low: mostly CVE and bug fixes | Rapid Patch for non-critical apps |
| Major version upgrade | 11 → 17 → 21 → 25 | High: removed APIs, strong encapsulation, GC and security defaults | Readiness assessment, then a planned upgrade |
| Vendor swap, same version | Oracle JDK → Temurin, Corretto, Zulu | Usually low, but not zero: builds, defaults and bundled tooling differ | OpenJDK migration with targeted verification |
3. Detection and rollback
If detection is fast and rollback is cheap, exhaustive testing isn't needed
This is the engineering argument behind Rapid Patch. When a bad patch is caught in minutes and reversed in minutes, it costs far less to skip a full regression run for a low-criticality app.
- Progressive rolloutCanary at 1%, then 10%, then 100%, each step gated on automated health checks.
- Observability as the safety netCompare error rates, latency, GC pause times and thread behavior before and after the patch.
- Fast, rehearsed rollbackThis is often the real gap, especially outside containers. When it is, we fix it first.
- Smoke tests and synthetic transactionsTargeted checks of the paths that matter, in place of a full regression suite.
4. Known failure modes
We check for the ways JVM changes actually break
Most JVM patch incidents fall into a short list of known patterns. We check for each one before rollout, not after.
APM and instrumentation agents
Java agents from APM, security and profiling vendors are among the most common things to break on a JVM change.
TLS and cipher defaults
Disabled protocols and removed cipher suites can silently break integrations with older partners and appliances.
JIT and warm-up behavior
Compiler changes shift warm-up curves, which matters for latency-sensitive services behind tight SLOs.
GC defaults and tuning
Collector defaults and ergonomics change between releases, and hand-tuned flags can be deprecated or ignored.
Removed and encapsulated APIs
Strong encapsulation of JDK internals and the removal of the Security Manager break older libraries on major upgrades.
Container awareness
Older runtimes size heaps and thread pools from the host, not the container limits they actually run under.
5. Governance
What your CAB actually approves
Usually the hardest part isn't technical. It's getting a risk and compliance function to accept a different process. So the deliverable isn't only automation. It's a governance framework, a waiver process and an audit trail that let your Change Advisory Board approve streamlined patching for a defined tier of applications.
- Classification rationale and every input behind it
- The named person who accepted the risk, and their authority to do so
- Rollout plan, health gates and rollback procedure
- Evidence from each rollout: signals checked, results, timestamps
- Re-review schedule and the triggers that force one
Find out what's actually running in your estate
A Quick Scan inventories the JVMs in one business unit in days. You get versions, vendors, patch levels, CVE exposure and Oracle licensing exposure, with no production changes and no CAB ticket.