Une chose que je vois trop souvent : une équipe a un DevSecOps mature côté app classique, et zéro contrôle dédié sur le pipeline MLOps qui sert le modèle de scoring de fraude ou l'assistant IA en prod. Du coup la surface d'attaque IA passe à travers. Voici les 7 points que je vérifie quand j'audite un pipeline MLOps en 2026.
Pourquoi le DevSecOps classique ne suffit pas
Le pipeline MLOps a des artefacts que le SAST/DAST/SCA ne sait pas voir :
- Des datasets (training, validation, test) qui peuvent être empoisonnés.
- Des features stores qui peuvent fuiter des données entre tenants.
- Des modèles (.pt, .onnx, .pkl) qui sont des binaires exécutables non scannés.
- Des notebooks qui contiennent souvent des secrets et du code mal review.
- Des infrastructures GPU souvent moins durcies que les apps classiques.
Ignorer ça, c'est avoir un coffre-fort à la porte avec une fenêtre ouverte derrière.
Les 7 points de contrôle, du dataset au déploiement
1. Provenance et intégrité des datasets
À l'entrée du pipeline, chaque dataset doit avoir :
- Source identifiée (interne, fournisseur tiers, open dataset). Une provenance non documentée = à refuser.
- Hash de contenu stocké et vérifié à chaque utilisation.
- Licence vérifiée (problème majeur pour les datasets open scrapés sans regarder).
- Politique d'usage documentée (PII présentes ? RGPD-compatible ?).
Sans ça, vous ne pouvez ni détecter un data poisoning ni répondre à une demande légale sur l'origine d'une décision automatisée.
2. Scan secrets / PII sur les datasets
Les datasets contiennent souvent des PII non anticipées (emails dans un dataset de logs, noms dans un dataset de conversations). Avant l'entraînement :
- Scan automatisé PII (Presidio, scrubadub, regex métier).
- Quarantaine des datasets non-conformes.
- Process documenté pour les exceptions légitimes.
3. Sécurité du feature store
Si vous avez un feature store (Feast, Tecton, custom), les contrôles :
- Cloisonnement par tenant strict (la feature d'un client ne fuit pas vers un autre).
- Audit log sur les lectures sensibles.
- Time-travel safety (ne pas leaker du futur dans le training).
- Accès basé sur les rôles côté ML engineers et côté services consumers.
4. Notebooks et expérimentation
Le notebook est le maillon faible. À mettre :
- Pre-commit secrets scanning sur les notebooks (Gitleaks supporte).
- Politique : aucun notebook avec des credentials ne va en main. Si besoin de creds, secrets manager.
- Review obligatoire avant de promouvoir un notebook en pipeline de prod.
5. Entraînement dans un environnement isolé
L'entraînement ne doit pas tourner avec un accès illimité au cloud. Pour chaque pipeline d'entraînement :
- Service account dédié, principe du moindre privilège.
- Réseau restreint (pas d'internet sortant non whitelisté pour le job de training).
- Logs structurés, exportés, immuables.
- Limites de ressources strictes (timeout, mémoire, GPU).
6. Scanning des artefacts modèles
Un fichier .pt ou .pkl est un binaire qui peut contenir du code malveillant (pickle exécute du Python à l'unpickling). À avoir :
- Format safe par défaut (safetensors plutôt que pickle quand possible).
- Scan des modèles sortants (ModelScan, Picklescan).
- Signature des modèles validés (Sigstore, Cosign sur l'image qui les contient).
- Registry interne avec contrôle d'accès (MLflow, Vertex Model Registry, custom).
7. Déploiement et inférence
Au déploiement :
- Le modèle déployé est celui qui a passé l'évaluation sécurité (red teaming, voir AI red teaming programme).
- L'endpoint d'inférence est rate-limité, authentifié, monitoré.
- Les inputs et outputs sont loggés (avec attention RGPD si PII).
- Détection en runtime des inputs adversariaux (voir HiddenLayer dans la stack).
Le mapping NIST AI RMF / MITRE ATLAS
Pour chaque point, vous pouvez le mapper aux référentiels :
- NIST AI RMF : fonctions GOVERN, MAP, MEASURE, MANAGE — chaque point ci-dessus alimente une ou plusieurs sous-catégories.
- MITRE ATLAS : techniques d'attaque (ML Supply Chain Compromise, Poison Training Data, ML Model Theft) — chaque contrôle réduit une technique précise.
Avoir cette traçabilité contrôle ↔ référentiel rend votre programme défendable face à un auditeur externe et lisible pour la direction. Voir NIST AI RMF + MITRE ATLAS utilisés conjointement.
Les pièges que je vois revenir
Croire qu'un MLOps "managé" (Vertex, SageMaker, Azure ML) couvre la sécu
Le cloud provider couvre l'infra (chiffrement disque, isolation tenant côté hardware). Il ne couvre pas vos contrôles métier (provenance dataset, scan PII, signature modèle). Le partage des responsabilités s'arrête à votre service account.
Vouloir tout faire en un coup
Les 7 points ne se mettent pas en place en un sprint. Ordre que je propose : 1 (provenance) → 5 (isolation training) → 2 (scan PII) → 4 (notebooks) → 7 (déploiement) → 6 (artefacts) → 3 (feature store). En vrai, 6-12 mois pour une équipe qui démarre.
Ne pas connecter au DevSecOps existant
Le pipeline MLOps doit hériter des contrôles DevSecOps classiques (SAST sur le code des notebooks/training, SCA sur les libs Python, secrets scanning partout). Pas deux pipelines parallèles. Un pipeline avec des contrôles spécifiques greffés. Voir stack DevSecOps minimale.
Sous-estimer la dette de notebook
Beaucoup d'équipes ML ont 100+ notebooks d'expérimentation jamais nettoyés, avec des credentials, des extraits de données client. Une fuite vient souvent de là. Inventorier, scanner, archiver ou nettoyer.
Mon avis en 1 ligne
Le pipeline MLOps a sa propre surface d'attaque. Sans les 7 contrôles ci-dessus, votre DevSecOps même excellent ne sécurise pas votre IA. Et plus vous mettez en prod tôt sans ces contrôles, plus la remédiation est chère après. Compter 3-6 mois pour atteindre un niveau défendable sur les 7 points, en parallèle de la roadmap produit.