AI-BOM, ML-BOM und ISO/IEC 27090: Welches Modell läuft eigentlich in deinem Cluster?

01 — Die blinde Stelle der SBOM

Eine klassische SBOM beschreibt Code und Pakete. Warum das unverzichtbar ist, habe ich am Beispiel von libssh2 und CVE-2026-7598 gezeigt.

Ein KI-Workload besteht aber aus mehr als seinem Container. Die eigentliche Logik steckt in Artefakten, die kein Paketmanager kennt:

• Modellgewichte: oft Dutzende Gigabyte, aus Hugging Face, einem Registry oder einem Bucket.
• Trainings- und Fine-Tuning-Daten: Herkunft, Lizenz, Stand.
• Tokenizer, Konfigurationen, Adapter: LoRA und Co.
• Prompts und MCP-Konfigurationen: die neue Angriffsfläche agentischer Workloads. Wie real die ist, zeigt die MCP-stdio-Kette aus dem Mai.
• Externe KI-Dienste: zur Laufzeit aufgerufen.

Wird eines davon manipuliert, sieht dein Image-Scanner nichts. Das Image ist ja unverändert. Data Poisoning, ein ausgetauschtes Modell oder ein Backdoor-Adapter bleiben unsichtbar.

Das ist Supply-Chain-Security, nur eine Ebene tiefer. Genau diese Ebene beschreibt eine AI-BOM.

02 — AI-BOM und ML-BOM im Vergleich

AI-BOM ist der Sammelbegriff, ML-BOM der Name bei CycloneDX. Gemeint ist dasselbe: ein maschinenlesbares Inventar aller KI-Bestandteile eines Systems, inklusive ihrer Beziehungen.

Meine Empfehlung: Spricht deine Pipeline schon CycloneDX, bleib dabei. Die ML-BOM ist dann ein weiterer Komponententyp im selben Dokument, kein Parallelprozess.

Was unbedingt hinein gehört

• Modell mit Name, Version und Hash der Gewichte, nicht nur ein Tag
• Herkunft: Registry, Repository oder URL, dazu der Lieferant
• Lizenz von Modell und Daten
• Trainings- und Fine-Tuning-Datensätze, soweit bekannt
• Abhängigkeiten: Basismodell, Adapter, Tokenizer
• Model Card: Zweck, Grenzen, bekannte Risiken

03 — ISO/IEC 27090 als Leitfaden

ISO/IEC 27090:2026 kommt aus dem JTC 1/SC 27, also aus der Ecke von ISO 27001. Auf 56 Seiten beschreibt sie, wie KI-spezifische Bedrohungen über den Lebenszyklus erkannt und abgewehrt werden.

• Ein Leitfaden: Zertifizieren lässt du dich danach nicht. Sie ergänzt dein ISMS.
• Keine Konformitätsvermutung: Für AI Act und Cyber Resilience Act zählen die harmonisierten Normen. 27090 liegt als Ebene darüber.
• Lebenszyklus statt Momentaufnahme: Bedrohungen werden von den Daten bis zum Betrieb betrachtet.

Hier schließt sich der Kreis zur AI-BOM. Du kannst keine Bedrohung für ein Asset erkennen, von dem du nichts weißt. Die AI-BOM ist für 27090, was das Asset-Register für 27001 ist.

Dieselbe Inventur verlangt auch der AI Act. Was das praktisch heißt, steht in meiner Checkliste zum EU AI Act. Wie ein Nachweis mehrere Standards bedient, zeigt Grundschutz++ als Code, Teil 7.

Die Norm ist erst seit wenigen Tagen verfügbar. Welche Kapitel Inventar und Lieferkette im Detail behandeln, zeigt dir der Normtext selbst. Für den Einstieg reicht die Grundidee: erst inventarisieren, dann bewerten.

04 — Modelle als OCI-Artefakte im Cluster

Der größte Hebel im Cluster ist banal. Hör auf, Gewichte per Init-Container aus einem Bucket zu ziehen. Pack sie als OCI-Artefakt ins Registry, genau wie deine Images.

Für TYPO3-Code mache ich das längst. Die Idee dahinter steht in TYPO3 als signiertes OCI-Artefakt, die Umsetzung in der Feldnotiz zu Code als Image-Volume. Für Modelle funktioniert es genauso:

• CNCF ModelPack standardisiert, wie Modelle als OCI-Artefakte verpackt werden. Das CLI modctl baut sie.
• Harbor speichert sie neben deinen Images, mit Rechten pro Repository und unveränderlichen Digests.
• Image Volumes sind seit Kubernetes 1.36 stabil. Ein Pod hängt das Artefakt read-only ein.

