Open Source Security: KI findet Sicherheitslücken schneller, als sie geschlossen werden

Nehmen wir an, Ihr Unternehmen baut Sondermaschinen und betreibt für seine Kunden ein Serviceportal. Eine Agentur hat es vor einigen Jahren in Java entwickelt, eine selbst geschriebene Schnittstelle holt Ersatzteilpreise und Lieferzeiten aus dem ERP. An einem Montag meldet der Schwachstellenscanner eine kritische Lücke in einer Bibliothek, mit der das Portal XML-Dateien verarbeitet. Behoben ist sie nur in der neuesten Hauptversion, und ausgerechnet diese verträgt sich nicht mit der ERP-Schnittstelle.

Solche Montage werden häufiger. KI-Modelle finden Sicherheitslücken in Open-Source-Software inzwischen in einem Tempo, mit dem die Behebung nicht Schritt hält. Vulnerability Remediation (Schwachstellenbehebung) umfasst alle Schritte zwischen dem Fund einer Sicherheitslücke und dem Moment, in dem die korrigierte Software in Produktion läuft, ohne dort etwas anderes zu beschädigen. An dieser Stelle entscheidet sich, ob mehr gefundene Lücken Ihre Software tatsächlich sicherer machen.

Dieser Beitrag zeigt, warum ein Fix aufwendiger ist als ein Update, warum Korrekturen zurück ins Ursprungsprojekt gehören und was Initiativen wie Lightwell und Akrites daran ändern sollen.

Open Source steckt in fast jeder Software

Banken, Spitäler, Energieversorger und Cloud-Plattformen laufen auf Code, den oft kleine Teams oder Freiwillige geschrieben haben. Für den Open Source Security and Risk Analysis Report 2026 (März 2026) hat Black Duck 947 Codebasen untersucht: 98 Prozent enthielten Open-Source-Komponenten, und im Schnitt steckten in jeder Codebasis 581 Schwachstellen.

Das Modell hat viel Innovation ermöglicht. Wer ein Projekt in der Freizeit pflegt, kann aber keine Reaktionszeiten zusagen, wie sie kritische Infrastruktur bräuchte. Unternehmen haben Open Source jahrelang schneller genutzt, als sie in dessen Absicherung investiert haben. Weil alles vernetzt ist, bleibt ein Fehler in einer unscheinbaren Bibliothek auch nicht dort. Er steckt in Tausenden Anwendungen, die auf ihr aufbauen.

KI findet Lücken schneller, als sie geschlossen werden

Was erfahrene Sicherheitsforscher früher wochenlang beschäftigt hat, erledigen aktuelle Frontier-Modelle in einem Bruchteil der Zeit. Anthropic hat am 7. April 2026 Project Glasswing vorgestellt, eine Initiative mit Partnern wie AWS, Apple, Google, Microsoft und der Linux Foundation. Das nicht öffentlich verfügbare Modell Claude Mythos Preview fand dabei unter anderem eine 27 Jahre alte Lücke in OpenBSD, einem Betriebssystem mit besonders gutem Sicherheitsruf. Ein Angreifer konnte damit jeden Rechner mit OpenBSD aus der Ferne zum Absturz bringen, allein indem er eine Verbindung aufbaute.

Im ersten Zwischenbericht vom 22. Mai 2026 nennt Anthropic mehr als 1.000 untersuchte Open-Source-Projekte und 23.019 vom Modell gemeldete Schwachstellen, 6.202 davon als hoch oder kritisch eingestuft. Von 1.752 dieser Funde, die bis dahin geprüft waren, erwiesen sich 90,6 Prozent als echt. Den Engpass verortet Anthropic selbst bei der Frage, wie schnell sich solche Mengen verifizieren, melden und patchen lassen.

Wie groß der Abstand ist, zeigt die Disclosure-Übersicht des Projekts. Mit Stand 2. Oktober 2026 hat Anthropic 6.157 Schwachstellen in 591 Open-Source-Projekten an die Maintainer gemeldet. Behoben sind nach eigener Kenntnis 516 davon.

Ähnliche Werkzeuge stehen auch Angreifern zur Verfügung. Ob der Verteidiger mit einem sauber eingespielten Patch zuerst ankommt oder der Angreifer mit einem Exploit, entscheidet sich deshalb zunehmend nach dem Fund.

Warum ein Fix mehr ist als ein Update

Im Serviceportal beginnt die Arbeit mit der Meldung des Scanners erst. Das Team muss klären, welche Versionen der Bibliothek betroffen sind und welche andere Komponente noch von ihr abhängt. Es muss abschätzen, was ein Ausfall des Portals kostet und wann ein Eingriff am wenigsten stört, etwa nicht mitten in der Hauptsaison für Wartungsaufträge. Dann folgen die Korrektur selbst, Regressionstests, die zeigen, dass sie nichts anderes beschädigt, die Prüfung auf allen Systemen, auf denen das Portal läuft, und schließlich der Rollout in Produktion.

Der Rat aus dem Lehrbuch lautet, auf die neueste Version zu aktualisieren. Im Serviceportal würde das die ERP-Schnittstelle brechen. Anderswo stehen Abhängigkeitskonflikte, regulatorische Vorgaben oder eigener Code im Weg, der auf der Bibliothek aufsetzt. Realistisch ist dann ein Backport: Die Korrektur wird auf die Version übertragen, die bereits läuft. Das verlangt Entwickler, die Code und Umgebung kennen. KI kann die Lücke analysieren und einen Patch vorschlagen, ob er in Ihre Umgebung passt, muss ein Mensch beurteilen. Wie AI Agents und Entwickler beim Schreiben von Software zusammenarbeiten, beschreibt unser Beitrag zum Agentic Engineering.

