Lightwell und SAP: Wenn Patchen allein nicht reicht

Open Source ist aus modernen Unternehmensanwendungen nicht wegzudenken. Das gilt auch für SAP-Landschaften, selbst wenn die eingesetzte Software nur einen Teil des gesamten Technologie-Stacks ausmacht. Denn rund um die Systeme existieren Integrationsplattformen, Eigenentwicklungen, Automatisierungslösungen, Schnittstellen, Monitoring-Tools und zahlreiche weitere Anwendungen, von denen viele auf Open-Source-Komponenten basieren oder solche als Abhängigkeiten einbinden. Damit entsteht eine Software-Lieferkette, die deutlich größer ist als das eigentliche SAP-Produkt.

Für die IT-Sicherheit ist das ein großes Problem, das klassische Vulnerability-Management-Prozesse nur teilweise lösen. Ein Scanner erkennt eine verwundbare Version und der Hersteller oder die Open-Source-Community stellt eine korrigierte Version bereit. Technisch wäre die Schwachstelle damit zwar behoben, operativ ist die Sache aber noch lange nicht erledigt. Denn die neue Version muss nicht zwangsläufig mit den bestehenden Systemen kompatibel sein.

Ein Upgrade kann APIs verändern, transitive Abhängigkeiten austauschen, Regressionen verursachen oder eine erneute Zertifizierung erforderlich machen. Bei einer geschäftskritischen Anwendung ist es deshalb nicht nur wichtig, ob ein Fix verfügbar ist, sondern auch, wie er in die bestehende Softwareversion integriert werden kann. Da viele Unternehmen dieses Risiko scheuen beziehungsweise nicht eingehen wollen, bleiben bekannte Schwachstellen folglich ungelöst, häufen sich als langfristige Sicherheitsausnahmen an oder erfordern kostspielige, proprietäre Patches und Forks.

Der Mythos-Moment erzwingt ein Umdenken

Diese Entwicklung verschärft sich mit künstlicher Intelligenz rasant. Im Rahmen des Glasswing-Projekts von Anthropic wurden mithilfe des Modells Mythos Preview Tausende Sicherheitslücken in Open-Source-Software aufgespürt – darunter fast 3900 Schwachstellen mit hohem oder kritischem Schweregrad. KI kann Code in einem Tempo analysieren, das mit herkömmlichen manuellen Verfahren nicht erreicht werden kann. Dadurch verändert sich auch die Dynamik bei Zero-Day-Schwachstellen: Je schneller potenzielle Angriffsflächen identifiziert werden, desto schneller schließt sich das Zeitfenster für ihre Absicherung. Für einzelne Unternehmen ist es nahezu unmöglich, jede gefundene Schwachstelle selbst zu bewerten und zu priorisieren. Das verschärft wiederum das Problem des Remediation Gap. Zwischen der Entdeckung einer Sicherheitslücke und ihrer tatsächlichen Behebung in einer produktiven Anwendung können Wochen oder sogar Monate vergehen. In dieser Zeit bleiben Unternehmen entweder mit einer bekannten Schwachstelle zurück, müssen eigene Patches pflegen oder stehen vor der Entscheidung, ein riskantes Upgrade durchzuführen.

Aber auch „alte“ Schwachstellen sind nach wie vor ein Problem. Ein besonders prägnantes Beispiel ist Log4Shell. Die Sicherheitslücke in der weitverbreiteten Java-Bibliothek Apache Log4j wurde Ende 2021 öffentlich bekannt und als kritisch eingestuft. Betroffen waren Anwendungen, die eine verwundbare und nicht aktualisierte Version der Bibliothek einsetzten. Unter bestimmten Voraussetzungen konnten Angreifer darüber Schadcode aus der Ferne ausführen und somit weitreichenden Zugriff auf die betroffenen Systeme erlangen. Zwar wird Log4Shell bei den wichtigen Systemen in der Regel gepatcht sein, trotzdem sorgen veraltete und damit vergessene Log4Shell-Abhängigkeiten in der Software-Lieferkette nach wie vor für enorme Anfälligkeiten.

