Warum die Risiken der KI-Supply-Chain das SBOM-Modell überholt haben

Jahrelang basierten Software-Stücklisten auf Annahmen, die im Allgemeinen zutrafen. Abhängigkeiten waren statisch. Release-Zyklen waren vorhersehbar. Indem Teams erfassten, was zum Build-Zeitpunkt in eine Anwendung einging, konnten sie später fundierte Risikoentscheidungen treffen. Dieser Ansatz funktionierte, weil sich herkömmliche Software innerhalb klarer Grenzen und vorhersehbar verhielt. KI stellt diese Annahmen nahezu unmittelbar infrage.

KI-Supply-Chains verändern sich rasant. Über Nacht entstehen neue Open-Source-Modelle. Agent-Frameworks entwickeln sich in öffentlichen Repositories schneller weiter, als die meisten Sicherheitsteams den Überblick behalten können. MCP-Server, Prompts, Datensätze und Orchestrierungs-Tools ändern sich ständig, während Entwickler experimentieren. Das Tempo ist nicht einfach nur höher. Es ist grundlegend anders.

KI-Komponenten sind außerdem keine passiven Bestandteile. Sie prägen das System aktiv während seiner Laufzeit. Modelle können zur Laufzeit neue Tools einbinden. Agents generieren Prompts, verketten Aktionen und rufen Dienste auf, die im ursprünglichen Code nie definiert wurden. Komponenten schaffen spontan neue Beziehungen und Ausführungspfade. Das bedeutet: Die Supply-Chain ist nicht länger zum Build-Zeitpunkt festgelegt.

Hier beginnt das SBOM-Modell an seine Grenzen zu stoßen. Eine statische Komponentenliste kann ein System, das sich während des Betriebs verändert, nicht erfassen. Sicherheitsteams benötigen mehr als eine Momentaufnahme dessen, was zum Zeitpunkt des Commits vorhanden war. Sie müssen nachvollziehen können, wie KI-Komponenten interagieren, welche Aufrufe sie tätigen und wie sich diese Beziehungen weiterentwickeln.

Aus diesem Bedarf entstand die Idee einer KI-Stückliste. Der Begriff kann jedoch irreführend sein. Eine AIBOM ist keine Checkliste. Sie ist eine dynamische Übersicht über Komponenten, Verhaltensweisen und Verbindungen, die widerspiegelt, wie KI-Systeme tatsächlich funktionieren. Statische Artefakte reichen nicht mehr aus, wenn die Software selbst darauf ausgelegt ist, sich zu verändern.

Das wachsende Problem: Die Hälfte der KI-Supply-Chain befindet sich außerhalb des Repositorys

Sobald man akzeptiert, dass KI-Supply-Chains dynamisch sind, wird ein weiteres Problem sichtbar. Das Repository zeigt nur einen Teil des Gesamtbilds. Ein wachsender Teil der KI-Supply-Chain gelangt nie in die Versionsverwaltung. Er läuft auf den Rechnern der Entwickler.

Entwickler installieren und testen lokal KI-Tools, oft schneller, als Sicherheitsteams den Überblick behalten können. Bei einem großen Medienunternehmen richteten Teams lokale MCP-Server ein, um schneller zu arbeiten. Dabei stellten sie fest, dass die Security-Abteilung weder wusste, wo sich diese Server befanden, noch worauf sie zugriffen. Bei einem globalen Investmentunternehmen testeten Entwickler lokale KI-Agents und Automatisierungs-Tools mit weitreichendem Zugriff auf interne Systeme – ohne Prüfung. In einem anderen Unternehmen waren lokale MCP-Tools offiziell verboten, dennoch nutzten Entwickler sie weiter, weil sie ihre Arbeit vereinfachten.

Dieses Verhalten ist nicht böswillig, sondern pragmatisch. Entwickler nutzen die Tools, die ihnen bei der Problemlösung helfen. Risiken entstehen, wenn diese Tools außerhalb der Kontrollen eingesetzt werden, auf die sich Sicherheitsteams verlassen.

