L’IA identifie les vulnérabilités du code, mais qui gère le risque ?

Diagramme montrant la supervision de la sécurité dans GitLab au sein d'un environnement de développement IA

L’identification des vulnérabilités assistée par l’IA évolue rapidement. Cependant, les défis plus complexes liés à l’application des règles, à la gouvernance et à la sécurité de la chaîne d’approvisionnement nécessitent une plateforme holistique comme GitLab.

Récemment, la société Anthropic a annoncé Claude Code Security. Il s’agit d’un système d’IA qui identifie les failles et suggère des correctifs. Le marché a réagi immédiatement. Les actions du secteur de la sécurité ont chuté, et les investisseurs se sont demandé si l’IA risquait de remplacer les outils AppSec et DevSecOps traditionnels.

La question qui préoccupe tout le monde est claire : Si l’IA peut écrire et sécuriser du code, le domaine de la sécurité des applications devient-il obsolète ? La réponse courte est non. Si la sécurité se limitait uniquement à l’analyse du code, cela pourrait être vrai. Mais la sécurité d’entreprise (Enterprise Security) ne s’est jamais résumée à la simple détection. L’identification des vulnérabilités par l’IA progresse certes très vite, mais les défis complexes de l’application des politiques, de la gouvernance et de la sécurisation de la chaîne d’approvisionnement exigent une plateforme globale comme GitLab.

Les vraies questions difficiles en sécurité applicative

Les organisations ne demandent plus si l’IA est capable de trouver des vulnérabilités. Elles posent trois questions bien plus difficiles :

  1. Ce que nous nous apprêtons à livrer est-il réellement sécurisé ?
  2. Notre posture de risque a-t-elle changé à mesure que les environnements et les dépendances évoluent ?
  3. Comment supervisons-nous le code composé par l’IA et les sources tierces, dont nous restons responsables ?

Ces questions nécessitent une solution au niveau de la plateforme. La détection signale le risque, mais la gouvernance détermine ce qui se passe ensuite. GitLab est la couche d’orchestration conçue pour superviser le cycle de vie du logiciel de bout en bout. Elle fournit aux équipes l’application des règles, la visibilité et la capacité d’audit nécessaires pour le développement assisté par l’IA.

Faire confiance à l’IA exige une supervision des risques

Les systèmes d’IA s’améliorent rapidement pour détecter les failles et proposer des correctifs. C’est une avancée significative, mais l’analyse ne remplace pas la responsabilité. Les systèmes d’IA ne peuvent pas appliquer d’eux-mêmes les politiques de l’entreprise. Ils ne peuvent pas non plus définir seuls ce qu’est un risque acceptable.

Ce sont les humains qui doivent définir les limites et les politiques à l’intérieur desquelles les agents opèrent. Il faut établir une séparation des tâches, garantir des pistes d’audit et maintenir des contrôles cohérents. La confiance envers les agents ne découle pas de leur autonomie, mais d’une supervision bien définie. Plus les organisations accordent d’autonomie à l’IA, plus la supervision doit être robuste. Cette supervision n’est pas un frein ou un obstacle ; c’est la fondation qui rend le développement assisté par l’IA fiable à grande échelle.

Les modèles d’IA voient le code – Les plateformes voient le contexte

Un grand modèle de langage (LLM) analyse le code de manière isolée. À l’inverse, une plateforme de sécurité applicative d’entreprise comprend le contexte. Cette différence est fondamentale, car les décisions relatives aux risques dépendent du contexte :

  1. Qui a écrit le changement ?
  2. À quel point l’application est-elle critique pour l’entreprise ?
  3. Comment interagit-elle avec l’infrastructure et les dépendances ?
  4. La vulnérabilité est-elle réellement accessible (reachable) en production ?
  5. Est-elle exploitable dans l’environnement de production ?

Les décisions de sécurité dépendent de ce contexte. Sans lui, la détection génère des alertes bruyantes et des faux positifs. Ces alertes ralentissent le développement. Avec le contexte, les organisations peuvent prioriser (triage) rapidement et gérer les risques efficacement.

Les analyses statiques ne suffisent plus

Le contexte évolue sans cesse à mesure que le logiciel change. Par conséquent, la supervision ne peut se limiter à une décision unique ou à une analyse statique. Les risques logiciels sont dynamiques. Les dépendances changent et les environnements évoluent de manière imprévisible pour une analyse isolée. Un scan “propre” à un instant T ne garantit pas la sécurité future (au moment de la mise en production et au-delà).

La sécurité d’entreprise dépend d’une assurance continue. Il faut intégrer des contrôles directement dans les flux de travail (workflows) de développement. Ces contrôles évaluent le risque pendant la construction, le test et le déploiement du logiciel. La détection fournit l’information, et la supervision continue permet aux organisations de publier leurs produits en toute sécurité.

Superviser l’avenir des agents autonomes (Agentic)

L’IA redéfinit la création de logiciels. La question n’est plus de savoir si nous utiliserons l’IA, mais avec quel niveau de sécurité nous pourrons étendre son utilisation. Les logiciels d’aujourd’hui sont composés de code généré par l’IA, de bibliothèques open source et de dépendances tierces.

Superviser ce qui est publié à partir de toutes ces sources est la partie la plus difficile de la sécurité applicative. Aucun outil destiné uniquement au développeur n’est conçu pour gérer cela. En tant que plateforme d’orchestration intelligente, GitLab a été spécifiquement bâtie pour résoudre ce problème. GitLab Ultimate intègre la supervision et l’application des politiques directement dans les workflows où le logiciel est créé. Ainsi, les équipes de sécurité peuvent superviser à la vitesse de l’IA.

