Forschungsfeld · Supply Chain Security
Von der Stückliste bis zum Coding-Agenten: Lieferketten nachweisbar machen
Software, Modelle und Dienste kommen heute aus vielen Händen. Vami Research untersucht, wie sich diese Lieferkette nachweisbar machen lässt: mit SBOM, VEX und SLSA-Provenance, mit AI-SBOMs für Modelle und Trainingsdaten, mit einer Stückliste für Coding-Agenten und mit Bewertungen von Dienstleistern nach den EBA-Leitlinien und den Katalogen der Cloud Security Alliance.
- SBOM & VEX
- AI-SBOM
- SLSA
- Slopsquatting
- Coding-Agenten
- Drittparteienrisiko
- CSA CAIQ & AICM
- Deep Dives
- 6
- Whitepaper
- 3
- Lösungen
- 1
Die Lieferkette endet nicht mehr beim Paketmanager
Software besteht aus Bibliotheken, Frameworks und Diensten Dritter. Spätestens seit Log4Shell ist klar: Ohne Komponententransparenz lässt sich nicht beantworten, ob und wo eine neue Schwachstelle trifft. Der Cyber Resilience Act macht die Software-Stückliste für Produkte mit digitalen Elementen zur Pflicht – als Teil der technischen Dokumentation, mindestens für die obersten Abhängigkeiten. Die Meldepflichten gelten seit dem 11. September 2026, die Hauptpflichten ab dem 11. Dezember 2027.
Mit KI kommen neue Glieder hinzu. Modelle, Gewichte und Trainingsdaten bestimmen das Verhalten eines KI-Systems, tauchen in einer klassischen SBOM aber nicht auf. Angriffe darauf sind dokumentiert: JFrog fand im Februar 2024 rund 100 bösartige Modelle auf Hugging Face, deren Schadcode beim Laden ausgeführt wird. Coding-Agenten erweitern die Kette um MCP-Server, Skills und Editor-Erweiterungen – wie verwundbar auch dieser Vertriebsweg ist, zeigte am 29. Oktober 2026 eine manipulierte Claude-Code-Erweiterung im Cursor-Marktplatz.
Hinzu kommen Dienstleister, Cloud- und KI-Anbieter. Mit NIS2 und DORA ist die Bewertung direkter Lieferanten zur Pflicht geworden. Die am 18. September 2026 veröffentlichten Leitlinien EBA/GL/2026/09 schaffen für Kreditinstitute, Wertpapierfirmen, Zahlungsinstitute und weitere Finanzunternehmen einen Rahmen für Non-ICT-Dienstleistungen; ihr Anwendungsbeginn steht noch nicht fest. Vami Research verbindet technische Nachweise wie SBOM, VEX und Provenance mit standardisierten Bewertungen nach CSA CAIQ und AI Controls Matrix.
Offene Fragen der Praxis
- 01
Wie wird eine SBOM vom Dokument zum Frühwarnsystem für neue Schwachstellen?
Unser Ansatz
Wir setzen auf die Erzeugung zur Build-Zeit, etwa mit cdxgen oder Syft, je Release versioniert und idealerweise signiert. Danach zählt der laufende Abgleich mit NVD, OSV und GitHub Advisories; VEX hält fest, ob eine verwundbare Komponente das Produkt tatsächlich betrifft. VamiAppSec überwacht jede ausgelieferte SBOM auf aktiv ausgenutzte Schwachstellen, unter anderem mit CISA KEV, und priorisiert mit EPSS.
- 02
Was gehört in die Stückliste eines KI-Systems, dessen Verhalten sich ohne Codeänderung verschiebt?
Unser Ansatz
Neben Bibliotheken inventarisieren wir Modelle, Gewichte sowie Trainings- und Evaluationsdaten samt Herkunft. CycloneDX führt Modelle und Daten seit Version 1.5 als eigene Komponenten, SPDX 3.0 bietet ein AI- und ein Dataset-Profil, Model Cards werden maschinenlesbar. Eine gepflegte AI-SBOM liefert die Datengrundlage für die Dokumentationspflichten aus Cyber Resilience Act und AI Act.
- 03
Wie lassen sich Coding-Agenten einführen, ohne die Kontrolle über die Lieferkette zu verlieren?
Unser Ansatz
Wie jede andere Änderung: Neue Abhängigkeiten und Lockfile-Änderungen brauchen eine benannte Freigabe im Dependency-Review, durchgesetzt über einen internen Registry-Proxy mit Freigabeliste. Für Finanzunternehmen im vollen DORA-Rahmenwerk verlangen die technischen Regulierungsstandards, Genehmigung und Umsetzung von Änderungen zu trennen – ein Agent, der eigene Pull Requests mergt, passt dazu nicht.
- 04
Wie steuern Organisationen Drittparteienrisiken über IKT, Non-ICT, Cloud und KI-Dienste in einem Rahmen?
Unser Ansatz
Über einen Lebenszyklus: Drittparteien erfassen, nach Kritikalität einstufen, Sicherheitspraktiken bewerten und vertraglich absichern – von der Beschaffung bis zum Exit. KI-Dienste prüfen wir nach der AI Controls Matrix der CSA, die etwa Model Poisoning und Prompt Injection adressiert. Von Finanzunternehmen erwarten die EBA-Leitlinien ausdrücklich einen ganzheitlichen Ansatz über ICT und Non-ICT.
Was wir festhalten
- 01
Eine SBOM wirkt erst im Betrieb
Das einmalige Erzeugen einer Datei ist noch kein SBOM-Management. Ihren Nutzen entfaltet die Stückliste erst im laufenden Abgleich mit Schwachstellendaten: Dann lässt sich bei einer neuen CVE sofort sagen, welche Produkte betroffene Komponenten enthalten. VEX ergänzt die SBOM um die Herstelleraussage, ob eine verwundbare Komponente das Produkt tatsächlich betrifft.
Beleg: SBOM-Management
- 02
KI-Modelle können sich ändern, ohne dass sich Code bewegt
Das Verhalten eines KI-Systems hängt an Modell, Gewichten und Trainingsdaten – Artefakten, die eine klassische SBOM nicht erfasst. Erneutes Training oder Fine-Tuning kann ein Modell grundlegend verändern, während Code und Paketversionen gleich bleiben. Eine AI-SBOM nach CycloneDX ML-BOM oder SPDX 3.0 macht diese Bestandteile bewertbar.
Beleg: AI-SBOM
- 03
Ein Agenten-Inventar mit bloßen Namen veraltet lautlos
Coding-Agenten bringen eigene Glieder in die Lieferkette: Werkzeug, Modell und Anbieter, MCP-Server, Skills und Regeldateien. Remote-MCP-Server können sich ändern, ohne dass die Organisation es bemerkt. Wir empfehlen deshalb eine maschinenlesbare Agenten-Stückliste mit Version oder Hash für MCP-Server und Skills – geführt neben der SBOM je Release.
- 04
Lieferantenbewertung ist ein Prozess, kein Fragebogen
Ein ausgefüllter Fragebogen beschreibt einen Anbieter zu einem Stichtag. Belastbar wird die Bewertung erst als laufender Prozess: Kritikalität einstufen, CAIQ- oder AICM-Antworten sowie Zertifikate und Prüfberichte auswerten und Neubewertungen an definierte Auslöser knüpfen – für kritische Funktionen ergänzt um Konzentrationsanalyse und Exit-Strategie nach DORA.
Beleg: Lieferkettensicherheit
Wie wir vorgehen
Vami Research betrachtet die Lieferkette als Kette von Nachweisen: was in einem Artefakt steckt, wie es gebaut wurde, wer es liefert und welche Agenten es verändern dürfen.
SBOM zur Build-Zeit
Stücklisten in CycloneDX oder SPDX direkt im Build erzeugen, je Release versionieren und mit den Artefakten ablegen – etwa mit cdxgen oder Syft.
VEX und Schwachstellen-Abgleich
Laufender Abgleich mit NVD, OSV und GitHub Advisories; VEX- und CSAF-Dokumente halten fest, welche Funde ein Produkt tatsächlich betreffen.
AI-SBOM
Modelle, Gewichte und Datensätze als Komponenten erfassen: CycloneDX ML-BOM, SPDX-3.0-Profile für AI und Datasets, maschinenlesbare Model Cards.
SLSA-Provenance
Herkunftsnachweise als in-toto-Attestation, signiert und vor dem Deployment verifiziert; Ausbau entlang der Stufen L1 bis L3 des Build Track.
Agenten-Stückliste
Je Coding-Agent Werkzeug und Version, Modell und Anbieter, MCP-Server, Skills und Regeldateien maschinenlesbar erfassen – MCP-Server und Skills mit Version oder Hash.
Anbieterbewertung nach Katalog
CSA CCM und CAIQ für Cloud-Anbieter, AI Controls Matrix für KI-Dienste – ausgewertet zusammen mit vorliegenden Zertifikaten und Prüfberichten.
So starten Sie
- 1Inventar aufbauenKomponenten, Modelle, Erweiterungen und Dienstleister erfassen und nach Kritikalität einstufen – als Grundlage jeder Bewertung.
- 2Kontrollen verankernSBOM und Provenance im Build, Freigaben für neue Abhängigkeiten und Erweiterungen, vertragliche Pflichten für Zulieferer und Anbieter.
- 3Laufend überwachenAusgelieferte SBOMs gegen CISA KEV abgleichen und mit EPSS priorisieren, Anbieter bei definierten Auslösern neu bewerten, Nachweise für CRA, NIS2 und DORA führen.
Deep Dives, Whitepaper und Analysen
Deep Dives 6
Whitepaper 3
Vom Feld in die Umsetzung
Verwandte Forschungsfelder
Ihre Lieferkette von der SBOM bis zum Coding-Agenten prüfen?
Wir bewerten mit Ihnen SBOM-Prozess, KI-Komponenten, Agenten-Richtlinien und kritische Dienstleister und ordnen die Ergebnisse CRA, NIS2 und DORA zu. Sprechen Sie uns für ein unverbindliches Erstgespräch an.