Blog

JBoss EAP 7: Warum 'Es läuft ja noch' ein Risiko ist

JBoss EAP 7 läuft - aber laufen bedeutet nicht sicher, nicht compliant, nicht auditierbar. Was wirklich auf dem Spiel steht.

Warum “läuft” kein Sicherheitsstatus ist

JBoss EAP 7 läuft. Es verarbeitet Requests, liefert Responses, zeigt keine Fehler im Monitoring. Für viele IT-Leiter ist das Argument genug, die Migration zu verschieben.

Das ist eine gefährliche Fehleinschätzung - und sie basiert auf einem Denkfehler: Verfügbarkeit und Sicherheit sind verschiedene Eigenschaften. Ein System kann hochverfügbar sein und trotzdem angreifbar, auditierbar sein und trotzdem non-compliant.

JBoss EAP 7 befindet sich seit Juni 2025 im Extended Life Cycle Support. Patches für moderate und niedrige CVEs kommen nicht mehr. Patches für wichtige CVEs (CVSS 7.0-8.9) sind nicht garantiert. Nur kritische Lücken werden noch gepatcht - nach Red Hats eigenem Zeitplan, nicht nach dem des Angreifers. Den genauen Supportumfang erklärt der Artikel JBoss EAP 7 im Extended Life Cycle: Was das konkret bedeutet.

Ungepatzte CVEs: Was konkret offenbleibt

Die Schwachstellendatenbank ist kein theoretisches Problem. Gegen WildFly und JBoss EAP wurden 2024 mehr als 30 CVEs gemeldet. Davon lagen mehrere im CVSS-Bereich 7.0 bis 8.9 - also in der Kategorie “wichtig”, für die es im Extended Life Cycle Support keine garantierten Fixes gibt.

Was konkret offenbleibt, wenn Patches ausbleiben:

  • Deserialisierungslücken in integrierten Bibliotheken (bekanntes Angriffsmuster gegen Java-Middleware)
  • Informationslecks über fehlerhafte HTTP-Response-Behandlung
  • Privilege-Escalation durch unsauber konfigurierte Security-Domains
  • Angreifbare Drittkomponenten (Log4j-Klasse von Risiko, auch wenn konkrete Versionen variieren)

Keines dieser Risiken erzeugt Alarme im normalen Monitoring. Das System läuft. Erst ein gezielter Angriff oder ein Penetrationstest bringt das Problem ans Licht.

Configuration Drift: Was sich unbemerkt verschlebt

Neben unzureichendem Patching gibt es ein zweites, häufig unterschätztes Risiko: Configuration Drift.

Im laufenden Betrieb akkumulieren sich Änderungen. Ein Workaround hier, eine temporäre Ausnahme dort, eine Konfigurationsanpassung für ein spezifisches Deployment. Niemand schreibt alles auf. Nach zwei bis drei Jahren weicht der Ist-Zustand einer JBoss-Instanz spürbar vom ursprünglichen Soll-Zustand ab.

Das konkrete Risiko: Sicherheitseinstellungen, die einmal gesetzt wurden, wurden überschrieben. Security-Subsysteme, die aktiviert sein sollten, sind deaktiviert. Ports sind offen, die geschlossen sein sollten.

Mehr dazu, was Configuration Drift bei JBoss EAP 7 in Compliance-Audits bedeutet, lesen Sie im Artikel JBoss EAP 7: Configuration Drift und Compliance-Risiken.

In regulierten Umgebungen ist Configuration Drift nicht nur ein Sicherheitsrisiko. Es ist ein Compliance-Risiko, weil der dokumentierte Sollzustand und der reale Betriebszustand auseinanderfallen.

Was Auditoren sehen

Auditoren - egal ob für ISO 27001, BSI IT-Grundschutz, SOC 2 oder KRITIS-Nachweise - folgen einem ähnlichen Prüfmuster. Sie fragen nicht nur “läuft es”, sondern:

  • Welcher Patch-Stand ist aktuell installiert?
  • Welche CVEs sind bekannt und ungefixed?
  • Wie wird Patch-Compliance überwacht?
  • Wann wurde zuletzt ein Vulnerability Assessment durchgeführt?
  • Was ist der Plan für das EOL-Datum im Oktober 2027?

Auf jede dieser Fragen muss eine strukturierte, dokumentierte Antwort vorliegen. “Es läuft stabil und es gab keine Vorfälle” ist keine Antwort, die einen Finding verhindert.

Laut einer Studie von Enterprise Strategy Group von 2023 haben 67 Prozent der Organisationen mit veralteter Middleware im Vorjahr mindestens ein Audit-Finding zu Patch-Compliance oder Lifecycle-Status erhalten. Bei Organisationen, die sich in der Extended-Support-Phase befanden, lag die Quote bei 82 Prozent.

Das ist kein Zufall. Auditoren kennen die Red-Hat-Lifecycle-Daten. Wer mit EAP 7 auftaucht, muss mit Fragen rechnen.

Was passiert, wenn ein Finding dokumentiert wird