Erschwerend kommt hinzu, dass ein bereitgestelltes Sicherheitsupgrade allein nicht ausreicht. Der Weg vom Patch in die Produktion ist oft beschwerlich: Die Anwendung muss neu gebaut, automatisierte und manuelle Tests müssen durchgeführt, Abhängigkeiten geprüft und Änderungen freigegeben werden. Bei kritischen Anwendungen kommen gegebenenfalls fachliche Abnahmen, Compliance-Anforderungen oder formale Change-Prozesse hinzu. Somit wird die Geschwindigkeit der nachgelagerten Prozesse zu einem wesentlichen Faktor. Ein Unternehmen kann noch so schnell auf ein neues Sicherheitsupgrade zugreifen – wenn der interne Build- und Deployment-Prozess mehrere Wochen oder sogar Monate benötigt, bleibt die Schwachstelle entsprechend lange bestehen oder wird erst gar nicht angegangen.

Lightwell: Sicherheitsfix statt erzwungenen Versionssprungs

Genau diese Lücke adressiert Lightwell, eine gemeinsame Initiative von Red Hat und IBM zur Absicherung der Open-Source-Software-Lieferkette. Das Konzept erweitert ein Prinzip, das Red Hat seit Jahrzehnten bei Enterprise-Software praktiziert: Sicherheitskorrekturen werden nicht zwangsläufig durch einen kompletten Versionssprung ausgeliefert, sondern können gezielt auf eine weiterhin unterstützte Version zurückportiert werden. Das Ziel ist, die sicherheitsrelevante Änderung einzubringen, ohne gleichzeitig einen unnötigen Funktions- oder API-Sprung zu erzwingen. Für Unternehmen ist das ein wichtiger Aspekt: Ein Backport adressiert die Sicherheitslücke, ohne automatisch die gesamte Abhängigkeitsstruktur der Anwendung zu verändern.

Der Unterschied zu einem manuellen Fork ist dabei enorm. Ein Unternehmen könnte zwar theoretisch den Quellcode einer betroffenen Bibliothek kopieren, den Patch einspielen und ein eigenes Artefakt bauen. Damit würde es aber auch dauerhaft die Verantwortung für diesen Fork übernehmen: Build-Prozess, Signierung, Abhängigkeiten, weitere Security-Fixes, Dokumentation und gegebenenfalls die spätere Rückführung in den Upstream. Ein weiterer Unterschied zum herkömmlichen Patch-Management liegt in der Frage, was nach dem Einspielen des Updates passiert. In einer modernen Software-Lieferkette genügt es nicht mehr, eine neue JAR-Datei bereitzustellen. Unternehmen müssen nachvollziehen können, was sie einsetzen, woher es kommt, wie es gebaut wurde und welche Sicherheitsinformationen damit verbunden sind.

Lightwell liefert deshalb nicht nur gepatchte und signierte Artefakte, sondern auch Supply-Chain-Metadaten. Dazu gehören unter anderem Software Bills of Materials (SBOM), SLSA-Level-3-Provenance sowie Signaturen über Sigstore beziehungsweise Cosign. Dies ist insbesondere für SAP-Kunden relevant, da die Open-Source-Abhängigkeit wie gesagt nicht an der Grenze des SAP-Systems endet. In einer Integrationslandschaft können Java-Bibliotheken, Messaging-Komponenten, APIs, Container, Build-Tools oder KI-Frameworks Teil des Gesamtsystems sein. Eine SBOM macht diese Komponenten maschinenlesbar sichtbar. VEX (Vulnerability Exploitability Exchange) geht sogar noch einen Schritt weiter.

