cyberivy
AIsbomAI SecurityML SecurityAI-BOMCycloneDXSPDXHugging FaceOpen Source AI

AIsbom prüft KI-Modelldateien, bevor sie Code ausführen

20. September 2026

GitHub-Vorschaubild des AIsbom-Repositories mit Projektname, Beschreibung und Repository-Metadaten

AIsbom untersucht Modelldateien statisch auf Schadcode, riskante Lizenzen und manipulierte Vorlagen. Das Open-Source-Werkzeug erzeugt zugleich CycloneDX- oder SPDX-Nachweise.

Worum es geht

AIsbom ist ein Open-Source-Sicherheitsscanner für Dateien von Machine-Learning-Modellen. Das Werkzeug untersucht unter anderem PyTorch-, Pickle-, Keras-, GGUF-, ONNX-, SafeTensors- und NumPy-Dateien, ohne das Modell zu laden. Das ist wichtig, weil manche Formate ausführbaren Code oder Verweise auf externe Dateien enthalten können. Ein Modell aus einem öffentlichen Repository ist deshalb nicht automatisch so harmlos wie eine gewöhnliche Datendatei.

Die aktuelle Version 1.6.0 erschien am 14. September 2026. Sie ergänzt auf Wunsch VEX-Aussagen zu exakt festgelegten Python-Abhängigkeiten über die öffentliche OSV-Schnittstelle. Der Kern bleibt jedoch die statische Prüfung der Modellartefakte.

Was AIsbom tatsächlich macht

Der Scanner zerlegt Pickle-Bytecode, sucht in Keras-Konfigurationen nach ausführbaren Lambda-Schichten, prüft GGUF-Chatvorlagen auf verdächtige Jinja-Konstrukte und kontrolliert ONNX-Verweise auf Dateien außerhalb des Modellordners. SafeTensors- und GGUF-Kopfbereiche werden gelesen, ohne Gewichte vollständig auszuführen. Laut Projektdokumentation wird kein Payload entpackt oder gestartet.

Als Ziel akzeptiert AIsbom einzelne Dateien, Verzeichnisse, HTTPS-Adressen und hf://-Verweise auf Hugging Face. Für passende Remote-Dateien nutzt es Bereichsanfragen, um nur benötigte Kopfbereiche abzurufen. Das Ergebnis erscheint im Terminal und zusätzlich als Software- beziehungsweise AI-BOM. Unterstützt werden CycloneDX und SPDX; kritische Funde können einen CI-Lauf mit einem eigenen Exit-Code stoppen. Es gibt außerdem eine GitHub Action und eigenständige Binärdateien für mehrere Desktop-Plattformen.

Warum das wichtig ist

Teams behandeln Modellgewichte oft wie große, passive Datenpakete. Bei Pickle-basierten Formaten ist diese Annahme gefährlich: Das Laden kann Objekte rekonstruieren und dabei Funktionen aufrufen. Auch ein GGUF-Modell kann eine Chatvorlage enthalten, während ONNX externe Datenpfade referenzieren kann. AIsbom setzt vor diesem Ladepunkt an und eignet sich daher als Eingangskontrolle für Modellregistries, Build-Pipelines und lokale KI-Experimente.

Der zweite Nutzen ist Nachvollziehbarkeit. Eine CycloneDX- oder SPDX-Datei hält Hashwerte, Formate und erkannte Lizenzangaben fest. Das ersetzt keine juristische Prüfung, schafft aber eine maschinenlesbare Bestandsaufnahme. Version 1.6.0 kann für fest gepinnte Python-Pakete zusätzlich OSV-Abfragen durchführen; dabei werden Paketname und Version an api.osv.dev gesendet. Wer das nicht möchte, kann die Abfrage deaktivieren.

Einfach erklärt

