Wie bereits in einem anderen Artikel erwähnt: Ohne den Einsatz von Open-Source-Komponenten ist die moderne Software-Entwicklung praktisch undenkbar. In den letzten Jahren sind die damit verbundenen Risiken jedoch immer vielfältiger, komplexer und zahlreicher geworden. Erstens: Schwachstellen beeinträchtigen die Infrastruktur und die Codebasis von Unternehmen und können oft nicht rechtzeitig behoben werden. Zweitens: unzuverlässige und unvollständige Daten. Und drittens: Malware kann in beliebten Komponenten lauern. Es reicht nicht aus, einfach die Versionsnummern zu scannen und dem IT-Team Korrekturtickets zu schicken. Das Schwachstellen-Management muss viel breiter angelegt sein. Die Rede ist von Richtlinien für Software-Downloads, Begrenzungen für KI-Assistenten und Regeln für die gesamte Software-Entwicklungs-Pipeline.

Pool mit vertrauenswürdigen Open-Source-Komponenten

Der Kern der Lösung besteht darin, der Nutzung von anfälligem und bösartigem Code einen Riegel vorzuschieben. Dazu sind die folgenden Maßnahmen erforderlich:

• Internes Repository für Artefakte. Die einzige Quelle für Komponenten, die in der internen Entwicklung genutzt werden, muss ein einheitliches Repository sein. Für diese Komponenten gilt eine Überprüfungsprozedur.
• Strenges Komponenten-Screening. Dabei werden überprüft: bekannte Versionen der Komponente, bekannte anfällige Versionen und bösartige Versionen, Veröffentlichungsdatum, Aktivitätsverlauf sowie Reputation des Pakets und seiner Autoren. Die Untersuchung des gesamten Paketinhalts, einschließlich Build-Anweisungen, Testfällen und anderer Zusatzdaten ist obligatorisch. Wenn neue Komponenten in die Registry aufgenommen werden, erfolgt eine Filterung mithilfe spezieller Open-Source-Scanner oder einer umfassenden Sicherheitslösung für Cloud-Workloads.
• Anheften von Abhängigkeiten. Build-Prozesse, KI-Tools und Entwickler dürfen bei Versionsangaben keine Vorlagen (z. B. „kürzlich verwendet“) verwenden. Projekt-Builds müssen auf verifizierten Versionen beruhen. Gleichzeitig müssen angeheftete Abhängigkeiten regelmäßig aktualisiert werden. Und zwar auf die neuesten verifizierten Versionen, die Kompatibilität gewährleisten und keine bekannten Schwachstellen aufweisen. Dadurch wird das Risiko von Lieferkettenangriffen durch die Kompromittierung eines bekannten Pakets erheblich reduziert.

Verbesserung von Daten über Schwachstellen

Um Schwachstellen effektiver zu identifizieren und richtig zu priorisieren, muss ein Unternehmen mehrere IT- und Sicherheitsprozesse einrichten:

• Anreicherung von Daten über Schwachstellen. Je nach den Anforderungen des Unternehmens können Informationen durch die Kombination mit Daten aus NVD, EUVD, BDU, GitHub Advisory Database und osv.dev angereichert werden oder es wird ein kommerzieller Threat-Intelligence-Feed erworben, der bereits aggregierte und angereicherte Daten bietet. Auf jeden Fall ist es empfehlenswert, zusätzlich Threat-Intelligence-Feeds zu überwachen, um reale Exploit-Trends zu verfolgen und das Profil von Angreifern zu verstehen, die auf bestimmte Schwachstellen spezialisiert sind. Kaspersky bietet einen spezialisierten Daten-Feed, der sich auf Open-Source-Komponenten konzentriert.
• Detaillierte Analyse der Software-Komposition. Spezialisierte Software-Kompositionsanalyse-Tools (SCA) ermöglichen eine fachgerechte Untersuchung der Abhängigkeitskette im Open-Source-Code. Dazu zählen eine vollständige Inventarisierung der verwendeten Bibliotheken sowie die Erkennung veralteter oder nicht mehr unterstützter Komponenten. Daten über fehlerfreie Komponenten eignen sich auch, um die Artefakt-Registry anzureichern.
• Identifizierung von Abandonware. Selbst wenn eine Komponente formell nicht als anfällig gilt und die Unterstützung nicht offiziell beendet wurde, lohnt sich eine Suche nach Komponenten, die seit über einem Jahr keine Updates mehr erhalten haben. Diese müssen separat analysiert und möglicherweise ersetzt werden (ähnlich wie EOL-Komponenten).

Schutz von KI-Code und KI-Agenten

Die Aktivitäten von KI-Systemen, die beim Programmieren verwendet werden, erfordern komplexe Sicherheitsmaßnahmen – von der Filterung der Eingabedaten bis hin zur Benutzerschulung:

• Einschränkungen für Abhängigkeitsempfehlungen. Die Entwicklungsumgebung muss so konfiguriert werden, dass KI-Agenten und -Assistenten nur auf Komponenten und Bibliotheken aus der vertrauenswürdigen Artefakt-Registry verweisen können. Falls die erforderlichen Tools dort nicht zu finden sind, muss das Modell eine Aufnahme der Abhängigkeit in die Registry beantragen. Es darf sich nicht einfach ein anderes Tool aus PyPI holen, das der Beschreibung entspricht.
• Filterung von Modellausgaben. Trotz dieser Einschränkungen muss alles, was vom Modell generiert wird, auch überprüft werden. Auf diese Weise wird sichergestellt, dass der KI-Code keine veralteten, ausgemusterten, anfälligen oder erfundenen Abhängigkeiten enthält. Diese Prüfung sollte direkt in den Code-Aufnahmeprozess oder in die Build-Vorbereitungsphase integriert werden. Sie ersetzt nicht den traditionellen statischen Analyseprozess: Die CI/CD-Pipeline muss weiterhin mit SAST-Tools ausgerüstet sein.
• Training für Entwickler. IT- und Sicherheitsteams müssen sich mit den Eigenschaften, Funktionsprinzipien und häufigsten Fehlern von KI-Systemen bestens auskennen. Dazu sollten die Mitarbeiter ein spezielles Training absolvieren, das auf die jeweiligen Rollen zugeschnitten ist.

