Praktische Schritte zum Schutz Ihrer MLOps-Pipeline

Stellen Sie sich die nächste Vorstandssitzung vor. Sie, ein Sicherheitsverantwortlicher in Ihrem Unternehmen, werden Ihre Standardübersicht mit Risiken, Abhilfemaßnahmen und Vorfällen präsentieren. Dann wird eines der Vorstandsmitglieder fragen: Wie bereiten Sie sich auf den Schutz der neuen KI-Technologien und der MLOps-Pipelines vor, die das Unternehmen bereits nutzt? 

Hier ist Ihre Antwort.

KI bringt neue Risiken mit sich

MLOps-Pipelines (manchmal auch als AI Ops bezeichnet) ähneln in ihrem Wert für Unternehmen zwar herkömmlichen Datenverarbeitungssystemen, weisen jedoch deutliche Schwachstellen auf. Angreifer können darauf abzielen Vorurteile einführen, Modellergebnisse manipulieren oder die Datenintegrität oder Tools gefährdenmit dem Ziel Dies untergräbt die Modellzuverlässigkeit und verzerrt Entscheidungsprozesse. ATLAS, ein Framework der MITRE-Organisation für den MLOps-Schutz, unterstreicht die Notwendigkeit maßgeschneiderter Sicherheitsmaßnahmen, die diese Herausforderungen bewältigen.

KI wird neue Vorschriften mit sich bringen

Der aufstrebende Bereich der KI und MLOps wird von Regulierungsbehörden weltweit zunehmend unter die Lupe genommen. In Ermangelung einer umfassenden Bundesgesetzgebung in den Vereinigten Staaten sind Leitlinien von Gremien wie dem National Institute of Standards and Technology (NIST) wie dem Risikomanagement-Framework für künstliche Intelligenz 1.0bietet einen Einblick in künftige Regulierungsrahmen. Das Rahmenwerk betont die Vertrauenswürdigkeit von KI-Systemen, einschließlich der sieben definierten Merkmale vertrauenswürdiger KI-Systeme: Sicherheit, Sicherheit und Widerstandsfähigkeit, Erklärbarkeit und Interpretierbarkeit, Privatsphäre-verbessert, fair mit schädlicher Voreingenommenheit gemanagt, rechenschaftspflichtig und transparent, sowie gültig und zuverlässig.

MLOps und Software Supply Chain haben viele Gemeinsamkeiten

Die Ähnlichkeiten zwischen den Schwachstellen der MLOps-Pipeline und den Risiken der traditionellen Software-Lieferkette sind frappierend. In beiden Bereichen besteht die Gefahr von Kompromissen, die darauf abzielen, die Integrität des Entwicklungsprozesses und die Sicherheit des Endprodukts zu untergraben. Die böswillige Änderung eines LLM ähnelt der böswilligen Änderung einer Softwareabhängigkeit. Das böswillige Modifizieren der Software, auf der das LLM läuft, ist in Wirklichkeit ein Angriff auf die Software-Lieferkette. Verantwortlichkeits-, Transparenz- und Vertrauensanforderungen, die in der KI-Welt diskutiert werden, sind genau das, was hinter den SBOM-Anforderungen in der Welt der Software-Lieferkette steht.

Die MITRE-Organisation veröffentlicht Cybersicherheitsmodelle. MITRE hat kürzlich das Atlas-Modell für den MLOps-Schutz veröffentlicht, das hier zu finden ist hier. Nachfolgend finden Sie einen Überblick über das Modell:

Genau wie im „traditionellen“ Bereich der Cybersicherheit befinden sich KI- und MLOps-Vorschriften noch in der Entwicklung. Die Einhaltung dieser neuen Vorschriften würde es einfacher machen, vorhandene MLOps-Ressourcen zu schützen und die Übereinstimmung von MLOps-Prozessen mit bestehenden und neuen Best Practices zu bestätigen. Organisationen müssen die Integrität ihres Modells sowie dessen Unvoreingenommenheit bestätigen.

Es gibt Technologien, die beiden Bereichen dienen

Technologien, die die Integrität von Daten, Code und Tools gewährleisten, können die erforderlichen Integritätskontrollen für die Sicherheit der Software-Lieferkette sowohl von MLOps als auch von DevOps bereitstellen.

Technologien, die Transparenz und Vertrauensmaße für Software bereitstellen, können ähnliche Werte für MLOps liefern. 

Bescheinigungsbasierte Supply-Chain-Sicherheitstechnologie

