{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/de/autor/alexander-bock/"},"categories":["AI Security"],"content":{"markdown":"Kaum ein Team baut ein KI-System von Grund auf. Es nimmt ein Modell von einem Anbieter oder aus einem Modell-Hub, ein Embedding-Modell, eine Vektordatenbank, Python-Pakete, Datensätze für das Fine-Tuning und Plugins, die einem Agenten seine Werkzeuge geben. Jedes dieser Teile stammt von jemand anderem, und jedes kann ein Risiko in Ihr System bringen. Zusammen bilden sie die **KI-Lieferkette** (AI Supply Chain). Sie abzusichern heißt: jedes Teil kennen, wissen, woher es kommt, und beurteilen, ob Sie ihm trauen können.\n\nDies ist Teil 4 von Level 3 (Profi) im Lernpfad AI Security. Sie lernen die wichtigsten Risiken der Lieferkette kennen — Modelldateien, die Code ausführen, vergiftete Daten, schädliche Plugins und Abhängigkeiten — und die Gegenmaßnahmen: sichere Formate, Signaturen, Model Cards, eine KI-Stückliste (AI-BOM) und einen Prüfprozess. Die OWASP Top 10 für LLM-Anwendungen aus Level 2 führen „Supply Chain“ und „Data and Model Poisoning“ als zwei eigene Risiken (Quelle: OWASP Top 10 for LLM Applications 2026, genai.owasp.org).\n\n## Die KI-Lieferkette im Überblick\n\nDie Karte zeigt die Teile unseres Support-Assistenten, die von außen kommen. In der linken Spalte tritt das Risiko ein; die mittlere Spalte ist Ihre Chance, es aufzuhalten.\n\n![Karte der Lieferkette: links Modell-Hubs, Datensätze, Pakete, Plugins und Modell-APIs mit ihrem typischen Risiko; in der Mitte ein Tor zum Prüfen und Freigeben mit Register und AI-BOM; rechts die KI-App mit Sprachmodell, Embedding-Modell, Vektordatenbank, Agenten-Tools und Prompts](/images/learn/de/ai-supply-chain-security-map.webp \"Die KI-Lieferkette des Beispiel-Assistenten: Jedes Teil von außen passiert dasselbe Tor, bevor es in die App gelangt.\")\n\nAus der Karte folgen zwei Regeln:\n\n- **Wissen, was läuft.** Führen Sie eine Liste aller Modelle, Datensätze, Pakete und Plugins, mit Version und Herkunft.\n- **Nichts geht ungeprüft in den Betrieb.** Neue Teile und neue Versionen alter Teile passieren dasselbe Tor.\n\n## Modelldateien, die Code ausführen\n\nDie Gewichte eines Modells sind nur Zahlen, doch das Dateiformat drumherum ist nicht immer harmlos. Viele ältere Modelldateien nutzen das **Pickle**-Format von Python. Pickle kann Anweisungen speichern, die beim Laden der Datei ausgeführt werden. Eine manipulierte Modelldatei zu laden kann also heißen, den Code eines Angreifers auf Ihrem Rechner auszuführen.\n\nDas ist keine Theorie. Im Februar 2024 berichtete das Sicherheitsunternehmen JFrog, es habe auf der Plattform Hugging Face rund 100 Modelle mit schädlichem Code gefunden, der beim Laden lief (Quelle: JFrog Security Research, 2024, jfrog.com). Vier Gegenmaßnahmen helfen:\n\n- **Sichere Formate bevorzugen.** Das Format **safetensors**, entwickelt von Hugging Face, speichert nur die Zahlen und kann keinen Code ausführen. Seit Version 2.6 (Januar 2025) lädt die Funktion `torch.load` von PyTorch standardmäßig in einem eingeschränkten Modus: Sie lädt Gewichte und einfache Datentypen, aber keine beliebigen Objekte (Quelle: Release Notes zu PyTorch 2.6, pytorch.org).\n- **Fremden Code nicht blind ausführen.** Manche Modelle bringen eigenen Python-Code mit, und Ladeoptionen wie `trust_remote_code` in der Bibliothek Hugging Face Transformers führen ihn aus. Nutzen Sie sie erst, wenn Sie den Code geprüft haben.\n- **Neue Dateien isoliert laden.** Öffnen Sie nicht vertrauenswürdige Modelldateien in einer Sandbox ohne Geheimnisse und ohne Netzwerkzugang, wie in [Teil 2 dieses Levels](/de/ai-security/learn/secure-rag-and-ai-agents/) beschrieben.\n- **Versionen genau festlegen.** Verweisen Sie auf ein Modell über eine feste Revision oder einen Datei-Hash, nicht über „latest“. Ein Repository auf einem Modell-Hub kann sich ändern, nachdem Sie es geprüft haben.\n\n## Vergiftete Daten und versteckte Hintertüren\n\n**Data Poisoning** (Datenvergiftung) heißt, Trainings- oder Fine-Tuning-Daten so zu manipulieren, dass das Modell etwas lernt, das es nicht lernen soll: falsche Fakten, eine Verzerrung oder eine versteckte **Hintertür** (Backdoor). Eine Hintertür ist ein Verhalten, das nur auftritt, wenn eine bestimmte Auslöserphrase vorkommt. In allen anderen Tests verhält sich das Modell normal — deshalb sind Hintertüren schwer zu finden.\n\nFür eine Vergiftung braucht es weniger Daten, als viele annehmen. Die OWASP-Liste zitiert dazu eine Studie von 2025, wie Teil 1 von Level 2 erwähnt hat. Darin trainierten Anthropic, das britische AI Security Institute und das Alan Turing Institute Modelle mit 600 Millionen bis 13 Milliarden Parametern. Bei jeder Größe genügten 250 vergiftete Dokumente, um eine einfache Hintertür einzubauen — obwohl die größeren Modelle weit mehr saubere Trainingsdaten sahen (Quelle: Anthropic, „A small number of samples can poison LLMs of any size“, 2025, anthropic.com). Die Hintertür in dieser Studie war harmlos — sie brachte das Modell dazu, Kauderwelsch zu schreiben —, zeigt aber, dass Größe allein ein Modell nicht schützt.\n\nIn Ihrem eigenen System hat Vergiftung drei Einfallstore: das Basismodell, das Sie herunterladen, die Daten für das Fine-Tuning und die Dokumente in Ihrer RAG-Wissensbasis. Gegenmaßnahmen:\n\n- Kennen Sie die Herkunft jedes Datensatzes: wer ihn erstellt hat, wann und wie die Daten gesammelt wurden. **Datasheets for Datasets**, ein von Forschenden vorgeschlagenes Dokumentationsformat, beschreiben genau das.\n- Begrenzen Sie, wer Trainingsdaten und Wissensquellen ändern darf, und protokollieren Sie jede Änderung.\n- Filtern Sie Daten, entfernen Sie Dubletten und prüfen Sie Stichproben von Hand.\n- Testen Sie das Modell vor und nach dem Fine-Tuning mit demselben Evaluationsdatensatz und vergleichen Sie die Ergebnisse.\n\nLevel 4 behandelt Vergiftung und verwandte Angriffe ausführlich im Teil über [Adversarial Machine Learning](/de/ai-security/learn/adversarial-machine-learning/).\n\n## Plugins, Tools und Abhängigkeiten\n\nAgenten bekommen ihre Fähigkeiten über Plugins und Tools, heute oft über das **Model Context Protocol** (MCP), einen offenen Standard, der Tools und Datenquellen mit KI-Assistenten verbindet. Ein Plugin läuft mit den Rechten, die Sie ihm geben, und seine Tool-Beschreibungen landen direkt im Kontext des Modells. Ein schädliches oder kompromittiertes Plugin kann deshalb Daten stehlen, Anweisungen in seinen Beschreibungen verstecken oder sein Verhalten mit einem Update ändern.\n\nAuch klassische Software-Abhängigkeiten zählen. Python-Pakete, deren Namen bekannten Paketen ähneln — man spricht von **Typosquatting** —, können Schadsoftware enthalten. KI-Programmierassistenten schlagen manchmal Pakete vor, die es gar nicht gibt, und Angreifer können solche Namen registrieren. Level 1 erklärt dieses Risiko im Teil über [Halluzinationen als Sicherheitsrisiko](/de/ai-security/learn/hallucinations-as-a-security-risk/). Gegenmaßnahmen:\n\n- Führen Sie eine Positivliste freigegebener Plugins und MCP-Server und installieren Sie nichts aus unbekannten Quellen.\n- Prüfen Sie, welche Rechte jedes Plugin verlangt, und gewähren Sie nur das Nötigste.\n- Legen Sie Versionen fest und prüfen Sie Updates, bevor Sie sie ausrollen.\n- Nutzen Sie Lock-Dateien mit Hashes für Pakete sowie **Software Composition Analysis** (SCA), eine Art von Tool, das Abhängigkeiten auf bekannte Schwachstellen prüft.\n\n## Herkunftsnachweise: Model Cards, Signaturen und AI-BOMs\n\nVier Arten von Nachweisen sagen Ihnen, was Sie betreiben:\n\n| Nachweis | Was er enthält | Welche Frage er beantwortet |\n|---|---|---|\n| Model Card | Zweck, Trainingsdaten, Evaluationen und Grenzen eines Modells | Passt dieses Modell zu meinem Einsatz? |\n| Datasheet eines Datensatzes | Herkunft, Erhebungsmethode und Inhalt eines Datensatzes | Woher stammen diese Daten? |\n| Hash oder Signatur | Ein kryptografischer Fingerabdruck der Dateien | Sind das genau die Dateien, die der Herausgeber veröffentlicht hat? |\n| SBOM oder AI-BOM | Eine Bestandsliste aller Komponenten mit Versionen und Herkunft | Was genau steckt in meinem System? |\n\nModel Cards wurden 2019 von Forschenden bei Google vorgeschlagen (Quelle: Mitchell et al., „Model Cards for Model Reporting“, 2019). Für Signaturen hat eine Arbeitsgruppe der Open Source Security Foundation (OpenSSF) 2025 Version 1.0 einer Bibliothek zum Signieren von Modellen veröffentlicht. Sie kann Modelldateien mit dem Projekt Sigstore signieren und die Signatur prüfen, bevor ein Modell geladen wird (Quelle: Sigstore-Blog, „Taming the Wild West of ML: Practical Model Signing with Sigstore“, 2025, blog.sigstore.dev). Eine **Software-Stückliste** (Software Bill of Materials, SBOM) führt alle Bestandteile einer Software auf; eine **AI-BOM** erweitert sie um Modelle und Datensätze. Beide verbreiteten SBOM-Standards decken inzwischen KI ab: CycloneDX mit seiner Machine-Learning-BOM und SPDX 3.0 mit seinen Profilen für KI und Datensätze.\n\n{{\u003c callout type=\"try\" title=\"Eine AI-BOM in einer Stunde beginnen\" \u003e}}\nWählen Sie eine KI-Funktion und listen Sie alles auf, was sie von außen nutzt: Modelle (Name, Version oder Hash, Herkunft, Lizenz), Datensätze, Pakete (übernehmen Sie sie aus der Lock-Datei), Plugins und MCP-Server (Herausgeber, Rechte) sowie Modell-APIs (Anbieter, Modellversion). Tragen Sie zu jeder Zeile eine verantwortliche Person ein. Für den Anfang genügt eine einfache Tabelle neben dem Code; aktualisieren Sie sie mit jedem Release.\n{{\u003c /callout \u003e}}\n\n## Modelle mit offenen Gewichten: der größte Download\n\nViele Teams betreiben **Open-Weight-Modelle** — Modelle, deren Gewichte jeder herunterladen kann — auf eigenen Servern oder in einer GPU-Cloud. Unsere [LLM-Datenbank](/de/llm/) führt {{\u003c stat \"models-open\" \u003e}} Modelle mit offenen Gewichten, von insgesamt {{\u003c stat \"models\" \u003e}} Modellen. Das Diagramm zeigt, wann sie erschienen sind:\n\n![Balkendiagramm der Modelle in unserer LLM-Datenbank nach Erscheinungsjahr, offene und geschlossene Gewichte nebeneinander; Modelle mit offenen Gewichten machen in den letzten Jahren einen großen Anteil aus](/images/learn/de/ai-supply-chain-security-open-weights.webp \"Modelle in unserer LLM-Datenbank nach Erscheinungsjahr und Art der Gewichte. Das laufende Jahr ist nicht vollständig. Daten: Epoch AI, CC BY 4.0.\")\n\nJedes dieser Modelle ist ein großer Download aus einer fremden Quelle. Hier einige Beispiele aus unserer Datenbank mit ihrem Gesamtwert für die Leistungsfähigkeit:\n\n{{\u003c llm-models \"kimi-k3 deepseek-v4-1-flash qwen-3-8-27b glm-5-3-flash llama-3-70b\" \u003e}}\n\nOffene Gewichte sind an sich nicht unsicher. Mit einem Download wird die Prüfung der Lieferkette aber zu Ihrer Aufgabe. Bei einer API verwaltet der Anbieter die Modelldateien, und Ihre Prüfungen verlagern sich auf Vertrag, Datenbedingungen und Versionswechsel. Wenn Sie Modelle selbst betreiben — zum Beispiel in einer GPU-Cloud wie Runpod —, wenden Sie die Prüfliste unten auf jedes Modell und jedes Update an. Plattformen wie Airia helfen Unternehmen nach Angaben des Anbieters, die genutzten Modelle, Agenten und Tools abzusichern und zu steuern. Wir haben keines der beiden Tools getestet.\n\n{{\u003c tools \"runpod airia\" \u003e}}\n\n## Prüfliste für KI-Komponenten\n\nDie Treppe zeigt die Reihenfolge der Prüfungen für ein heruntergeladenes Modell; die Tabelle deckt alle Arten von Komponenten ab.\n\n![Sechs Stufen, die Vertrauen in ein heruntergeladenes Modell aufbauen: Herkunft prüfen, Lizenz klären, sicheres Format nutzen, Dateien scannen, Hash oder Signatur prüfen, testen und eintragen](/images/learn/de/ai-supply-chain-security-vetting.webp \"Von „im Netz gefunden“ zu „freigegeben“: sechs Prüfungen, bevor ein Modell in den Betrieb geht.\")\n\n| Komponente | Vor der Nutzung prüfen | Nachweis, den Sie aufbewahren |\n|---|---|---|\n| Modellgewichte | Bekannter Herausgeber, Lizenz, Format safetensors, Scan, Hash oder Signatur | Model Card, Hash, Scan-Ergebnis |\n| Modell-API | Vertrag und Datenbedingungen, festgelegte Modellversion, Ankündigung von Änderungen | Vertrag, Modellversion in den Logs |\n| Datensätze | Herkunft, Lizenz, personenbezogene Daten, Prüfung auf Vergiftung | Datasheet, Stichprobenprüfung |\n| Pakete | Exakte Namen, festgelegte Versionen mit Hashes, bekannte Schwachstellen | Lock-Datei, SCA-Bericht |\n| Plugins und MCP-Server | Herausgeber, Rechte, festgelegte Version, Prüfung von Updates | Eintrag in der Positivliste, Rechteprüfung |\n| Quellen der Wissensbasis | Wer schreiben darf, Prüfung neuer Quellen | Quellenliste, Änderungsprotokoll |\n\nJede freigegebene Komponente kommt mit Version, Herkunft und verantwortlicher Person in Ihre AI-BOM. Wird eine neue Schwachstelle oder ein schädliches Paket bekannt, beantwortet diese Liste innerhalb von Minuten die erste Frage der [Incident Response für KI](/de/ai-security/learn/ai-incident-response/): Sind wir betroffen?","text":"Kaum ein Team baut ein KI-System von Grund auf. Es nimmt ein Modell von einem Anbieter oder aus einem Modell-Hub, ein Embedding-Modell, eine Vektordatenbank, Python-Pakete, Datensätze für das Fine-Tuning und Plugins, die einem Agenten seine Werkzeuge geben. Jedes dieser Teile stammt von jemand anderem, und jedes kann ein Risiko in Ihr System bringen. Zusammen bilden sie die KI-Lieferkette (AI Supply Chain). Sie abzusichern heißt: jedes Teil kennen, wissen, woher es kommt, und beurteilen, ob Sie ihm trauen können.\nDies ist Teil 4 von Level 3 (Profi) im Lernpfad AI Security. Sie lernen die wichtigsten Risiken der Lieferkette kennen — Modelldateien, die Code ausführen, vergiftete Daten, schädliche Plugins und Abhängigkeiten — und die Gegenmaßnahmen: sichere Formate, Signaturen, Model Cards, eine KI-Stückliste (AI-BOM) und einen Prüfprozess. Die OWASP Top 10 für LLM-Anwendungen aus Level 2 führen „Supply Chain“ und „Data and Model Poisoning“ als zwei eigene Risiken (Quelle: OWASP Top 10 for LLM Applications 2026, genai.owasp.org).\nDie KI-Lieferkette im Überblick Die Karte zeigt die Teile unseres Support-Assistenten, die von außen kommen. In der linken Spalte tritt das Risiko ein; die mittlere Spalte ist Ihre Chance, es aufzuhalten.\nDie KI-Lieferkette des Beispiel-Assistenten: Jedes Teil von außen passiert dasselbe Tor, bevor es in die App gelangt. Aus der Karte folgen zwei Regeln:\nWissen, was läuft. Führen Sie eine Liste aller Modelle, Datensätze, Pakete und Plugins, mit Version und Herkunft. Nichts geht ungeprüft in den Betrieb. Neue Teile und neue Versionen alter Teile passieren dasselbe Tor. Modelldateien, die Code ausführen Die Gewichte eines Modells sind nur Zahlen, doch das Dateiformat drumherum ist nicht immer harmlos. Viele ältere Modelldateien nutzen das Pickle-Format von Python. Pickle kann Anweisungen speichern, die beim Laden der Datei ausgeführt werden. Eine manipulierte Modelldatei zu laden kann also heißen, den Code eines Angreifers auf Ihrem Rechner auszuführen.\nDas ist keine Theorie. Im Februar 2024 berichtete das Sicherheitsunternehmen JFrog, es habe auf der Plattform Hugging Face rund 100 Modelle mit schädlichem Code gefunden, der beim Laden lief (Quelle: JFrog Security Research, 2024, jfrog.com). Vier Gegenmaßnahmen helfen:\nSichere Formate bevorzugen. Das Format safetensors, entwickelt von Hugging Face, speichert nur die Zahlen und kann keinen Code ausführen. Seit Version 2.6 (Januar 2025) lädt die Funktion torch.load von PyTorch standardmäßig in einem eingeschränkten Modus: Sie lädt Gewichte und einfache Datentypen, aber keine beliebigen Objekte (Quelle: Release Notes zu PyTorch 2.6, pytorch.org). Fremden Code nicht blind ausführen. Manche Modelle bringen eigenen Python-Code mit, und Ladeoptionen wie trust_remote_code in der Bibliothek Hugging Face Transformers führen ihn aus. Nutzen Sie sie erst, wenn Sie den Code geprüft haben. Neue Dateien isoliert laden. Öffnen Sie nicht vertrauenswürdige Modelldateien in einer Sandbox ohne Geheimnisse und ohne Netzwerkzugang, wie in Teil 2 dieses Levels beschrieben. Versionen genau festlegen. Verweisen Sie auf ein Modell über eine feste Revision oder einen Datei-Hash, nicht über „latest“. Ein Repository auf einem Modell-Hub kann sich ändern, nachdem Sie es geprüft haben. Vergiftete Daten und versteckte Hintertüren Data Poisoning (Datenvergiftung) heißt, Trainings- oder Fine-Tuning-Daten so zu manipulieren, dass das Modell etwas lernt, das es nicht lernen soll: falsche Fakten, eine Verzerrung oder eine versteckte Hintertür (Backdoor). Eine Hintertür ist ein Verhalten, das nur auftritt, wenn eine bestimmte Auslöserphrase vorkommt. In allen anderen Tests verhält sich das Modell normal — deshalb sind Hintertüren schwer zu finden.\nFür eine Vergiftung braucht es weniger Daten, als viele annehmen. Die OWASP-Liste zitiert dazu eine Studie von 2025, wie Teil 1 von Level 2 erwähnt hat. Darin trainierten Anthropic, das britische AI Security Institute und das Alan Turing Institute Modelle mit 600 Millionen bis 13 Milliarden Parametern. Bei jeder Größe genügten 250 vergiftete Dokumente, um eine einfache Hintertür einzubauen — obwohl die größeren Modelle weit mehr saubere Trainingsdaten sahen (Quelle: Anthropic, „A small number of samples can poison LLMs of any size“, 2025, anthropic.com). Die Hintertür in dieser Studie war harmlos — sie brachte das Modell dazu, Kauderwelsch zu schreiben —, zeigt aber, dass Größe allein ein Modell nicht schützt.\nIn Ihrem eigenen System hat Vergiftung drei Einfallstore: das Basismodell, das Sie herunterladen, die Daten für das Fine-Tuning und die Dokumente in Ihrer RAG-Wissensbasis. Gegenmaßnahmen:\nKennen Sie die Herkunft jedes Datensatzes: wer ihn erstellt hat, wann und wie die Daten gesammelt wurden. Datasheets for Datasets, ein von Forschenden vorgeschlagenes Dokumentationsformat, beschreiben genau das. Begrenzen Sie, wer Trainingsdaten und Wissensquellen ändern darf, und protokollieren Sie jede Änderung. Filtern Sie Daten, entfernen Sie Dubletten und prüfen Sie Stichproben von Hand. Testen Sie das Modell vor und nach dem Fine-Tuning mit demselben Evaluationsdatensatz und vergleichen Sie die Ergebnisse. Level 4 behandelt Vergiftung und verwandte Angriffe ausführlich im Teil über Adversarial Machine Learning.\nPlugins, Tools und Abhängigkeiten Agenten bekommen ihre Fähigkeiten über Plugins und Tools, heute oft über das Model Context Protocol (MCP), einen offenen Standard, der Tools und Datenquellen mit KI-Assistenten verbindet. Ein Plugin läuft mit den Rechten, die Sie ihm geben, und seine Tool-Beschreibungen landen direkt im Kontext des Modells. Ein schädliches oder kompromittiertes Plugin kann deshalb Daten stehlen, Anweisungen in seinen Beschreibungen verstecken oder sein Verhalten mit einem Update ändern.\nAuch klassische Software-Abhängigkeiten zählen. Python-Pakete, deren Namen bekannten Paketen ähneln — man spricht von Typosquatting —, können Schadsoftware enthalten. KI-Programmierassistenten schlagen manchmal Pakete vor, die es gar nicht gibt, und Angreifer können solche Namen registrieren. Level 1 erklärt dieses Risiko im Teil über Halluzinationen als Sicherheitsrisiko. Gegenmaßnahmen:\nFühren Sie eine Positivliste freigegebener Plugins und MCP-Server und installieren Sie nichts aus unbekannten Quellen. Prüfen Sie, welche Rechte jedes Plugin verlangt, und gewähren Sie nur das Nötigste. Legen Sie Versionen fest und prüfen Sie Updates, bevor Sie sie ausrollen. Nutzen Sie Lock-Dateien mit Hashes für Pakete sowie Software Composition Analysis (SCA), eine Art von Tool, das Abhängigkeiten auf bekannte Schwachstellen prüft. Herkunftsnachweise: Model Cards, Signaturen und AI-BOMs Vier Arten von Nachweisen sagen Ihnen, was Sie betreiben:\nKI-Lieferkette absichern: Modelle, Daten, Plugins Nachweis Was er enthält Welche Frage er beantwortet Model Card Zweck, Trainingsdaten, Evaluationen und Grenzen eines Modells Passt dieses Modell zu meinem Einsatz? Datasheet eines Datensatzes Herkunft, Erhebungsmethode und Inhalt eines Datensatzes Woher stammen diese Daten? Hash oder Signatur Ein kryptografischer Fingerabdruck der Dateien Sind das genau die Dateien, die der Herausgeber veröffentlicht hat? SBOM oder AI-BOM Eine Bestandsliste aller Komponenten mit Versionen und Herkunft Was genau steckt in meinem System? Model Cards wurden 2019 von Forschenden bei Google vorgeschlagen (Quelle: Mitchell et al., „Model Cards for Model Reporting“, 2019). Für Signaturen hat eine Arbeitsgruppe der Open Source Security Foundation (OpenSSF) 2025 Version 1.0 einer Bibliothek zum Signieren von Modellen veröffentlicht. Sie kann Modelldateien mit dem Projekt Sigstore signieren und die Signatur prüfen, bevor ein Modell geladen wird (Quelle: Sigstore-Blog, „Taming the Wild West of ML: Practical Model Signing with Sigstore“, 2025, blog.sigstore.dev). Eine Software-Stückliste (Software Bill of Materials, SBOM) führt alle Bestandteile einer Software auf; eine AI-BOM erweitert sie um Modelle und Datensätze. Beide verbreiteten SBOM-Standards decken inzwischen KI ab: CycloneDX mit seiner Machine-Learning-BOM und SPDX 3.0 mit seinen Profilen für KI und Datensätze.\n▸Eine AI-BOM in einer Stunde beginnen\nWählen Sie eine KI-Funktion und listen Sie alles auf, was sie von außen nutzt: Modelle (Name, Version oder Hash, Herkunft, Lizenz), Datensätze, Pakete (übernehmen Sie sie aus der Lock-Datei), Plugins und MCP-Server (Herausgeber, Rechte) sowie Modell-APIs (Anbieter, Modellversion). Tragen Sie zu jeder Zeile eine verantwortliche Person ein. Für den Anfang genügt eine einfache Tabelle neben dem Code; aktualisieren Sie sie mit jedem Release.\nModelle mit offenen Gewichten: der größte Download Viele Teams betreiben Open-Weight-Modelle — Modelle, deren Gewichte jeder herunterladen kann — auf eigenen Servern oder in einer GPU-Cloud. Unsere LLM-Datenbank führt 172 Modelle mit offenen Gewichten, von insgesamt 343 Modellen. Das Diagramm zeigt, wann sie erschienen sind:\nModelle in unserer LLM-Datenbank nach Erscheinungsjahr und Art der Gewichte. Das laufende Jahr ist nicht vollständig. Daten: Epoch AI, CC BY 4.0. Jedes dieser Modelle ist ein großer Download aus einer fremden Quelle. Hier einige Beispiele aus unserer Datenbank mit ihrem Gesamtwert für die Leistungsfähigkeit:\nModelle aus unserer LLM-Datenbank ModellErschienenGewichteECIRang Kimi K3 Moonshot16.07.2026offen157,417 DeepSeek V4.1 Flash DeepSeek09.09.2026offen155,631 Qwen 3.8 27B Alibaba14.08.2026offen151,652 GLM-5.3-Flash Z.ai (Zhipu AI)20.08.2026offen153,245 Llama 3-70B Meta AI18.04.2024offen122,9191 ECI = Epoch Capabilities Index, ein Gesamtwert über viele Benchmarks; Rang unter allen Modellen mit ECI. Daten: Epoch AI, abgerufen am 17.10.2026, Lizenz CC BY 4.0. Alle Modelle: LLM-Datenbank.\nOffene Gewichte sind an sich nicht unsicher. Mit einem Download wird die Prüfung der Lieferkette aber zu Ihrer Aufgabe. Bei einer API verwaltet der Anbieter die Modelldateien, und Ihre Prüfungen verlagern sich auf Vertrag, Datenbedingungen und Versionswechsel. Wenn Sie Modelle selbst betreiben — zum Beispiel in einer GPU-Cloud wie Runpod —, wenden Sie die Prüfliste unten auf jedes Modell und jedes Update an. Plattformen wie Airia helfen Unternehmen nach Angaben des Anbieters, die genutzten Modelle, Agenten und Tools abzusichern und zu steuern. Wir haben keines der beiden Tools getestet.\nRunpodInfrastruktur \u0026amp; Hosting · KI ist der KernGPU-Cloud zum Trainieren und Betreiben von KI-Modellen, abgerechnet nach Nutzung. AiriaSicherheit \u0026amp; Governance · KI ist der KernOrchestrierungsplattform für Unternehmen, um KI-Lösungen abgesichert zu bauen und zu verwalten. Kurzbeschreibungen aus unserem Tool-Vergleich, nach Angaben der Anbieter — nicht von ABXK getestet.\nPrüfliste für KI-Komponenten Die Treppe zeigt die Reihenfolge der Prüfungen für ein heruntergeladenes Modell; die Tabelle deckt alle Arten von Komponenten ab.\nVon „im Netz gefunden“ zu „freigegeben“: sechs Prüfungen, bevor ein Modell in den Betrieb geht. KI-Lieferkette absichern: Modelle, Daten, Plugins (2) Komponente Vor der Nutzung prüfen Nachweis, den Sie aufbewahren Modellgewichte Bekannter Herausgeber, Lizenz, Format safetensors, Scan, Hash oder Signatur Model Card, Hash, Scan-Ergebnis Modell-API Vertrag und Datenbedingungen, festgelegte Modellversion, Ankündigung von Änderungen Vertrag, Modellversion in den Logs Datensätze Herkunft, Lizenz, personenbezogene Daten, Prüfung auf Vergiftung Datasheet, Stichprobenprüfung Pakete Exakte Namen, festgelegte Versionen mit Hashes, bekannte Schwachstellen Lock-Datei, SCA-Bericht Plugins und MCP-Server Herausgeber, Rechte, festgelegte Version, Prüfung von Updates Eintrag in der Positivliste, Rechteprüfung Quellen der Wissensbasis Wer schreiben darf, Prüfung neuer Quellen Quellenliste, Änderungsprotokoll Jede freigegebene Komponente kommt mit Version, Herkunft und verantwortlicher Person in Ihre AI-BOM. Wird eine neue Schwachstelle oder ein schädliches Paket bekannt, beantwortet diese Liste innerhalb von Minuten die erste Frage der Incident Response für KI: Sind wir betroffen?\n","words":1655},"date":"2026-10-14","description":"Heruntergeladene Modelle, vergiftete Daten, schädliche Plugins, riskante Pakete: So prüfen Sie die Teile Ihres KI-Systems mit Model Cards, Signaturen und AI-BOM.","image":"https://abxk.ai/images/cover/ai-supply-chain-security.webp","json":"https://abxk.ai/de/ai-security/learn/ai-supply-chain-security/index.json","kind":"page","language":"de","learning_path":{"category":"ai-security","level":3,"level_name":"Profi"},"modified":"2026-10-14","related_tools":["Runpod","Airia","Pinecone"],"section":"ai-security","tags":["lieferkette","offene-gewichte","ai-bom","datenvergiftung"],"title":"KI-Lieferkette absichern: Modelle, Daten, Plugins","translations":[{"json":"https://abxk.ai/en/ai-security/learn/ai-supply-chain-security/index.json","language":"en","url":"https://abxk.ai/en/ai-security/learn/ai-supply-chain-security/"}],"url":"https://abxk.ai/de/ai-security/learn/ai-supply-chain-security/"}