Ein AI-BOM-Tool für die DevSecOps-Pipeline auswählen

Möchten Sie Modelllizenzen prüfen, verwundbare Abhängigkeiten nachverfolgen oder erkennen, dass sich ein verwendetes Modell geändert hat? Je nach Ziel unterscheiden sich die erforderlichen Angaben und Werkzeuge. Erfassen Sie zunächst Modell-ID und Version, Anbieter, Softwareabhängigkeiten, Einsatzort und verantwortliche Person sowie bei Bedarf Datensätze und Lizenzen.

ML-BOM von CycloneDX ist ein Format, das unter anderem Modelle und Datensätze abbilden kann. Dass ein Feld im Format vorgesehen ist, bedeutet jedoch nicht, dass ein Werkzeug den zugehörigen Wert aus Ihrer Unternehmensumgebung ermitteln kann.

cdxgen kommt für die Erzeugung einer BOM aus Quellen wie dem Quellcode infrage. Dependency-Track nimmt CycloneDX BOM entgegen und lässt sich zur Übernahme aus CI/CD sowie zur Analyse von Komponenten nutzen. Die Erzeugung durch das erste Werkzeug und die Entgegennahme und Verwaltung durch das zweite erfüllen unterschiedliche Aufgaben. Bewerten Sie daher auch eine Kombination.

Auch die Generierungswerkzeuge unterscheiden sich darin, was sie untersuchen. Die AIBoMGen CLI erstellt auf Basis der Nutzung von Hugging-Face-Modellen im Repository eine CycloneDX AI BOM; zudem steht eine GitHub Action zur Verfügung. xgrep untersucht offline die Nutzung von KI-SDKs und Modellen im Code und gibt die Ergebnisse im Format CycloneDX 1.6 aus. Die KI-spezifische Ausgabe von xgrep enthält jedoch keine allgemeinen Softwareabhängigkeiten, sodass eine SBOM separat erstellt werden muss.

Auch wenn Sie bereits einen SBOM-Generator einsetzen, erfasst dieser nicht zwangsläufig modellspezifische Informationen. Suchen Sie im CycloneDX Tool Center nach weiteren Kandidaten und prüfen Sie neben den unterstützten Formaten auch die ausgegebenen Felder für Modellinformationen, CLI oder API, Authentifizierung und die Einbindung in bestehende Ticketabläufe.

Das Folgende ist ein offizielles Beispiel für cdxgen v13.6.0. Erzeugen Sie die BOM für ein Ziel ohne vertrauliche Inhalte und gleichen Sie Modell-ID, Version und Lizenz mit der ursprünglichen Konfiguration ab. Es handelt sich um ein Befehlsbeispiel, nicht um das Ergebnis einer Ausführung in dieser Umgebung.

Die in Modellkarten aufgeführten Datensätze und Basismodelle sind Angaben des Anbieters. Behandeln Sie diese nicht als Nachweis für eine tatsächliche Nutzung beim Training, sondern prüfen Sie die Angaben in der Karte, beobachtete Abhängigkeiten und Nachweise zu Trainingsjobs getrennt voneinander.

cdxgen -r --include-formulation -o aibom.json --bom-audit --bom-audit-categories ai-bom .

Modelle, die zur Laufzeit über Umgebungsvariablen oder externe APIs ausgewählt werden, können bei einer ausschließlich statischen Analyse des Repositorys übersehen werden. Wären wir mit der Prüfung des Codes betraut, würden wir das erzeugte Inventar mit der Anwendungskonfiguration und den Nutzungsaufzeichnungen abgleichen und nicht aufgeführte Referenzen untersuchen. Die Codeanalyse allein liefert nicht zwangsläufig ein vollständiges Bild der Nutzung externer Modelle.

Ändern Sie nach der Einbindung in CI die Modellversion und prüfen Sie, ob das nächste Artefakt eine entsprechende Änderung aufweist und ob beim empfangenden System die erforderlichen Felder erhalten bleiben. Die erfolgreiche Ausführung des Erzeugungsbefehls bedeutet nicht zwangsläufig, dass CI bei erkannten Problemen fehlschlägt. Fehlerbedingungen und der Umgang mit Exit-Codes müssen gesondert konfiguriert werden. Zudem braucht es einen Prozess, der ausstehende manuelle Prüfungen nicht als bestanden wertet.