PHP2Shell: Was der Vorfall für Compliance bedeutet

Den Auftakt macht ein Impulsvortrag zu PHP2Shell. Unter diesem Namen wurden im Oktober 2026 zwei kritische Schwachstellen im PHP-Kern bekannt (CVE-2026-109618 und CVE-2026-109619), über die Angreifer ohne Anmeldung Code auf betroffenen Servern ausführen können. Der Vortrag ordnet ein, was passiert ist und ob es ein Einzelfall war. Für Lizenz- und Asset-Manager steht vor allem eine Frage im Raum: Was bedeutet das für Compliance und Security?

KI-Kosten: Token, Verbrauch und Vertragsklauseln

Drei Blöcke widmen sich der künstlichen Intelligenz. Ein Mitglied stellt vor, wie sich Token-Verbrauch und Consumption-Kosten in den Griff bekommen lassen, was KI-Lösungen dabei leisten und welche Werkzeuge der Markt bisher bietet. Anschließend wird diskutiert. Ein zweiter Impuls zeigt einen Baustein der Renewal-Vorbereitung: wie KI unterstützt, wenn in Vendor Calls kein Notetaker mitlaufen darf.

Nach der Kaffeepause folgt eine offene Diskussion über KI-Klauseln in Softwareverträgen. Es geht darum, wie solche Klauseln methodisch geprüft werden und welche Formulierungen genauer hinsehen lassen sollten. Die rechtliche Bewertung im Einzelfall bleibt Sache der jeweiligen Fach- und Rechtsabteilung.

Lageberichte zu Atlassian und IBM

Ein kurzer Block gibt zunächst einen Ausblick auf die Lighthouse Alliance Academy, mit der die Community 2027 erweitert werden soll. Danach stehen zwei Hersteller im Mittelpunkt. Der Atlassian-Lagebericht greift das angekündigte Ende der Data-Center-Produkte auf. Nach Herstellerangaben erreichen unter anderem Jira Software, Jira Service Management und Confluence Data Center am 28. März 2029 ihr End of Life und sind dann nur noch lesend nutzbar. Hinzu kommt die neue Vertragsfassung mit Preissteigerungen und mehr verbrauchsabhängigen Bestandteilen. Der Vortrag stellt Prüfschritte vor, die jedes Haus auf die eigene Vertrags- und Systemlage anwendet.

Zu IBM diskutieren die Teilnehmenden Alternativen zum IBM License Metric Tool (ILMT) für die Sub-Capacity-Messung und tauschen Erfahrungen zum Ablauf der Zusammenarbeit mit einem Authorized SAM Provider (ASP) aus.

Walk & Talk: Quick-Wins für IT-Kosten

Der Nachmittag findet im Gehen statt. Bei einer Werksführung beim gastgebenden Mitglied sammeln die Teilnehmenden zehn Quick-Wins, mit denen sich IT-Kosten kurzfristig senken lassen. Im Fokus stehen Methoden und Stellschrauben, die jedes Unternehmen eigenständig auf seine Lage überträgt.

„Die Themen kommen aus dem Kreis der Mitglieder. Ob PHP2Shell, KI-Verbrauch oder das Data-Center-Ende bei Atlassian: Fast jedes Haus sitzt gerade an ähnlichen Fragen. Im Gespräch mit Kollegen aus anderen Branchen findet man die passenden Prüfschritte schneller als allein am Schreibtisch“, sagt Markus Oberg, Chairman der Lighthouse Alliance.

Mitdiskutieren

Zum Abschluss gibt es einen Ausblick auf das nächste Treffen und weitere Online-Veranstaltungen. Software-Lizenzmanager, IT-Einkäufer und Vendor-Manager, die diese Themen ebenfalls im Kollegenkreis diskutieren möchten, finden Informationen zur Mitgliedschaft auf der Website der Lighthouse Alliance. Für ein persönliches Gespräch steht Markus Oberg direkt zur Verfügung.

Weitere Informationen: lighthouse-alliance.com/mitglied-werden

Über die Lighthouse Alliance

Die Lighthouse Alliance ist eine geschlossene, branchenübergreifende und herstellerunabhängige Community für Software-Lizenz- und Cloudmanagement sowie Software-Einkauf im DACH-Raum. Ihr gehören über 60 erfahrene IT-Manager an, unter anderem aus DAX- und SMI-Konzernen, Versicherungen, Landes- und Unternehmensrechenzentren, dem gehobenen Mittelstand und von öffentlichen Auftraggebern. In Mitgliedertreffen, Online-Meetings, Arbeitskreisen und einer zweitägigen Jahreskonferenz tauschen die Mitglieder Erfahrungen zu Methoden, Strukturen und Prozessen aus. Jedes Unternehmen trifft seine Entscheidungen eigenständig. Chairman ist Markus Oberg.

www.lighthouse-alliance.com