Mehr Funde machen Software also nicht automatisch sicherer. Können die Projekte die Menge an Meldungen nicht verarbeiten, bleiben Lücken monatelang offen, und mit jeder Woche steigt das Risiko, dass ein Angreifer dieselbe Schwachstelle unabhängig entdeckt.

Korrekturen gehören upstream

Upstream bezeichnet das Ursprungsprojekt, aus dem alle anderen ihren Code beziehen. Ein solches Projekt trägt Jahre an Architekturentscheidungen und Wissen in sich, das ein Modell aus dem Code allein nicht ablesen kann. Maintainer erkennen, ob ein Fix an anderer Stelle Folgen hat, und halten das Projekt langfristig stabil.

Behält ein Unternehmen seinen Backport im eigenen Fork, ist nur ihm geholfen. Jede weitere Firma mit demselben Problem baut ihre eigene Korrektur, die Forks driften auseinander, und jede Abweichung muss dauerhaft jemand pflegen. Wird der Fix im Ursprungsprojekt eingebracht, profitieren alle, die die Bibliothek nutzen.

Kein einzelnes Unternehmen kann Open Source allein absichern. Dafür braucht es KI-Anbieter, Softwarehersteller, Cloud-Plattformen, Sicherheitsfirmen, Maintainer und gemeinnützige Stiftungen, die ihre Arbeit abstimmen. Zwei Initiativen versuchen das gerade.

Lightwell: geprüfte Fixes für die Version, die läuft

IBM und Red Hat haben am 6. Oktober 2026 gemeldet, dass ihre Initiative Lightwell mehr als 400 bisher unbekannte Schwachstellen in verbreiteten Java-Bibliotheken behoben hat. Lightwell kombiniert KI-gestützte Analyse mit dem Review erfahrener Entwickler und mit Tests, damit ein Patch die Lücke schließt, ohne neue Probleme einzuführen. Die Korrekturen werden auf die Versionen zurückportiert, die Unternehmen produktiv einsetzen, und über abgesicherte Repositories ausgeliefert. Scanner, Pipelines und Testprozesse bleiben dabei unverändert.

Über die Lightwell Clearinghouse können Unternehmen gezielt einzelne Schwachstellen zur bevorzugten Behebung einreichen, auch für ältere Versionen. Passende Fixes gehen unter Responsible Disclosure an das Ursprungsprojekt zurück. Für ein Serviceportal wie das oben beschriebene wäre das ein Weg, die bisherige Bibliotheksversion zu behalten und trotzdem einen geprüften Patch zu bekommen.

Akrites: ein gemeinsames Incident Response Team

Die Linux Foundation hat am 25. Juni 2026 Akrites gestartet. Zu den Gründungsmitgliedern zählen unter anderem AWS, Anthropic, Google, IBM, Microsoft mit GitHub, NVIDIA, OpenAI, Red Hat und JPMorganChase, die Anschubfinanzierung kommt von Alpha-Omega. Im Mittelpunkt steht ein gemeinsames Security Incident Response Team (SIRT), das einen einheitlichen Prozess für Coordinated Vulnerability Disclosure betreibt.

Laut akrites.org durchläuft jeder Fund denselben Weg, damit Maintainer einem einzigen, berechenbaren Partner gegenüberstehen und Embargos einheitlich gehandhabt werden. Ein Mitglied meldet den Fund an das SIRT. Dort werden doppelte Meldungen zu einem Fall zusammengeführt, die Schwere geprüft und Zuständigkeiten vergeben. Maintainer oder Entwickler aus der Industrie bereiten den Fix vertraulich vor und testen ihn. Veröffentlicht wird in einem gemeinsamen Zeitfenster, und der Fix erscheint im Ursprungsprojekt.

Hat ein kritisches Paket keinen aktiven Maintainer mehr, übernimmt Akrites diese Rolle als letzte Instanz, damit Korrekturen trotzdem alle Nutzer erreichen.

Was Sie im eigenen Unternehmen tun können

Die großen Initiativen entlasten das Ökosystem. Für Ihre eigenen Anwendungen verkürzen vier Vorkehrungen den Weg vom Fund zum Rollout:

• Bestand kennen: Eine Software Bill of Materials (SBOM, Stückliste der Softwarekomponenten) für jede Anwendung zeigt sofort, ob eine gemeldete Bibliothek bei Ihnen läuft, auch in zugekaufter Software.
• Tests automatisieren: Ohne Regressionstests wird jeder Patch zum Risiko, und Teams schieben ihn hinaus.
• Zuständigkeiten klären: Wer pflegt die Abhängigkeiten des Serviceportals, wenn die Agentur nicht mehr beauftragt ist? Diese Frage gehört in jeden Wartungsvertrag.
• Zurückgeben: Fixes, die Ihr Team entwickelt, upstream einbringen, statt sie im eigenen Fork zu pflegen.

Häufige Fragen zu Open Source Security

Was bedeutet Vulnerability Remediation? Gemeint sind alle Schritte nach dem Fund einer Sicherheitslücke: Betroffenheit prüfen, Fix entwickeln, testen und ohne Nebenwirkungen in Produktion bringen.

Macht KI Open-Source-Software unsicherer? KI hilft Verteidigern wie Angreifern, Lücken zu finden. Sicherer wird Software erst, wenn die Behebung mit dem Tempo der Funde mithält.

Warum nicht einfach auf die neueste Version aktualisieren? Neue Hauptversionen ändern oft Schnittstellen, auf die eigener Code oder Integrationen angewiesen sind. Ein Backport auf die laufende Version ist dann der sicherere Weg.

Sie wollen KI in Ihrer Softwareentwicklung einsetzen, auch um Ihren eigenen Code auf Schwachstellen zu prüfen? Wir unterstützen Sie bei Auswahl und Einführung der passenden AI Agents.