Ein Audit-Finding zu unzureichendem Patch-Management ist kein Formalienfehler. In regulierten Branchen hat es direkte Konsequenzen:

  • Remediationspflicht mit Frist: Das Finding muss behoben werden, oft innerhalb von 60 bis 90 Tagen. Das erzwingt kurzfristige Kapazität, die in der Planung nicht vorgesehen war.
  • Folgeaudit: Viele Zertifizierungsschemata fordern ein Nachaudit für offene kritische Findings.
  • Managementhaftung: Bei KRITIS-Betreibern und NIS2-pflichtigen Organisationen kann unzureichendes Patch-Management direkt zu persönlicher Managementhaftung führen.
  • Versicherungsausschlüsse: Cyber-Versicherungen prüfen zunehmend, ob bekannte, ungepatchte Schwachstellen im Schadensfall als grobe Fahrlässigkeit gewertet werden.

Das System lief. Der Angriff - oder das Finding - kam trotzdem.

Warum die Fehleinschätzung so häufig ist

Die Logik hinter “es läuft ja noch” ist menschlich verständlich. Keine unmittelbaren Symptome, kein akuter Druck, andere Prioritäten. Das ist exakt der Zustand, in dem technische Schulden entstehen.

Drei typische Konstellationen, in denen die Fehleinschätzung besonders häufig auftritt:

1. Fehlende Ownership: Niemand ist explizit verantwortlich für den Middleware-Lifecycle. Die Applikationsteams sagen, das ist Infra. Die Infra sagt, das ist Applikation. Das Thema fällt durch.

2. Kein CVE-Monitoring: Wenn kein automatisches Monitoring auf neue CVEs gegen JBoss EAP 7 eingerichtet ist, bemerkt niemand, wenn neue Schwachstellen publiziert werden. Das System läuft, die Lücke wächst unbemerkt.

3. Unklare Migrationshürde: Die Migration zu EAP 8 ist technisch nicht trivial. Jakarta EE 10 bringt Breaking Changes (jakarta.* statt javax.*). Die geschätzte Komplexität führt dazu, dass das Thema in der Priorisierung nach hinten rutscht - immer wieder.

Wie Teams mit begrenzter Kapazität trotzdem planbar vorgehen können, beschreibt der Artikel Migration wenn das Team am Limit ist.

Der konkrete Mindeststandard für den laufenden Betrieb

Wer JBoss EAP 7 noch betreibt und eine Migration nicht kurzfristig realisieren kann, sollte zumindest folgendes sicherstellen:

  • Red Hat Security Advisories für EAP 7 aktiv überwachen (RSS oder API)
  • CVE-Tracker mit Severity-Filter einrichten (CVSS ab 7.0 automatisch eskalieren)
  • Dokumentierten Ist-Zustand der laufenden Konfiguration erzeugen und versionieren
  • Schriftlichen Plan für Oktober 2027 vorhalten - auch wenn er noch nicht final ist
  • Security-Patches, die Red Hat im ELS noch liefert, zeitnah einspielen (Verzögerung ist kein Puffer, sondern zusätzliches Risiko)

Das ist kein Ersatz für eine Migration. Aber es reduziert das Risiko eines unerwarteten Findings und gibt IT-Leitern eine vertretbare Position gegenüber Auditoren.


FAQ

Ist JBoss EAP 7 im Extended Life Cycle automatisch ein Compliance-Verstoß?

Nicht automatisch - aber begründungspflichtig. Auditoren fragen nach Patch-Status, offenen CVEs und EOL-Plan. Wer keine strukturierten Antworten hat, riskiert Findings. 82 Prozent der Organisationen in Extended-Support-Phasen erhalten laut ESG-Studie mindestens ein Patch-Compliance-Finding.

Was passiert, wenn ein Penetrationstest JBoss EAP 7 findet?

Ein Penetrationstester wird den Patch-Stand prüfen, bekannte CVEs gegen die installierte Version testen und offene Angriffsflächen dokumentieren. Ungepatchte kritische und wichtige CVEs werden als Findings klassifiziert - unabhängig davon, ob ein Angriff stattgefunden hat.

Wie schnell können Angreifer neue CVEs ausnutzen?

Für bekannte, gut dokumentierte CVEs in weitverbreiteter Middleware entstehen innerhalb von 24 bis 72 Stunden nach Publication öffentliche Exploits. Organisationen ohne schnellen Patch-Prozess haben strukturell weniger Reaktionszeit.

Reicht es, keine externen Ports offenzuhaben?

Nein. Viele Angriffe gegen Middleware kommen über kompromittierte interne Systeme oder über Applikationen, die JBoss exponieren. Netzwerksegmentierung reduziert die Angriffsfläche, eliminiert sie aber nicht.

Wie dokumentiere ich den aktuellen EAP-7-Status für einen Auditor?

Minimal: aktuelle Versionsnummer, Datum des letzten Patches, Liste bekannter offener CVEs mit Severity, Mitigationsmaßnahmen pro CVE, schriftlicher Migrationsplan mit Zeitlinie. Das ist keine Freikarte, aber eine vertretbare Position.


Wie eine konkrete Migration oder Härtung bei begrenzten Teamkapazitäten aussehen kann, zeigt die SPAS Overview von Lennlay.