Die Preis- und Modellwechsel der vergangenen zwei Jahre haben in vielen Organisationen dieselbe Frage ausgelöst: Gibt es zu diesem Hersteller überhaupt eine tragfähige Alternative. Im Mitgliederkreis der Lighthouse Alliance wird sie derzeit in drei Feldern beantwortet, jeweils mit demselben Vorgehen und ohne Anbieterbeteiligung.

Virtualisierung: der Markt bewegt sich langsamer als die Debatte

Nach Schätzungen aus dem Kreis liegt VMware bei der Virtualisierung im eigenen Rechenzentrum weiterhin bei einer Größenordnung von rund 70 % Marktanteil, gefolgt von Hyper-V mit rund 17 %, Nutanix mit rund 6 % und Proxmox mit rund 3 %. Als reifster direkter Ersatz im Konzernumfeld gilt Nutanix. Proxmox wird vor allem im Mittelstand und bei Anforderungen an europäische Anbieter geprüft, Hyper-V und Azure Local in Häusern mit starker Microsoft-Bindung, OpenShift, OpenStack und SUSE-Produkte bei Cloud-nativer Ausrichtung. Eine allgemeingültige Rangfolge gibt es nicht, die Eignung hängt an Größe, Betriebsmodell und vorhandenem Know-how.

Bewertung in acht Dimensionen statt Bauchgefühl

Der Kreis arbeitet mit einem festen Ablauf: Bewertung entlang von acht Dimensionen, Aussortieren der Ausschlusskriterien, Auswahlliste, Machbarkeitsnachweis, Gesamtkostenrechnung, Entscheidung. Wichtig ist die Reihenfolge. Wer mit der Kostenrechnung beginnt, rechnet häufig Optionen durch, die an einem technischen oder organisatorischen Ausschlusskriterium ohnehin scheitern.

Dokumentenwerkzeuge und Java-Laufzeitumgebungen

Für Acrobat liegt mit Nitro ein vollwertiger Ersatz vor. In einem Pilotprojekt mit 150 Nutzern meldeten 54 % eine Zeitersparnis, 74 % bewerteten die Alternative als gleichwertig oder besser, die Lizenzkosten lagen rund 43 % niedriger. Diese Werte stammen aus einem konkreten Piloten und sind kein übertragbares Ergebnis; der Aufwand für einen solchen Test liegt erfahrungsgemäß bei drei bis fünf Wochen. Bei Java-Anwendungsservern schafft ein Termin Druck: Für Oracle Fusion Middleware 12c einschließlich WebLogic Server endet der Premier Support im Dezember 2026, der Extended Support im Dezember 2027. Für die Zeit danach hat Oracle ein jährlich verlängerbares Programm mit eingeschränktem Leistungsumfang angekündigt. Im Kreis werden alternative Anwendungsserver geprüft, die dem Jakarta-EE-Standard folgen und einen mehrjährigen, vertraglich zugesicherten Lebenszyklus bieten. Bei der Bewertung kommt es auf die Herkunft der Alternative an: Ein häufig zitierter Referenzfall ohne Codeänderungen betraf den Wechsel von GlassFish auf einen daraus hervorgegangenen Server. Eine Ablösung von WebLogic ist deutlich aufwendiger und lässt sich damit nicht gleichsetzen.

Neutral bewerten heißt: ohne Provision

Der Unterschied zur Anbieterberatung liegt in der Beteiligung. In der Lighthouse Alliance sitzen keine Hersteller und kein Vertrieb am Tisch, die Bewertungen stammen von Organisationen, die den jeweiligen Wechsel selbst durchlaufen oder abgebrochen haben. Auch abgebrochene Projekte werden dokumentiert, weil sie die Ausschlusskriterien am zuverlässigsten offenlegen. Informationen zur Arbeitsweise stehen unter lighthouse-alliance.com.

„Lock-in ist kein Naturgesetz, sondern eine Rechnung, die niemand aufgemacht hat“, sagt Markus Oberg, Chairman der Lighthouse Alliance. „Man muss den Wechsel nicht vollziehen, um von ihm zu profitieren. Aber man muss ihn durchgerechnet haben, sonst führt man die nächste Verhandlung ohne Alternative im Rücken.“

Die Lighthouse Alliance lädt Lizenzmanager, IT-Einkäufer und Vendor-Manager ein, ihre Bewertungen und Migrationserfahrungen im geschützten Kreis einzubringen und mitzudiskutieren.

Über die Lighthouse Alliance

Die Lighthouse Alliance ist eine geschlossene, herstellerunabhängige Community von Software-Lizenzmanagern, IT-Einkäufern und Vendor-Managern aus über 50 Organisationen im DACH-Raum. Mitglieder tauschen sich vertraulich und anonymisiert zu Lizenzkosten, Vendor-Strategien, Cloud und Audits aus, praxisnah, auf Augenhöhe, ohne Anbieter im Kreis. Kontakt: Markus Oberg, Chairman, lighthouse-alliance.com.

In drei Wochen schließt Oracle das zweite Quartal seines Geschäftsjahres. Der größte Hebel des Jahres liegt zwar am Geschäftsjahresende im Mai, doch auch das Quartalsende erzeugt Abschlussdruck, vor allem bei Verträgen, die ohnehin in diesem Zeitraum auslaufen. ProLicense begleitet solche Gespräche ausschließlich auf Kundenseite und kennt die internen Abläufe aus der Zeit der Gründer bei Oracle.

Wie der Vertrieb auf den Stichtag zuarbeitet

Vertriebsmitarbeiter und Teams werden an Quartalszielen gemessen. Ein Abschluss, der am 1. Dezember unterschrieben wird, zählt für das laufende Quartal nicht mehr. Deshalb steigt die Bereitschaft, über Preis und Bedingungen zu sprechen, in den letzten Wochen deutlich.

Wichtig ist dabei der interne Ablauf: Rabatte oberhalb bestimmter Schwellen müssen freigegeben werden, und diese Freigabe braucht Vorlauf. Wer erst in der letzten Woche eine weitreichende Forderung stellt, bekommt sie oft nicht mehr durch den Prozess, selbst wenn der Vertrieb sie unterstützt. Für größere Zugeständnisse ist der Zeitpunkt jetzt, nicht Ende November.

„Zum Quartalsende zählt für den Vertrieb, was unterschrieben und eingereicht ist. Genau deshalb entstehen dann Spielräume, die sechs Wochen vorher niemand eingeräumt hätte. Wer diesen Moment nutzen will, muss allerdings selbst entscheidungsfähig sein, sonst verhandelt er gegen die eigene Freigabekette“, sagt Christian Grave, Geschäftsführer der ProLicense.

Welche Zugeständnisse realistisch sind

Am häufigsten bewegt sich der Rabatt auf neue Lizenzen. Er wirkt doppelt, weil Oracle den jährlichen Support mit 22 % auf den Netto-Lizenzpreis berechnet. Verhandelbar sind außerdem Zahlungsziele, die Laufzeit und Vertragsklauseln: Preisschutz für spätere Nachkäufe, Regelungen zur Teilkündigung von Supportpositionen und Grenzen für künftige Supportsteigerungen.

Zurückhaltung ist bei Paketen angebracht, die einen hohen Rabatt an Cloud-Kontingente oder zusätzliche Produkte koppeln. Solche Bundles senken die Gesamtkosten selten, sie verlagern Ausgaben und verlängern die Bindung.

Womit Kunden rechnen müssen

Zum Stichtag verdichten sich auch die Methoden. Dazu gehören Angebote mit sehr kurzer Gültigkeit, der Hinweis auf offene Lizenzfragen bis hin zur Andeutung eines Audits, die späte Änderung des Leistungsumfangs kurz vor Unterschrift und Zusagen, die im Gespräch fallen, aber nicht im Vertrag stehen.

Das Gegenmittel ist schlicht: Jede Zusage gehört in das Ordering Document oder einen Vertragszusatz. Was dort nicht steht, existiert nach dem Abschluss nicht mehr.

„Mündliche Zusagen aus der Verhandlung sind wertlos, sobald der Ansprechpartner wechselt. Maßgeblich ist der Vertragstext, und der wird in der letzten Woche vor dem Stichtag besonders schnell verschickt“, sagt Rechtsanwalt Sören Reimers, Geschäftsführer der ProLicense.

Was in drei Wochen noch möglich ist

Realistisch sind in dieser Zeit vier Schritte: den eigenen Bedarf und die Compliance-Position klären, eine Alternative benennen können, die internen Entscheidungswege für eine kurzfristige Unterschrift freiräumen und die Forderungen schriftlich und vollständig übergeben. Wer erst am 27. November merkt, dass die Geschäftsführung in Urlaub ist, verhandelt im Januar zu schlechteren Bedingungen.

ProLicense begleitet Oracle Lizenzverhandlungen auf Kundenseite und unterstützt bei der Auditabwehr, falls das Gespräch diese Wendung nimmt. Ziel bleibt minimale Kosten bei voller Compliance. Anfragen nimmt ProLicense über die Kontaktseite entgegen.

Der Wechsel von Oracle JDK auf eine freie OpenJDK-Distribution ist technisch in den meisten Fällen unkritisch. Beide beruhen auf derselben Codebasis, das OpenJDK-Projekt steht unter der GPL mit Classpath Exception und ist für den Produktivbetrieb kostenfrei nutzbar. Die eigentliche Frage betrifft den Support: Wer liefert Sicherheitsupdates, in welcher Frist, und wie lange für eine bestimmte Version?

Distribution ist nicht gleich Distribution

Aus dem OpenJDK-Quellcode entstehen mehrere gepflegte Builds, unter anderem von Eclipse Adoptium, Amazon, Microsoft, Red Hat, BellSoft, IBM und Azul. Funktional entsprechen sie bei den LTS-Versionen dem Oracle JDK. Unterschiede gibt es bei den Zusagen: wie schnell nach einem Sicherheitsupdate ein Build bereitsteht, wie lange eine Version überhaupt weiter gepflegt wird und für welche Betriebssysteme und Architekturen es fertige Pakete und Container-Images gibt.

