When Quarkus goes EOL, the CVEs don't stop.
Never-Ending Support (NES) for Quarkus keeps your Kubernetes-native Java services secure, compliant, and audit-ready after your release line reaches end of life. When you're locked to Quarkus 2.16 or 3.20, NES gives your security team a supported build so you control the security posture, the upgrade timeline, and where engineering spends its time.
TRUSTED BY ENTERPRISE
Security, compliance, and continuity, solved together
Quarkus ships a new release roughly every month, and each non-LTS line stops getting community fixes the moment the next one lands. Even LTS lines are actively supported for about a year. Unless you chase every release, your services drift onto an end-of-life version fast, and the CVEs that follow go unpatched while scanners flag every build. NES for Quarkus is a supported build of the 2.16 or 3.20 release line you're already on.
Security
The risk: Quarkus sits at the network edge, handling HTTP, REST, and auth traffic. When your line goes EOL, there's no upstream fix.
CVE fixes across all severity levels on your EOL release line, closing the window that HTTP, security-policy, and deserialization attacks depend on.
SLA-backed patch delivery tied to severity
Fixes applied to your exact 2.16 or 3.20 line
Core, HTTP, REST, security & data coverage
Compliance
The risk: an open audit finding with no remediation path under CRA, DORA, NIS2, PCI DSS, and SOC 2.
Every build ships with VEX statements auditors and scanner tools can consume, so you have documented evidence to close the unsupported-dependency finding.
Coverage for SOC 2, PCI DSS, HIPAA, FedRAMP
DORA, NIS2, EU Cyber Resilience Act, and more
VEX statements & documented patch history
Business Continuity
The risk: a forced Quarkus major-version bump can break Jakarta EE, MicroProfile, and extension contracts your services depend on.
A drop-in quarkus-bom you swap in with a version change and no application code changes, so you migrate Quarkus lines on your own schedule.
Months or years of runway to migrate right
No rewrites, no broken extensions
A fraction of the cost of a forced framework migration
ECOSYSTEM PARTNERSHIP
The Commonhaus Foundation is a non-profit home for community-governed open source projects, including Jackson, ensuring their long-term stewardship and sustainability. HeroDevs is proud to be the founding member of the Commonhaus Foundation Open Source Sustainability Initiative (OSSI). HeroDevs worked with Commonhaus to establish this security focused initiative and provides Never-Ending Support (NES) for end-of-life versions of Jackson, and other open-source projects governed by The Commonhaus Foundation.
What changes the day you install NES.
Before — the pain
Your services run on an EOL Quarkus line
Scanners flag every build. No upstream patches are coming. When a new HTTP or security-policy CVE drops, the window between disclosure and exploit stays open until you migrate.
After — with HeroDevs
NES restores your patch path
A quarkus-bom version swap resumes SLA-backed CVE patches across the covered extensions, with your APIs and application behavior unchanged.
Before — the pain
An open finding with no answer
Internal audit, SOC 2, and a customer security questionnaire all flag your EOL quarkus-core. There's no remediation path short of a subscription or a rushed upgrade — and no defensible answer for auditors.
After — with HeroDevs
Findings close, questionnaires answer themselves
A named, vendor-backed build with committed SLAs and VEX statements. Scanners stop flagging CVEs and you reference a runtime aligned to PCI DSS, HIPAA, SOC 2, DORA, and NIS2.
Before — the pain
The release cadence vs. the roadmap
Jumping Quarkus lines can bring Jakarta EE, MicroProfile, and extension changes that break your services. Chasing the monthly cadence — or a rushed LTS jump — pulls engineers off the roadmap.
After — with HeroDevs
Migrate on your terms, not the cadence
A drop-in BOM — no code changes. Teams get the breathing room to plan a proper upgrade while the line they run stays secure, compliant, and stable.
Not just quarkus-core.
NES for Quarkus covers the extensions most services actually depend on: the runtime and CDI core, the HTTP, REST, and messaging layer, and the security, identity, and persistence extensions.
Core & runtime
The engine
quarkus-core
quarkus-arc (CDI)
quarkus-vertx
quarkus-bootstrap
HTTP, REST & messaging
The edge
quarkus-rest
quarkus-resteasy
quarkus-vertx-http
quarkus-grpc
quarkus-rest-client
smallrye-reactive-messaging
Security, data & platform
The glue
quarkus-security
quarkus-oidc
quarkus-smallrye-jwt
quarkus-hibernate-orm
quarkus-agroal
quarkus-jdbc-postgresql
Easy to deploy, no disruptions
Add the registry
Register registry.herodevs.io as a Maven repository in your pom.xml or settings.xml.
Set up your token
Add your HeroDevs auth token to settings.xml so the build can pull the patched artifacts.
Swap the BOM
Point quarkus-bom at the -nes build and rebuild. No application code changes.
Scanners pass
Actively patched and commercially supported — so CVE findings on EOL Quarkus close.
A defensible answer for every standard, framework, or regulation
EOL software undermines patch-management expectations across regulations worldwide. NES gives you a maintained, vendor-backed build with committed SLAs and a documented patch history to demonstrate compliance to auditors and regulators.
PCI DSS
Req. 6.3.3 requires known critical and high-severity vulnerabilities to be patched within 30 days. EOL Quarkus with no upstream patch puts you out of compliance. NES restores the patch path.
HIPAA
Unsupported frameworks make it hard to show reasonable safeguards for systems handling ePHI. NES provides active maintenance and risk reduction.
SOC 2
Trust Services Criteria expect timely vulnerability remediation and patch management. EOL dependencies raise material findings during audit unless a compensating support path exists. NES is that support path.
NIS2
Article 21 covers patching, vulnerability, and supply-chain management. Running EOL software without a maintained support path creates risk that NIS2 expects operators to actively mitigate.
DORA
DORA treats EOL software as a resilience gap for financial ICT assets. NES gives you a maintained build and a documented patch-management program.
Cyber Resilience Act
Governs software lifecycle security for products with digital elements. NES gives you a maintained, patched build for your EOL Quarkus line during the coverage period.
NIST CSF 2.0
Control PR.PS-02 requires organizations to actively maintain or remove vulnerable software based on risk. NES enables compliance without a forced upgrade.
FedRAMP
Continuous monitoring expects flaw remediation on a defined cadence. A patched, vendor-backed build gives your ISSO the documented remediation path to justify keeping EOL Quarkus in the authorization boundary.
Commercial Contracts
Vulnerability and configuration management controls require identifying technical vulnerabilities and keeping software within secure standards. NES restores that posture for EOL software.
Built by security engineers who patch what you run.
Every NES for Quarkus build closes the known CVEs for covered extensions on your version line, and ships with VEX statements and release notes that map to the advisories your scanner is flagging.
HeroDevs is a CVE Numbering Authority and a founding member of the Commonhaus Open Source Sustainability Initiative, funding the maintainers and ecosystems that keep Java open source moving forward.
CVE Numbering Authority
Discovery and publication of CVEs in HeroDevs-covered products.
VEX with every build
Machine-readable for your scanners
Committed SLAs
Severity-tied patch delivery
Frequently Asked Questions
Contact Us
Got questions about Never-Ending Support for your open-source library? We're here to help!
Discover how HeroDevs NES Products can keep your systems secure and compliant.
Learn how our solutions can deliver value to your organization.
Get detailed pricing information tailored to your needs.
Stay on Top of Java and JVM Security & Compliance Updates
View All Articles
.png)