apiVersion: v1
kind: Pod
metadata:
  name: llm-inference
spec:
  containers:
    - name: server
      image: registry.example.com/ai/vllm@sha256:<image-digest>
      args: ["--model=/models"]
      volumeMounts:
        - name: model
          mountPath: /models
          readOnly: true
  volumes:
    - name: model
      image:
        reference: registry.example.com/models/my-llm@sha256:<model-digest>
        pullPolicy: IfNotPresent

Im Pod-Spec stehen jetzt zwei Digests: Laufzeit und Modell. Alles mit Digest kannst du signieren, attestieren und bei der Admission prüfen.

05 — Warnsignale in der AI-BOM

Eine AI-BOM ist erst ein Werkzeug, wenn du sie lesen kannst. Drei Stufen helfen bei der Entscheidung.

Blocker

• Gewichte als Pickle (.bin, .pt, .pkl, .ckpt): Pickle führt beim Laden beliebigen Code aus. Das ist das curl | bash der KI-Welt. Safetensors oder GGUF enthalten nur Tensoren.
• trust_remote_code nötig oder eigene Python-Dateien im Modell-Repository: Dieser Code läuft in deinem Inference-Pod.
• Kein Hash, oder er passt nicht zum Digest: Dann ist nicht belegbar, dass getestetes und laufendes Modell gleich sind.
• Ungepinnte Revision, etwa main statt Commit: das :latest für Gewichte.
• Auffälliger Lieferant: Typosquats bekannter Organisationen, frische Accounts, Forks ohne Erklärung.
• Unerwartete Dateien: Skripte, Binaries oder zusätzliche Pickles neben Safetensors.

Prüfen

• Gebrochene Herkunft: Das angebliche Basismodell passt nicht zur Architektur. Dasselbe gilt für Merges aus vielen Quellen.
• Quantisierung eines Dritten: verbreitet, aber ohne Abgleich mit den Originalgewichten.
• Adapter oder Tokenizer aus anderer Quelle: Beide ändern das Verhalten subtil.
• Unbekannte Fine-Tuning-Daten bei kleinen Fine-Tunes: Hier versteckt sich Poisoning am ehesten.
• Lizenz fehlt, „other“ oder non-commercial: kein Sicherheitsrisiko, aber ein Blocker für den Einsatz.
• Downloads zur Laufzeit von URLs außerhalb deines Registrys.

Normal

• Keine Trainingsdaten bei großen Hersteller-Modellen. Das ist Branchenstandard. Notier es als akzeptiertes Risiko.
• Community-Lizenzen mit Acceptable Use Policy. Juristisch prüfen, verdächtig sind sie nicht.
• Eigene Quantisierungen aus verifizierten Gewichten. Dann gehört die Kette dir.

Wichtig: Die AI-BOM enthält nur, was der Generator findet. Ergänze sie um einen Scanner wie ModelScan oder picklescan, der in die Dateien schaut. Die Blocker werden harte Regeln, die Prüf-Fälle Warnungen mit dokumentierter Ausnahme.

06 — Die AI-BOM als Gate in GitLab CI

Eine AI-BOM als PDF im Wiki schützt nichts. Sie muss in der Pipeline entstehen, dort geprüft werden und im Cluster wirken. Das Muster kennst du aus Grundschutz Teil 3 zum signierten Artefakt und dem CVE-Gate aus Teil 4.

1. Erzeugen: AI-BOM aus Repository und Modell-Metadaten generieren.
2. Validieren: Schema prüfen. Kaputte BOMs brechen den Build.
3. Policy prüfen: Hash, Lizenz und erlaubte Formate durchsetzen.
4. Attestieren: AI-BOM als signierte Attestation an Modell- und Image-Digest hängen.
5. Admission: Im Cluster nur zulassen, was eine gültige Attestation hat.

stages: [aibom, verify, attest]

variables:
  MODEL_REF: registry.example.com/models/my-llm
  IMAGE_REF: registry.example.com/ai/vllm
  # MODEL_DIGEST und IMAGE_DIGEST kommen aus den Build-/Push-Jobs

aibom:generate:
  stage: aibom
  image: ghcr.io/cyclonedx/cdxgen:latest   # in echt: per Digest pinnen
  script:
    - cdxgen -t ai --spec-version 1.7 -o aibom.cdx.json .
  artifacts:
    paths: [aibom.cdx.json]

aibom:validate:
  stage: verify
  image: cyclonedx/cyclonedx-cli:latest   # in echt: per Digest pinnen
  script:
    - cyclonedx validate --input-file aibom.cdx.json --fail-on-errors