Ein erster Prüfpunkt ist die Zertifizierung. Ein Build sollte das Technology Compatibility Kit für die jeweilige Java-SE-Version bestanden haben. Damit ist belegt, dass er dem Standard entspricht und Anwendungen sich wie erwartet verhalten. Der zweite Prüfpunkt sind die Update-Zeiträume, die sich je Distribution und Version deutlich unterscheiden, gerade bei älteren Versionen wie Java 8 und 11.

Was ein Supportvertrag zusätzlich leistet

Frei verfügbare Builds decken den Normalfall ab. Ein kommerzieller Supportvertrag ergänzt Reaktionszeiten, benannte Ansprechpartner, Unterstützung bei Fehlern in der Laufzeitumgebung und häufig Sicherheits-Backports für Versionen, die andere nicht mehr pflegen. Für regulierte Bereiche ist zudem die Nachweisbarkeit relevant: Gegenüber Prüfern lässt sich belegen, wer die Laufzeitumgebung pflegt und in welcher Frist Schwachstellen behoben werden.

Ein Unterschied betrifft das Preismodell. Kommerzieller OpenJDK-Support wird üblicherweise nach Servern, Prozessoren oder Instanzen abgerechnet, also nach dem tatsächlichen Einsatz. Die Oracle Java SE Universal Subscription rechnet dagegen nach der Gesamtzahl der Mitarbeiter. Genau daraus ergibt sich in vielen Umgebungen der Kostenunterschied.

„Die Frage ist nie, ob OpenJDK funktioniert, sondern wer im Ernstfall haftet und liefert. Für ein Testsystem reicht ein freier Build. Für eine Anwendung, an der das Kerngeschäft hängt, will jeder Betriebsleiter einen Vertrag mit Fristen“, sagt Markus Oberg, Partner und Business Development Manager der ProLicense.

Die Umstellung sauber abschließen

Der Wechsel wirkt nur, wenn er vollständig ist. Deshalb gehört an den Anfang eine Inventur aller Java-Installationen, einschließlich der Laufzeitumgebungen, die in Drittsoftware mitgeliefert werden. Für jede betroffene Anwendung ist zu prüfen, ob der Hersteller den Betrieb auf der gewählten Distribution unterstützt. Danach folgen Tests in Entwicklungs- und Abnahmeumgebungen, bevor die Produktion umgestellt wird.

Am Ende steht die Dokumentation: welche Oracle-JDK-Installationen wann entfernt wurden und welche Distribution seitdem im Einsatz ist. Diese Unterlagen sind die Grundlage, falls Oracle später Fragen zur Java-Nutzung stellt.

„Nach einem Umstieg kommen die Fragen von Oracle oft erst mit Verzögerung, gestützt auf Download-Daten aus der Vergangenheit. Wer dann für jeden Server zeigen kann, was wann entfernt und was installiert wurde, beendet das Gespräch schnell. Ohne Dokumentation wird daraus eine Verhandlung“, sagt Christian Grave, Geschäftsführer der ProLicense.

ProLicense berät bei Auswahl, Kostenvergleich und Umstellung herstellerunabhängig auf Kundenseite und ist zugleich Partner von Azul, einem der Anbieter kommerzieller OpenJDK-Distributionen. Bei Rückfragen von Oracle unterstützt ProLicense in der Auditabwehr. Ziel bleibt minimale Kosten bei voller Compliance. Anfragen nimmt ProLicense über die Kontaktseite entgegen.

Ein Oracle ULA gibt Unternehmen für eine feste Laufzeit das Recht, bestimmte Produkte unbegrenzt zu installieren. Am Ende der Laufzeit stehen zwei Wege: zertifizieren oder verlängern. Die Zertifizierung wandelt die zum Stichtag gemeldeten Installationen in eine dauerhafte Lizenzmenge um, die sich später nicht mehr erhöhen lässt. Die Verlängerung kostet erneut eine Einmalgebühr und verschiebt die Entscheidung. Beide Wege legen die Oracle-Kosten für Jahre fest.

Die Entscheidung hängt an drei Fragen

Die erste Frage lautet, ob der Bestand weiter wächst. Wer in den kommenden Jahren zusätzliche Datenbanken oder Optionen benötigt, fährt mit einer Verlängerung unter Umständen günstiger als mit Nachkäufen nach der Zertifizierung. Die zweite Frage betrifft die Produkte selbst: Sind die im ULA genannten Produkte noch Teil der Zielarchitektur, oder laufen ohnehin Migrationen? Die dritte Frage ist die schwierigste: Lässt sich die Zählung der Installationen belastbar belegen?

Was bei der Zertifizierung zählt

Gezählt wird, was zum Stichtag tatsächlich installiert und im Einsatz ist, und nur für die Produkte, die im Vertrag stehen. Nach dem Stichtag zählt keine weitere Installation mehr. Wer also im letzten Jahr der Laufzeit ohnehin geplante Projekte umsetzt, sichert sich dauerhafte Lizenzen, ohne dafür zusätzlich zu zahlen. Rein formale Installationen ohne betriebliche Nutzung gehören ausdrücklich nicht dazu, sie halten einer Prüfung nicht stand und beschädigen die eigene Position.

Zwei Punkte führen regelmäßig zu Streit. Der erste ist die Virtualisierung: In VMware-Umgebungen zählt Oracle nicht die einzelne virtuelle Maschine, sondern die zugrunde liegenden Hosts. Der zweite betrifft die Cloud. Ob Installationen bei einem Public-Cloud-Anbieter in die Zertifizierung einfließen, hängt vom Wortlaut des ULA ab. Fehlt eine Regelung, ist das Ergebnis Verhandlungssache.

„Die Zertifizierung ist kein Formular, sondern eine Verhandlung. Oracle prüft jede Zahl, die den eigenen Umsatz schmälert, und akzeptiert jede, die für eine Verlängerung spricht. Wer ohne eigene, geprüfte Erhebung in dieses Gespräch geht, zertifiziert fast immer zu wenig“, sagt Christian Grave, Geschäftsführer der ProLicense.

Was nach dem Stichtag gilt

Mit der Zertifizierung endet das unbegrenzte Nutzungsrecht. Ab diesem Moment gilt die gemeldete Menge, jeder weitere Bedarf wird zugekauft. Der Supportbetrag bleibt dagegen in der Regel unverändert, auch wenn am Ende weniger Lizenzen zertifiziert werden als erwartet. Auch deshalb lohnt der genaue Blick auf die Vertragsbedingungen, bevor die Erklärung unterschrieben wird.

„Maßgeblich ist der ULA-Text, nicht die Auskunft aus dem Vertrieb. Definitionen zu Konzerngesellschaften, Territorium und erfassten Produkten entscheiden darüber, was am Ende zertifiziert werden darf. Diese Klauseln gehören vor die Zertifizierung auf den Tisch, nicht danach“, sagt Rechtsanwalt Sören Reimers, Geschäftsführer der ProLicense.

Der Zeitplan entscheidet über den Spielraum

Oracle spricht Kunden häufig schon zwölf bis achtzehn Monate vor Ablauf auf eine Verlängerung an, mit einem klaren Informationsvorsprung. ProLicense empfiehlt deshalb, spätestens ein Jahr vor dem Stichtag mit der eigenen Erhebung zu beginnen: Installationen erfassen, geplante Projekte vorziehen, Vertragsklauseln prüfen und die Entscheidung rechnen.

Wer zusätzlich Verhandlungsspielraum sucht, achtet auf Oracles Geschäftsjahr, das am 31. Mai endet. Fällt das Gespräch über Verlängerung oder Nachkauf in die Wochen davor, steigt die Abschlussbereitschaft auf Herstellerseite spürbar.

ProLicense begleitet ULA-Zertifizierungen auf Kundenseite, erstellt die notwendige Lizenzbilanz und prüft die Verträge. Ziel bleibt minimale Kosten bei voller Compliance. Anfragen nimmt ProLicense über die Kontaktseite entgegen.

In vielen Konzernen liegen die Angaben zu Software-Assets, Verträgen, Nutzung und Kosten in getrennten Systemen. Solange diese Bestände nicht zusammengeführt sind, bleiben Doppelungen, ungenutzte Berechtigungen und ungünstige Metriken unentdeckt. Ein Projekt aus dem Mitgliederkreis der Lighthouse Alliance zeigt, welche Größenordnung darin stecken kann.

Der Fall in Zahlen

Ausgangspunkt waren vier getrennte Datenquellen mit über 5.000 Assets und über 1.500 Verträgen. Diese Bestände wurden mit Hilfe von KI abgeglichen, bereinigt und zu einer gemeinsamen Gesamtsicht zusammengeführt. Auf dieser Grundlage ließ sich ein jährliches Einsparpotenzial von mehr als 19 Millionen Euro identifizieren. Der Wert bezieht sich auf identifiziertes Potenzial in einem konkreten Fall, nicht auf ein bereits realisiertes oder übertragbares Ergebnis. Wie viel davon gehoben wird, entscheidet sich in den anschließenden Verhandlungen und Umstellungen.

Fünf Hebel, kein einzelner Effekt

Das Potenzial verteilt sich auf mehrere Ansatzpunkte: die Anpassung ungünstiger Lizenzmetriken, die Bündelung und Konsolidierung verstreuter Verträge, die Ablösung redundanter Software, den Ersatz einzelner Produkte durch Alternativen sowie die Reduktion von Mengen mit anschließender Neuverhandlung. Keiner dieser Punkte erfordert neue Technik. Sie erfordern eine Datenlage, die belegt, was tatsächlich im Einsatz ist.