Lokale KI-Agents und MCP-Server haben oft direkten Zugriff auf Pipelines, Zugangsdaten und interne Dienste. Daten können ohne Dokumentation oder Kontrolle übertragen werden. Da diese Komponenten nie CI/CD-, SAST- oder SCA-Workflows durchlaufen, bleibt ihr Verhalten weitgehend unsichtbar – obwohl sie nur einen Laptop von der Produktion entfernt sind.

Dieser Wandel hat Schatten-IT komplexer gemacht. Bei Schatten-IT ging es um nicht genehmigte SaaS-Angebote. Shadow AI umfasst nicht genehmigte Modelle, lokale Tools, MCP-Server, Agents und experimentelle Frameworks, die auf Entwickler-Endgeräten laufen. Sie ist lokal, verändert sich schnell und wird von Einzelpersonen statt von der Beschaffung vorangetrieben.

Das Ergebnis ist eine wachsende Transparenzlücke. Selbst der vollständigste Einblick in ein Repository lässt KI-Komponenten außer Acht, die nie darin auftauchen. Mit der beschleunigten KI-Entwicklung sind Entwicklerrechner zu einem der am wenigsten verstandenen Bereiche der KI-Supply-Chain geworden.

Warum eine AI-BOM allein das Problem nicht löst (aber ein Anfang ist)

Eine KI-Stückliste schafft die dringend benötigte Struktur für moderne KI-Systeme. Sie bietet Einblick in Modelle, auf die im Quellcode verwiesen wird, Agent-Frameworks in Repositories, MCP-Server-Konfigurationen, Prompts, Datensätze und deklarierte Abhängigkeiten. Bei KI-Komponenten, die committet, geprüft und versioniert werden, ist dieser Einblick wertvoll.

Dieser Einblick schafft eine Ausgangsbasis. Er ermöglicht Sicherheitsteams, von Annahmen zu Fakten überzugehen und die KI-Nutzung mit Zuversicht zu steuern. Innerhalb der Versionsverwaltung bietet die AI-BOM einen klaren Überblick darüber, was vorhanden ist und wie die Komponenten miteinander verbunden sind. Die Einschränkung betrifft alles, was nie ins Repository gelangt.

Eine AI-BOM erkennt weder lokale MCP-Toolchains auf Entwicklerrechnern noch für Tests verwendete KI-Agent-Runtimes, auf Endgeräten installierte LLM-Clients oder CLI-Tools und agentische Frameworks, mit denen Entwickler lokal experimentieren. Viele dieser Tools schaffen es überhaupt nicht in GitHub.

Dadurch entsteht ein blinder Fleck. Einblick auf Repository-Basis zeigt die Absicht, aber nicht alles, was während der Entwicklung tatsächlich ausgeführt wird. Sobald KI-Tools über CI/CD und die Abdeckung herkömmlicher Scans hinaus auf Laptops eingesetzt werden, entziehen sie sich dem Blick der AIBOM – obwohl diese Komponenten oft Zugriff auf sensible Daten und interne Systeme haben.

Eine AIBOM allein löst das Problem nicht. Sie ist ein notwendiger Ausgangspunkt, erzählt aber nur einen Teil der Geschichte. Wenn KI-Tools außerhalb des Repositorys eingesetzt werden, gilt das auch für einen erheblichen Teil des Risikos.

Die Lösung: AI-BOM und Einblick in Entwickler-Desktops vereinen

Um die Lücke zwischen Repositories und Entwicklerrechnern zu schließen, braucht es keine zusätzlichen Hürden. Erforderlich ist ein anderes Modell für Transparenz. Statt umfangreiche Endgeräte-Agents hinzuzufügen oder neue Workflows vorzuschreiben, konzentriert sich der entstehende Ansatz darauf, vorhandene Informationen aus verschiedenen Umgebungen miteinander zu verknüpfen.