Eine SBOM beantwortet im Wesentlichen die Frage, welche Komponente vorhanden ist. VEX kann ergänzende Informationen darüber liefern, ob und wie eine Software von einer bestimmten Schwachstelle tatsächlich betroffen ist. Für regulierte Unternehmen ist das von entscheidender Bedeutung. Anforderungen aus DORA, NIS2 oder dem Cyber Resilience Act erhöhen den Druck, Softwarekomponenten, Schwachstellen und deren Behandlung nachvollziehbar zu dokumentieren. Lightwell stellt diese Informationen zusammen mit den Artefakten bereit, sodass sie nicht nachträglich manuell aus verschiedenen Quellen zusammengetragen werden müssen.

Auch mit Blick auf künftige beziehungsweise freiwillige europäische Zertifizierungs- und Compliance-Anforderungen wie EUCS (European Cybersecurity Certification Scheme for Cloud Services) oder EUCC (European Common Criteria-based Cybersecurity Certification Scheme) sind solche nachweisbaren Supply-Chain- und Build-Artefakte relevant.

Zwei Versionen für unterschiedliche Bedürfnisse

Lightwell setzt zudem nicht erst beim fertigen Patch an. Das Modell kombiniert KI-gestützte Triage mit menschlicher Engineering-Expertise. Die KI hilft dabei, die massive Flut an CVEs zu bewältigen, indem sie Schwachstellen in Sekundenschnelle analysiert, ihre Relevanz bewertet und mögliche Korrekturen erstellt. Die resultierenden Änderungen werden anschließend automatisiert getestet und durch menschliche Experten – besser gesagt mehr als 20.000 Techniker von Red Hat und IBM – validiert, bevor sie als Artefakte bereitgestellt werden. Die entwickelten Patches werden aber nicht nur den Kunden zugänglich gemacht, sondern im Sinne der Open-Source-Gemeinschaft auch an die Ursprungsprojekte zurückgegeben, damit die gesamte Branche profitiert.

Der anfängliche Schwerpunkt des Lightwell-Ökosystems liegt auf Maven/Java. Das ist gerade für SAP-Kunden interessant, da Java-Anwendungen ihre Dependencies häufig über Maven-Repositories beziehen und in zahlreichen Integrations-, Middleware- und kundeneigenen Anwendungsszenarien eine Rolle spielen. Gleichzeitig ist Java nur der Anfang. Lightwell soll auf weitere Ökosysteme wie PyPI, npm und Go ausgeweitet werden, um den Anforderungen regulierter Branchen gerecht zu werden, in denen die Sanierung festgelegter beziehungsweise gepinnter Versionen besonders relevant ist. Verfügbar ist die Lösung derzeit in zwei unterschiedlichen Versionen.

Lightwell Network ermöglicht einen Self-Service-Zugriff auf den verfügbaren Katalog geeigneter, korrigierter Pakete. Das schließt digital signierte Binärdateien und Quellcode sowie Compliance-Artefakte ein. Lightwell Clearinghouse Premier wiederum richtet sich an stark regulierte Branchen, die eine intensive Betreuung benötigen. Unternehmen profitieren zusätzlich unter anderem von einer Schwachstellenmeldung für kundenspezifische Paketversionen, einer priorisierten Überprüfung neuartiger Schwachstellen sowie einem dedizierten Security-TAM (Technical Account Manager) und einer vertraglich zugesicherten (SLA-basierten) Behebung für bestimmte Anwendungsbereiche.

Was bedeutet das konkret für SAP-Kunden und -Partner?