Rechnen ohne Datenabfluss

Die Auswertung erfolgte nach dem Zero-Leak-Prinzip innerhalb der Umgebung des Unternehmens. Die Daten wurden anonymisiert verarbeitet und die Ergebnisse einer manuellen Qualitätssicherung unterzogen. Für Organisationen mit hohen Anforderungen an Vertraulichkeit ist dieser Punkt in der Regel die Voraussetzung dafür, dass ein solches Projekt überhaupt startet.

Die Hürde war nicht die Technik

Der aufwendigste Teil des Projekts lag außerhalb der Auswertung. Fachbereiche mussten Einwände gegen die Ergebnisse einbringen können, die Datenqualität wurde erst im Widerspruch belastbar, und die Einbindung des Betriebsrats gehörte von Beginn an dazu. Nach Einschätzung der Beteiligten braucht ein solches Vorhaben eine eigene Kommunikationslinie, die erklärt, wozu die Auswertung dient und wozu nicht.

Vom Einzelfall zur Blaupause

In der Lighthouse Alliance wird der Fall derzeit diskutiert und auf andere Ausgangslagen übertragen: Welche Datenquellen sind Pflicht, welche Bereinigungsschritte lohnen sich zuerst, wo entstehen Scheineinsparungen. Aus dem Setup eines Mitglieds wird auf diesem Weg eine Vorgehensbeschreibung, die der gesamte Kreis nutzen kann. Informationen zur Arbeitsweise stehen unter lighthouse-alliance.com.

„Künstliche Intelligenz spart kein Geld. Saubere Daten tun es“, sagt Markus Oberg, Chairman der Lighthouse Alliance. „Das Modell hat in diesem Fall nichts entdeckt, was ein Team nicht auch hätte finden können. Es hat nur vier Bestände in Wochen zusammengeführt statt in Quartalen, und genau darin liegt der Unterschied zwischen einer Idee und einer Verhandlungsgrundlage.“

Die Lighthouse Alliance lädt Lizenzmanager, IT-Einkäufer und Vendor-Manager ein, eigene Erfahrungen mit datengetriebenen Auswertungen im geschützten Kreis einzubringen und mitzudiskutieren.

Über die Lighthouse Alliance

Die Lighthouse Alliance ist eine geschlossene, herstellerunabhängige Community von Software-Lizenzmanagern, IT-Einkäufern und Vendor-Managern aus über 50 Organisationen im DACH-Raum. Mitglieder tauschen sich vertraulich und anonymisiert zu Lizenzkosten, Vendor-Strategien, Cloud und Audits aus, praxisnah, auf Augenhöhe, ohne Anbieter im Kreis. Kontakt: Markus Oberg, Chairman, lighthouse-alliance.com.

Seit dem 11. September 2026 müssen Hersteller vernetzter Produkte aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden. Ab dem 11. Dezember 2027 gilt der Cyber Resilience Act (Verordnung (EU) 2024/2847) vollständig. Bis dahin bleiben gut dreizehn Monate. Für Unternehmen mit abgekündigten Open-Source-Komponenten in ihren Produkten ist das knapp, weil die Lösung selten in wenigen Wochen zu haben ist.

Wer als Hersteller gilt

Der CRA richtet sich an alle, die Produkte mit digitalen Elementen in der EU in Verkehr bringen. Das betrifft nicht nur Geräte, sondern jede Art von Software, die kommerziell bereitgestellt wird. Unternehmen, die Software ausschließlich intern nutzen, fallen nicht darunter, für sie greifen andere Regeln wie NIS2. Wer Software außerhalb einer gewerblichen Tätigkeit frei verfügbar macht, ist ebenfalls nicht erfasst, und für Verwalter größerer Open-Source-Ökosysteme gelten reduzierte Pflichten.

Was ab Dezember 2027 verlangt wird

Zu den grundlegenden Anforderungen gehören sichere Voreinstellungen, ein sicherer Update-Mechanismus, eine dokumentierte Risikobewertung und eine maschinenlesbare Software-Stückliste, die mindestens die direkten Abhängigkeiten abdeckt. Hinzu kommen die technische Dokumentation, die Einordnung des Produkts in die jeweilige Klasse und das passende Konformitätsbewertungsverfahren. Für die Standardkategorie genügt regelmäßig eine interne Bewertung, externe Prüfungen betreffen bestimmte wichtige und kritische Produktklassen.

Der zentrale Punkt für Altkomponenten steckt im Supportzeitraum. Hersteller müssen ihn festlegen und offen kommunizieren, und er beträgt grundsätzlich mindestens fünf Jahre, sofern die erwartete Nutzungsdauer nicht kürzer ist. In dieser Zeit sind Schwachstellen zu behandeln.

Warum abgekündigte Komponenten die Zusage gefährden