AIsbom arbeitet wie die Sicherheitskontrolle an einem Werkstor. Ein Paket wird nicht erst in der Fabrik geöffnet und ausprobiert. Stattdessen prüft die Kontrolle Verpackung, Begleitpapiere und auffällige Mechanismen, bevor das Paket in den Produktionsbereich gelangt. Sie kann nicht beweisen, dass der gesamte Inhalt gutartig ist, aber bekannte gefährliche Bauarten früh aussortieren.

Praktisches Beispiel

Ein kleines Data-Team übernimmt zwölf Modelle aus öffentlichen Repositories: fünf SafeTensors-Dateien, drei GGUF-Dateien, zwei ONNX-Modelle und zwei ältere Pickle-Artefakte. Vor dem Import in die interne Registry scannt die CI alle zwölf Ziele. AIsbom meldet bei einem Pickle-Modell einen kritischen Funktionsaufruf, bei einem ONNX-Modell einen Pfad außerhalb des Modellordners und bei einem GGUF-Modell eine nichtkommerzielle Lizenz.

Die Pipeline blockiert die beiden technischen Risiken. Das Lizenzthema geht an die zuständige Person, während die übrigen neun Modelle mit Hashwerten in einer CycloneDX-Datei dokumentiert werden. Der sinnvolle erste Test ist klein: ein bekanntes SafeTensors-Modell und ein isoliertes Testartefakt scannen, Ausgaben prüfen und erst danach einen verpflichtenden CI-Schritt einführen.

Einordnung und Grenzen

  • Statische Analyse erkennt bekannte Strukturen und Regeln, aber nicht jede denkbare Hintertür in Gewichten oder im späteren Inferenzcode.
  • Ein unkritischer Scan ist keine Garantie für Modellqualität, Datenschutz, Fairness oder sichere Ausgaben. Laufzeit, Abhängigkeiten und Anwendungscode brauchen eigene Kontrollen.
  • Remote- und VEX-Funktionen können Metadaten an Hugging Face beziehungsweise OSV senden. Für vertrauliche Modelle müssen Teams Netzwerkzugriff, Tokens und Telemetrie bewusst konfigurieren.
  • Lizenzangaben in Modelldateien können fehlen oder falsch sein. Die erzeugte BOM unterstützt eine Prüfung, ersetzt sie aber nicht.

SEO- und GEO-Schlüsselbegriffe

AIsbom, ML Model Security, AI-BOM, CycloneDX, SPDX, Pickle Security, GGUF Security, ONNX Security, SafeTensors, Hugging Face, OSV, KI-Lieferkette

💡 Im Klartext

AIsbom prüft KI-Modelldateien auf bekannte technische und rechtliche Risiken, ohne sie zu laden. Es kann gefährliche Dateistrukturen melden und einen maschinenlesbaren Nachweis für die Lieferkette erzeugen.

Wichtigste Erkenntnisse

  • AIsbom prüft mehrere verbreitete Modellformate vollständig statisch.
  • Kritische Funde können CI-Pipelines über einen eigenen Exit-Code stoppen.
  • Das Werkzeug erzeugt CycloneDX- und SPDX-Nachweise mit Hash- und Lizenzdaten.
  • Optionale OSV-Abfragen senden Namen und Versionen fest gepinnter Pakete an einen externen Dienst.
  • Ein sauberer Scan ersetzt keine Laufzeit-, Datenschutz- oder Qualitätsprüfung.

Häufige Fragen

Führt AIsbom das geprüfte Modell aus?

Nein. Laut Projektdokumentation arbeitet der Scanner statisch und lädt weder Modell noch Payload zur Ausführung.

Welche Formate werden geprüft?

Unter anderem PyTorch/Pickle, Keras, GGUF, ONNX, SafeTensors, NumPy, joblib und dill.

Eignet sich AIsbom für CI?

Ja. Es gibt eine GitHub Action, strukturierte Ausgabeformate und getrennte Exit-Codes für Fehler und kritische Risiken.

Ist ein unauffälliger Scan eine Sicherheitsgarantie?

Nein. Der Scan deckt definierte statische Risiken ab; Laufzeitcode, Modellverhalten und Infrastruktur müssen separat geprüft werden.

Quellen & Kontext