L’IA va accélérer le développement de manière spectaculaire. Les organisations qui en tireront le meilleur parti ne seront pas seulement celles dotées des assistants les plus intelligents. Ce seront celles qui auront instauré la confiance grâce à une supervision robuste.

Pour savoir comment GitLab aide les organisations à superviser et à publier du code généré par l’IA en toute sécurité, contactez-nous.

Pour plus d’informations sur la solution GitLab pour la gestion de la sécurité du code et des applications,
Contactez-nous : gitlab@almtoolbox.com Ou par téléphone : +33 01 84 17 53 28 (France) or 866-503-1471 (USA & Canada)

Notre société a aidé des centaines de clients à passer à Git et GitLab (depuis 2015) ainsi qu’à choisir des outils d’aide au développement logiciel, de gestion de configuration, de CI/CD et de développement sécurisé, y compris avec l’assistance d’outils d’IA et dans des environnements hébergés sur site (Self-hosted).
Nous sommes également les représentants officiels de GitLab en Israël et opérons à l’international depuis 2016.
Pour plus de détails, contactez-nous : gitlab@almtoolbox.com

Cet article a été rédigé par ALM Toolbox, basé notamment sur un article écrit par Omar Azaria de GitLab, et a été adapté par nos soins pour le public francophone.

Liens pertinents :

Sécurité et conformité du code avec GitLab

 

gitlab logo security devsecops

Outre le contrôle de version et le CI/CD, GitLab propose également une variété de tests de sécurité sur votre code propriétaire (code que vous développez) ou sur le code externe que vous utilisez (c’est-à-dire open source), ainsi que des capacités de conformité du code – pour vous aider à vous assurer que vous faites l’utilisation appropriée et légale de toutes les bibliothèques open source et des extraits de code.

En fait, dans GitLab, vous pouvez également exécuter les tests sur le code lui-même, puis tout voir à l’aide d’un tableau de bord central qui montre tout organisé.
Le tableau de bord de GitLab vous permet également d’exécuter certaines actions sur les résultats et les découvertes, et de partager les informations entre toutes les parties prenantes (ou quiconque est autorisé à les regarder en fonction des autorisations).

gitlab security dashboard
Tableau de bord de sécurité de GitLab (vue au niveau du groupe). Cliquez pour agrandir.

Les tests peuvent être exécutés à partir de GitLab CI (l’outil CI/CD intégré fourni avec GitLab) et peuvent également être connectés à d’autres outils CI tels que Jenkins.

Les tests peuvent être exécutés même si le code se trouve dans un autre outil SCM (tel que git, GitHub, Bitbucket, etc.).

Certains des tests sont dynamiques, ce qui signifie qu’ils ne s’exécutent pas sur le code lui-même, mais sur l’application ou le site Web qui exécute le code.

Les tests peuvent être exécutés à la fois depuis un serveur GitLab privé (auto-hébergé) ou depuis le cloud / SaaS (par exemple, gitlab dot com).

Vous pouvez voir ici un aperçu des fonctionnalités d’analyse de sécurité pertinentes :

Remarque : la plupart des fonctionnalités ici nécessitent une licence GitLab Ultimate. Si vous avez besoin d’un devis, contactez-nous (nos coordonnées sont ci-dessous).

Feature

Description

Container Scanning Exécutez une analyse de sécurité pour vous assurer que les images Docker de votre application ne présentent aucune vulnérabilité connue dans l’environnement où votre code est livré.
Dependency List Identifiez les composants inclus dans votre projet en accédant à la liste des dépendances (également appeléeBill of Material ou BOM), qui est souvent demandée par les équipes de sécurité et de conformité.
Dependency Scanning Protégez votre application des vulnérabilités qui affectent les dépendances dynamiques en détectant automatiquement les bogues de sécurité bien connus dans vos bibliothèques incluses.
Static Application Security Testing (SAST) Recherche de code source vulnérable ou de bogues de sécurité bien connus dans les bibliothèques incluses dans l’application. Les résultats sont ensuite affichés dans la demande de fusion et dans la vue Pipeline.
Ce test prend en charge les langages de code suivants:  C/C++, Apex, .NET, Java, Go, JS, Python, PHP, Swift, TypeScript, NodeJS et plus.
Dynamic Application Security Testing (DAST) Assurez-vous que vous n’êtes pas exposé aux vulnérabilités des applications Web telles que l’authentification cassée, les scripts intersites ou l’injection SQL.
Secret Detection Vérification des secrets et des informations d’identification involontairement commis dans le code git et l’historique.
API Fuzzing Testez les API dans vos applications pour trouver les vulnérabilités et les bogues qui manquent aux processus d’assurance qualité traditionnels.
Coverage Fuzzing Trouvez des vulnérabilités de sécurité et des bogues dans votre application que les processus d’assurance qualité traditionnels manquent, prenant en charge
C/C++, Go, Java, JS, Python et autres langages de code.
Security Dashboard Gagnez en visibilité sur les correctifs prioritaires en identifiant et en suivant les tendances des risques de sécurité dans l’ensemble de votre organisation.
License Compliance Vérifiez que les licences de vos dépendances sont compatibles avec votre application(e.g. GPL, BSD, Apache, MIT licenses etc.), et les approuver ou les refuser.

 

ALMtoolbox est le  représentant officiel de GitLab, Hashicorp  en France et dans d’autres pays.

Contactez pour toute question, un devis ou même une license d’évaluation:
par email  devops.fr@almtoolbox.com ou +33 1 84 17 53 28
 Nous fournissons des conseils GitLab, la migration, aidons les clients à choisir les licences les mieux adaptées, un hébergement privé, un support de qualité et rapide, le développement de modules complémentaires GitLab et nous soutenons et vendons une variété d’outils DevSecOps et ALM.

 

First release: December 2021