{"id":167273,"date":"2026-10-22T11:19:12","date_gmt":"2026-10-22T09:19:12","guid":{"rendered":"https:\/\/e3mag.com\/?p=167273"},"modified":"2026-10-22T11:19:17","modified_gmt":"2026-10-22T09:19:17","slug":"lightwell-und-sap-wenn-patchen-allein-nicht-reicht","status":"publish","type":"post","link":"https:\/\/e3mag.com\/de\/lightwell-und-sap-wenn-patchen-allein-nicht-reicht\/","title":{"rendered":"Lightwell und SAP: Wenn Patchen allein nicht reicht"},"content":{"rendered":"\n

Open Source ist aus modernen Unternehmensanwendungen nicht wegzudenken. Das gilt auch f\u00fcr SAP-Landschaften, selbst wenn die eingesetzte Software nur einen Teil des gesamten Technologie-Stacks ausmacht. Denn rund um die Systeme existieren Integrationsplattformen, Eigenentwicklungen, Automatisierungsl\u00f6sungen, Schnittstellen, Monitoring-Tools und zahlreiche weitere Anwendungen, von denen viele auf Open-Source-Komponenten basieren oder solche als Abh\u00e4ngigkeiten einbinden. Damit entsteht eine Software-Lieferkette, die deutlich gr\u00f6\u00dfer ist als das eigentliche SAP-Produkt.<\/p>\n\n\n\n

F\u00fcr die IT-Sicherheit ist das ein gro\u00dfes Problem, das klassische Vulnerability-Management-Prozesse nur teilweise l\u00f6sen. Ein Scanner erkennt eine verwundbare Version und der Hersteller oder die Open-Source-Community stellt eine korrigierte Version bereit. Technisch w\u00e4re die Schwachstelle damit zwar behoben, operativ ist die Sache aber noch lange nicht erledigt. Denn die neue Version muss nicht zwangsl\u00e4ufig mit den bestehenden Systemen kompatibel sein.<\/p>

\"\"<\/a><\/div><\/div>\n\n\n\n

Ein Upgrade kann APIs ver\u00e4ndern, transitive Abh\u00e4ngigkeiten austauschen, Regressionen verursachen oder eine erneute Zertifizierung erforderlich machen. Bei einer gesch\u00e4ftskritischen Anwendung ist es deshalb nicht nur wichtig, ob ein Fix verf\u00fcgbar 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\u00f6st, h\u00e4ufen sich als langfristige Sicherheitsausnahmen an oder erfordern kostspielige, propriet\u00e4re Patches und Forks.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Der Mythos-Moment erzwingt ein Umdenken<\/h2>\n\n\n\n

Diese Entwicklung versch\u00e4rft sich mit k\u00fcnstlicher Intelligenz rasant. Im Rahmen des Glasswing-Projekts von Anthropic wurden mithilfe des Modells Mythos Preview Tausende Sicherheitsl\u00fccken in Open-Source-Software aufgesp\u00fcrt \u2013 darunter fast 3900 Schwachstellen mit hohem oder kritischem Schweregrad. KI kann Code in einem Tempo analysieren, das mit herk\u00f6mmlichen manuellen Verfahren nicht erreicht werden kann. Dadurch ver\u00e4ndert sich auch die Dynamik bei Zero-Day-Schwachstellen: Je schneller potenzielle Angriffsfl\u00e4chen identifiziert werden, desto schneller schlie\u00dft sich das Zeitfenster f\u00fcr ihre Absicherung. F\u00fcr einzelne Unternehmen ist es nahezu unm\u00f6glich, jede gefundene Schwachstelle selbst zu bewerten und zu priorisieren. Das versch\u00e4rft wiederum das Problem des Remediation Gap. Zwischen der Entdeckung einer Sicherheitsl\u00fccke und ihrer tats\u00e4chlichen Behebung in einer produktiven Anwendung k\u00f6nnen Wochen oder sogar Monate vergehen. In dieser Zeit bleiben Unternehmen entweder mit einer bekannten Schwachstelle zur\u00fcck, m\u00fcssen eigene Patches pflegen oder stehen vor der Entscheidung, ein riskantes Upgrade durchzuf\u00fchren.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Vom Scanner bis zum produktiven System: Zwischen der Identifikation einer Schwachstelle und ihrem Deployment liegen Analyse, Remediation, Build, Tests und Freigabe \u2013 und damit viel Zeit. (Quelle: Red Hat)<\/em><\/figcaption><\/figure>\n\n\n\n

Aber auch \u201ealte\u201c Schwachstellen sind nach wie vor ein Problem. Ein besonders pr\u00e4gnantes Beispiel ist Log4Shell. Die Sicherheitsl\u00fccke in der weitverbreiteten Java-Bibliothek Apache Log4j wurde Ende 2021 \u00f6ffentlich bekannt und als kritisch eingestuft. Betroffen waren Anwendungen, die eine verwundbare und nicht aktualisierte Version der Bibliothek einsetzten. Unter bestimmten Voraussetzungen konnten Angreifer dar\u00fcber Schadcode aus der Ferne ausf\u00fchren 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\u00e4ngigkeiten in der Software-Lieferkette nach wie vor f\u00fcr enorme Anf\u00e4lligkeiten.<\/p>\n\n\n\n

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\u00fcssen durchgef\u00fchrt, Abh\u00e4ngigkeiten gepr\u00fcft und \u00c4nderungen 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 \u2013 wenn der interne Build- und Deployment-Prozess mehrere Wochen oder sogar Monate ben\u00f6tigt, bleibt die Schwachstelle entsprechend lange bestehen oder wird erst gar nicht angegangen.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Lightwell: Sicherheitsfix statt erzwungenen Versionssprungs<\/h2>\n\n\n\n

Genau diese L\u00fccke 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\u00e4ufig durch einen kompletten Versionssprung ausgeliefert, sondern k\u00f6nnen gezielt auf eine weiterhin unterst\u00fctzte Version zur\u00fcckportiert werden. Das Ziel ist, die sicherheitsrelevante \u00c4nderung einzubringen, ohne gleichzeitig einen unn\u00f6tigen Funktions- oder API-Sprung zu erzwingen. F\u00fcr Unternehmen ist das ein wichtiger Aspekt: Ein Backport adressiert die Sicherheitsl\u00fccke, ohne automatisch die gesamte Abh\u00e4ngigkeitsstruktur der Anwendung zu ver\u00e4ndern.<\/p>\n\n\n\n

Der Unterschied zu einem manuellen Fork ist dabei enorm. Ein Unternehmen k\u00f6nnte zwar theoretisch den Quellcode einer betroffenen Bibliothek kopieren, den Patch einspielen und ein eigenes Artefakt bauen. Damit w\u00fcrde es aber auch dauerhaft die Verantwortung f\u00fcr diesen Fork \u00fcbernehmen: Build-Prozess, Signierung, Abh\u00e4ngigkeiten, weitere Security-Fixes, Dokumentation und gegebenenfalls die sp\u00e4tere R\u00fcckf\u00fchrung in den Upstream. Ein weiterer Unterschied zum herk\u00f6mmlichen Patch-Management liegt in der Frage, was nach dem Einspielen des Updates passiert. In einer modernen Software-Lieferkette gen\u00fcgt es nicht mehr, eine neue JAR-Datei bereitzustellen. Unternehmen m\u00fcssen nachvollziehen k\u00f6nnen, was sie einsetzen, woher es kommt, wie es gebaut wurde und welche Sicherheitsinformationen damit verbunden sind.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n

Unternehmen haben beim Schlie\u00dfen von Schwachstellen drei Optionen:<\/h2>\n\n\n\n
    \n
  1. Klassisches Upgrade:<\/strong> Die Anwendung \u00fcbernimmt eine neuere Dependency-Version und akzeptiert die damit verbundenen Kompatibilit\u00e4ts- und Testaufw\u00e4nde.<\/li>\n\n\n\n
  2. Risiko akzeptieren oder selbst patchen:<\/strong> Die Organisation h\u00e4lt die bestehende Version und baut gegebenenfalls einen eigenen Workaround oder Fork.<\/li>\n\n\n\n
  3. Gezieltes Backporting:<\/strong> Der Security-Fix wird auf die produktiv eingesetzte Version portiert und als kontrolliertes Artefakt in die bestehende Supply Chain eingebracht, ohne die Anwendung ver\u00e4ndern zu m\u00fcssen.<\/li>\n<\/ol>\n\n\n\n

    Welche Variante sinnvoll ist, h\u00e4ngt von der Anwendung, dem Risikoprofil und dem Betriebsmodell ab. Lightwell erweitert dabei den technischen L\u00f6sungsraum um eine Option, die insbesondere bei stabilen, langlebigen und schwer ver\u00e4nderbaren Anwendungen relevant ist.<\/p>\n<\/div><\/div>\n\n\n\n

    <\/div>\n\n\n\n

    Lightwell liefert deshalb nicht nur gepatchte und signierte Artefakte, sondern auch Supply-Chain-Metadaten. Dazu geh\u00f6ren unter anderem Software Bills of Materials (SBOM), SLSA-Level-3-Provenance sowie Signaturen \u00fcber Sigstore beziehungsweise Cosign. Dies ist insbesondere f\u00fcr SAP-Kunden relevant, da die Open-Source-Abh\u00e4ngigkeit wie gesagt nicht an der Grenze des SAP-Systems endet. In einer Integrationslandschaft k\u00f6nnen 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.<\/p>\n\n\n\n

    Eine SBOM beantwortet im Wesentlichen die Frage, welche Komponente vorhanden ist. VEX kann erg\u00e4nzende Informationen dar\u00fcber liefern, ob und wie eine Software von einer bestimmten Schwachstelle tats\u00e4chlich betroffen ist. F\u00fcr regulierte Unternehmen ist das von entscheidender Bedeutung. Anforderungen aus DORA, NIS2 oder dem Cyber Resilience Act erh\u00f6hen den Druck, Softwarekomponenten, Schwachstellen und deren Behandlung nachvollziehbar zu dokumentieren. Lightwell stellt diese Informationen zusammen mit den Artefakten bereit, sodass sie nicht nachtr\u00e4glich manuell aus verschiedenen Quellen zusammengetragen werden m\u00fcssen.<\/p>\n\n\n\n

    Auch mit Blick auf k\u00fcnftige beziehungsweise freiwillige europ\u00e4ische 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.<\/p>\n\n\n\n

    <\/div>\n\n\n\n

    Zwei Versionen f\u00fcr unterschiedliche Bed\u00fcrfnisse<\/h2>\n\n\n\n

    Lightwell setzt zudem nicht erst beim fertigen Patch an. Das Modell kombiniert KI-gest\u00fctzte Triage mit menschlicher Engineering-Expertise. Die KI hilft dabei, die massive Flut an CVEs zu bew\u00e4ltigen, indem sie Schwachstellen in Sekundenschnelle analysiert, ihre Relevanz bewertet und m\u00f6gliche Korrekturen erstellt. Die resultierenden \u00c4nderungen werden anschlie\u00dfend automatisiert getestet und durch menschliche Experten \u2013 besser gesagt mehr als 20.000 Techniker von Red Hat und IBM \u2013 validiert, bevor sie als Artefakte bereitgestellt werden. Die entwickelten Patches werden aber nicht nur den Kunden zug\u00e4nglich gemacht, sondern im Sinne der Open-Source-Gemeinschaft auch an die Ursprungsprojekte zur\u00fcckgegeben, damit die gesamte Branche profitiert.<\/p>\n\n\n\n

    Der anf\u00e4ngliche Schwerpunkt des Lightwell-\u00d6kosystems liegt auf Maven\/Java. Das ist gerade f\u00fcr SAP-Kunden interessant, da Java-Anwendungen ihre Dependencies h\u00e4ufig \u00fcber Maven-Repositories beziehen und in zahlreichen Integrations-, Middleware- und kundeneigenen Anwendungsszenarien eine Rolle spielen. Gleichzeitig ist Java nur der Anfang. Lightwell soll auf weitere \u00d6kosysteme 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\u00fcgbar ist die L\u00f6sung derzeit in zwei unterschiedlichen Versionen.<\/p>\n\n\n\n

    <\/div>\n\n\n\n
    \n

    Lightwell ist kein Ersatz f\u00fcr:<\/h2>\n\n\n\n