Eine Zusage über fünf Jahre lässt sich nur halten, wenn für jede enthaltene Komponente Sicherheitsupdates verfügbar sind. Steckt ein Framework im Produkt, das der Maintainer nicht mehr pflegt, fehlt genau diese Grundlage. Die Software-Stückliste macht das zudem sichtbar, und Kunden im B2B-Geschäft fragen sie zunehmend ab.

Für Bestandsprodukte gilt keine vollständige rückwirkende Bewertung, solange sie vor dem Stichtag in Verkehr gebracht und danach nicht wesentlich verändert werden. Ob eine Änderung wesentlich ist, hängt davon ab, ob sie die Cybersicherheit oder den Verwendungszweck betrifft. Bei Produkten mit regelmäßigen Releases ist diese Grenze schnell erreicht.

„Der Supportzeitraum ist eine Zusage an den Markt, keine Absichtserklärung. Wer fünf Jahre Sicherheitsupdates verspricht und im Produkt eine abgekündigte Komponente trägt, hat ein Problem, sobald die erste Schwachstelle gemeldet wird“, sagt Rechtsanwalt Sören Reimers, Geschäftsführer der ProLicense.

Was bis Dezember 2027 zu klären ist

Der erste Schritt ist die Bestandsaufnahme: Welche Produkte fallen unter den CRA, welche Komponenten stecken darin, und welche davon erhalten keine Updates mehr? Danach folgt die Entscheidung je Komponente. Sie kann ersetzt werden, sie kann im eigenen Haus gepflegt werden, oder der Support wird eingekauft. ProLicense vertreibt als Reseller Never-Ending Support (NES) von HeroDevs, der für abgekündigte Open-Source-Versionen weiterhin CVE-Behebungen mit vertraglich zugesagten Fristen liefert. Damit lässt sich ein Supportzeitraum unterlegen, ohne das Produkt neu zu bauen.

„Dreizehn Monate klingen nach viel Zeit. Wer aber erst die Stückliste erstellen, dann die Altkomponenten bewerten und anschließend Ersatz entwickeln muss, ist schnell darüber hinaus. Die Bestandsaufnahme gehört in dieses Jahr, nicht ins nächste“, sagt Markus Oberg, Partner und Business Development Manager der ProLicense.

ProLicense unterstützt bei der Bewertung abgekündigter Komponenten und beim Vergleich von Ersatz, Eigenpflege und Drittsupport, mit dem Ziel minimaler Kosten bei voller Compliance. Das Vorgehen entspricht dem Drittsupport bei Oracle-Software. Anfragen nimmt ProLicense über die Kontaktseite entgegen.

Schritt 1: Die Feature-Nutzung ehrlich erheben

Am Anfang steht die Frage, welche Bestandteile produktiv genutzt werden. Netzwerkvirtualisierung, softwaredefinierter Speicher, Automatisierung und Disaster-Recovery-Funktionen sind in den Paketen enthalten, laufen aber in vielen Umgebungen nicht oder nur in Testinstallationen. Installiert ist nicht gleich genutzt, und für die Verhandlung zählt nur, was tatsächlich in Betrieb ist.

Aus dieser Erhebung ergibt sich, welches Paket überhaupt passt und welche Zusatzkomponenten aus dem Angebot gestrichen werden können.

Schritt 2: Cores und Cluster vor dem Renewal aufräumen

Da pro Core abgerechnet wird, wirkt jede unnötige Kapazität dauerhaft auf den Preis. Vor dem Angebot lohnt deshalb der Blick auf verwaiste virtuelle Maschinen, überdimensionierte Cluster, getrennt lizenzierbare Test- und Entwicklungsumgebungen und auf die Frage, ob eine Konsolidierung auf weniger Hosts machbar ist.

Wichtig ist außerdem die Core-Dichte der Hardware. Ein Serverwechsel auf Prozessoren mit mehr Kernen erhöht die Lizenzmenge, auch wenn die Arbeitslast gleich bleibt. Wer einen Hardware-Refresh plant, rechnet die Lizenzfolgen vorher durch.

„Das Angebot des Herstellers beschreibt die heutige Umgebung, nicht den tatsächlichen Bedarf. Wir sehen regelmäßig Kunden, die zehn bis zwanzig Prozent ihrer Kapazität gar nicht brauchen. Diese Aufräumarbeit gehört vor die Verhandlung, nicht danach“, sagt Markus Oberg, Partner und Business Development Manager der ProLicense.

Schritt 3: Alternativen als Druckmittel aufbauen

Ein Angebot lässt sich nur verändern, wenn es eine Alternative gibt. In Frage kommen der Wechsel auf eine andere Virtualisierungsplattform, die Verlagerung einzelner Workloads oder, bei vorhandenen unbefristeten Lizenzen, der Betrieb ohne Herstellersupport mit einem Drittanbieter. Glaubwürdig wird das nur mit einer echten Analyse: Welche Workloads ließen sich in welchem Zeitraum verlagern, zu welchen Kosten und mit welchem Risiko?