Systematische Entfernung von EOL-Komponenten

Wenn in den Unternehmenssystemen veraltete Open-Source-Komponenten im Einsatz sind, müssen die entsprechenden Schwachstellen systematisch und einheitlich behoben werden. Dafür gibt es grundsätzlich drei Methoden:

• Migration. Diese Methode verursacht den höchsten Organisationsaufwand und ist am teuersten, da eine Komponente vollständig ersetzt wird. Anschließend müssen alle auf der Komponente basierenden Anwendungen angepasst, neu geschrieben oder ausgetauscht werden. Die Entscheidung für eine Migration ist besonders schwierig, wenn dadurch eine umfassende Überarbeitung des gesamten internen Codes erforderlich wird. Häufig sind Kernkomponenten betroffen. Beispielsweise ist eine Migration von Node.js 14 oder Python 2 alles andere als einfach.
• Langfristiger Support (LTS). Für umfangreiche veraltete Projekte werden spezielle Support-Dienste angeboten. Manchmal handelt es sich dabei um einen Zweig des veralteten Systems, der von anderen Entwicklern betreut wird. Andere Möglichkeit: Backport-Patch, bei dem spezialisierte Teams Patches für bestimmte Schwachstellen auf ältere, nicht unterstützte Versionen übertragen. Der Umstieg auf LTS verursacht generell laufende Support-Kosten, was jedoch in vielen Fällen immer noch kostengünstiger sein kann als eine komplette Migration.
• Kompensationsmaßnahmen. Nach einer detaillierten Analyse können umfassende Sicherheitsmaßnahmen durchgeführt werden, um das Exploit-Risiko für Schwachstellen in einem älteren Produkt zu reduzieren. Effektivität und Wirtschaftlichkeit dieses Ansatzes hängen von der Rolle der Software im Unternehmen ab.

Sicherheit, IT und Business müssen zusammenarbeiten, um eine dieser drei Optionen für jede dokumentierte EOL- oder aufgegebene Komponente auszuwählen und diese dann in den Asset-Registrys und SBOMs des Unternehmens zu realisieren.

Risikobasiertes Open-Source-Schwachstellen-Management

Alle oben genannten Maßnahmen reduzieren die Menge an anfälliger Software und Komponenten, die in das Unternehmen gelangen, und vereinfachen die Erkennung und Behebung von Schwachstellen. Trotzdem ist es schlicht unmöglich, alle Fehler zu beheben: Die Zahl der Anwendungen und Komponenten wächst einfach zu schnell.

Darum müssen Schwachstellen nach wie vor priorisiert werden, um die realen Risiken zuerst zu adressieren. Das Risikobewertungsmodell muss erweitert werden, um die Eigenheiten von Open Source zu berücksichtigen. Dabei stellen sich folgende Fragen:

• Wird der anfällige Codezweig tatsächlich in der Umgebung des Unternehmens ausgeführt? Es sollte eine Erreichbarkeitsanalyse für gefundene Schwachstellen durchgeführt werden. Viele fehlerhafte Code-Snippets werden innerhalb der spezifischen Implementierung des Unternehmens nie ausgeführt, sodass die Schwachstelle gar nicht ausgenutzt werden kann. Die Analyse können bestimmte SCA-Lösungen übernehmen. Dabei kann auch ein alternatives Szenario bewertet werden: Was passiert, wenn die anfälligen Prozeduren oder Komponenten vollständig aus dem Projekt entnommen werden? Manchmal erweist sich dieses Vorgehen als überraschend praktisch.
• Wird der Fehler bei realen Angriffen ausgenutzt? Ist ein PoC verfügbar? Die Antworten auf diese Fragen sind Teil von standardmäßigen Priorisierungs-Frameworks wie EPSS. Hier muss aber eine viel breitere Palette von Informationsquellen berücksichtigt werden.
• Wurden in dieser Abhängigkeits-Registry oder in verwandten und ähnlichen Komponenten cyberkriminelle Aktivitäten gemeldet? Hieraus ergeben sich zusätzliche Priorisierungsfaktoren.

Anhand dieser Faktoren können die Ressourcen effektiv zugewiesen und die gefährlichsten Fehler vorrangig behoben werden.

Transparenz ist Trumpf

Die Sicherheitsanforderungen für Open-Source-Software werden weiter steigen. Unternehmen, die Anwendungen entwickeln (auch für den internen Gebrauch) müssen strenge Vorschriften erfüllen, ihr Vorgehen dokumentieren und die Cybersicherheit in ihren Systemen überprüfbar machen. Nach Schätzungen von Sonatype erfüllen weltweit bereits 90 % der Unternehmen eine oder mehrere Anforderungen, um die Zuverlässigkeit der eingesetzten Software nachzuweisen. Daher gilt Transparenz in Expertenkreisen als „die Währung für Sicherheit in der Software-Lieferkette“.

Durch Kontrolle beim Einsatz von Open-Source-Komponenten und -Anwendungen, Threat-Intelligence-Anreicherung und strenge Überwachung KI-basierter Entwicklungssysteme können Unternehmen notwendige Innovationen einführen und dabei den hohen Anforderungen gerecht werden, die von Aufsichtsbehörden und Kunden gestellt werden.