In this article
Von SBOM zu AI-BOM: Mehr Transparenz in KI-nativen Systemen
Jahrelang diente die Software Bill of Materials als verlässliche Grundlage für Governance. Sie ermöglichte Teams, zu verstehen, welche Komponenten in eine Anwendung eingeflossen waren, Risiken zu bewerten und wachsenden Compliance-Anforderungen gerecht zu werden. Doch während sich die Softwareentwicklung zunehmend auf KI-native Systeme ausrichtet, beginnt dieses Fundament zu bröckeln.
Hier kommt die AI Bill of Materials ins Spiel. Eine AI-BOM erfasst die KI-nativen Komponenten, die moderne Anwendungen inzwischen prägen – über Repositories, Pipelines und laufende Systeme hinweg. Modelle, Agents, Prompts, Datensätze und unterstützende Services werden Teil des Gesamtbilds. Während die SBOM die Software-Governance verankert, entwickelt sich die AI-BOM zum Rückgrat der KI-nativen Sicherheit.
Dieser Leitfaden untersucht, warum SBOM-Denken in einem KI-getriebenen Ökosystem nicht mehr ausreicht, in dem sich Komponenten häufig ändern und das Verhalten zur Laufzeit statt während des Build-Prozesses geprägt wird. Er erläutert, warum Unternehmen die AI-BOM als grundlegende Fähigkeit nutzen und warum Transparenz die erste und dringendste Voraussetzung ist. In einer Welt mit schnell wechselnden Tools und allgegenwärtiger Shadow AI ist es der erste Schritt für alles Weitere, zu verstehen, was vorhanden ist.
Warum SBOM-Denken im KI-Zeitalter versagt
Um zu verstehen, warum die AI-BOM unverzichtbar geworden ist, sollten wir zunächst betrachten, was nicht mehr funktioniert. Die Annahmen, auf denen SBOMs basierten, stammten aus einer Softwarewelt mit einer begrenzten Zahl von Komponenten, bekannten Abhängigkeiten und einem überschaubaren Tempo für Veränderungen. KI-native Systeme sind ganz anderen Bedingungen ausgesetzt. Bevor wir untersuchen, wie Unternehmen sich anpassen, lohnt sich ein Blick darauf, warum die vertrauten Annahmen aus der SBOM-Ära im KI-Zeitalter nicht mehr gelten.
KI-Komponenten ändern sich ständig
KI-native Systeme sind von ständigem Wandel geprägt. Die Komponenten, auf denen sie beruhen, bleiben nicht lange genug unverändert, um sie wie herkömmliche Abhängigkeiten zu behandeln. Diese Volatilität ist inzwischen die Regel und nicht mehr die Ausnahme.
Modelle werden wöchentlich, manchmal sogar häufiger, aktualisiert, wenn neue Funktionen und Optimierungen veröffentlicht werden. Agent-Frameworks entwickeln sich ebenso schnell weiter: Neue Abstraktionen, Tools und Ausführungsmuster tauchen in öffentlichen Repositories auf. MCP-Server werden eingerichtet, um neue Tools oder Workflows bereitzustellen – oft als Reaktion auf unmittelbare Entwicklungsanforderungen statt auf langfristige Pläne. Prompts, die zunehmend wie ausführbare Logik wirken, werden laufend bearbeitet und verfeinert. Datensätze verändern sich, wenn Daten hinzugefügt, gefiltert oder ersetzt werden. Dadurch ändert sich das Modellverhalten, ohne dass der umgebende Code angepasst wird.
Diese Komponenten sind nicht wie Bibliotheken an bestimmte Versionen gebunden. Sie befinden sich nicht in einem zentralen Repository. Und einzelne Entwickler können sie ohne großen Aufwand einführen. Sie wie statische Abhängigkeiten zu behandeln, führt fast unmittelbar zu blinden Flecken.
In einer KI-nativen Umgebung muss Governance mit Komponenten umgehen können, die sich laufend verändern, dezentral verteilt sind und ständig in Bewegung bleiben.
Das Kernproblem ist mangelnde Transparenz
Für die meisten Sicherheitsverantwortlichen besteht die Herausforderung nicht darin, jede Entscheidung zu verstehen, die ein KI-System treffen könnte. CISOs versuchen nicht, das Verhalten von Agents bis hin zu einzelnen Prompts oder Ausgaben nachzuvollziehen. Was sie zuerst brauchen, ist etwas viel Grundlegenderes: einen Überblick darüber, was vorhanden ist.
Sie möchten wissen, welche Agents, Modelle und MCP-Server im gesamten Unternehmen tatsächlich eingesetzt werden. Sie möchten verstehen, welche Tools oder Workflows diese Komponenten bereitstellen und auf welche externen Systeme sie zugreifen können. Sie benötigen Einblick in die Datensätze und Prompts, die das Verhalten prägen, denn diese Eingaben sind oft ebenso wichtig wie der Code selbst.
Ohne diesen Überblick lassen sich Risiken nicht bewerten, Richtlinien nicht festlegen und Vorfälle nicht wirksam bewältigen. Herkömmliche SBOMs wurden nie entwickelt, um einen solchen Einblick zu bieten. Sie erfassen statische Abhängigkeiten zu einem bestimmten Zeitpunkt, nicht die aktiven, sich weiterentwickelnden Komponenten, die KI-native Systeme prägen. Deshalb fehlt Sicherheitsteams die Transparenz, die sie für eine wirksame KI-Governance benötigen.
Was Sicherheitsverantwortliche uns berichten
Die Transparenzlücke ist längst keine Theorie mehr. Sie zeigt sich immer wieder in Gesprächen mit Sicherheitsverantwortlichen, die versuchen, bestehende Kontrollen auf eine sich ständig wandelnde KI-Landschaft anzuwenden.
Die zunehmende Zahl an Frameworks
Für viele große Unternehmen beginnt die Herausforderung mit der schieren Menge. Ein Unternehmen berichtete von einem ständigen Zustrom neuer Agent-Frameworks, Orchestrierungstools, Modellpakete und MCP-Server in seinen Entwicklungsteams. Entwickler setzten sie schnell ein, um zügiger voranzukommen. Die Governance-Teams konnten nicht Schritt halten.
Sicherheits- und Compliance-Maßnahmen wurden reaktiv. Sobald ein Framework geprüft war, war bereits ein weiteres hinzugekommen. Das Problem war nicht die Ablehnung von Innovation, sondern der fehlende Überblick darüber, was vorhanden war.
Für dieses Unternehmen wurde die AI-BOM unverzichtbar. Sie bot eine zuverlässige Möglichkeit, KI-Komponenten über Repositories hinweg zu erfassen und so die notwendige Grundlage für Governance zu schaffen, während sich das Ökosystem weiterentwickelte.
Die AI-BOM steckt noch in den Anfängen, ist aber entscheidend.
Ein anderes Unternehmen beschrieb seinen Ansatz zurückhaltender, aber ebenso dringlich. Die AI-BOM stecke noch in den Anfängen, räumte das Unternehmen ein. Standards seien im Entstehen. Bewährte Vorgehensweisen stünden noch nicht fest. Trotzdem sei die AI-BOM unvermeidlich.
KI-Komponenten haben den Schritt von experimentellen Tools zu wesentlichen Abhängigkeiten vollzogen. Modelle, Agents und unterstützende Services bestimmen inzwischen unmittelbar, wie sich Anwendungen verhalten und wie Daten verarbeitet werden. Gleichzeitig beginnen Aufsichtsbehörden, Erwartungen an Transparenz, Herkunftsnachweise und Verantwortlichkeit in KI-Lieferketten zu formulieren.
Auf perfekte Leitlinien zu warten, erscheint nicht länger als praktikable Option. Für dieses Unternehmen geht es bei der Einführung einer AI-BOM weniger um den Reifegrad als um Bereitschaft. Wer jetzt für Transparenz sorgt, schafft eine Grundlage, auf der sich bei sich ändernden Anforderungen aufbauen lässt – statt erst aufzuholen, sobald die Erwartungen verbindlich festgelegt sind.
Wir erwarten, dass unsere Tools Neues erfassen.
Ein drittes Thema kommt in diesen Gesprächen ebenso regelmäßig zur Sprache: Unternehmen erwarten nicht mehr, das KI-Ökosystem selbst im Blick zu behalten. Sicherheitsteams wissen, wie schnell neue Agent-Frameworks, MCP-Server, Modellpakete, Prompts und Datensätze auftauchen. Bis ein manueller Prüfprozess festgelegt ist, hat sich die Landschaft bereits verändert. Ein verlässliches Inventar allein mit menschlichem Aufwand aktuell zu halten, ist nicht mehr realistisch.
Deshalb erwarten Unternehmen, dass Snyk diese Transparenz für sie sicherstellt. Sie verlassen sich auf die automatisierte Erkennung neuer Komponenten, sobald diese auftauchen. So bleibt der Überblick aktuell, ohne dass ständig eingegriffen werden muss. In einem Ökosystem, das sich so schnell weiterentwickelt, ist Automatisierung kein bloßer Komfort – nur so kann Transparenz Schritt halten.
Die neue KI-Angriffsfläche: Erst Transparenz, dann alles Weitere
Sobald Unternehmen erkennen, wie schnell sich KI-Komponenten verbreiten und wie begrenzt die Möglichkeiten zur manuellen Erfassung sind, verlagert sich der Fokus von der Tool-Auswahl auf die Angriffsfläche.
Die explosionsartige Zunahme von Shadow AI
Mit der zunehmenden Einführung von KI ist eine neue Art von Sicherheitsrisiko entstanden. Shadow AI geht weit über vereinzelte Experimente oder einzelne Tools hinaus. Sie umfasst inzwischen eine wachsende Zahl von Komponenten, die unbemerkt das Verhalten von Anwendungen prägen, ohne jemals formal geprüft worden zu sein.
Nicht genehmigte Agents werden eingerichtet, um Aufgaben zu automatisieren oder Workflows zu orchestrieren. Nicht dokumentierte MCP-Server stellen neue Tools und Funktionen ohne klare Zuständigkeit bereit. Ad-hoc-Wrapper verbinden Modelle mit internen Systemen. Sie werden oft zur Lösung eines unmittelbaren Problems erstellt und bleiben dann bestehen. Verborgene LLM-Aufrufe tauchen in der Anwendungslogik auf, während Prompt-Ketten zu funktionalen Entscheidungspfaden werden, statt nur einfache Eingaben zu sein.
Für sich genommen wirken viele dieser Elemente unbedenklich. Zusammengenommen schaffen sie eine KI-Angriffsfläche, die sich nur schwer erfassen lässt und leicht übersehen wird. Shadow AI wird nicht durch Absicht oder Komplexität definiert, sondern durch Unsichtbarkeit. Wenn Komponenten außerhalb der üblichen Erkennungs- und Governance-Prozesse bestehen, schaffen sie allein deshalb Risiken, weil sie unbekannt sind.
Konkrete Transparenzlücken
Solche Lücken treten in realen Umgebungen auf. In einem Fall entdeckte ein Unternehmen bei einer routinemäßigen Demo einen aktiven MCP-Server. Das AppSec-Team wusste nichts davon. Es war nichts falsch konfiguriert. Es gab keinen Angriff. Der Server war schlicht für die Kontrollen unsichtbar, auf die sich das Team verließ. In Unternehmen zeigt sich immer wieder dasselbe Muster: KI-Komponenten, die das Verhalten maßgeblich beeinflussen, liegen außerhalb der formalen Erkennungsprozesse – nicht aus Nachlässigkeit, sondern weil die bestehenden Kontrollen nie dafür entwickelt wurden, sie zu erkennen.
Die AI-BOM: Die neue verlässliche Informationsquelle
Zusammengenommen zeigen diese Lücken, dass eine neue verlässliche Informationsquelle benötigt wird. Die AI-BOM erfüllt diese Aufgabe, indem sie in KI-nativen Umgebungen die Transparenz schafft, für die SBOMs nie entwickelt wurden.
Eine AI-BOM erfasst die Komponenten, die den Betrieb von KI-Systemen bestimmen. Sie erfasst die verwendeten Modelle, die darauf aufbauenden Agents sowie die Tools und Ketten, die diese Agents aufrufen. Sie erfasst MCP-Server und die von ihnen bereitgestellten Funktionen sowie die Prompts und Datensätze, die das Verhalten prägen. Außerdem berücksichtigt sie externe KI-APIs, die Funktionen über die Anwendungsgrenzen hinaus erweitern.
Diese Transparenz schafft die Grundlage für konkrete Maßnahmen. Governance orientiert sich an der Realität statt an Annahmen. Die Überwachung kann sich auf tatsächlich vorhandene Komponenten konzentrieren. Red-Team-Tests können reale Konfigurationen prüfen statt hypothetische Workflows. So wird die AI-BOM vom Inventar zum operativen Rückgrat.
Warum AI-BOM ≠ SBOM
Auch wenn der Begriff vertraut klingt, unterscheidet sich eine AI-BOM grundlegend von einer herkömmlichen SBOM. SBOMs wurden für Softwaresysteme mit stabilen Komponenten, vorhersehbaren Updates und klaren Abhängigkeitsstrukturen entwickelt. Für KI-native Systeme gelten andere Bedingungen.
SBOM | AI-BOM |
|---|---|
Langsame, vorhersehbare Updates | Ständige, unvorhersehbare Veränderungen |
Bibliotheken und Pakete | Modelle, Agents, Prompts, Datensätze, MCPs |
Nachvollziehbare Herkunft | Entstehende, undurchsichtige Herkunft |
Mittlerer Erkennungsaufwand | Hoher Erkennungsaufwand |
Diese Unterschiede haben praktische Folgen für Governance, Überwachung und Sicherheitsmanagement.
Warum Automatisierung unverzichtbar ist – und warum Snyk führend ist
Umfang und Geschwindigkeit des Wandels im KI-Ökosystem machen eines deutlich: Manuelle Erfassung kann nicht Schritt halten. In diesem Umfang stößt die menschliche Prüfung an ihre Grenzen. Bis eine neue Komponente erkannt wird, kann sie bereits in mehreren Teams oder Workflows im Einsatz sein
Hier wird Automatisierung unverzichtbar. Kontinuierliche Erkennung und Klassifizierung sind die einzig praktikablen Möglichkeiten, den Überblick über KI-Komponenten aktuell zu halten, während sie auftauchen und sich verändern. Snyk ist in diesem Bereich führend: Automatisierte Erkennung wird mit laufender Forschung kombiniert, damit neue Frameworks, MCP-Server, Modellmuster und Datensätze erkannt werden, sobald sie auftauchen.
Der Forschungsvorsprung von Snyk
Automatisierung allein reicht nicht aus – sie braucht Erkenntnisse, die sie steuern. Zu wissen, was gescannt werden muss, ist genauso wichtig wie kontinuierliches Scannen.
Das spezialisierte KI-Lieferketten-Forschungsteam von Snyk untersucht in Echtzeit, wie sich das Ökosystem weiterentwickelt. Es verfolgt neue Agent-Frameworks, sobald sie auftauchen, analysiert neue MCP-Muster und Nutzungsmodelle und untersucht neu entdeckte KI-Angriffsvektoren in der Praxis. Das Team beobachtet außerdem, wie schnell Modellfamilien und Datensatztypen wachsen, und erkennt, wie dadurch neue Abhängigkeiten und Risiken entstehen.
Diese Forschung sorgt dafür, dass die AI-BOM aktuell bleibt. Kunden müssen nicht selbst jede neue Version, jedes Framework und jedes Muster überwachen. Snyk übernimmt diese Arbeit für sie und übersetzt Veränderungen im Ökosystem in Erkennung und Kontext, auf die sie sich verlassen können. Das ist der zentrale Mehrwert einer forschungsbasierten AI-BOM: Transparenz, die sich ebenso schnell weiterentwickelt wie die KI-Lieferkette selbst.
AI-BOMs als Grundlage für KI-Governance und AI-SPM
Wenn KI-Systeme aus der Experimentierphase in zentrale Geschäftsprozesse übergehen, wird eine zuverlässige Grundlage unverzichtbar. So wie sich SBOMs von einer bewährten Praxis zu einer Voraussetzung für die Software-Governance entwickelt haben, schlagen AI-BOMs in KI-nativen Umgebungen einen ähnlichen Weg ein.
Sie schaffen die nötige Transparenz, um Governance-Entscheidungen zu unterstützen, Daten zu schützen, Red-Teaming-Maßnahmen zu steuern, die Aktivitäten von Agenten zu überwachen und sich auf regulatorische Prüfungen vorzubereiten. Die Signale der Aufsichtsbehörden weisen bereits in diese Richtung.
Doch Transparenz allein reicht nicht aus. Mit dem Wachstum von KI-Umgebungen müssen Unternehmen die Sicherheitslage von Hunderten Modellen, Agenten, Datensätzen und Konnektoren kontinuierlich verstehen können – nicht als statische Inventare, sondern als dynamische Systeme, die sich täglich verändern. Hier werden AI-BOMs zu einer grundlegenden Informationsquelle für das AI Security Posture Management (AI-SPM).
KI-Lieferketten entwickeln sich zu schnell für das Denken im SBOM-Zeitalter. Shadow AI breitet sich weiter aus. Die Aufsicht nimmt zu. In diesem Umfeld wird die AI-BOM zur unverzichtbaren Informationsquelle für KI-native Systeme.
Wenn SBOMs das vergangene Jahrzehnt der Softwaresicherheit geprägt haben, werden AI-BOMs das nächste prägen. Snyk entwickelt die forschungsbasierte Grundlage, mit der sich AI-BOMs zu umfassendem AI-SPM weiterentwickeln lassen – und rohe Bestandsdaten in kontinuierliche, umsetzbare Sicherheitserkenntnisse verwandeln.
Entdecken Sie, wie Snyk Evo die Transparenz durch AI-BOMs verbessert, die inneren Abläufe von KI-Systemen offenlegt und den Grundstein für einen neuen Ansatz zur Bewertung der KI-Sicherheitslage legt. Erfahren Sie, wie forschungsbasierte KI-Sicherheit in der Praxis aussieht.
SPICKZETTEL
KI-Risiken mit Evo AI-SPM unter Kontrolle
Erfahren Sie, wie Evo AI-SPM Sie dabei unterstützt, Ihre Agents zu schützen, den Überblick über die zunehmende KI-Verbreitung zu behalten und KI souverän zu steuern.