Risques liés à la sécurité de l'IA : ce que les équipes DevSecOps doivent savoir pour sécuriser les systèmes d'IA
Les risques liés à la sécurité de l'IA ne se limitent plus au comportement des modèles ou à la confidentialité des données. Aujourd'hui, ils affectent également la manière dont les logiciels sont écrits, testés, développés et déployés. À mesure que les outils de codage IA, les systèmes d'IA agents et les flux de travail basés sur l'IA font leur apparition, ces risques s'aggravent. SDLCLes équipes DevSecOps sont confrontées à un nouveau type de risque : un code plus rapide, une automatisation plus rapide et des erreurs plus rapides.
Cependant, cela ne signifie pas que les équipes doivent ralentir l'adoption de l'IA. Au contraire, elles ont besoin de mesures de sécurité adaptées au rythme du développement assisté par l'IA. Ce guide explique les principaux risques de sécurité liés à l'IA, leur manifestation dans les flux de travail d'ingénierie réels et comment les équipes peuvent réduire leur exposition au niveau du code, des dépendances et des secrets. pipelineet agents.
Pour un aperçu plus complet de la manière dont l'IA modifie le paysage des menaces, consultez notre guide sur Cybersécurité de l'IA.
Quels sont les risques liés à la sécurité de l'IA ?
Les risques liés à la sécurité de l'IA sont des faiblesses, des menaces ou des modes de défaillance qui apparaissent lors de la conception, de l'entraînement, de l'intégration ou de l'utilisation de l'intelligence artificielle au sein de systèmes réels. Ces risques peuvent affecter les modèles, les données, les invites, les API, le code, pipelineet les outils qui les relient.
Le Recommandations du NCSC sur l'IA et la cybersécurité explique que la cybersécurité est une exigence fondamentale pour des systèmes d'IA sûrs et fiables. De même, Cadre de gestion des risques NIST AI elle offre aux organisations une structure pour gérer les risques liés à l'IA grâce à la gouvernance, la mesure et des contrôles pratiques.
Pour les équipes DevSecOps, le problème est plus spécifique. L'IA fait désormais partie intégrante de la chaîne de livraison logicielle. Elle écrit du code, suggère des dépendances, génère des configurations, appelle des API et agit parfois de manière autonome. Par conséquent, les risques liés à la sécurité de l'IA doivent être gérés au sein même de l'IA. SDLC, et pas seulement au niveau du modèle.
Pourquoi les risques liés à la sécurité de l'IA sont différents aujourd'hui
Les risques traditionnels en cybersécurité proviennent généralement de code écrit par des humains, de logiciels vulnérables, d'identifiants faibles ou d'infrastructures mal configurées. Ces risques existent toujours. Cependant, l'IA modifie leur vitesse d'apparition et la difficulté à les détecter.
Le code généré par l'IA peut sembler correct, mais ne pas passer les contrôles d'autorisation. Un assistant de programmation IA peut suggérer un package vulnérable. Un flux de travail automatisé peut appeler le mauvais outil, accéder au mauvais fichier ou exposer une information confidentielle dans un journal. De plus, les systèmes d'IA dépendent souvent du contexte, des invites, des connecteurs et des outils externes, ce qui multiplie les points de vulnérabilité en matière de sécurité.
Le Top 10 de l'OWASP pour les candidatures au LLM Ce système met en lumière des risques tels que l'injection de vulnérabilités, la divulgation d'informations sensibles, les problèmes liés à la chaîne d'approvisionnement et les pouvoirs d'intervention excessifs de l'IA. Ces catégories sont utiles car elles établissent un lien entre le comportement de l'IA et les problèmes concrets de sécurité des applications.
En d'autres termes, les risques liés à la sécurité de l'IA ne concernent pas uniquement le modèle lui-même, mais l'ensemble du système qui l'entoure.
Principaux risques de sécurité liés à l'IA pour les équipes DevSecOps
Voici les risques les plus importants liés à l'utilisation de l'IA dans le développement, la sécurité des applications et… CI/CD workflows.
1. Vulnérabilités du code généré par l'IA
Les outils de programmation par IA peuvent générer du code fonctionnel mais non sécurisé. Par exemple, ils peuvent créer des requêtes SQL sans paramétrage adéquat, omettre la validation des entrées ou implémenter une logique d'authentification faible.
Cela s'explique par le fait que de nombreux systèmes d'IA génèrent des modèles de code probables à partir de données d'entraînement. Or, un code probable n'est pas toujours un code sécurisé. En pratique, le modèle peut reproduire des exemples non sécurisés car ils sont fréquents dans les dépôts publics.
Des exemples courants comprennent:
- Injection SQL
- Script inter-site
- Contrôles d'autorisation manquants
- Gestion de session faible
- désérialisation non sécurisée
- Protection CSRF manquante
Par conséquent, le code généré par l'IA doit être considéré comme non fiable jusqu'à ce qu'il réussisse. SAST, vérifications et examens des politiques.
Suggestion de lien interne : reliez cette section à votre article sur AI SAST.
2. Risques liés à la chaîne d'approvisionnement et à la dépendance
Les outils d'IA ne se contentent pas de générer du code. Ils suggèrent également des paquets, des versions, des scripts et des commandes d'installation. Cela crée un lien direct entre les recommandations de l'IA et les risques liés à la chaîne d'approvisionnement logicielle.
Par exemple, un outil d'IA peut suggérer :
- Un emballage obsolète
- Une dépendance typosquattée
- Un nom de colis halluciné
- Un paquet contenant des scripts d'installation suspects
- Une bibliothèque vulnérable mais encore largement utilisée
De plus, les attaquants peuvent exploiter ce comportement en enregistrant des noms de paquets que les outils d'IA sont susceptibles d'inventer. Ce risque, souvent appelé « slopsquatting », transforme l'hallucination du modèle en une attaque ciblant la chaîne d'approvisionnement des paquets.
Pour réduire ce risque, les équipes ont besoin de SCA, la détection des logiciels malveillants, l'application des politiques de dépendance et l'analyse de l'accessibilité. Ils devraient également utiliser des signaux d'exploitabilité tels que EPSS et les renseignements sur l'exploitation active provenant de CISCatalogue des vulnérabilités exploitées connues.
3. Divulgation des secrets dans les flux de travail d'IA
La divulgation de données confidentielles représente l'un des risques de sécurité les plus concrets liés à l'IA. Les développeurs intègrent fréquemment du contexte dans les outils d'IA. Ce contexte peut inclure des clés API, des jetons, des identifiants, des URL ou des configurations internes.
De plus, le code généré par l'IA peut inclure des espaces réservés qui semblent réels, ou pire encore, copier des secrets dans les fichiers sources. pipeline scripts ou journaux. Une fois que les secrets sont entrés dans l'historique Git ou CI/CD Les journaux, quant à eux, peuvent rester exploitables longtemps après leur création. commit.
Les points d'exposition courants comprennent :
- Historique de l'invite
- Code généré
- Git commits
- CI/CD journaux
- IaC fichiers
- Images de conteneurs
- Espaces de travail partagés
Pour cette raison, les équipes devraient combiner l'analyse au niveau de l'IDE, pre-commit vérifications, analyses de l'historique du référentiel, CI/CD Analyse des journaux et révocation automatique.
Suggestion de lien interne : reliez cette section à votre produit de sécurité des secrets ou à un contenu connexe.
4. Mauvaise utilisation des agents et outils d'IA
IA agentique Cela introduit un nouveau niveau de risque car les agents ne se contentent pas de suggérer des actions. Ils peuvent aussi agir.
Un agent d'IA peut exécuter des commandes shell, modifier des fichiers, appeler des API, ouvrir pull requestsmodifier les flux de travail d'intégration continue ou interagir avec les services cloud. Bien que cela génère d'importants gains de productivité, cela accroît également le risque d'erreurs.
Les principaux risques comprennent :
- Exécution de shell non sécurisée
- Clés API avec autorisations excessives
- Modifications de code non autorisées
- mauvaise configuration du connecteur MCP ou API
- Appels d'outils en dehors du champ d'application approuvé
- L'accès à l'environnement au-delà des exigences de la tâche
La catégorie « Top 10 » de l’OWASP LLM relative aux pouvoirs excessifs est particulièrement pertinente ici. Si un agent dispose de trop d’accès, une instruction erronée, une injection de prompt ou un outil compromis peut se transformer en véritable incident de sécurité.
5. CI/CD et Pipeline Risques
Le code généré par l'IA finit par atteindre pipelineÀ ce stade, le risque passe du code source aux builds, aux artefacts, aux secrets, aux dépendances et aux flux de travail de déploiement.
Par exemple, une modification assistée par l'IA peut :
- Ajouter une étape de compilation non sécurisée
- Modifier un flux de travail GitHub Actions
- Extraire un package malveillant lors de l'installation
- Inscrire les secrets dans les journaux de compilation
- Désactiver un contrôle de sécurité
- Modifier la logique de déploiement
En conséquence, CI/CD La sécurité devient essentielle à l'adoption de l'IA. Pipeline guardrails devrait bloquer les comportements non sécurisés avant leur mise en production. Pour plus de détails, consultez notre contenu sur CI/CD Sécurité et software supply chain security.
6. Fuite de données et injection rapide
L'injection de prompts est l'un des risques de sécurité les plus connus en IA, mais elle est souvent mal comprise. Il ne s'agit pas uniquement d'un problème lié aux chatbots. Ce risque peut affecter tout flux de travail d'IA qui reçoit des données externes et les utilise ensuite pour orienter ses actions.
Par exemple, une description de problème, un fichier README, un ticket d'assistance ou une page de documentation de dépendance malveillants peuvent contenir des instructions cachées. Si un agent d'IA lit ce contenu et l'exécute, l'attaquant peut influencer les appels d'outils, les modifications de code ou l'accès aux données.
Les fuites de données peuvent se produire de manière similaire. Le modèle peut révéler des informations sensibles, résumer des fichiers privés ou transmettre des données confidentielles à des services externes. Par conséquent, les systèmes d'IA nécessitent un filtrage rapide, des contrôles des résultats, des restrictions d'utilisation et une définition claire des données auxquelles ils peuvent accéder.
Risques liés à la sécurité de l'IA dans le monde entier SDLC
Les risques liés à la sécurité de l'IA apparaissent à différentes étapes du cycle de vie du logiciel. L'essentiel est de sécuriser chaque étape, et pas seulement l'application finale.
| SDLC Stage | Risques liés à la sécurité de l'IA | Exemple | Contrôle recommandé |
|---|---|---|---|
| IDE | Code généré par IA non sécurisé | Un assistant de programmation IA suggère une logique d'authentification non sécurisée. | En temps réel SAST et des retours sur le codage sécurisé. |
| Commit | Révélation des secrets | Un jeton apparaît dans le code généré ou commit l'histoire. | Détection des secrets, pre-commit vérifications et révocation automatique. |
| Pull Request | Contournement de la politique | Le code généré modifie les règles de contrôle d'accès sans vérification. | PR guardrails et l'application des politiques. |
| Se construisent | Dépendance malveillante | Un paquet suggéré par l'IA présente un comportement d'installation suspect. | SCA, la détection de logiciels malveillants et les vérifications des politiques de dépendance. |
| CI/CD | Pipeline manipulation | Un agent modifie les fichiers de flux de travail ou les scripts de déploiement. | CI/CD Contrôles de sécurité et détection des anomalies. |
| Runtime | Injection rapide ou fuite de données | Les données externes permettent à un flux de travail d'IA de révéler un contexte sensible. | Contrôles rapides, restrictions d'accès et surveillance. |
Risques liés à la sécurité de l'IA par rapport aux risques traditionnels en matière de cybersécurité
La cybersécurité traditionnelle reste importante. Cependant, l'IA introduit de nouveaux comportements qui nécessitent des contrôles différents.
| Région | Risques traditionnels en matière de cybersécurité | Risques liés à la sécurité de l'IA |
|---|---|---|
| Code | Vulnérabilités écrites par des humains. | Génération de schémas non sécurisés par l'IA à une vitesse accrue. |
| Dépendances | Paquets vulnérables connus. | Paquets suggérés par l'IA : hallucinations, malveillance ou dangerosité. |
| Secrets Playa Esmeralda Resort & Spa | Identifiants accidentellement commitédité par les développeurs. | Des secrets copiés dans des invites, du code généré ou des journaux. |
| Outils | Utilisation abusive manuelle des outils de développement. | Des agents autonomes utilisent mal les outils ou les API. |
| Pipelines | Mal configuré CI/CD workflows. | Modifications du flux de travail générées par l'agent ou automatisation non sécurisée. |
Exemples concrets de risques liés à la sécurité de l'IA
Les risques liés à la sécurité de l'IA ne sont pas théoriques. Plusieurs cadres publics et travaux de recherche suivent désormais ces questions de manière plus formelle.
Le Référentiel des risques liés à l'IA du MIT Ce catalogue recense plus de 1 700 risques liés à l’IA, couvrant diverses causes et domaines. Parallèlement, l’OWASP propose des catégories pratiques pour les risques liés aux applications LLM, notamment l’injection rapide de vulnérabilités, la divulgation d’informations sensibles, les failles de sécurité de la chaîne d’approvisionnement et les pouvoirs excessifs.
Pour les équipes DevSecOps, les exemples les plus pertinents apparaissent souvent dans le domaine de la livraison de logiciels :
- Des outils d'IA suggèrent du code vulnérable
- Agents d'IA modifiant les fichiers de flux de travail
- Les dépendances générées par l'IA introduisent une exposition de la chaîne d'approvisionnement
- Des secrets qui fuient à travers les invites, les journaux ou commits
- Flux de travail d'agents faisant appel à des outils en dehors du périmètre approuvé
En bref, les risques liés à la sécurité de l'IA deviennent beaucoup plus graves lorsque les systèmes d'IA peuvent accéder au code, aux identifiants, aux packages, pipelines, ou infrastructure.
Comment atténuer concrètement les risques liés à la sécurité de l'IA
La meilleure façon de réduire les risques liés à la sécurité de l'IA est de considérer le développement assisté par l'IA comme faisant partie intégrante du système. SDLCCela signifie analyser en amont, valider fréquemment et appliquer les politiques là où les développeurs travaillent réellement.
1. Analyser le code généré par l'IA dans l'IDE
Les développeurs devraient recevoir des notifications de sécurité pendant qu'ils écrivent ou acceptent du code généré par l'IA. Cela réduit les changements de contexte et permet de corriger les problèmes avant qu'ils n'atteignent Git.
Utilisation:
- SAST dans l'IDE
- Explications des vulnérabilités en ligne
- Suggestions de correctifs sécurisés
- Remédiation tenant compte des politiques
Ceci est particulièrement important pour les assistants de codage IA, où des suggestions non sécurisées peuvent rapidement s'introduire dans le code source.
2. Valider les dépendances avant la compilation
Les dépendances suggérées par l'IA doivent être vérifiées avant leur installation ou leur distribution. Par conséquent, les équipes doivent appliquer des contrôles de dépendances pendant le développement et CI/CD.
Utilisation:
- SCA
- Détection des logiciels malveillants
- Détection de typosquatting
- Notation EPSS
- Analyse d'accessibilité
- Blocage basé sur des politiques
Cela permet de prioriser les colis qui représentent un risque réel, et non une simple exposition théorique.
3. Détecter et révoquer automatiquement les secrets
L'analyse des données sensibles doit couvrir bien plus que le code source. Les flux de travail assistés par l'IA peuvent révéler des identifiants à de nombreux endroits.
Utilisation:
- Pre-commit balayage
- Analyse de l'historique du dépôt
- Pipeline analyse des journaux
- IaC balayage
- Numérisation d'images de conteneurs
- Révocation automatique
De ce fait, les équipes réduisent le délai entre l'exposition et le confinement.
4. Appliquer Guardrails in CI/CD
Guardrails Il convient de déterminer si une modification est suffisamment sûre pour être mise en œuvre. Le signalement est utile, mais le blocage est nécessaire en cas de risque critique.
Guardrails doit couvrir :
- Nouvelles vulnérabilités critiques
- Secrets Playa Esmeralda Resort & Spa
- Dépendances malveillantes
- Paquets non épinglés ou non approuvés
- Modifications non sécurisées du flux de travail
- Manquant SBOMs
- Violations de politique
De plus, les équipes devraient commencer par le mode de rapport uniquement en cas de besoin, puis passer au blocage à mesure que leur confiance grandit.
5. Surveiller le comportement de l'outil agentique
Les systèmes d'IA multi-agents nécessitent une observabilité. Si un agent peut modifier des fichiers, déclencher des compilations ou appeler des API, les équipes doivent savoir ce qu'il a fait, quand il l'a fait et si cette action était prévue.
Moniteur:
- Appels d'outils
- modifications du fichier de flux de travail
- Activité d'écriture du dépôt
- Destinations du réseau
- Accès aux secrets
- Pull request création
- Pipeline déclenche
Sans cette visibilité, il devient difficile de faire confiance à l'autonomie des agents.
Comment Xygeni contribue à réduire les risques liés à la sécurité de l'IA
Xygeni se concentre sur la sécurisation du développement assisté par l'IA tout au long de la chaîne de livraison logicielle. Plutôt que de traiter le risque lié à l'IA comme une catégorie distincte, il relie le code, les dépendances, les secrets, pipelineet le contexte commercial.
Par exemple :
- SAST permet de détecter rapidement le code non sécurisé généré par l'IA.
- SCA Il valide les dépendances et détecte les paquets malveillants.
- Secrets Security détecte les informations d'identification exposées dans les référentiels et pipelines.
- CI/CD Sécurité Applique les politiques avant que des changements dangereux ne soient mis en œuvre.
- Détection d’Anomalies identifie les comportements inhabituels dans les flux de travail de développement et de livraison.
- ASPM Elle permet de corréler les résultats en une vue d'ensemble des risques afin que les équipes puissent prioriser ce qui compte.
C’est important car les risques liés à la sécurité de l’IA sont par nature transversaux. Une dépendance vulnérable, un jeton exposé et une modification non sécurisée du flux de travail peuvent sembler isolés dans certains outils. Cependant, combinés, ils peuvent constituer une faille de sécurité bien plus importante.
Cadres de gestion des risques liés à la sécurité de l'IA à connaître
Plusieurs cadres de référence aident les équipes à structurer leur travail.
Le Cadre de gestion des risques NIST AI Aide les organisations à cartographier, mesurer, gérer et gouverner les risques liés à l'IA. Il est utile pour le leadership, la conformité et les programmes de gestion des risques.
Le Top 10 de l'OWASP pour les candidatures au LLM est plus pratique pour les équipes AppSec car elle correspond directement aux risques techniques tels que l'injection rapide, l'exposition de données sensibles, les vulnérabilités de la chaîne d'approvisionnement et l'abus de pouvoir.
Le Conseils du NCSC en matière d'IA et de cybersécurité est utile aux responsables de la sécurité qui doivent comprendre comment l'IA modifie les risques cybernétiques organisationnels.
Ensemble, ces ressources mettent en évidence un point clair : la sécurité de l’IA doit être gérée à travers les personnes, les processus, les systèmes et les flux de travail de livraison de logiciels.
Liste de contrôle : Comment réduire les risques liés à la sécurité de l’IA
Utilisez cette liste de contrôle comme point de départ pratique.
| Zone de contrôle | Quoi Faire | Pourquoi ça compte |
|---|---|---|
| Code généré par l'IA | Courir SAST dans l'IDE, le PR et CI/CD pipeline. | Empêche la mise en production de code non sécurisé. |
| Dépendances | Utilisez le SCA, détection de logiciels malveillants, EPSS et accessibilité. | Bloque les paquets risqués suggérés par l'IA. |
| Secrets Playa Esmeralda Resort & Spa | Scanner commits, journaux, historique, IaC, et des conteneurs. | Réduit l'exposition et l'utilisation abusive des identifiants. |
| CI/CD | Imposer pipeline guardrails et les portes de contrôle des politiques. | Empêche les compilations et les déploiements non sécurisés. |
| Outils d'agent | Surveiller les appels d'outils, les accès API et les modifications de flux de travail. | Limite les excès d'initiative et les comportements inattendus. |
| La gestion des risques | Utilisez le ASPM corréler les résultats entre les différentes couches. | Aide les équipes à se concentrer sur les risques commerciaux réels. |
Points clés à retenir
- Les risques liés à la sécurité de l'IA affectent désormais le code, les dépendances, les secrets, pipelineet agents.
- Les outils AppSec traditionnels restent nécessaires, mais ils doivent s'exécuter plus tôt et avec davantage de contexte.
- Le code généré par l'IA doit être considéré comme non fiable jusqu'à sa validation.
- Les flux de travail des agents IA ont besoin guardrails, les autorisations et l'observabilité.
- Les équipes DevSecOps ont besoin d'une visibilité unifiée sur l'ensemble de l'ensemble du système. SDLC gérer efficacement les risques liés à l'IA.
FAQ : Risques liés à la sécurité de l'IA
Quels sont les risques liés à la sécurité de l'IA ?
Les risques liés à la sécurité de l'IA sont des menaces ou des failles qui apparaissent lors de la conception, de l'intégration ou de l'utilisation des systèmes d'IA. Ils peuvent affecter les modèles, les données, les invites, le code, les dépendances, les API, etc. pipelines.
Quels sont les principaux risques de sécurité liés à l'IA pour les équipes DevSecOps ?
Les principaux risques comprennent le code généré par l'IA non sécurisé, les dépendances vulnérables, la divulgation de secrets, l'injection de paquets, les autorisations excessives des agents et les éléments non sécurisés. CI/CD automatisation.
Pourquoi les risques liés à la sécurité de l'IA sont-ils différents des risques traditionnels en matière de cybersécurité ?
Les systèmes d'IA peuvent générer du code, suggérer des dépendances, appeler des outils et agir de manière autonome. Par conséquent, les risques apparaissent plus rapidement et à davantage de niveaux du système. SDLC.
Comment les équipes peuvent-elles réduire les risques liés à la sécurité de l'IA ?
Les équipes peuvent réduire les risques en analysant le code généré par l'IA, en validant les dépendances, en détectant les secrets et en appliquant les politiques de sécurité. CI/CD guardrails, en surveillant le comportement des agents et en corrélant les résultats par le biais de ASPM.
Le code généré par l'IA est-il sûr ?
Le code généré par l'IA n'est pas sûr par défaut. Il doit être examiné, analysé, testé et validé avant sa mise en production.
Réflexions finales : Les risques liés à la sécurité de l’IA nécessitent SDLC-Contrôles de niveau
L'IA modifie la vitesse et la nature des risques logiciels. Elle aide les équipes à développer plus rapidement, mais elle introduit également de nouvelles voies d'accès au code non sécurisé, aux secrets exposés, aux dépendances non sécurisées et à l'automatisation risquée dans la chaîne de livraison.
Par conséquent, la sécurité de l'IA ne peut être gérée uniquement par la gouvernance des modèles ou des documents de politique. Elle nécessite des contrôles pratiques au sein même de l'IA. SDLC: Commentaires sur l'IDE, SAST, SCA, détection de secrets, CI/CD guardrails, détection d'anomalies et ASPM-corrélation de niveau.
Les équipes qui gèrent efficacement les risques liés à la sécurité de l'IA ne seront pas celles qui freinent son adoption, mais celles qui mettent en place un cadre de sécurité adéquat.