Die AIBOM-Erkennung auf Repository-Basis erfüllt weiterhin ihre Kernaufgabe: Sie identifiziert Modelle, Agent-Frameworks, Prompts, Datensätze und Konfigurationen in der Versionsverwaltung. Ergänzend machen leichtgewichtige Scans auf Entwicklerrechnern lokale MCP-Server, Agent-Runtimes und KI-Tools sichtbar, während sie tatsächlich verwendet werden. Diese gezielten Scans haben einen eng begrenzten Umfang und sind keine herkömmliche Endgeräteüberwachung. Zusammen schaffen sie ein zusammenhängendes Bild der KI-Supply-Chain, wie sie in der Praxis besteht.

Dieser einheitliche Überblick entspricht den Anforderungen der Kunden. Einige möchten dieselben MCP-Frameworks in Repositories und lokalen Umgebungen nachverfolgen. Andere wünschen sich eine zentrale Anlaufstelle für eine einfache Frage: Welche KI-Komponenten werden irgendwo im Unternehmen eingesetzt? Viele möchten Leitplanken, die eine sichere Nutzung ermöglichen, ohne Tools zu verbieten oder Entwickler-Workflows zu stören.

Die Stärke dieses Ansatzes liegt darin, dass Transparenz zur Kontrolle wird. Wenn Teams erkennen können, welche Komponenten vorhanden sind, wie sie miteinander verbunden sind und wo sie ausgeführt werden, wird Governance praktikabel. Richtlinien können sich auf genehmigte Tools, sichere Konfigurationen und einheitliche Versionen konzentrieren – statt auf Einschränkungen, die Entwickler umgehen.

AI Security Posture Management bietet die verbindende Ebene. Es vereint Erkenntnisse aus Repositories, Abhängigkeitsbeziehungen, die Erkennung lokaler MCP-Server und Agents sowie Governance-Richtlinien in einer zentralen Ansicht. Das Ergebnis ist keine strengere Kontrolle durch Zwang, sondern bessere Kontrolle durch Verständnis. So können Unternehmen KI verantwortungsvoll steuern, während sie sich weiterentwickelt.

Das gemeinsame Wertversprechen: Der einzige vollständige Überblick über Ihre KI-Supply-Chain

Wenn sich die Transparenz sowohl auf Repositories als auch auf Entwicklerrechner erstreckt, wird die KI-Supply-Chain endlich sichtbar. Der Code allein erzählt nie die ganze Geschichte. Lokales Experimentieren allein lässt außer Acht, wie Systeme formalisiert und ausgeliefert werden. Zusammen ergeben beide Perspektiven ein vollständiges Bild davon, wie KI im gesamten Unternehmen tatsächlich entwickelt, getestet und eingesetzt wird.

Die meisten Security-Tools erfassen nur eine Seite des Gesamtbilds. Einige konzentrieren sich auf das, was in die Versionsverwaltung eingecheckt wird. Andere betrachten isolierte Laufzeitsignale oder Aktivitäten auf Endgeräten. AI Security Posture Management verbindet diese Perspektiven. Es erkennt, was im Code vorhanden ist und was auf Entwickler-Desktops läuft, und führt beide Informationen in einem einheitlichen, schlüssigen Modell zusammen. Erst dieser kombinierte Blick macht aus fragmentierten Signalen umsetzbare Erkenntnisse.

Das ist wichtig, denn Einschränkungen haben sich als unwirksame Kontrolle erwiesen. Ein Verbot von MCP-Servern verhindert nicht deren Nutzung. Ein Verbot lokaler Agents drängt Experimente lediglich weiter aus dem Blickfeld. Entwickler werden weiterhin Tools einsetzen, mit denen sie schneller arbeiten können. Der Unterschied zwischen unkontrolliertem Risiko und kontrollierter Einführung ist Transparenz. Wenn Teams sehen, welche KI-Komponenten verwendet werden, wo sie laufen und wie sie interagieren, können sie das Verhalten mithilfe von Richtlinien und Konfigurationen lenken, statt es zu verbieten.