ProLicense hat die Risiken einer Migration auf Nutanix in einer eigenen Meldung dargestellt. Für die Verhandlung gilt: Eine geprüfte Alternative wirkt, eine angedrohte nicht.

In der Verhandlung: Laufzeit und Klauseln

Neben Preis und Menge gehören die Vertragsbedingungen auf den Tisch. Dazu zählen die Laufzeit, die Preisentwicklung bei der nächsten Verlängerung, die Möglichkeit, Mengen bei sinkendem Bedarf zu reduzieren, und die Konditionen für Wachstum während der Laufzeit. Eine mehrjährige Bindung kann sinnvoll sein, aber nur mit einer Regelung für den Fall, dass die Umgebung schrumpft.

„Wer bei der Verlängerung nur über Rabatt spricht, verschenkt den größeren Hebel. Der liegt in der Menge und in den Klauseln für die nächsten Jahre“, sagt Christian Grave, Geschäftsführer der ProLicense.

Anfragen nimmt ProLicense über die Kontaktseite entgegen.

Was die ersten DORA-Prüfungen gezeigt haben

Nach Berichten aus der Prüfungspraxis konzentrieren sich die bisherigen Feststellungen auf drei Felder. Im IKT-Risikomanagementrahmen wurden kritische und wichtige Funktionen nicht immer vollständig identifiziert, sodass die Sicherheitsmaßnahmen nicht risikoorientiert abgeleitet waren. Im Bereich Erkennung waren Systeme, die kritische Funktionen stützen, nicht durchgängig an die Sicherheitsüberwachung angebunden. Im Geschäftsfortführungsmanagement fehlten teilweise Business-Impact-Analysen.

Abgekündigte Software taucht in diesen Feldern nicht als eigener Prüfungspunkt auf. Sie wird dort sichtbar, wo Prüfer nach Vollständigkeit und Nachvollziehbarkeit fragen.

Wo EOL-Komponenten in der Prüfung auffallen

Der erste Punkt ist das Asset-Inventar. Wer kritische und wichtige Funktionen sauber auf Anwendungen und deren Komponenten herunterbricht, macht damit auch sichtbar, welche Frameworks und Bibliotheken keine Sicherheitsupdates mehr erhalten. Fehlt diese Tiefe, ist bereits das Inventar unvollständig.

Der zweite Punkt ist das Schwachstellenmanagement. Für jede erkannte Schwachstelle muss ein Behandlungspfad dokumentiert sein. Bei End-of-Life-Komponenten endet dieser Pfad ohne Patch, übrig bleiben Ausnahmen und kompensierende Maßnahmen. Werden diese Ausnahmen über Jahre verlängert, ist die Frage nach dem Zielbild absehbar.

Der dritte Punkt betrifft Dienstleister. Wer Sicherheits-Support für alte Komponenten einkauft, führt einen IKT-Drittdienstleister ein, der ins Informationsregister gehört und dessen Vertrag den Anforderungen genügen muss. Auch das prüft die Aufsicht.

„In Prüfungen scheitert es selten am Verständnis für das Risiko, sondern an der Nachweisbarkeit. Wer nicht zeigen kann, welche Komponenten in kritischen Anwendungen stecken und wer sie patcht, hat eine Feststellung, unabhängig davon, wie gut das System technisch abgesichert ist“, sagt Rechtsanwalt Sören Reimers, Geschäftsführer der ProLicense.

Reaktionswege nach einer Feststellung

Feststellungen werden mit Fristen und einem Maßnahmenplan abgearbeitet, die Umsetzung wird nachgehalten. Für EOL-Komponenten heißt das in der Regel: kurzfristig einen Patch-Pfad herstellen, mittelfristig migrieren. Eine Migration innerhalb weniger Monate ist bei tief integrierten Frameworks selten realistisch.

Als kurzfristige Maßnahme kommt Drittsupport infrage. ProLicense vertreibt als Reseller Never-Ending Support (NES) von HeroDevs, der für abgekündigte Open-Source-Versionen weiterhin CVE-Behebungen mit vertraglich zugesagten Reaktionszeiten liefert. Damit lässt sich gegenüber der Aufsicht belegen, wer die Komponente pflegt und in welcher Frist. Die Migration bleibt im Plan, bekommt aber ein realistisches Datum.

„Ein Maßnahmenplan, der nur aus einem Migrationsprojekt besteht, überzeugt niemanden, wenn das Projekt achtzehn Monate dauert. Sinnvoll ist die Kombination: sofort einen Supportvertrag, der die Lücke schließt, und parallel die geplante Ablösung“, sagt Markus Oberg, Partner und Business Development Manager der ProLicense.

ProLicense unterstützt Institute bei der Bestandsaufnahme abgekündigter Komponenten, beim Vergleich der Optionen und bei der Vertragsgestaltung, mit dem Ziel minimaler Kosten bei voller Compliance. Das Vorgehen entspricht dem Drittsupport bei Oracle-Software. Anfragen nimmt ProLicense über die Kontaktseite entgegen.