Damit die Branche weiterhin Software gemeinsam nutzen kann, benötigt sie ein zuverlässiges System zur Meldung und Nachverfolgung kompromittierter Pakete.
Obwohl heute mehr Open-Source-Software als je zuvor verfügbar ist, war das Risiko bei ihrer Nutzung noch nie so hoch. Warum? Weil aktuelle Berichte über manipulierte Pakete zeigen, dass die Überprüfung des Quellcodes in einem öffentlichen Repository keine Garantie dafür bietet, dass das bereitgestellte Paket sicher ist.
Da wir davon ausgehen, dass Pakete sicher sind, obwohl sie nachweislich nicht sicher sind, ist das Ökosystem der Software-Lieferkette entsprechenden Risiken ausgesetzt. Build-Artefakte, Pakete, Pipelines, Paketverteilungsstellen und Installationsprozesse werden regelmäßig für böswillige Zwecke missbraucht.
Je beliebter das Paket ist, desto schneller entsteht Schaden. Derzeit beobachten wir, dass vor allem KI-Tools von Manipulationen betroffen sind, und KI-Agenten verschärfen den Schaden so rasant, dass man mit Fug und Recht sagen kann, die Branche sei von der Kompromittierung von Paketen überfordert.
Mit dem, was wir bisher getan haben, werden wir dieses Ziel nicht erreichen
Im Open-Source-Software-Ökosystem gibt es kein offizielles Verzeichnis kompromittierter Softwarepakete. Das bedeutet, dass Organisationen über kein verlässliches System verfügen, anhand dessen sie den von ihnen verwendeten Codepaketen vertrauen können. Darüber hinaus gehen Build-Pipelines, Installationsprozesse und Paket-Repositorys von Sicherheit statt von einer möglichen Kompromittierung aus. Automatisierung und KI-Agenten verschärfen und beschleunigen das Risiko in Maschinengeschwindigkeit.
Um dieser neuen Herausforderung zu begegnen, benötigt das Open-Source-Software-Ökosystem:
- Branchenweite Zusammenarbeit, um kompromittierte Pakete über eine zentrale, verlässliche Informationsquelle zu melden.
- Gezielte Anstrengungen, um die Sicherheitslücken in der Software-Lieferkette des Ökosystems zu schließen.
- Verpflichtung des Ökosystems, branchenweit bewährte Verfahren zu entwickeln, bekannt zu machen und umzusetzen.
Eine Kultur des kontinuierlichen Lernens und der stetigen Verbesserung ist ein wirksamer Schutz. Wir dürfen niemals aufhören, die Sicherheit unseres Quellcode-Ökosystems, unserer Build-Pipelines und unserer Paket-Repositorys zu verbessern.
Erste Schritte
Wir haben bereits etwas, das dem Benötigten nahekommt. Es wird von der Open Source Security Foundation (OpenSSF) betrieben und heißt Malicious Packages Repository (MPR). Es bietet eine zentrale Anlaufstelle und ein einheitliches Verfahren zur Definition und Meldung schädlicher Pakete. Was noch fehlt, ist eine umfassende Beteiligung der Branche, damit es sich als De-facto-Standard für die Erfassung kompromittierter Pakete und die Behebung der damit verbundenen Probleme etabliert.
Das MPR verwendet eine maschinenlesbare Dateispezifikation namens Open Source Vulnerability (OSV), die JSON nutzt, um die Übermittlung und Erfassung von Meldungen sowie die Versorgung von Scannern mit Daten zu automatisieren. Dies ermöglicht ein spezielles Verfahren, mit dem vertrauenswürdige Sicherheitsforscher kontinuierlich, schnell und effizient neue Daten einspeisen können. Darüber hinaus wird es von einer aktiven Arbeitsgruppe gepflegt, die neuen Mitwirkenden und Verbesserungsvorschlägen offen gegenübersteht.
Wir brauchen etwas wie das OpenSSF MPR, das auf manipulierte Pakete ausgerichtet ist und für sie das leistet, was das CVE-Programm für Schwachstellen im Quellcode leistet. Veränderung beginnt damit, den Ist-Zustand anzuerkennen, und genau das war sicherlich der Anstoß für die Einrichtung des OpenSSF MPR. Die Arbeit hat also begonnen, doch es bleibt noch viel zu tun, bevor es so hilfreich sein kann wie die CVE-Datenbank. Als Branche können und sollten wir zusammenarbeiten, um unser gemeinsames Software-Ökosystem vertrauenswürdiger zu machen.
Über den Autor
Ähnliche Blogbeiträge
Top 10 der KI-App-Bereitstellung: Mangelnde Sicherheit und Einhaltung gesetzlicher Vorschriften
KI erweitert Compliance über die Absicherung von Zugriffspfaden und Datenspeichern hinaus auf die Steuerung des Laufzeitverhaltens – einschließlich Modellzugriff, Abrufkontext, Ausgaben und Agentenaktionen. Daher müssen Kontrollen näher an die Inferenz rücken.
KI-App-Bereitstellung – Top 10: Unzureichende Datenverkehrskontrollen
Herkömmliche Ratenbegrenzungen und Drosselungsmechanismen erfassen das tatsächliche Schadensausmaß nicht. KI-Workloads verteilen sich auf Modelle, Vektordatenbanken und Dienste und führen so zu Latenzspitzen, kaskadierenden Ausfällen und wiederholten Anfragen.
Verhalten und Grenzen: Der Wandel hin zu agentischer Sicherheit
Agenten erzeugen emergente, unbegrenzte Abfolgen, in denen sich Risiken im Laufe der Zeit summieren. Sicherheit muss sich daher von der Validierung einzelner Anfragen hin zu einer kontinuierlichen Verhaltenssteuerung über mehrstufige, sich weiterentwickelnde Abläufe verlagern.
Agentenfähigkeiten: Ein neuer offener Standard
Skills erklären eine Absicht, erzwingen aber keine Kontrolle. Echte Sicherheit muss an der Schnittstelle zu den Tools verankert sein – dort, wo die Überlegungen von Agenten zu Handlungen werden und Richtlinien durchgesetzt werden können.
Von Paketen zu Prompts: Inferenz erweitert den Stack um eine neue Ebene
Inferenz ist kein Training. Sie ist kein Experimentieren. Sie ist keine Data-Science-Übung. Inferenz ist Laufzeitverhalten in der Produktion und verhält sich wie eine Anwendungsschicht.