Um diesem Wandel voraus zu sein, müssen Sie neue Trends kontinuierlich im Blick behalten. Das KI-Ökosystem steht nicht still. Regelmäßig kommen neue Agent-Frameworks hinzu. MCP-Server entwickeln sich weiter. Open-Source-Modelle verändern sich. Orchestrierungs-Tools, Datensatz-Lader und Automatisierungsbibliotheken vergrößern jeden Monat die Angriffsfläche. Kunden verlassen sich darauf, dass Snyk diese Entwicklungen verfolgt und in Erkennungen und Kontext übersetzt, auf deren Grundlage sie handeln können.

Abgerundet wird das Gesamtbild durch die Erkenntnis, was offengelegt ist, wenn Repositories und Entwicklungsendgeräte erfasst werden. Snyk Code schließt den Kreis, indem es zeigt, wie diese Risiken entstanden sind. Unternehmen müssen außerdem SAST-Lösungen nutzen, um Erkenntnisse zu Laufzeit und Assets den anfälligen Codepfaden zuzuordnen, die sie verursacht haben. So können Teams von fragmentierter Erkennung zu koordinierter Behebung übergehen. Code-Korrekturen senken dann automatisch nachgelagerte Risiken auf Endgeräten und in Repository-Umgebungen, die mit KI-gestützten Systemen verbunden sind.

Diese Forschungsgrundlage sorgt dafür, dass der Überblick langfristig vollständig bleibt. Mit dem Wachstum und Wandel der KI-Supply-Chain wird es ebenso wichtig, neue Komponenten zu erkennen und ihre Rolle zu verstehen, wie das Vorhandene zu erfassen. So entsteht ein dynamisches Verständnis von KI-Risiken, das mit der tatsächlichen Entwicklungspraxis Schritt hält.

AIBOM + Einblick in Entwickler-Desktops = die neue Grundlage für KI-Sicherheit

Wenn sich die Transparenz sowohl auf Repositories als auch auf Entwicklerrechner erstreckt, wird die KI-Supply-Chain endlich verständlich. Der Code zeigt, was Teams ausliefern möchten. Entwicklerumgebungen machen sichtbar, wie KI erkundet, getestet und eingesetzt wird. Zusammen liefern sie den Kontext, den Sicherheitsteams brauchen, um von reaktiven Vermutungen zu fundierter Governance überzugehen.

Das ist wichtig, denn Einschränkungen lassen sich nicht skalieren. MCP-Server oder lokale Agents zu blockieren, drängt Experimente lediglich aus dem Blickfeld. Entwickler werden weiterhin Tools einsetzen, mit denen sie schneller arbeiten können. Transparenz trennt unkontrollierte Risiken von einer kontrollierten Einführung. Wenn Teams sehen, welche KI-Komponenten verwendet werden, wo sie laufen und wie sie interagieren, können sie das Verhalten mithilfe von Richtlinien und Konfigurationen lenken, statt Arbeitsabläufe zu stören.

Ein präziser Überblick erfordert ein kontinuierliches Bewusstsein für Veränderungen. Das KI-Ökosystem entwickelt sich rasant weiter. Neue Agent-Frameworks, MCP-Server, Modelle und Tools kommen ständig hinzu. Komponenten erkennen und ihre Rolle verstehen zu können, macht Transparenz zu einer dauerhaft tragfähigen Sicherheitsstrategie.

Die KI-Supply-Chain entwickelt sich schneller weiter, als herkömmliche Sicherheitsmodelle Schritt halten können. Entdecken Sie, wie kontinuierliche Transparenz Ihnen hilft, ohne zusätzliche Hürden vorauszubleiben.