Das Konzept des evidenzbasierten Software-Lieferkettenschutzes ist einfach: Einem Software-Artefakt sollte nicht vertraut werden, es sei denn, es gibt genügend Beweise für seine Vertrauenswürdigkeit. Die Umsetzung dieses Konzepts umfasst Tools zur Beweiserhebung, eine Richtlinien-Engine, die die Beweise auswertet, um sie zu verifizieren, Warnungen vor Verstößen und Empfehlungen für Abhilfemaßnahmen sowie Mechanismen zur gemeinsamen Nutzung, die Transparenz und Zusammenarbeit ermöglichen. Der Gesamtrahmen ist ein akademisches Beispiel für eine solche Lösung. Die Software-Supply-Chain-Plattform von Scribe ist unter anderem eine kommerzielle Manifestation dieser Technologie und hat ihre Technologie erweitert, um die ML-Ops-Herausforderungen zu unterstützen.

Der evidenzbasierte Ansatz von Scribe ist unabhängig von den Besonderheiten der Beweise; Somit kann dieselbe Technologie beispielsweise dem MLOps-Schutz dienen:

• Gewährleistung der Softwareintegrität und der ML-Pipeline-Integrität.
• Sicherstellung der Integrität von Open-Source-Abhängigkeiten und der Integrität des KI-Modells.
• Auswertung von SAST-Berichten, um KI-spezifische Testtools-Berichte sicherzustellen (z. B. Biasing-Tests).
• Teilen von SBOMs und Richtlinienbewertungen sowie MLBOMs- und MLOps-Richtlinienbewertungen. 

Scribe Security Software Supply Chain-Technologie für KI/ML-Operationen

Der MITRE ATLAS und die Technologie von Scribe

Im Folgenden finden Sie eine Zuordnung der aktuellen Fähigkeiten von Scribe im Vergleich zur MITRE ATLAS-Angriffskarte:

Angriffsphase	Techniken	Lösung des Schreibers
Entwicklung von Angreiferressourcen	Veröffentlichen Sie vergiftete Datensätze Gifttrainingsdaten.	Datenintegrität: Bestätigen Sie die verbrauchten Datensätze und überprüfen Sie die Quelle und den Inhalt der Datensätze. Bestätigen Sie Trainingsdaten und überprüfen Sie den Inhalt und die Quelle der Trainingsdaten.
Erster Zugriff	Kompromiss in der ML-Lieferkette	Daten- und Codeintegrität: Bescheinigen Sie Daten, Modelle, Software und Konfigurationen der ML-Pipelines. Durchsetzung der ML-Pipeline-Richtlinie: Attestieren Sie Aktionen und überprüfen Sie Richtlinien entsprechend (z. B. Release-Prozess-Kit, Tests, Zugriffsmuster).
Erster Zugriff, Auswirkungen	ML-Modell umgehen (z. B. gestaltete Anfragen)	Genaue Pipeline-Verfolgung: Verfolgen Sie Ressourcen und erkennen Sie Anomalien von ML-Pipeline-Zugriffsmustern (FS-Tracker).
ausführung	Befehls- und Skriptinterpreter	Genaue Pipeline-Verfolgung: Verfolgen Sie Ressourcen und erkennen Sie Anomalien von ML-Pipeline-Zugriffsmustern (FS-Tracker).
Beharrlichkeit	Gifttrainingsdaten	Datenintegrität: Bestätigen Sie Trainingsdaten, überprüfen Sie den Inhalt und die Quelle der Trainingsdaten.
Beharrlichkeit, Inszenierung von ML-Angriffen	Backdoor-ML-Modell	Datenintegrität: Bescheinigen Sie den Lebenszyklus des ML-Modells und überprüfen Sie ihn bei der Verwendung.
Impact der HXNUMXO Observatorien	Systemmissbrauch für externe Wirkung	Richtlinien auf Systemebene: Bestätigen Sie Systemverhalten und -eigenschaften und wenden Sie Richtlinien entsprechend an (z. B. Rechenkosten, Zugriffsmuster).

Im Folgenden finden Sie eine Zuordnung der MITRE-Mitigations im Vergleich zur Scribe-Technologie:

MITRE-Minderungs-ID	Milderung	Lösung des Schreibers
AML.M0005	Kontrollieren Sie den Zugriff auf ML-Modelle und ruhende Daten	Genaue Pipeline-Verfolgung: Verfolgen Sie Ressourcen und erkennen Sie Anomalien von ML-Pipeline-Zugriffsmustern (FS-Tracker).
AML.M0007	Trainingsdaten bereinigen	Datenintegrität: Bestätigen und überprüfen Sie die für das Training verwendeten Daten
AML.M0011	Beschränken Sie das Laden der Bibliothek	Daten- und Codeintegrität: Bestätigen und überprüfen Sie das Laden des Datenmodells und der Codebibliothek.
AML.M0013	Codesignatur	Codeintegrität: Bestätigen und überprüfen Sie den verwendeten Code.
AML.M0014	Überprüfen Sie ML-Artefakte	Daten- und Codeintegrität: Bestätigen und überprüfen Sie das Laden des Datenmodells und der Codebibliothek.
AML.M0016	Vulnerability Scanning	Schwachstellenscan, Richtlinienbewertung: Bescheinigen Sie die Ausführung von Tools wie dem Schwachstellenscan. Bewerten Sie die Richtlinien bezüglich dieser Bescheinigungen. Scannen Sie Schwachstellen basierend auf SBOM-Bescheinigungen, die aus der ML-Pipeline gesammelt werden.

Signieren und Verifizieren von ML-Datensätzen und -Modellen mit Valint

Valint ist das leistungsstarke CLI-Tool von Scribe zum Generieren und Validieren von Attestierungen. Valint kann zum Signieren und Überprüfen von ML-Datensätzen und -Modellen verwendet werden.

Beispiel:

Wir wollen das HuggingFace-Modell verwenden wtp-bert-tiny. Um eine Gefährdung des Modells zu verhindern, möchten wir es vor der Verwendung signieren und überprüfen. Das Erstellen einer Attestierung (signierter Nachweis) kann mit dem folgenden Befehl erfolgen:

valint bom git:https://huggingface.co/benjamin/wtp-bert-tiny -o attest

Dieser Befehl erstellt eine signierte Bescheinigung für das Repository des Modells. Die Bescheinigung wird in einem Bescheinigungsspeicher (in diesem Fall – einem lokalen Ordner) gespeichert und signiert (in diesem Fall – mithilfe der schlüssellosen Signierung von Sigstore).

Eine typische Verwendung des Modells wäre das Klonen des Repos und die Verwendung seiner Dateien. Die Überprüfung der Integrität des Modells unmittelbar nach dem Herunterladen kann mit den folgenden Befehlen erfolgen:

Git-Klon git:https://huggingface.co/benjamin/wtp-bert-tiny valint verifizieren git:wtp-bert-tiny

Die Überprüfung der Modellintegrität vor jeder Verwendung kann mit dem folgenden Befehl erfolgen:

Valint verifiziert git:wtp-bert-tiny

Anmerkungen: 

• Ein ähnlicher Ansatz kann zum Signieren und Überprüfen von Datensätzen verwendet werden.
• Eines der Merkmale von ML-Modellen ist ihre enorme Größe. Um das Herunterladen und Bearbeiten großer, nicht benötigter Dateien zu vermeiden, a best Practices besteht darin, nur die erforderlichen Dateien herunterzuladen. Dieser Anwendungsfall wird von Valint unterstützt, das nur das Signieren eines bestimmten Ordners oder einer bestimmten Datei unterstützt.

Richtlinien für ML-Modelle überprüfen

Valint von Scribe ist ein leistungsstarkes Tool zur Richtlinienüberprüfung. Eine Möglichkeit zur Risikobewältigung ist die Durchsetzung von Richtlinien. Im folgenden Abschnitt werden wir zeigen, wie das Risiko reduziert werden kann, indem eine Lizenzrichtlinie für die verwendeten ML-Modelle durchgesetzt wird. 

Angenommen, wir erlauben in unserem Projekt nur die Verwendung der MIT-Lizenz. Nach der Konfiguration kann Valint es überprüfen:

valint verifizieren git:wtp-bert-tiny -d att -c verify-license.yml

Dieser Befehl verwendet die Verifizierungslizenz Richtlinie, die wie folgt definiert ist:

attest: cocosign: Richtlinien: - Name: ML-Richtlinie aktivieren: wahr Module: - Name: Prüflizenz Typ: Prüfartefakt aktivieren: wahr Eingabe: signiert: wahr Format: attest-cyclonedx-json Rego: Pfad: verifizieren-hf -license.rego

Die in der implementierte Richtlinie verify-hf-license.rego Die Datei extrahiert aus der signierten Bescheinigung die HuggingFace-Modell-ID, ruft Informationen über das Modell aus der HuggingFace-API ab und überprüft, ob es sich um MIT handelt.

Ein ähnlicher Ablauf kann verwendet werden, um Lizenzen von Open-Source-Datensätzen zu überprüfen.

Anwendungsfall: Schutz eines realen ML-Ops-Dienstes

Ein ML-Ops-Dienst ist Teil einer Anwendung, die einen einfachen Zugriff auf KI-Modelle ermöglicht; Die Dienstnutzer müssen lediglich ihre Anfragen angeben, und alle praktischen Aspekte des Zugriffs auf das ML-Modell werden vom Dienst im Hintergrund erledigt.

Beispiel:

Wir möchten einen Dienst erstellen und nutzen, der den Zugriff auf Microsofts „die Vermittlung von Kompetenzen,„Open-Source-Paket (vereinfacht ausgedrückt ermöglicht dieses Paket eine bessere Nutzung von Large Language Models (LLMs), indem es Abfrageketten anstelle einer einzelnen Eingabeaufforderung ausführt).

Der Dienst ist ein Docker-Image, das den Dienstcode und das Modell enthält. Wir werden unseren Code auf dem Andromeda-Chain-Projekt basieren. Das Projekt umschließt die Anleitungsbibliothek mit einem Dienst und erstellt ein Docker-Image mit der Anwendung.

Im Folgenden finden Sie die Basisversion der Docker-Datei:

VON python:3.10 KOPIEREN ./requirements.cpu.txt require.txt RUN pip3 install -r require.txt RUN RUN mkdir models \ cd models \ git clone https://huggingface.co/api/models/benjamin/wtp-bert- tiny COPY ./guidance_server Guidance_server WORKDIR Guidance_server # Setze den Einstiegspunkt CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "9000"]

Es ist ganz einfach; Beim Erstellen des Dockers werden die Codeabhängigkeiten installiert, das Modell installiert und der Servicecode in das Docker-Image kopiert. 

Sobald das Image erstellt ist, können wir mit dem folgenden Valint-Befehl eine signierte Bescheinigung davon erstellen:

valint bom ml-service:latest -o attest

Dieser Befehl generiert eine signierte Bescheinigung, die eine detaillierte SBOM des Docker-Images mit dem Namen ml-service enthält.

Diese Bescheinigung kann später mit dem folgenden Befehl zur Überprüfung des Docker-Images verwendet werden:

valint überprüfen ml-service:latest

Dieser Befehl überprüft die Integrität des Bildes – sowohl des Codes als auch des ML-Modells. Die Überprüfung kann jedes Mal durchgeführt werden, wenn das Image bereitgestellt wird, wodurch sichergestellt wird, dass ein gültiger Container verwendet wird.

Aufbau eines geschützten ML-Ops-Dienstes

Durch die Kombination der in den vorherigen Absätzen gezeigten Fähigkeiten können wir nun zeigen, wie das Gebäude eines ML-Ops-Dienstes geschützt werden kann:

Voraussetzung: Sobald ein Modell ausgewählt ist, erstellen Sie eine Bescheinigung davon:

valint bom git:https://huggingface.co/benjamin/wtp-bert-tiny -o attest

Pipeline erstellen:

1. Überprüfen Sie die Integrität und die Lizenz des Modells in der Build-Pipeline:

Git-Klon https://huggingface.co/benjamin/wtp-bert-tiny valint verifizieren git:wtp-bert-tiny -d att -c verify-license.yml

2. Erstellen Sie den Docker und erstellen Sie eine Bescheinigung davon:

docker build -t ml-service:latest . valint bom ml-service:latest -o attest

3. Bevor Sie das Bild verwenden, überprüfen Sie es:

valint überprüfen ml-service:latest

Dieser Überprüfungsschritt garantiert, dass das bereitgestellte Image dasjenige ist, das mit dem darin enthaltenen überprüften Modell erstellt wurde.

Eine ähnliche Überprüfung kann vor jeder Bereitstellung in Kubernetes mithilfe des Zulassungscontrollers von Scribe durchgeführt werden. 

Software Empfehlungen 

Die Investition in ein Software-Lieferkettensicherheitsprodukt im Jahr 2024, das sowohl den unmittelbaren Anforderungen der Software-Lieferkette als auch den sich entwickelnden Anforderungen von MLOps gerecht wird, ist eine strategische Entscheidung.

Die Investition in eine evidenzbasierte Lösung mit einer flexiblen Richtlinien-Engine würde eine zukünftige Integration mit neuen domänenspezifischen MLOps-Sicherheitstechnologien ermöglichen, wenn diese ausgereift sind.

Warum ist dies ein Scribe-Sicherheits-Blogbeitrag?

Wenn Sie alles bis hierher gelesen haben, sollten Sie die Antwort kennen: Scribe bietet eine beweis-/bescheinigungsbasierte Software-Supply-Chain-Sicherheitslösung mit einer flexiblen und erweiterbaren Richtlinien-Engine. Für einen ausführlichen Anwendungsfall zum Schutz einer MLOps-Pipeline mithilfe von Scribe-Produkten klicken Sie hier hier.