Bei einer KI-Anbieter-Lieferkette auf Bankenniveau kann jedes Artefakt, das in die Produktion gelangt, bis zur überprüften Quelle zurückverfolgt, im gleichen Digest neu aufgebaut und vor der Ausführung kryptografisch verifiziert werden. Konkret kann der Anbieter reproduzierbare Image-Builds von Erstanbietern, von einem Zulassungscontroller zum Zeitpunkt der Bereitstellung überprüfte Signaturen, eine maschinenlesbare Herkunft und eine Software-Stückliste für jedes Release sowie einen Release-Pfad nachweisen, bei dem Menschen ein ungeprüftes Artefakt nicht um die Kontrollen herumschieben können. Gemäß dem Digital Operational Resilience Act (DORA), Verordnung (EU) 2022/2554 ist die Bank verpflichtet, dies vor der Unterzeichnung genau zu prüfen, sodass ein seriöser Anbieter mit vorbereiteten Beweisen eintrifft. Dieser Artikel beschreibt jede Praxis, die Beweise, nach denen ein Prüfer fragen sollte, die DORA-Bestimmungen, denen jede dient, und eine Fragencheckliste, die ein Technologierisiko- oder Beschaffungsteam jedem KI-Anbieter vorlegen kann.
Die hier beschriebenen Praktiken sind diejenigen, die KLA für seinen eigenen Release-Pfad anwendet; Die Seiten Sicherheit und Vertrauenscenter tragen die ständigen Ansprüche. Um einen umfassenderen Überblick über die Kontrolle von Agenten im Bankwesen zu erhalten, beginnen Sie mit dem Leitfaden zur KI-Governance im Bankwesen.
Warum die Software-Lieferkette eine DORA-Frage ist
DORA wurde am 14. Dezember 2022 verabschiedet und gilt seit dem 17. Januar 2025 für Finanzunternehmen in der EU. Kapitel V, „Management von IKT-Drittparteirisiken“, regelt, wie ein Finanzunternehmen Verträge über externe Technologie abschließt. Die Definitionen erledigen die erste Arbeit. Artikel 3 Absatz 19 definiert einen IKT-Drittanbieter als „ein Unternehmen, das IKT-Dienste erbringt“, eine Definition, die weit genug gefasst ist, um im Wesentlichen jeden KI-Anbieter abzudecken. Artikel 3 Absatz 22 definiert eine kritische oder wichtige Funktion als eine Funktion, deren Störung oder deren unterbrochene, mangelhafte oder fehlgeschlagene Ausführung die finanzielle Leistung des Unternehmens, die Solidität oder Kontinuität seiner Dienstleistungen oder die kontinuierliche Einhaltung der Bedingungen seiner Zulassung erheblich beeinträchtigen würde. Ein KI-System, das Transaktionen überprüft, AML-Warnungen selektiert oder die Zahlungsfreigabe steuert, unterstützt häufig eine solche Funktion, sobald die Bank die dokumentierte Selbsteinschätzung durchführt.
Diese Klassifizierung legt die Messlatte für das gesamte Engagement höher. Gemäß Artikel 28 Absatz 4 muss das Finanzunternehmen vor Abschluss des Vertrags alle relevanten Risiken identifizieren und bewerten und alle erforderlichen Sorgfaltsmaßnahmen gegenüber dem potenziellen Anbieter ergreifen. Artikel 28 Absatz 5 erlaubt den Abschluss von Verträgen nur mit Anbietern, die angemessene Informationssicherheitsstandards einhalten, und verlangt, dass bei kritischen oder wichtigen Funktionen gebührend berücksichtigt wird, dass der Anbieter die aktuellsten und hochwertigsten Informationssicherheitsstandards verwendet. Artikel 30 Absatz 3 Buchstabe c verpflichtet dann den Vertrag selbst, wenn kritische oder wichtige Funktionen unterstützt werden, vom Anbieter zu verlangen, dass er über IKT-Sicherheitsmaßnahmen, -Tools und -Richtlinien im Einklang mit dem Rechtsrahmen des Unternehmens verfügt.
Eine kompromittierte oder nicht überprüfbare Build-Pipeline eines Anbieters ist ein direkter Weg zu den Schäden, auf die diese Bestimmungen abzielen. Wenn der Anbieter nicht angeben kann, welches Artefakt genau in Produktion läuft, kann die Bank ihre eigenen Change-Management- und Patching-Pflichten gemäß Artikel 9(4)(e) und (f) für die ausgelagerte Funktion nicht erfüllen, kann einen Bericht über schwerwiegende Vorfälle gemäß Artikel 19 nicht auf die betroffenen Versionen beschränken und die Prüfungsrechte, die gemäß Artikel 30(3)(e) im Vertrag zu gewähren sind, nicht einhalten. Lieferkettennachweise sind daher Bewertungsmaterial für die Artikel-28-Akte der Bank und nicht für das Verkäufermarketing.
| Bereitstellung | Was es erfordert | Was der Anbieter liefert |
|---|---|---|
| Artikel 28 Absatz 4 | Risikoidentifizierung vor Vertragsabschluss und umfassende Due-Diligence-Prüfung des potenziellen Anbieters | Ein überprüfbares Lieferketten-Dossier: Erstellung, Signierung, Verifizierung, Herkunft, SBOM, Freigabekontrollen |
| Artikel 28 Absatz 5 | Vertragsabschluss nur mit Anbietern, die angemessene Informationssicherheitsstandards erfüllen; höchste Qualitätsstandards für kritische oder wichtige Funktionen | Benannte Framework-Konformität (z. B. Ziele auf SLSA-Ebene) mit den Artefakten, die sie untermauern |
| Artikel 28 Absatz 3 | Ein Informationsregister, das alle IKT-Vertragsvereinbarungen abdeckt | Stabile Dienst-, Komponenten- und Versionskennungen, die die Bank in ihr Register aufnehmen kann |
| Artikel 30 Absatz 3 Buchstabe c | Vertragliche IKT-Sicherheitsmaßnahmen, Tools und Richtlinien für kritische oder wichtige Funktionen | Die Lieferkettenkontrollen sind als überprüfbare vertragliche Verpflichtungen niedergeschrieben |
| Artikel 30 Absatz 3 Buchstabe e | Laufende Überwachungs-, Zugriffs-, Inspektions- und Prüfungsrechte | Verifizierungsbefehle und Zugriff auf Beweismittel kann ein Bankprüfer ohne die Hilfe des Anbieters ausführen |
| Artikel 19 | Meldung schwerwiegender IKT-bezogener Vorfälle durch das Finanzunternehmen | Genaue Identifizierung der betroffenen Version anhand von Digests, SBOMs und Herkunft innerhalb der Vorfallzeitpläne |
Reproduzierbare Builds: Dieselbe Quelle erzeugt denselben Digest
Ein Build ist reproduzierbar, wenn eine unabhängige Neuerstellung derselben Quellrevision ein bitidentisches Artefakt erzeugt, was für Container-Images denselben Image-Digest bedeutet. Reproduzierbarkeit macht „Vertrauen Sie unserer Pipeline“ zu einer Eigenschaft, die jeder testen kann. Wenn eine Neuerstellung aus der veröffentlichten Quelle den laufenden Digest erzeugt, wurde zwischen der Quellenüberprüfung und der Produktion nichts eingefügt, und im Artefakt befindet sich kein nicht überprüftes Compiler-Flag, keine Abhängigkeitsdrift oder kein manueller Patch.
Die Technik dahinter ist spezifisch und überprüfbar. Build-Zeitstempel werden an die Quellrevision und nicht an die Wanduhr angeheftet, sodass zwei Builds desselben Commits dieselben Zeiten einbetten. Der Builder selbst wird durch Digest fixiert, sodass die Toolchain nicht unbemerkt driften kann. Layer-Zeitstempel werden auf den fixierten Wert umgeschrieben. Abhängigkeiten werden aus einer Sperrdatei aufgelöst und der Build lehnt nicht angeheftete Eingaben ab. In der Release-Pipeline von KLA führt ein Reproduzierbarkeitsgate zwei saubere Neuerstellungen jedes abgedeckten First-Party-Service-Images mit deaktivierten Caches durch und schlägt die Veröffentlichung fehl, wenn sich die Digests unterscheiden, und der Release-Digest muss dem neu erstellten Digest vor der Heraufstufung entsprechen.
Für einen DORA-Prüfer untermauert die Reproduzierbarkeit das Prüfungsrecht nach Artikel 28 Absatz 6 mit etwas Stärkerem als Interviewbeweisen: Die Prüfung kann den Build erneut ausführen. Außerdem erhält die Dienstbeschreibung gemäß Artikel 30 Absatz 2 Buchstabe a echten Inhalt, da „die von uns bereitgestellte Software“ in einen Digest und nicht in eine von einem Menschen eingegebene Versionszeichenfolge aufgelöst wird.
- Anzufordernder Nachweis: Die Ausgabe der Reproduzierbarkeitsprüfung für eine aktuelle Version zeigt, dass der Rebuild-Digest dem Release-Digest entspricht.
- Anzufordernder Nachweis: die Pipeline-Konfiguration, die angeheftete Build-Zeitstempel, an Digest angeheftete Builder und gesperrte Abhängigkeiten nachweist.
- Anzufordernde Nachweise: die Scope-Erklärung: Welche Bilder fallen unter das Reproduzierbarkeitstor und wie sieht der Plan für den Rest aus.
- Warnhinweis: ein Anbieter, der den Digest, der derzeit für seinen eigenen Dienst ausgeführt wird, nicht benennen kann.
Signierte Bilder, überprüft, wo es darauf ankommt: beim Einlass
Eine Signatur auf einem Containerbild bindet das Artefakt an eine Identität. Cosign von Sigstore ist zum gängigen Tool geworden: Die Pipeline signiert den Image-Digest nach der Erstellung, und bei der Verifizierung werden sowohl die Signatur als auch die Identität des Unterzeichners überprüft. Das schlüssellose Signieren stärkt den Identitätsanspruch, da das Zertifikat anhand der OIDC-Identität des CI-Systems für ein bestimmtes Repository und einen bestimmten Workflow ausgestellt wird, sodass die Signatur „erstellt von dieser Pipeline in diesem Zweig“ und nicht „signiert von dem Besitzer einer Schlüsseldatei“ lautet.
Das Signieren allein ist dekorativ, es sei denn, etwas weigert sich, unsignierte Artefakte auszuführen. Der entscheidende Durchsetzungspunkt ist die Clusterzulassung. Ein Kubernetes-Zulassungscontroller, Kyverno in der KLA-Bereitstellung, überprüft die Signatur auf jedem First-Party-Image, bevor der Pod zugelassen wird, löst Tags in unveränderliche Digests auf, sodass überprüft wurde, was ausgeführt wird, und schlägt in der Produktion fehl: Wenn die Richtlinie nicht ausgewertet werden kann, wird die Arbeitslast nicht gestartet. Der Rollout erfolgt stufenweise, mit Überwachung im Prüfmodus in der Entwicklung vor der Durchsetzung in Produktions-Namespaces.
Dies ist die Kontrolle, die ein Bankteam am intensivsten untersuchen sollte, da sie die gesamte Unterzeichnungsgeschichte vom Prozess in die Physik umwandelt. Es lässt sich auch sauber auf die DORA-Sprache übertragen: Artikel 9(4)(e) erfordert dokumentierte Änderungsmanagementkontrollen, die sicherstellen, dass Änderungen an IKT-Systemen auf kontrollierte Weise aufgezeichnet, getestet, bewertet, genehmigt, implementiert und verifiziert werden, und die Überprüfung des Zulassungszeitpunkts ist der „verifizierte“ Schritt, der mechanisch durchgeführt wird. Für den Vertrag handelt es sich um eine konkrete Sicherheitsmaßnahme nach Artikel 30 Absatz 3 Buchstabe c, deren Konfiguration ein Prüfer nachlesen kann.
Die negativen Pfade verdienen die gleiche Aufmerksamkeit. Fragen Sie, was passiert, wenn die Überprüfung fehlschlägt, wenn das Signaturtransparenzprotokoll nicht erreichbar ist und wenn jemand versucht, ein außerhalb der sanktionierten Pipeline erstelltes Image bereitzustellen. Eine bankübliche Antwort zeigt ein blockiertes Zulassungsereignis und eine Warnung an, und der Anbieter sollte in der Lage sein, den block auf Anfrage vorzuführen. Durch die Benachrichtigung über die Verifizierungsrichtlinie selbst, also eine stillschweigend deaktivierte Richtlinie, wird der Kreis geschlossen.
Herkunft und SBOM: Was es ist und woher es kommt
Provenienz ist eine unterzeichnete Bescheinigung, die dokumentiert, wie ein Artefakt erstellt wurde: die Quellrevision, den Builder, den Arbeitsablauf und die Build-Parameter. Das SLSA-Framework standardisiert das Format und definiert Integritätsstufen für die Pipeline, die es erstellt. Eine Software-Stückliste (SBOM) listet die Komponenten innerhalb des Artefakts in einem maschinenlesbaren Format wie SPDX oder CycloneDX auf. Provenienz antwortet: „Wer hat das aus was gebaut?“; die SBOM antwortet „was drin ist“. Ein seriöser Anbieter generiert beides in der Pipeline zur Build-Zeit, hängt sie an das Image an und signiert sie, sodass sie die Integritätsgarantien des Artefakts teilen, anstatt in einem Wiki zu leben.
Für die Bank ist es das SBOM, das die Offenlegung einer Schwachstelle in eine begrenzte Frage verwandelt. Wenn das nächste kritische CVE in einer gemeinsamen Bibliothek landet, kann die Bank den Anbieter fragen, welche bereitgestellten Versionen die betroffene Komponente enthalten, und innerhalb weniger Stunden eine aus den SBOMs der laufenden Digests abgeleitete Antwort erwarten. Diese Funktion fließt in die Patch- und Aktualisierungsrichtlinien der Bank gemäß Artikel 9 Absatz 4 Buchstabe f für die ausgelagerte Funktion sowie in die Meldung von Vorfällen gemäß Artikel 19 ein, wobei der Bericht angeben muss, welche Dienste und Versionen betroffen waren. Die Herkunft dient dem Überwachungsrecht gemäß Artikel 30 Absatz 3 Buchstabe e: Ein Prüfer, der die Bescheinigung besitzt, kann unabhängig bestätigen, dass das laufende Artefakt von der genehmigten Pipeline aus der angegebenen Revision erstellt wurde.
Zwei Folgefragen unterscheiden erfahrene Anbieter von ambitionierten Anbietern. Erstens zur Berichterstattung: Werden Bescheinigungen für jedes Release-Artefakt erstellt oder nur für das Flaggschiff-Bild? Zweitens, Überprüfung: Verbraucht irgendetwas die Bescheinigungen oder werden sie erstellt und nie überprüft? Für die Vorfallforensik ist es immer noch wichtig, Herkunftsnachweise zu erstellen, die nicht überprüft werden können, und ein Anbieter, der diese Grenze ehrlich angibt, ist glaubwürdiger als einer, der Überprüfungen impliziert, die nicht existieren.
Ein kontrollierter Freigabeweg: keine Seitentüren
Die verbleibende Frage ist, ob die oben genannten Kontrollen umgangen werden können. Ein kontrollierter Release-Pfad bedeutet, dass der Weg vom zusammengeführten Quell- zum Produktionsverkehr geschlossen ist: Auf jedes Laufzeit-Image wird durch einen unveränderlichen Digest und nicht durch ein veränderliches Tag verwiesen, der Bereitstellungsstatus wird in einer versionierten Konfiguration (GitOps) deklariert, sodass Clusteränderungen auf überprüfte Commits zurückgeführt werden können, und die eigenen Abhängigkeiten der CI-Pipeline, einschließlich CI-Aktionen von Drittanbietern, sind an exakte Revisionen gebunden, sodass das Build-System nicht vor der Signatur geändert werden kann.
Das Digest-Pinning verdient eine eigene Überprüfung, da gute Pipelines dort still und leise auslaufen. Ein Tag wie v1.4 kann nach Überprüfung in der Registrierung neu angegeben werden; ein Digest kann das nicht. Die KLA-Pipeline überprüft, ob die Laufzeit Referenzbilder per Digest manifestiert und hält die Ausnahmeliste leer. Images von Drittanbietern, die im Cluster ausgeführt werden müssen, werden unter derselben Identität wie Images von Erstanbietern gespiegelt, gescannt und signiert, sodass die Zulassungsrichtlinie für alles gilt.
Hier wird auch der menschliche Faktor auf die Probe gestellt. Fragen Sie, wer unter welchem Break-Glass-Verfahren direkt in die Produktion gehen kann und welche Aufzeichnungen ein Break-Glass-Einsatz hinterlässt. Artikel 30 Absatz 3 Buchstabe b schreibt vor, dass der Vertrag Mitteilungs- und Berichtspflichten für Entwicklungen vorsieht, die die Lieferfähigkeit des Anbieters wesentlich beeinträchtigen. Eine Notfallfreigabe außerhalb des Standardpfads ist genau eine solche Entwicklung, und ein bankfähiger Anbieter kann das Verfahren, den Genehmigungspfad, der daraus entsteht, und wie das Artefakt auch im Notfall noch signiert und verifiziert wird, zeigen.
| Üben | Beweise, die ein Prüfer überprüfen kann | DORA-Relevanz |
|---|---|---|
| Reproduzierbare Erstanbieter-Builds | Transkript neu erstellen, das die Digest-Gleichheit für eine aktuelle Veröffentlichung zeigt; Pinned-Timestamp- und Pinned-Builder-Pipeline-Konfiguration | Konkretisierung der Sicherheitsstandards gemäß Artikel 28 Absatz 5; macht Prüfungen gemäß Artikel 28 Absatz 6 wiederholbar |
| Schlüsselloses Signieren von Bildern, gebunden an die CI-Identität | Ausgabe des Verifizierungsbefehls, die die Identität des Unterzeichners zeigt, die mit dem Freigabeworkflow verknüpft ist | Artikel 30 Absatz 3 Buchstabe e: unabhängige Überwachung; Identitätsnachweis für das Register nach Artikel 28 Absatz 3 |
| Überprüfung der Signatur zum Zeitpunkt des Einlasses, Fehler in der Produktion geschlossen | Die Zulassungsrichtlinie, eine nachgewiesene blockierte Bereitstellung und die dadurch ausgelöste Warnung | Artikel 9 Absatz 4 Buchstabe e verifizierte die Änderungskontrolle als vertragliche Maßnahme gemäß Artikel 30 Absatz 3 Buchstabe c |
| Unterzeichnete Provenienzbescheinigungen (SLSA) | Bescheinigung für einen Produktions-Digest mit Nennung von Quellrevision, Builder und Workflow | Prüfungsrechte gemäß Artikel 30 Absatz 3 Buchstabe e; Vorfallforensik gemäß Artikel 19 |
| SBOM pro Release-Artefakt | SPDX- oder CycloneDX-Dokument für den laufenden Digest; eine zeitgesteuerte Antwort auf „Welche Versionen enthalten Komponente X?“ | Füttert die Patch-Richtlinien der Bank gemäß Artikel 9 Absatz 4 Buchstabe f und die Vorfallsumfangsbestimmung gemäß Artikel 19 |
| Digest-Pinning und von GitOps deklarierte Bereitstellung | Manifest-Validierungsausgabe; eine leere Ausnahmeliste; Änderungsverlauf, der den Clusterstatus auf überprüfte Commits zurückverfolgt | Artikel 30 Absatz 2 Buchstabe a genaue Leistungsbeschreibung; Artikel 28 Absatz 4 Risikobewertungseingabe |
| Angeheftete CI-Abhängigkeiten | Workflow-Dateien, die Aktionen und Builder von Drittanbietern an exakte Revisionen anheften | Reduziert das Risiko der Subunternehmerkette. Artikel 29 Absatz 2 verlangt von der Bank eine Abwägung |
Die Käufer-Checkliste: Fragen und wie eine gute Antwort aussieht
Die folgende Tabelle zeigt die Lift-and-Use-Anlage. Legen Sie die Fragen einem beliebigen KI-Anbieter vor, notieren Sie die Antworten in der Bewertungsdatei gemäß Artikel 28 Absatz 4 und verwenden Sie die Spalte „Gute Antwort“ als Bewertungsanker. Jede gute Antwort hat eine Eigenschaft gemeinsam: Sie verweist eher auf ein Artefakt oder eine Demonstration als auf ein Richtlinien-PDF.
| Frage | Wie eine gute Antwort aussieht |
|---|---|
| Können Sie ein Produktionsimage aus der Quelle neu erstellen und den gleichen Auszug erhalten? | Ja, mit einem aktuellen Umbauprotokoll. Der Anbieter benennt, welche Bilder abgedeckt werden und gibt den Plan für den Rest an. |
| Welcher Digest wird gerade für Ihren Dienst ausgeführt, und woher wissen Sie das? | Ein aus dem Bereitstellungsstatus gelesener Digest, der einem Release-Datensatz zugeordnet ist, in Minuten. Das Zögern hier untergräbt jede andere Antwort. |
| Wie werden Bilder signiert und welche Identität bestätigt die Signatur? | Signieren auf Digest-Ebene mit dem an die CI-Workflow-Identität gebundenen Zertifikat und dem genauen Verifizierungsbefehl, den ein Dritter ausführen kann. |
| Was weigert sich, ein nicht signiertes oder falsch signiertes Bild auszuführen? | Ein Zulassungscontroller, der Signaturen vor dem Start von Pods überprüft, die Schließung in der Produktion erzwingt und fehlschlägt, mit einer nachgewiesenen blockierten Bereitstellung. |
| Was passiert, wenn die Infrastruktur zur Signaturüberprüfung ausfällt? | Eine angegebene Fail-Closed-Stellung für den Produktionszugang, den betrieblichen Fallback und die ausgelöste Warnung. Der Kompromiss wird verstanden und anerkannt. |
| Legen Sie Herkunftsbescheinigungen vor und kann ich diese überprüfen? | Signierte SLSA-Herkunft pro Release mit Benennung von Quellrevision, Builder und Workflow, einschließlich des Verifizierungsbefehls. |
| Können Sie mir eine SBOM für die genaue Version geben, die wir ausführen würden? | Eine maschinenlesbare SBOM, die zur Erstellungszeit für diesen Digest generiert wurde, sowie eine zugesagte Bearbeitung für Fragen zur Komponentenfreigabe. |
| Werden Ihre Laufzeitbilder per Tag oder Digest referenziert? | Überall verdauen, erzwungen durch eine Pipeline-Prüfung, mit leerer oder kurzer und begründeter Ausnahmeliste. |
| Wie werden Bilder von Drittanbietern und CI-Abhängigkeiten gleich behandelt? | Bilder Dritter werden gespiegelt, gescannt und unter der eigenen Identität des Anbieters signiert; CI-Aktionen und Builder sind an exakte Revisionen angeheftet. |
| Wer kann die Bereitstellung außerhalb des Standardpfads in der Produktion durchführen und welche Spuren hinterlässt dies? | Ein benanntes Glasbruchverfahren mit aufgezeichneten Genehmigungen, weiterhin unterzeichneten und überprüften Artefakten und einem meldepflichtigen Ereignis an die Bank. |
| Wie schnell können Sie mir sagen, ob wir gefährdet sind, wenn ein kritischer CVE auftritt? | Ein festgelegter Zeitplan, beantwortet aus SBOMs laufender Digests, im Einklang mit den Mitteilungspflichten im Vertrag. |
| Werden Sie diese Kontrollen in den Vertrag aufnehmen? | Ja: Die oben genannten Praktiken sind als Verpflichtungen gemäß Artikel 30 Absatz 3 mit Prüfungsrechten formuliert und werden nicht als veränderbares Richtliniendokument bezeichnet. |
Lesen Sie die Antworten: Bewertung und Vertragsverfolgung
Die Wertung ist unkompliziert. Eine Antwort, die durch ein Artefakt gestützt wird, das die Bank überprüfen kann, erhält die volle Punktzahl. Eine Antwort, die eine echte Kontrolle ohne unabhängige Beweise beschreibt, wird teilweise bewertet und generiert eine Beweisanforderung. Eine Antwort, die auf eine Zertifizierung umleitet, erhält für diese Checkliste null Punkte: Ein SOC-2-Bericht bescheinigt den Prüfungszeitraum und den Umfang der Kontrollen und weist selten die Reproduzierbarkeit, die Durchsetzung der Zulassung oder die Herkunft des spezifischen Artefakts nach, das die Bank betreiben wird. Zertifizierungen ergänzen Nachweise auf Artefaktebene; sie ersetzen es nicht.
Ehrliche Grenzaussagen sollten punkten, und das gilt in beide Richtungen. KLA veröffentlicht seine eigenen Grenzen im Trust Center, einschließlich der heute durchgesetzten und der abgestuften Kontrollen, da ein Anbieter, der eine perfekte Pipeline behauptet, eine Pipeline beschreibt, die niemand überprüft hat. Erwarten Sie Deckungslücken; Beurteilen Sie, ob der Anbieter weiß, wo er sich befindet, ob er ihn überwacht und die Schließung veranlasst.
Anschließend übertragen Sie die Ergebnisse in den Vertrag. Artikel 30 Absatz 1 schreibt vor, dass der vollständige Vertrag in einem einzigen schriftlichen Dokument vorliegen muss; Artikel 30 Absatz 2 Buchstabe b schreibt vor, dass Änderungen an den Verarbeitungs- und Speicherorten im Voraus bekannt gegeben werden müssen. Artikel 30 Absatz 3 Buchstabe e verlangt uneingeschränkte Zugriffs-, Inspektions- und Prüfungsrechte für kritische oder wichtige Funktionen. Die im Rahmen der Due Diligence überprüften Lieferkettenpraktiken werden zum konkreten Inhalt der Sicherheitsmaßnahmenklausel nach Artikel 30 Absatz 3 Buchstabe c, und die Überprüfungsbefehle werden zum Mechanismus, mit dem die Bank ihre Überwachungsrechte ausübt, ohne einen Lieferantenbesuch zu vereinbaren. Artikel 28 Absatz 8 verlangt Ausstiegsstrategien; Reproduzierbare Builds und vollständige SBOMs verringern das Ausstiegsrisiko erheblich, da die Bank beim Ausscheiden genau weiß, was sie ausgeführt hat.
Für Teams, die KLA speziell bewerten: die ständigen Lieferkettenansprüche live auf der Sicherheitsseite, die Überprüfungs-Vorantworten und Unterauftragsverarbeiter-Offenlegungen im Trust Center und den Bankenkontext in Lösungen für Finanzdienstleistungen.
Häufig gestellte Fragen
Ist ein KI-Anbieter ein IKT-Drittanbieter im Rahmen von DORA?
Artikel 3 Absatz 19 der Verordnung (EU) 2022/2554 definiert einen IKT-Drittanbieter als ein Unternehmen, das IKT-Dienste erbringt, und Artikel 3 Absatz 21 definiert IKT-Dienste allgemein als digitale Dienste und Datendienste, die fortlaufend über IKT-Systeme bereitgestellt werden. Ein KI-Anbieter, der einen gehosteten oder bereitgestellten Softwaredienst bereitstellt, fällt unter diese Definition, und die Sorgfalts-, Register- und Vertragspflichten der Bank in den Artikeln 28 bis 30 gelten für die Vereinbarung.
Erfordert DORA von Anbietern reproduzierbare Builds oder signierte Images?
In keiner Bestimmung werden diese Techniken genannt. DORA verpflichtet das Finanzunternehmen, vor Vertragsabschluss eine Due-Diligence-Prüfung und Risikobewertung durchzuführen (Artikel 28 Absatz 4), Verträge nur mit Anbietern abzuschließen, die angemessene Informationssicherheitsstandards erfüllen (Artikel 28 Absatz 5) und Anbieter, die kritische oder wichtige Funktionen unterstützen, an vertragliche IKT-Sicherheitsmaßnahmen, -Tools und -Richtlinien zu binden (Artikel 30 Absatz 3 Buchstabe c). Reproduzierbare Builds, signierte Bilder, die bei der Zulassung überprüft wurden, Herkunft und SBOMs sind derzeit die stärksten Beweise, die ein Anbieter für diese Tests bieten kann.
Welche Lieferkettennachweise sollte eine Bank von einem KI-Anbieter verlangen?
Ein Rebuild-Transkript, das die Digest-identische Reproduktion für eine aktuelle Version demonstriert, den Signaturüberprüfungsbefehl mit der CI-gebundenen Unterzeichneridentität, die Zulassungsrichtlinie, die nicht überprüfte Bilder zusammen mit einem demonstrierten block blockiert, eine signierte Herkunftsbescheinigung für einen Produktions-Digest, eine maschinenlesbare SBOM für die genaue auszuführende Version, die Digest-Pinning-Validierung für Laufzeitmanifeste und das Break-Glass-Verfahren mit der Spur, die es hinterlässt.
Warum ist die Überprüfung der Einlasszeit wichtiger als die Unterschrift selbst?
Eine Signatur, die nichts überprüft, ändert kein Ergebnis. Bei der Zulassungszeitüberprüfung wird die Prüfung in dem Moment durchgeführt, in dem ein Workload beginnt, sodass ein unsigniertes oder falsch signiertes Artefakt nicht in der Produktion ausgeführt werden kann, unabhängig davon, wer es gepusht hat oder warum. Darüber hinaus verfügt die Bank über einen einzigen überprüfbaren Kontrollpunkt: die Richtlinienkonfiguration, die Eintrittssperrereignisse und die Warnungen für die Richtlinie selbst.
Wie hängen Lieferkettenbeweise mit der DORA-Vorfallmeldung zusammen?
Artikel 19 verpflichtet Finanzunternehmen, schwerwiegende IKT-bezogene Vorfälle ihrer zuständigen Behörde zu melden. Die Festlegung des Umfangs eines solchen Berichts für einen ausgelagerten KI-Dienst hängt davon ab, genau zu wissen, welche Artefaktversionen betroffen waren. Mithilfe von Digest-Pinned-Bereitstellungen, SBOMs und Provenienz kann der Anbieter diese innerhalb von Stunden beantworten, was die Bank benötigt, um ihre eigenen Berichtsfristen einzuhalten und die im Vertrag gemäß Artikel 30(3)(b) festgelegten Mitteilungspflichten zu erfüllen.
Die wichtigsten Erkenntnisse
Die Lieferkette eines KI-Anbieters auf Bankenniveau wird mit Artefakten demonstriert: ein Rebuild, der den Produktions-Digest reproduziert, eine an die Pipeline-Identität gebundene Signatur, ein Zulassungscontroller, der alles andere blockiert, Herkunft und eine SBOM für jede Veröffentlichung sowie ein geschlossener Pfad von der überprüften Quelle bis zur laufenden Arbeitslast. DORA gibt der kaufenden Bank sowohl das Mandat als auch das Vokabular, diese Nachweise vor der Unterzeichnung zu verlangen, und bietet seriösen Anbietern die Möglichkeit, sich sichtbar von Anbietern mit einem Richtlinien-PDF zu unterscheiden. Verwenden Sie die Checkliste oben in der nächsten Bewertung, lesen Sie die ständigen Ansprüche von KLA auf der Sicherheitsseite und im Trust Center und ordnen Sie die Anbieterkonversation mit dem Leitfaden zur KI-Governance im Bankwesen und Lösungen für Finanzdienstleistungen in das umfassendere Kontrollbild ein.