aibom:policy:
  stage: verify
  image: alpine:3
  before_script:
    - apk add --no-cache jq
  script:
    # Jedes Modell braucht Hash und Lizenz, sonst bricht der Build
    - |
      jq -e '
        [.components[]? | select(.type == "machine-learning-model")] as $m
        | ($m | length) > 0
          and all($m[]; (.hashes // [] | length) > 0
                    and (.licenses // [] | length) > 0)
      ' aibom.cdx.json

aibom:attest:
  stage: attest
  image: cgr.dev/chainguard/cosign:latest   # in echt: per Digest pinnen
  id_tokens:
    SIGSTORE_ID_TOKEN:
      aud: sigstore
  script:
    - cosign attest --yes --type cyclonedx --predicate aibom.cdx.json "$MODEL_REF@$MODEL_DIGEST"
    - cosign attest --yes --type cyclonedx --predicate aibom.cdx.json "$IMAGE_REF@$IMAGE_DIGEST"

Drei Dinge, die du nicht überspringen solltest

• Gegen Digests attestieren, nie gegen Tags. Ein Tag ist ein Zeiger, kein Beweis.
• Die Policy wächst mit. Der jq-Check ist der Einstieg. Für Pickle-Verbot, Lizenz-Allowlist und erlaubte Quellen lohnt sich OPA oder Conftest.
• Signatur-Infrastruktur bewusst wählen. Keyless über das öffentliche Sigstore ist bequem, läuft aber über fremde Infrastruktur. Wer Unabhängigkeit ernst meint, nutzt Schlüssel aus dem eigenen KMS oder betreibt Sigstore selbst.

Und eine gültige Signatur allein beweist noch keinen sauberen Inhalt. Warum, habe ich nach Mini Shai-Hulud aufgeschrieben. Die Attestation sagt, wer die AI-BOM erstellt hat. Ob der Inhalt akzeptabel ist, entscheidet deine Policy.

07 — Admission mit Kyverno

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-aibom
spec:
  validationFailureAction: Enforce
  webhookTimeoutSeconds: 30
  rules:
    - name: verify-aibom-attestation
      match:
        any:
          - resources:
              kinds: [Pod]
      verifyImages:
        - imageReferences:
            - "registry.example.com/ai/*"
          attestations:
            - type: cyclonedx.org/bom
              attestors:
                - entries:
                    - keyless:
                        subject: "https://gitlab.example.com/ai/inference//.gitlab-ci.yml@refs/heads/main"
                        issuer: "https://gitlab.example.com"
              conditions:
                - all:
                    - key: "{{ components[?type=='machine-learning-model'] | length(@) }}"
                      operator: GreaterThan
                      value: 0
    - name: model-volumes-by-digest
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "Modelle nur aus dem freigegebenen Registry und nur per Digest."
        pattern:
          spec:
            =(volumes):
              - =(image):
                  reference: "registry.example.com/models/*@sha256:*"

Die erste Regel prüft die AI-BOM-Attestation am Laufzeit-Image. Die zweite stellt sicher, dass Modelle nur per Digest aus deinem Registry kommen.

Ein Hinweis aus der Praxis: Teste, ob verifyImages in deiner Kyverno-Version auch Image Volumes erfasst. Falls nicht, prüfst du die Signatur des Modell-Artefakts zusätzlich in der Pipeline oder mit einer eigenen Regel.

08 — Der Impuls

Zurück zum Audit. Die Frage nach dem Modell beantwortest du jetzt nicht mehr mit Schweigen. Du hast einen Digest, eine signierte AI-BOM und eine Policy, die alles andere abgelehnt hätte.

ISO/IEC 27090 sagt dir, welche Bedrohungen du ernst nehmen solltest. Die AI-BOM sagt dir, wo sie zuschlagen können. Deine Pipeline sorgt dafür, dass beides nicht in einer Excel-Liste endet.

Fang klein an: ein Modell, ein Registry, eine Policy. Wenn das läuft, ist der Rest Fleißarbeit.

Wie inventarisierst du heute die Modelle in deinem Cluster? Oder ist das bei dir auch noch der Bucket mit dem Init-Container?

09 — Quellen

• ISO/IEC 27090:2026 bei ISO
• AI Agents Under EU Law: Einordnung von 27090 neben AI Act und CRA
• CycloneDX Specification (ECMA-424)
• OWASP CycloneDX
• AI Bill of Materials: CycloneDX vs. SPDX
• CNCF ModelPack model-spec
• CNCF: How OCI artifacts will drive future AI use cases