Für SAP-Kunden ist es wichtig, zu wissen, dass Lightwell nicht dazu gedacht ist, die regulären Sicherheitsupdates zu ersetzen. Wird eine Schwachstelle in einem SAP-Produkt festgestellt, liegt die Verantwortung für deren Behebung grundsätzlich bei SAP. Die entsprechenden Korrekturen werden über die etablierten Prozesse wie SAP Security Notes bereitgestellt. Lightwell ersetzt zudem keine bestehenden Sicherheits- und Entwicklungsprozesse aufseiten der Unternehmen. Das schließt einerseits Tools für das Schwachstellen-Scanning ein, andererseits bleibt die Verantwortung für Integration, Applikationstests, Freigabe und Deployment beim Unternehmen. Lightwell verändert jedoch den technischen Ausgangspunkt dieser Tests. Die produktiv eingesetzte Dependency bleibt zunächst auf ihrer bestehenden Version, während der Security-Fix gezielt auf diese Version zurückportiert wird. Das Artefakt ist signiert, mit Supply-Chain-Informationen versehen und kann über den vorhandenen Repository- und Build-Prozess bezogen werden. Statt einen ganzen Versionssprung zu validieren, wird also eine gezielte Sicherheitskorrektur validiert.

Damit wird Lightwell auch für SAP-Partner interessant. Systemintegratoren, Beratungshäuser und Managed-Service-Anbieter können bestehende Kompetenzen im SAP-Betrieb, im Application-Lifecycle-Management, im Change-Management und in DevSecOps um eine weitere Ebene ergänzen. Partner können beispielsweise zunächst Transparenz über die Open-Source-Abhängigkeiten einer Anwendungslandschaft schaffen. Anschließend können sie bewerten, welche Komponenten besonders kritisch sind, welche Sicherheitsausnahmen bereits bestehen und an welcher Stelle zwischen Patch-Verfügbarkeit und Produktivsetzung Verzögerungen entstehen. Ein weiterer Ansatzpunkt liegt in der Integration in bestehende DevSecOps-Prozesse. Lightwell-Artefakte müssen in Repositories, Build-Prozesse und Testverfahren eingebunden werden. Automatisierte Rebuilds und Tests können dabei helfen, die Zeit zwischen einer verfügbaren Korrektur und ihrer Produktivsetzung zu verkürzen. Für SAP-Dienstleister ist das keine völlig neue Disziplin, denn sie verfügen über genügend Erfahrung mit Release-Management, Systemkopien, Transportprozessen und dem Betrieb geschäftskritischer Systeme. Diese Kompetenzen lassen sich nun auf die Open-Source-Abhängigkeiten rund um SAP-Anwendungen übertragen. Auch die Themen Governance und Compliance gehören dazu. Unternehmen benötigen nachvollziehbare und vor allem belegbare Informationen darüber, welche Komponenten eingesetzt werden, welche Schwachstellen bestehen, welche Korrektur angewendet wurde und wann diese in Produktion gelangt ist.

Open Source braucht einen belastbaren Wartungsprozess

Die eigentliche Bedeutung von Lightwell liegt nicht in einem einzelnen Repository oder einem einzelnen Patch. Vielmehr wird ein strukturelles Problem der Open-Source-Lieferkette adressiert. Open Source beschleunigt Innovationen, verteilt die Verantwortung für die einzelnen Komponenten jedoch über ein komplexes Ökosystem. Unternehmen müssen diese Komponenten trotzdem als Teil ihrer eigenen Lieferkette behandeln. Mit dem Voranschreiten der KI und einer damit einhergehenden Beschleunigung der Schwachstellenanalyse wird es jedoch immer schwieriger, jede gefundene Schwachstelle über einen klassischen Upgrade-Prozess zu beseitigen.

Hier setzt Lightwell mit seiner Kombination aus KI-gestützter Triage, automatisierter Patch-Erzeugung, Backporting auf konkrete Produktionsversionen, technischer Validierung, signierter Distribution und maschinenlesbaren Compliance-Artefakten an. Es geht darum, Sicherheitsprozesse auch dann kontrolliert und nachvollziehbar in die Produktion zu bringen, wenn ein Versionssprung aus technischen, regulatorischen oder betrieblichen Gründen keine praktikable Option ist.

Zum Partnereintrag: