Étapes pratiques pour protéger votre pipeline MLOps

Imaginez la prochaine réunion du conseil d'administration. En tant que responsable de la sécurité dans votre organisation, vous présenterez votre présentation standard avec les risques, les atténuations et les incidents. Ensuite, l'un des membres du conseil d'administration demandera : comment vous préparez-vous à protéger les nouvelles technologies d'IA et les pipelines MLOps que l'entreprise utilise déjà ? 

Voici votre réponse.

L’IA entraîne de nouveaux risques

Les pipelines MLOps (parfois également appelés AI Ops), bien que semblables aux systèmes de traitement de données traditionnels dans leur valeur pour les organisations, présentent des vulnérabilités distinctes. Les attaquants peuvent viser à insérer des biais, manipuler les résultats du modèle ou compromettre l'intégrité des données ou des outils, visant à compromettant la fiabilité des modèles et faussant les processus de prise de décision. ATLAS, un cadre de l'organisation MITRE pour la protection MLOps, souligne la nécessité de mesures de sécurité sur mesure qui répondent à ces défis.

L’IA entraînera de nouvelles réglementations

Le domaine en plein essor de l’IA et du MLOps fait l’objet d’une surveillance croissante de la part des régulateurs du monde entier. En l'absence d'une législation fédérale complète aux États-Unis, les conseils d'organismes comme le National Institute of Standards and Technology (NIST), comme le Cadre de gestion des risques liés à l'intelligence artificielle 1.0, offre un aperçu des futurs cadres réglementaires. Le cadre met l’accent sur la fiabilité des systèmes d’IA, y compris les sept caractéristiques définies des systèmes d’IA dignes de confiance : sécurité, sécurité et résilience, explicabilité et interprétabilité, confidentialité améliorée, équitable avec gestion des biais préjudiciables, responsable et transparent, aussi bien que valide et fiable.

Les MLOps et la chaîne d'approvisionnement logicielle ont beaucoup en commun

Les similitudes entre les vulnérabilités du pipeline MLOps et les risques traditionnels de la chaîne d’approvisionnement logicielle sont frappantes. Les deux domaines sont confrontés à des menaces de compromission visant à porter atteinte à l’intégrité du processus de développement et à la sécurité du produit final. La modification malveillante d'un LLM est assez similaire à la modification malveillante d'une dépendance logicielle ; modifier de manière malveillante le logiciel exécutant le LLM est, en fait, une attaque de la chaîne d'approvisionnement logicielle ; Les exigences de responsabilité, de transparence et de confiance évoquées dans le monde de l’IA sont exactement ce qui sous-tend les exigences SBOM dans le monde de la chaîne d’approvisionnement logicielle.

L'organisation MITRE publie des modèles de cybersécurité. MITRE a récemment publié le modèle Atlas pour la protection MLOps, disponible ici. Un aperçu du modèle est donné ci-dessous :

Tout comme dans le domaine « traditionnel » de la cybersécurité, les réglementations en matière d’IA et de MLOps sont encore en cours d’élaboration. Le respect de ces réglementations émergentes faciliterait la protection des actifs MLOps existants ainsi que l'attestation de la conformité des processus MLOps avec les meilleures pratiques existantes et émergentes. Les organisations devront attester de l'intégrité de leur modèle ainsi que de son impartialité.

Il existe des technologies qui serviront les deux domaines

Les technologies qui garantissent l'intégrité des données, du code et des outils peuvent fournir les contrôles d'intégrité requis pour la sécurité de la chaîne d'approvisionnement logicielle des MLOps et des DevOps.

Les technologies qui fournissent des mesures de transparence et de confiance envers les logiciels peuvent fournir des valeurs similaires pour les MLOps. 

Technologie de sécurité de la chaîne d'approvisionnement basée sur les attestations

Le concept de protection de la chaîne d’approvisionnement logicielle basée sur des preuves est simple : un artefact logiciel ne doit pas être fiable à moins qu’il n’y ait suffisamment de preuves de sa fiabilité. La mise en œuvre de ce concept implique des outils de collecte de preuves, un moteur politique qui évalue les preuves pour les vérifier, des alertes de violations et des recommandations d'atténuation, ainsi que des mécanismes de partage qui permettent la transparence et la collaboration. Le cadre intégral est un exemple académique d’une telle solution. La plateforme de chaîne d'approvisionnement logicielle de Scribe est, entre autres, une manifestation commerciale de cette technologie et a étendu sa technologie pour prendre en charge les défis ML-Ops.

L'approche fondée sur les preuves de Scribe est indépendante des spécificités des preuves ; ainsi, la même technologie peut servir la protection MLOps, par exemple :

• Assurer l’intégrité des logiciels et l’intégrité du pipeline ML.
• Assurer l'intégrité des dépendances open source et l'intégrité du modèle d'IA.
• Évaluer les rapports SAST pour garantir des rapports sur les outils de test spécifiques à l'IA (par exemple, tests de biais).
• Partager des SBOM et des évaluations de politiques, ainsi que des évaluations de politiques MLBOM et MLOps. 

Technologie de chaîne d'approvisionnement du logiciel de sécurité Scribe pour l'IA/ML-Ops

Le MITRE ATLAS et la technologie Scribe

Voici une cartographie des capacités actuelles de Scribe par rapport à la carte d'attaque de MITRE ATLAS :

Étape d'attaque	Techniques	La solution du scribe
Développement des ressources des attaquants	Publier des ensembles de données empoisonnés Données de formation sur le poison.	Intégrité des données: Attester des ensembles de données consommés et vérifier la source et le contenu des ensembles de données. Attester des données de formation et vérifier le contenu et la source des données de formation.
Accès initial	Compromis de la chaîne d’approvisionnement ML	Intégrité des données et du code : Attester des données, des modèles, des logiciels et des configurations des pipelines ML. Application de la politique du pipeline ML : Attester des actions et vérifier les politiques en conséquence (par exemple, kit de processus de publication, tests, modèles d'accès)
Accès initial, impact	Éviter le modèle ML (par exemple, requêtes spécialement conçues)	Suivi précis des pipelines : Suivez les ressources et détectez les anomalies des modèles d'accès au pipeline ML (FS-Tracker)
Internationaux	Interpréteur de commandes et de scripts	Suivi précis des pipelines : Suivez les ressources et détectez les anomalies des modèles d'accès au pipeline ML (FS-Tracker)
Persistence	Données de formation sur le poison	Intégrité des données: Attester des données de formation, vérifier le contenu et la source des données de formation.
Persistance, Mise en scène d'une attaque ML	Modèle ML de porte dérobée	Intégrité des données: Attester du cycle de vie du modèle ML, vérifier lors de l'utilisation.
Impact positif	Utilisation abusive du système pour un effet externe	Politiques au niveau du système : Attester du comportement et des caractéristiques du système et appliquer les politiques en conséquence (par exemple, coûts de calcul, modèles d'accès).

Voici une cartographie des atténuations MITRE par rapport à la technologie Scribe :

ID d’atténuation MITRE	Atténuation	La solution du scribe
AML.M0005	Contrôler l'accès aux modèles ML et aux données au repos	Suivi précis des pipelines : Suivez les ressources et détectez les anomalies des modèles d'accès au pipeline ML (FS-Tracker)
AML.M0007	Désinfecter les données d'entraînement	Intégrité des données: Attester et vérifier les données utilisées pour la formation
AML.M0011	Restreindre le chargement de la bibliothèque	Intégrité des données et du code : Attester et vérifier le chargement du modèle de données et de la bibliothèque de codes.
AML.M0013	Signature du code	Intégrité du code : Attester et vérifier le code utilisé.
AML.M0014	Vérifier les artefacts ML	Intégrité des données et du code : Attester et vérifier le chargement du modèle de données et de la bibliothèque de codes.
AML.M0016	Analyse de vulnérabilité	Analyse des vulnérabilités, évaluation des politiques : Attester de l’exécution d’outils tels que l’analyse des vulnérabilités. Évaluer les politiques concernant ces attestations. Analysez les vulnérabilités en fonction des attestations SBOM collectées à partir du pipeline ML.

Signature et vérification des ensembles de données et des modèles ML à l'aide de Valint

Valint est le puissant outil CLI de Scribe pour générer et valider des attestations. Valint peut être utilisé pour signer et vérifier des ensembles de données et des modèles ML.

Mise en situation :

Nous voulons utiliser le modèle HuggingFace wtp-bert-minuscule. Afin d'éviter de compromettre le modèle, nous souhaitons le signer et le vérifier avant utilisation. La création d'une attestation (preuve signée) peut être effectuée avec la commande suivante :

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

Cette commande créera une attestation signée pour le dépôt du modèle. L'attestation sera stockée dans un magasin d'attestations (dans ce cas – un dossier local) et sera signée (dans ce cas – à l'aide de la signature sans clé Sigstore).

Une utilisation typique du modèle serait de cloner le dépôt et d'utiliser ses fichiers. La vérification de l'intégrité du modèle immédiatement après le téléchargement peut être effectuée avec les commandes suivantes :

git clone git:https://huggingface.co/benjamin/wtp-bert-tiny valint vérifier git:wtp-bert-tiny

La vérification de l'intégrité du modèle avant chaque utilisation peut être effectuée avec la commande suivante :

Valint vérifie git: wtp-bert-tiny

Notes: 

• Une approche similaire peut être utilisée pour signer et vérifier des ensembles de données.
• L’une des caractéristiques des modèles ML est leur taille énorme. Pour éviter de télécharger et de manipuler des fichiers volumineux inutiles, un meilleures pratiques consiste à télécharger uniquement les fichiers nécessaires. Ce cas d'utilisation est pris en charge par Valint, qui prend en charge la signature uniquement d'un dossier ou d'un fichier spécifique.

Vérification des politiques sur les modèles ML

Scribe's Valint est un puissant outil de vérification des politiques. L’un des moyens de gérer les risques consiste à appliquer des politiques. Dans la section suivante, nous démontrerons comment réduire les risques en appliquant une politique de licence sur les modèles ML utilisés. 

Supposons que nous autorisons uniquement l'utilisation de la licence MIT dans notre projet. Une fois configuré, Valint peut le vérifier :

valint vérifier git:wtp-bert-tiny -d att -c verify-license.yml

Cette commande utilise le vérifier la licence politique qui est définie comme suit :

attester : cocosign : politiques : - nom : activation de la stratégie ML : vrai modules : - nom : vérifier le type de licence : vérifier-artefact activer : vrai entrée : signé : vrai format : attest-cyclonedx-json rego : chemin : vérifier-hf -licence.rego

La politique mise en œuvre dans le vérifier-hf-license.rego Le fichier extrait de l'attestation signée l'ID du modèle HuggingFace, extrait les informations de l'API HuggingFace sur le modèle et vérifie qu'il s'agit bien du MIT.

Un flux similaire peut être utilisé pour vérifier les licences des ensembles de données open source.

Cas d'utilisation : protection d'un service ML-Ops réel

Un service ML-Ops fait partie d'une application qui permet un accès facile aux modèles d'IA ; les utilisateurs du service n'ont qu'à formuler leurs demandes, et toutes les modalités pratiques d'accès au modèle ML sont effectuées en coulisses par le service.

Exemple:

Nous voulons produire et utiliser un service qui expose l'accès aux "l'orientation" package open source (en termes simples, ce package permet une meilleure utilisation des grands modèles linguistiques (LLM) en exécutant des chaînes de requêtes au lieu d'une seule invite).

Le service sera une image Docker contenant le code du service et le modèle. Nous baserons notre code sur le projet Andromeda-chain. Le projet enveloppe la bibliothèque de guidage avec un service et crée une image Docker avec l'application.

Voici la version de base du Dockerfile :

FROM python:3.10 COPIER ./requirements.cpu.txt conditions.txt RUN pip3 install -r conditions.txt RUN mkdir models \ cd models \ git clone https://huggingface.co/api/models/benjamin/wtp-bert- tiny COPY ./guidance_server guidance_server WORKDIR guidance_server # Définir le point d'entrée CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "9000"]

C'est assez simple ; lors de la construction du docker, les dépendances de code sont installées, le modèle est installé et le code du service est copié dans l'image Docker. 

Une fois l'image construite, nous pouvons en créer une attestation signée avec la commande Valint suivante :

valint bom ml-service:dernier -o attester

Cette commande génère une attestation signée qui contient un SBOM détaillé de l'image Docker nommée ml-service.

Cette attestation peut être utilisée ultérieurement pour vérifier l'image Docker, à l'aide de la commande suivante :

valint vérifier ml-service : dernier

Cette commande vérifie l'intégrité de l'image – à la fois le code et le modèle ML. La vérification peut être effectuée à chaque déploiement de l'image, garantissant ainsi l'utilisation d'un conteneur valide.

Création d'un service ML-Ops protégé

En combinant les capacités démontrées dans les paragraphes précédents, nous pouvons maintenant démontrer comment protéger la construction d'un service ML-Ops :

Prérequis : Une fois un modèle sélectionné – créez une attestation de celui-ci :

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

Construire un pipeline :

1. Vérifiez l'intégrité et la licence du modèle dans le pipeline de build :

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

2. Construisez le docker et créez une attestation de celui-ci :

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

3. Avant d'utiliser l'image, vérifiez-la :

valint vérifier ml-service : dernier

Cette étape de vérification garantit que l'image déployée est celle créée avec le modèle vérifié à l'intérieur.

Une vérification similaire peut être effectuée avant chaque déploiement dans Kubernetes à l'aide du contrôleur d'admission de Scribe. 

Recommandation 

Investir dans un produit de sécurité de la chaîne d’approvisionnement logicielle en 2024 qui répond à la fois aux exigences immédiates de la chaîne d’approvisionnement logicielle et aux demandes évolutives du MLOps est un choix stratégique.

Investir dans une solution fondée sur des preuves avec un moteur de politique flexible permettrait une intégration future avec les technologies de sécurité MLOps émergentes spécifiques à un domaine à mesure qu'elles mûrissent.

Pourquoi s'agit-il d'un article de blog Scribe Security ?

Vous devriez connaître la réponse si vous avez tout lu jusqu'ici : Scribe fournit une solution logicielle de sécurité de la chaîne d'approvisionnement basée sur des preuves/attestations avec un moteur de politique flexible et extensible. Pour un cas d'utilisation élaboré de protection d'un pipeline MLOps à l'aide des produits Scribe, appuyez sur ici.