[{"data":1,"prerenderedAt":826},["ShallowReactive",2],{"/fr-fr/blog/2025-owasp-top-10-whats-changed-and-why-it-matters":3,"navigation-fr-fr":37,"banner-fr-fr":463,"footer-fr-fr":473,"blog-post-authors-fr-fr-Fernando Diaz":711,"blog-related-posts-fr-fr-2025-owasp-top-10-whats-changed-and-why-it-matters":725,"next-steps-fr-fr":765,"blog-promotions-fr-fr":774},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":19,"description":20,"extension":23,"externalUrl":24,"featured":13,"heroImage":17,"isFeatured":13,"meta":25,"navigation":26,"path":27,"publishedDate":19,"rawbody":28,"seo":29,"slug":15,"stem":32,"tagSlugs":33,"tags":35,"template":14,"updatedDate":24,"__hash__":36},"blogPosts/fr-fr/blog/2025-owasp-top-10-whats-changed-and-why-it-matters.yml","OWASP Top 10 2025 : les changements importants",[7],"fernando-diaz",[9],"Fernando Diaz","La Fondation OWASP a publié la [huitième édition de son célèbre classement des « 10 principaux risques de sécurité » pour 2025](https://owasp.org/Top10/2025/0x00_2025-Introduction/), qui présente les changements significatifs dans le paysage de la sécurité des applications. Basée sur l'analyse de plus de 175 000 enregistrements de vulnérabilités ou expositions communes (CVE) et sur les retours de professionnels de la sécurité du monde entier, cette mise à jour aborde les vecteurs d'attaque modernes. Découvrez les changements apportés, leur importance et comment protéger vos systèmes.\n\n> :bulb: Rejoignez GitLab Transcend le 10 février pour découvrir comment l'IA agentique transforme la livraison de logiciels. Apprenez des témoignages de nos clients et explorez comment accélérer votre propre parcours de modernisation. [Inscrivez-vous dès maintenant.](https://about.gitlab.com/fr-fr/events/transcend/virtual/)\n\n## Quelles sont les nouveautés de 2025 ?\n\nDepuis la dernière publication du classement en 2021, les changements apportés en 2025 représentent un tournant majeur dans la sécurité des applications. Deux catégories entièrement nouvelles ont été ajoutées au classement, et deux autres ont été regroupées, ce qui met en évidence les risques émergents que les tests traditionnels ne détectent souvent pas.\n\nCes changements sont visibles dans le graphique ci-dessous :\n\n![OWASP Top 10 – changements de 2021 à 2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639428/tbekzibeqylorwqrkdau.png)\n\n### Deux nouvelles catégories\n\n* **A03 : Défaillances de la chaîne d'approvisionnement logicielle**. Cette catégorie s'inscrit dans la continuité de la catégorie de 2021 « Composants vulnérables et obsolètes » et englobe l'ensemble de la chaîne d'approvisionnement logicielle, y compris les dépendances, les systèmes de build et l'infrastructure de distribution. Malgré le plus faible nombre d'occurrences dans les données de test, cette catégorie présente les scores moyens d'exploitation et d'impact les plus élevés issus des CVE.\n* **A10 : Mauvaise gestion des conditions exceptionnelles**. Cette catégorie se concentre sur la gestion inappropriée des erreurs, les erreurs logiques et les scénarios d'échec ouvert. Cette catégorie traite de la manière dont les systèmes réagissent aux conditions anormales.\n\n### Changements majeurs dans le classement\n\n* Les erreurs de configuration de sécurité ont bondi de la 5e place (2021) à la 2e place (2025) et affectent désormais 3 % des applications testées.\n* La falsification de requêtes côté serveur (SSRF) a été consolidée dans la catégorie A01 : Contrôle d'accès insuffisant.\n* Les défaillances cryptographiques sont passées de la 2e à la 4e place.\n* L'injection est passée de la 3e à la 5e place.\n* La conception non sécurisée est passée de la 4e à la 6e place.\n\n## Pourquoi ces changements ?\n\nLa méthodologie OWASP combine une analyse basée sur les données avec le point de vue de la communauté. L'édition 2025 a analysé 589 énumérations de faiblesses communes (CWE), ce qui représente une augmentation substantielle par rapport aux quelque 400 CWE de 2021. Cette progression reflète la complexité croissante des systèmes logiciels modernes et la nécessité de détecter les menaces émergentes.\n\nLe volet relatif à l'enquête menée auprès de la communauté répond à une limitation fondamentale : les données de test concernent essentiellement le passé. Au moment où les chercheurs en sécurité développent des méthodologies de test et les intègrent dans des outils automatisés, des années peuvent s'être écoulées. Les deux catégories déterminées par la communauté garantissent que les risques émergents identifiés par les professionnels de première ligne sont inclus, même s'ils ne sont pas encore répandus dans les données de test automatisées.\n\nL'augmentation des erreurs de configuration de sécurité met en évidence une tendance du secteur : la sécurité basée sur la configuration, tandis que les défaillances de la chaîne d'approvisionnement logicielle reconnaissent l'essor des attaques sophistiquées ciblant les paquets compromis.\n\n## Détecter et gérer les vulnérabilités avec GitLab Ultimate\n\nGitLab Ultimate fournit des [scans de sécurité](https://docs.gitlab.com/user/application_security/detect/) complets pour détecter les risques dans les catégories du classement OWASP Top 10 2025. Par exemple, la plateforme de bout en bout analyse le code source, les dépendances et les définitions d'infrastructure de votre projet. Elle utilise également l'[analyseur Advanced de test statique de sécurité des applications (SAST)](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/) pour détecter les failles d'injection, les défaillances cryptographiques et les modèles de conception non sécurisés dans le code source. L'[analyse de l'Infrastructure as Code (IaC)](https://docs.gitlab.com/user/application_security/iac_scanning/) identifie les erreurs de configuration de sécurité dans vos définitions de déploiement. La [détection de secrets](https://docs.gitlab.com/user/application_security/secret_detection/) empêche la fuite d'identifiants, et l'[analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/) signale les bibliothèques qui présentent des vulnérabilités connues dans votre chaîne d'approvisionnement logicielle, ce qui répond directement à la nouvelle catégorie A03 relative aux défaillances de la chaîne d'approvisionnement logicielle.\n\nDe plus :\n\n* Les [tests dynamiques de sécurité des applications (DAST)](https://docs.gitlab.com/user/application_security/dast/) analysent votre application déployée afin de rechercher des contrôles d'accès défaillants, des échecs d'authentification et des vulnérabilités d'injection en simulant des vecteurs d'attaque.\n* Les [tests de sécurité des API](https://docs.gitlab.com/user/application_security/api_security/) analysent vos points de terminaison API à la recherche de faiblesses de validation des entrées et de contournements d'authentification.\n* Le [test de l'API web par injection de données aléatoires](https://docs.gitlab.com/user/application_security/api_fuzzing/) teste comment votre application gère les conditions exceptionnelles en générant des intrants inattendus, ce qui s'inscrit directement dans la nouvelle catégorie A10 relative à la mauvaise gestion des conditions exceptionnelles.\n\nLes scans de sécurité s'intègrent de manière transparente dans votre [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) et s'exécutent lorsque le code fait l'objet d'un push depuis une branche de fonctionnalité afin que les équipes de développement puissent corriger les vulnérabilités avant qu'elles n'atteignent la production. Les résultats de sécurité sont consolidés dans le [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/), où les équipes de sécurité peuvent classer, analyser et suivre les corrections. GitLab vous permet également de tirer parti des agents d'IA tels que l'[agent GitLab Duo Security Analyst](https://about.gitlab.com/fr-fr/blog/vulnerability-triage-made-simple-with-gitlab-security-analyst-agent/), disponible dans GitLab Duo Agent Platform, pour déterminer rapidement les vulnérabilités les plus critiques et savoir comment les traiter.\n\nLes [politiques d'approbation des merge requests](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) et les [politiques d'exécution des pipelines](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) vous permettent d'appliquer des contrôles supplémentaires afin de garantir que l'analyse de sécurité s'exécute de manière cohérente dans toute votre organisation. Les équipes du Succès client et des Services professionnels de GitLab veillent à ce que vous tiriez profit d'un investissement dans GitLab en temps opportun.\n\nLivrez des logiciels sécurisés plus rapidement grâce aux tests de sécurité dans la même plateforme que les équipes de développement utilisent déjà. Pour en savoir plus, consultez notre [page dédiée aux solutions de test de sécurité des applications](https://about.gitlab.com/fr-fr/solutions/application-security-testing/).\n\n## OWASP Top 10 2025 : analyse complète\n\n### A01 : Contrôle d'accès insuffisant\n\n#### Définition\n\nÉchecs dans l'application des politiques qui empêchent les utilisateurs d'agir en dehors de leurs autorisations prévues et entraînent des accès non autorisés.\n\n#### Impact sur votre système\n\n* Divulgation d'informations non autorisée\n* Destruction complète de données ou modification de données\n* Escalade de privilèges (des utilisateurs obtiennent des droits d'administrateur)\n* Consultation ou modification des comptes d'autres utilisateurs\n* Accès API depuis des sources non autorisées ou non fiables\n\n#### CWE notables\n\n* [CWE-22 : Traversée de chemin](https://cwe.mitre.org/data/definitions/22.html)\n* [CWE-200 : Exposition d'informations sensibles à un acteur non autorisé](https://cwe.mitre.org/data/definitions/200.html)\n* [CWE-352 : Falsification de requête cross-site (CSRF)](https://cwe.mitre.org/data/definitions/352.html)\n\n### A02 : Erreur de configuration de sécurité\n\n#### Définition\n\nSystèmes, applications ou services cloud configurés de manière incorrecte du point de vue de la sécurité.\n\n#### Impact sur votre système\n\n* Exposition d'informations sensibles via des messages d'erreur\n* Accès non autorisé via des comptes par défaut\n* Services ou fonctionnalités inutiles activés\n* Correctifs de sécurité obsolètes\n* Le serveur n'envoie pas d'en-têtes ou de directives de sécurité\n\n#### CWE notables\n\n* [CWE-16 : Configuration](https://cwe.mitre.org/data/definitions/16.html)\n* [CWE-521 : Exigences de mot de passe faibles](https://cwe.mitre.org/data/definitions/521.html)\n* [CWE-798 : Utilisation d'identifiants codés en dur](https://cwe.mitre.org/data/definitions/798.html)\n\n### A03 : Défaillances de la chaîne d'approvisionnement logicielle\n\n#### Définition\n\nPannes ou compromissions dans la construction, la distribution ou la mise à jour de logiciels par le biais de vulnérabilités ou de modifications malveillantes dans les dépendances, les outils ou les processus de build.\n\n#### Impact sur votre système\n\n* Paquets compromis introduisant des portes dérobées\n* Code malveillant injecté pendant les processus de build\n* Dépendances vulnérables propagées dans votre application\n* Utilisation de composants issus de sources non fiables en production\n* Absence de suivi des modifications au sein de votre chaîne d'approvisionnement \n\n#### CWE notables\n\n* [CWE-1395 : Dépendance à un composant tiers vulnérable](https://cwe.mitre.org/data/definitions/1395.html)\n* [CWE-1104 : Utilisation de composants tiers non maintenus](https://cwe.mitre.org/data/definitions/1104.html)\n\n### A04 : Défaillances cryptographiques\n\n#### Définition\n\nÉchecs liés à l'absence de cryptographie, à une cryptographie insuffisamment forte, à la fuite de clés cryptographiques et aux erreurs connexes.\n\n#### Impact sur votre système\n\n* Exposition de données sensibles (mots de passe, cartes de crédit, dossiers médicaux)\n* Attaques de type homme du milieu (man-in-the-middle)\n* Violation de données en raison d'un chiffrement faible\n* Compromission de clés entraînant une exposition à l'échelle du système\n* Échecs de conformité réglementaire (RGPD, PCI DSS)\n\n#### CWE notables\n\n* [CWE-327 : Utilisation d'un algorithme cryptographique défaillant ou risqué](https://cwe.mitre.org/data/definitions/327.html)\n* [CWE-330 : Utilisation de valeurs insuffisamment aléatoires](https://cwe.mitre.org/data/definitions/330.html)\n\n### A05 : Injection\n\n#### Définition\n\nFailles système qui permettent aux attaquants d'insérer du code ou des commandes malveillants (SQL, NoSQL, commandes OS, LDAP, etc.) dans les programmes.\n\n#### Impact sur votre système\n\n* Perte ou corruption de données par injection SQL\n* Compromission complète de la base de données\n* Prise de contrôle du serveur par injection de commandes\n* Attaques de cross-site scripting (XSS)\n* Divulgation d'informations\n* Déni de service\n\n#### CWE notables\n\n* [CWE-89 : Injection SQL](https://cwe.mitre.org/data/definitions/89.html)\n* [CWE-78 : Injection de commande dans le système d'exploitation](https://cwe.mitre.org/data/definitions/78.html)\n\n### A06 : Conception non sécurisée\n\n#### Définition\n\nFaiblesses dans la conception qui représentent différents échecs, exprimées sous forme de contrôles manquants ou inefficaces (défauts architecturaux plutôt que bogues d'implémentation).\n\n#### Impact sur votre système\n\n* Flux de réinitialisation de mot de passe faibles\n* Étapes d'autorisation manquantes\n* Logique métier défectueuse permettant des contournements\n* Modélisation des menaces inadéquate conduisant à des vulnérabilités\n* Modèles de conception qui échouent dans des scénarios d'attaque\n\n#### CWE notables\n\n* [CWE-209 : Génération de messages d'erreur avec des informations sensibles](https://cwe.mitre.org/data/definitions/209.html)\n* [CWE-522 : Identifiants avec protection insuffisante](https://cwe.mitre.org/data/definitions/522.html)\n* [CWE-656 : Dépendance à la sécurité par l'obscurité](https://cwe.mitre.org/data/definitions/656.html)\n\n### A07 : Échecs d'authentification\n\n#### Définition\n\nVulnérabilités qui permettent aux attaquants de tromper les systèmes pour qu'ils reconnaissent des utilisateurs invalides ou incorrects comme légitimes.\n\n#### Impact sur votre système\n\n* Prise de contrôle de compte et bourrage d'identifiants (credential stuffing) \n* Détournement de session\n* Attaques par force brute (brute force attacks) réussies\n* Exploitation de mécanismes de récupération de mot de passe faibles\n* Contournement de l'authentification multifacteur\n\n#### CWE notables\n\n* [CWE-287 : Authentification inappropriée](https://cwe.mitre.org/data/definitions/287.html)\n* [CWE-306 : Authentification manquante pour fonction critique](https://cwe.mitre.org/data/definitions/306.html)\n* [CWE-521 : Exigences de mot de passe faibles](https://cwe.mitre.org/data/definitions/521.html)\n\n### A08 : Défaillances d'intégrité des logiciels ou des données\n\n#### Définition\n\nUn code et une infrastructure qui ne parviennent pas à se protéger contre le code ou les données invalides ou non fiables traités comme fiables et valides.\n\n#### Impact sur votre système\n\n* Mises à jour non signées permettant l'injection de code malveillant\n* Désérialisation non sécurisée conduisant à l'exécution de code à distance\n* Compromission du pipeline CI/CD\n* Mécanismes de mise à jour automatique exploités\n* Artefacts logiciels altérés\n\n#### CWE notables\n\n* [CWE-345 : Vérification insuffisante de l'authenticité des données](https://cwe.mitre.org/data/definitions/345.html)\n* [CWE-346 : Erreur de validation d'origine](https://cwe.mitre.org/data/definitions/346.html)\n* [CWE-347 : Vérification inappropriée de la signature cryptographique](https://cwe.mitre.org/data/definitions/347.html)\n\n### A09 : Échecs de journalisation et d'alerte de sécurité\n\n#### Définition\n\nUne journalisation et surveillance insuffisantes avec des alertes inadéquates, ce qui complique la réponse rapide.\n\n#### Impact sur votre système\n\n* Non-détection des attaques pendant de longues périodes\n* Enquête sur les violations impossible\n* Violations de conformité dues à l'absence de pistes d'audit\n* Réponse aux incidents retardée\n* Incapacité à déterminer l'étendue de la compromission\n\n#### CWE notables\n\n* [CWE-117 : Neutralisation inappropriée des données de sortie pour les logs](https://cwe.mitre.org/data/definitions/117.html)\n* [CWE-532 : Insertion d'informations sensibles dans le fichier log](https://cwe.mitre.org/data/definitions/532.html)\n* [CWE-778 : Journalisation insuffisante](https://cwe.mitre.org/data/definitions/778.html)\n\n### A10 : Mauvaise gestion des conditions exceptionnelles\n\n#### Définition\n\nProgrammes qui ne parviennent pas à prévenir et détecter des situations inhabituelles et imprévisibles, ni à y réagir, ce qui conduit à des plantages, des comportements inattendus ou des vulnérabilités.\n\n#### Impact sur votre système\n\n* Divulgation d'informations via des messages d'erreur détaillés\n* Déni de service dû à des exceptions non gérées\n* Corruption d'état due à une gestion inappropriée des erreurs\n* Conditions de concurrence exploitées\n* Systèmes échouant en mode ouvert au lieu de fermé\n* Plantages d'application exposant des données sensibles\n\n#### CWE notables\n\n* [CWE-248 : Exception non capturée](https://cwe.mitre.org/data/definitions/248.html)\n* [CWE-390 : Détection d'une condition d'erreur sans action](https://cwe.mitre.org/data/definitions/390.html)\n* [CWE-391 : Condition d'erreur non vérifiée](https://cwe.mitre.org/data/definitions/391.html)\n\n## Bonnes pratiques de prévention et de correction\n\nGitLab fournit des outils qui vous permettent non seulement de trouver et de corriger rapidement les vulnérabilités du classement OWASP Top 10, mais également de les empêcher d'atteindre votre système de production. Suivez les bonnes pratiques ci-dessous pour améliorer et maintenir votre posture de sécurité :\n\n#### Scans de sécurité automatisés pour tous les dépôts\n\n* Effectuez une [analyse SAST](https://docs.gitlab.com/user/application_security/sast/) pour détecter tôt dans le cycle de vie du développement les modèles de conception non sécurisés tels que le stockage de mots de passe en texte clair, la gestion inadéquate des erreurs et le chiffrement manquant lors de la revue de code.\n* Effectuez une [détection de secrets](https://docs.gitlab.com/user/application_security/secret_detection/) pour identifier les identifiants dans les fichiers de configuration, les variables d'environnement et le code, en empêchant le stockage de mots de passe en texte clair et en garantissant que les secrets sont correctement gérés via les variables CI/CD de GitLab avec masquage et chiffrement.\n* Effectuez une [analyse DAST](https://docs.gitlab.com/user/application_security/dast/) pour détecter les vulnérabilités de contrôle d'accès défaillant.\n* Effectuez une [analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/) pour analyser les dépendances du projet dans les bases de données de vulnérabilités, identifier les CVE connus dans les dépendances directes et transitives sur plusieurs gestionnaires de paquets (npm, pip, Maven, etc.).\n* Effectuez une [analyse de conteneurs](https://docs.gitlab.com/user/application_security/container_scanning/) pour analyser les images Docker à la recherche de couches de base et de paquets vulnérables et garantir la sécurité de la chaîne d'approvisionnement des conteneurs avant le déploiement.\n* Effectuez une [analyse de l'IaC](https://docs.gitlab.com/user/application_security/iac_scanning/) pour vérifier vos fichiers de définition d'infrastructure à la recherche de vulnérabilités connues.\n* Tirez parti des [outils de sécurité relatifs aux API](https://docs.gitlab.com/user/application_security/api_security/) pour sécuriser et protéger les API Web contre les accès non autorisés, les utilisations abusives et les attaques.\n* Effectuez un [test de l'API web par injection de données aléatoires](https://docs.gitlab.com/user/application_security/api_fuzzing/) pour découvrir les bogues et les vulnérabilités potentielles que d'autres processus d'assurance qualité pourraient manquer.\n\n![Résultats de sécurité dans une merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639431/zs6xh8hz6mud3vuig3dy.png)\n\n\u003Cp>\u003C/p>\n\u003Ccenter>\u003Ci>Affichez les vulnérabilités détectées dans une merge request avec les diffs de la branche de fonctionnalité à la branche principale.\u003C/i>\u003C/center>\n\n#### Votre posture de sécurité\n\n* Générez une [nomenclature logicielle (SBOM)](https://docs.gitlab.com/user/application_security/dependency_list/) pour une visibilité complète des dépendances et des exigences de conformité.\n* Tirez parti du [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/) pour trier et classer les vulnérabilités dans une vue consolidée des vulnérabilités de sécurité trouvées dans votre code source.\n* Agissez rapidement sur les vulnérabilités en utilisant les [conseils de correction détaillés](https://docs.gitlab.com/user/application_security/vulnerabilities/) et les [données d'évaluation des risques](https://docs.gitlab.com/user/application_security/vulnerabilities/risk_assessment_data/).\n* Utilisez l'[inventaire de sécurité](https://docs.gitlab.com/user/application_security/security_inventory/) pour visualiser les actifs que vous devez sécuriser et comprendre les actions que vous devez entreprendre pour améliorer la sécurité.\n* Tirez parti du [Centre de conformité](https://docs.gitlab.com/user/compliance/compliance_center/) pour gérer les rapports d'adhésion aux normes de conformité, les rapports de violations et les frameworks de conformité.\n\n![Inventaire de sécurité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639429/e9vnakc8yiyjbjm8aj7s.png)\n\n\u003Cp>\u003C/p>\n\u003Ccenter>\u003Ci>Utilisez l'inventaire de sécurité pour afficher les scanners de sécurité activés et les vulnérabilités.\u003C/i>\u003C/center>\n\n#### Configuration de la prévention et maintenance de la documentation\n\n* Configurez des [politiques de sécurité](https://docs.gitlab.com/user/application_security/policies/) pour bloquer les merges ou les déploiements lorsque des vulnérabilités de gravité élevée sont détectées dans les dépendances, afin d'appliquer automatiquement des normes de sécurité.\n* Utilisez les [frameworks de conformité](https://docs.gitlab.com/user/compliance/compliance_frameworks/) pour appliquer les normes de sécurité organisationnelles via des vérifications automatiques de politiques qui contrôlent que les exigences de chiffrement, les pratiques de gestion des identifiants et les implémentations de workflows sécurisés sont respectées.\n* Utilisez le wiki GitLab et la documentation du dépôt pour maintenir les principes de conception de sécurité, les modèles approuvés et la documentation relative aux décisions architecturales qui guident les développeurs vers des [implémentations selon le principe Secure by Design](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/).\n* Implémentez des règles d'approbation de merge request qui nécessitent une revue par un architecte de sécurité pour les fonctionnalités qui impliquent l'authentification, l'autorisation, le chiffrement ou le traitement de données sensibles afin de garantir une validation de sécurité au niveau de la conception.\n* Créez des tests pour vérifier la validation des entrées et les approches de liste d'autorisation pour les chemins de fichiers.\n* Utilisez les tickets et epics GitLab pour documenter les exigences de sécurité et les modèles de menaces pendant la phase de conception afin de créer une documentation suivie des décisions de sécurité et de garantir que les considérations de sécurité sont traitées avant le début de l'implémentation.\n\n![Tableau de bord des politiques de sécurité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639429/q4eelq3rqt0oonzhwoyb.png)\n\n\u003Ccenter>\u003Ci>Affichez et définissez des politiques de sécurité au niveau de l'instance, du groupe ou du projet.\u003C/i>\u003C/center>\n\n#### Utilisation de l'IA\n\n* Utilisez les [suggestions de code](https://docs.gitlab.com/user/project/repository/code_suggestions/) pour obtenir des conseils proactifs pendant le développement. Les suggestions comprennent des modèles de conception sécurisés tels que le hachage approprié des mots de passe (bcrypt, Argon2), des mécanismes de stockage chiffrés et une gestion appropriée des erreurs qui ne divulgue pas d'informations sensibles.\n* Utilisez l'[agent GitLab Duo Security Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/) pour examiner les vulnérabilités de conception non sécurisées détectées en contexte. L'agent explique les implications architecturales, évalue les risques en fonction du modèle de menace de votre application et fournit des stratégies de correction qui traitent les défauts de conception d'origine plutôt que les symptômes.\n* [Révisez votre code à l'aide de l'IA](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code) pour garantir des normes de revue de code cohérentes dans votre projet.\n\n![Agent GitLab Duo Security Analyst](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639430/kqvgagepwleabt5zdkco.png)\n\n\u003Cp>\u003C/p>\n\u003Ccenter>\u003Ci>Tirez parti de l'agent GitLab Duo Security Analyst pour classer et évaluer rapidement les vulnérabilités de sécurité.\u003C/i>\u003C/center>\n\n## Points clés à retenir pour les équipes de développement\n\n* **La sécurité de la chaîne d'approvisionnement est essentielle** : avec l'ajout de la catégorie A03 et les scores d'impact élevés, la sécurisation de votre chaîne d'approvisionnement logicielle est obligatoire. Implémentez le suivi SBOM, l'analyse des dépendances et la vérification de l'intégrité dans l'ensemble de votre pipeline.\n* **La configuration est plus importante que jamais** : désormais à la 2e place du classement, la sécurité basée sur la configuration est devenue un vecteur d'attaque principal. Automatisez la vérification de la configuration et implémentez l'IaC avec la sécurité intégrée.\n* **Les menaces traditionnelles persistent** : bien que l'injection et les défaillances cryptographiques aient chuté dans le classement, elles restent critiques. Ne les reléguez donc pas au second plan.\n* **La gestion des erreurs est une question de sécurité** : la nouvelle catégorie A10 souligne que la gestion des échecs de votre application est une préoccupation de sécurité. Implémentez une gestion sécurisée des erreurs dès le départ.\n* **Les tests doivent évoluer** : la couverture CWE élargie (589 contre 400 en 2021) signifie que les stratégies de test doivent être complètes. Combinez les SAST, les DAST, l'analyse du code source et des tests de pénétration manuels pour garantir une couverture efficace.\n\n> Explorez les [solutions de sécurité et de gouvernance GitLab](https://about.gitlab.com/fr-fr/solutions/application-security-testing/) et notre [documentation sur l'analyse de sécurité](https://docs.gitlab.com/ee/user/application_security/) pour commencer à renforcer votre posture de sécurité dès aujourd'hui.","security",{"featured":13,"template":14,"slug":15},false,"BlogPost","2025-owasp-top-10-whats-changed-and-why-it-matters",{"heroImage":17,"authors":18,"date":19,"title":5,"description":20,"category":11,"tags":21,"body":10},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1759320418/xjmqcozxzt4frx0hori3.png",[9],"2026-02-02","Découvrez les nouveaux risques liés à la chaîne d'approvisionnement et à la gestion des erreurs, les changements dans le classement et les stratégies de correction au sein des 10 catégories.",[11,22],"open source","yml",null,{},true,"/fr-fr/blog/2025-owasp-top-10-whats-changed-and-why-it-matters","seo:\n  config:\n    noIndex: false\n  title: 'OWASP Top 10 2025 : les changements importants'\n  description: Découvrez les risques liés à la chaîne d'approvisionnement et à la\n    gestion des erreurs, les changements dans le classement et les stratégies de\n    correction.\n  ogImage: https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1759320418/xjmqcozxzt4frx0hori3.png\ncontent:\n  heroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1759320418/xjmqcozxzt4frx0hori3.png\n  authors:\n    - Fernando Diaz\n  date: 2026-02-02\n  title: 'OWASP Top 10 2025 : les changements importants'\n  description: Découvrez les nouveaux risques liés à la chaîne d'approvisionnement et à la\n    gestion des erreurs, les changements dans le classement et les stratégies de\n    correction au sein des 10 catégories.\n  category: security\n  tags:\n    - security\n    - open source\n  body: >-\n    La Fondation OWASP a publié la [huitième édition de son célèbre classement\n    des « 10 principaux risques de sécurité » pour\n    2025](https://owasp.org/Top10/2025/0x00_2025-Introduction/), qui présente\n    les changements significatifs dans le paysage de la sécurité des\n    applications. Basée sur l'analyse de plus de 175 000 enregistrements de\n    vulnérabilités ou expositions communes (CVE) et sur les retours de\n    professionnels de la sécurité du monde entier, cette mise à jour aborde les\n    vecteurs d'attaque modernes. Découvrez les\n    changements apportés, leur importance et comment protéger vos systèmes.\n\n\n    > :bulb: Rejoignez GitLab Transcend le 10 février pour découvrir comment l'IA agentique transforme la livraison de logiciels. Apprenez des témoignages de nos clients et explorez comment accélérer votre propre parcours de modernisation. [Inscrivez-vous dès maintenant.](https://about.gitlab.com/fr-fr/events/transcend/virtual/)\n\n\n    ## Quelles sont les nouveautés de 2025 ?\n\n\n    Depuis la dernière publication du classement en 2021, les changements apportés en 2025 représentent un tournant majeur dans la sécurité des applications. Deux catégories entièrement nouvelles ont été ajoutées au classement, et deux autres ont été regroupées, ce qui met en évidence les risques émergents que les tests traditionnels ne détectent souvent pas.\n\n\n    Ces changements sont visibles dans le graphique ci-dessous :\n\n\n    ![OWASP Top 10 – changements de 2021 à 2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639428/tbekzibeqylorwqrkdau.png)\n\n\n    ### Deux nouvelles catégories\n\n\n    * **A03 : Défaillances de la chaîne d'approvisionnement logicielle**. Cette catégorie s'inscrit dans la continuité de la catégorie de 2021 « Composants vulnérables et obsolètes » et englobe l'ensemble de la chaîne d'approvisionnement logicielle, y compris les dépendances, les systèmes de build et l'infrastructure de distribution. Malgré le plus faible nombre d'occurrences dans les données de test, cette catégorie présente les scores moyens d'exploitation et d'impact les plus élevés issus des CVE.\n\n    * **A10 : Mauvaise gestion des conditions exceptionnelles**. Cette catégorie se concentre sur la gestion inappropriée des erreurs, les erreurs logiques et les scénarios d'échec ouvert. Cette catégorie traite de la manière dont les systèmes réagissent aux conditions anormales.\n\n\n    ### Changements majeurs dans le classement\n\n\n    * Les erreurs de configuration de sécurité ont bondi de la 5e place (2021) à la 2e place (2025) et affectent désormais 3 % des applications testées.\n\n    * La falsification de requêtes côté serveur (SSRF) a été consolidée dans la catégorie A01 : Contrôle d'accès insuffisant.\n\n    * Les défaillances cryptographiques sont passées de la 2e à la 4e place.\n\n    * L'injection est passée de la 3e à la 5e place.\n\n    * La conception non sécurisée est passée de la 4e à la 6e place.\n\n\n    ## Pourquoi ces changements ?\n\n\n    La méthodologie OWASP combine une analyse basée sur les données avec le point de vue de la communauté. L'édition 2025 a analysé 589 énumérations de faiblesses communes (CWE), ce qui représente une augmentation substantielle par rapport aux quelque 400 CWE de 2021. Cette progression reflète la complexité croissante des systèmes logiciels modernes et la nécessité de détecter les menaces émergentes.\n\n\n    Le volet relatif à l'enquête menée auprès de la communauté répond à une limitation fondamentale : les données de test concernent essentiellement le passé. Au moment où les chercheurs en sécurité développent des méthodologies de test et les intègrent dans des outils automatisés, des années peuvent s'être écoulées. Les deux catégories déterminées par la communauté garantissent que les risques émergents identifiés par les professionnels de première ligne sont inclus, même s'ils ne sont pas encore répandus dans les données de test automatisées.\n\n\n    L'augmentation des erreurs de configuration de sécurité met en évidence une tendance du secteur : la sécurité basée sur la configuration, tandis que les défaillances de la chaîne d'approvisionnement logicielle reconnaissent l'essor des attaques sophistiquées ciblant les paquets compromis.\n\n\n    ## Détecter et gérer les vulnérabilités avec GitLab Ultimate\n\n\n    GitLab Ultimate fournit des [scans de sécurité](https://docs.gitlab.com/user/application_security/detect/) complets pour détecter les risques dans les catégories du classement OWASP Top 10 2025. Par exemple, la plateforme de bout en bout analyse le code source, les dépendances et les définitions d'infrastructure de votre projet. Elle utilise également l'[analyseur Advanced de test statique de sécurité des applications (SAST)](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/) pour détecter les failles d'injection, les défaillances cryptographiques et les modèles de conception non sécurisés dans le code source. L'[analyse de l'Infrastructure as Code (IaC)](https://docs.gitlab.com/user/application_security/iac_scanning/) identifie les erreurs de configuration de sécurité dans vos définitions de déploiement. La [détection de secrets](https://docs.gitlab.com/user/application_security/secret_detection/) empêche la fuite d'identifiants, et l'[analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/) signale les bibliothèques qui présentent des vulnérabilités connues dans votre chaîne d'approvisionnement logicielle, ce qui répond directement à la nouvelle catégorie A03 relative aux défaillances de la chaîne d'approvisionnement logicielle.\n\n\n    De plus :\n\n\n    * Les [tests dynamiques de sécurité des applications (DAST)](https://docs.gitlab.com/user/application_security/dast/) analysent votre application déployée afin de rechercher des contrôles d'accès défaillants, des échecs d'authentification et des vulnérabilités d'injection en simulant des vecteurs d'attaque.\n\n    * Les [tests de sécurité des API](https://docs.gitlab.com/user/application_security/api_security/) analysent vos points de terminaison API à la recherche de faiblesses de validation des entrées et de contournements d'authentification.\n\n    * Le [test de l'API web par injection de données aléatoires](https://docs.gitlab.com/user/application_security/api_fuzzing/) teste comment votre application gère les conditions exceptionnelles en générant des intrants inattendus, ce qui s'inscrit directement dans la nouvelle catégorie A10 relative à la mauvaise gestion des conditions exceptionnelles.\n\n\n    Les scans de sécurité s'intègrent de manière transparente dans votre [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) et s'exécutent lorsque le code fait l'objet d'un push depuis une branche de fonctionnalité afin que les équipes de développement puissent corriger les vulnérabilités avant qu'elles n'atteignent la production. Les résultats de sécurité sont consolidés dans le [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/), où les équipes de sécurité peuvent classer, analyser et suivre les corrections. GitLab vous permet également de tirer parti des agents d'IA tels que l'[agent GitLab Duo Security Analyst](https://about.gitlab.com/fr-fr/blog/vulnerability-triage-made-simple-with-gitlab-security-analyst-agent/), disponible dans GitLab Duo Agent Platform, pour déterminer rapidement les vulnérabilités les plus critiques et savoir comment les traiter.\n\n\n    Les [politiques d'approbation des merge requests](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) et les [politiques d'exécution des pipelines](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) vous permettent d'appliquer des contrôles supplémentaires afin de garantir que l'analyse de sécurité s'exécute de manière cohérente dans toute votre organisation. Les équipes du Succès client et des Services professionnels de GitLab veillent à ce que vous tiriez profit d'un investissement dans GitLab en temps opportun.\n\n\n    Livrez des logiciels sécurisés plus rapidement grâce aux tests de sécurité dans la même plateforme que les équipes de développement utilisent déjà. Pour en savoir plus, consultez notre [page dédiée aux solutions de test de sécurité des applications](https://about.gitlab.com/fr-fr/solutions/application-security-testing/).\n\n\n    ## OWASP Top 10 2025 : analyse complète\n\n\n    ### A01 : Contrôle d'accès insuffisant\n\n\n    #### Définition\n\n\n    Échecs dans l'application des politiques qui empêchent les utilisateurs d'agir en dehors de leurs autorisations prévues et entraînent des accès non autorisés.\n\n\n    #### Impact sur votre système\n\n\n    * Divulgation d'informations non autorisée\n\n    * Destruction complète de données ou modification de données\n\n    * Escalade de privilèges (des utilisateurs obtiennent des droits d'administrateur)\n\n    * Consultation ou modification des comptes d'autres utilisateurs\n\n    * Accès API depuis des sources non autorisées ou non fiables\n\n\n    #### CWE notables\n\n\n    * [CWE-22 : Traversée de chemin](https://cwe.mitre.org/data/definitions/22.html)\n\n    * [CWE-200 : Exposition d'informations sensibles à un acteur non autorisé](https://cwe.mitre.org/data/definitions/200.html)\n\n    * [CWE-352 : Falsification de requête cross-site (CSRF)](https://cwe.mitre.org/data/definitions/352.html)\n\n\n    ### A02 : Erreur de configuration de sécurité\n\n\n    #### Définition\n\n\n    Systèmes, applications ou services cloud configurés de manière incorrecte du point de vue de la sécurité.\n\n\n    #### Impact sur votre système\n\n\n    * Exposition d'informations sensibles via des messages d'erreur\n\n    * Accès non autorisé via des comptes par défaut\n\n    * Services ou fonctionnalités inutiles activés\n\n    * Correctifs de sécurité obsolètes\n\n    * Le serveur n'envoie pas d'en-têtes ou de directives de sécurité\n\n\n    #### CWE notables\n\n\n    * [CWE-16 : Configuration](https://cwe.mitre.org/data/definitions/16.html)\n\n    * [CWE-521 : Exigences de mot de passe faibles](https://cwe.mitre.org/data/definitions/521.html)\n\n    * [CWE-798 : Utilisation d'identifiants codés en dur](https://cwe.mitre.org/data/definitions/798.html)\n\n\n    ### A03 : Défaillances de la chaîne d'approvisionnement logicielle\n\n\n    #### Définition\n\n\n    Pannes ou compromissions dans la construction, la distribution ou la mise à jour de logiciels par le biais de vulnérabilités ou de modifications malveillantes dans les dépendances, les outils ou les processus de build.\n\n\n    #### Impact sur votre système\n\n\n    * Paquets compromis introduisant des portes dérobées\n\n    * Code malveillant injecté pendant les processus de build\n\n    * Dépendances vulnérables propagées dans votre application\n\n    * Utilisation de composants issus de sources non fiables en production\n\n    * Absence de suivi des modifications au sein de votre chaîne d'approvisionnement \n\n\n    #### CWE notables\n\n\n    * [CWE-1395 : Dépendance à un composant tiers vulnérable](https://cwe.mitre.org/data/definitions/1395.html)\n\n    * [CWE-1104 : Utilisation de composants tiers non maintenus](https://cwe.mitre.org/data/definitions/1104.html)\n\n\n    ### A04 : Défaillances cryptographiques\n\n\n    #### Définition\n\n\n    Échecs liés à l'absence de cryptographie, à une cryptographie insuffisamment forte, à la fuite de clés cryptographiques et aux erreurs connexes.\n\n\n    #### Impact sur votre système\n\n\n    * Exposition de données sensibles (mots de passe, cartes de crédit, dossiers médicaux)\n\n    * Attaques de type homme du milieu (man-in-the-middle)\n\n    * Violation de données en raison d'un chiffrement faible\n\n    * Compromission de clés entraînant une exposition à l'échelle du système\n\n    * Échecs de conformité réglementaire (RGPD, PCI DSS)\n\n\n    #### CWE notables\n\n\n    * [CWE-327 : Utilisation d'un algorithme cryptographique défaillant ou risqué](https://cwe.mitre.org/data/definitions/327.html)\n\n    * [CWE-330 : Utilisation de valeurs insuffisamment aléatoires](https://cwe.mitre.org/data/definitions/330.html)\n\n\n    ### A05 : Injection\n\n\n    #### Définition\n\n\n    Failles système qui permettent aux attaquants d'insérer du code ou des commandes malveillants (SQL, NoSQL, commandes OS, LDAP, etc.) dans les programmes.\n\n\n    #### Impact sur votre système\n\n\n    * Perte ou corruption de données par injection SQL\n\n    * Compromission complète de la base de données\n\n    * Prise de contrôle du serveur par injection de commandes\n\n    * Attaques de cross-site scripting (XSS)\n\n    * Divulgation d'informations\n\n    * Déni de service\n\n\n    #### CWE notables\n\n\n    * [CWE-89 : Injection SQL](https://cwe.mitre.org/data/definitions/89.html)\n\n    * [CWE-78 : Injection de commande dans le système d'exploitation](https://cwe.mitre.org/data/definitions/78.html)\n\n\n    ### A06 : Conception non sécurisée\n\n\n    #### Définition\n\n\n    Faiblesses dans la conception qui représentent différents échecs, exprimées sous forme de contrôles manquants ou inefficaces (défauts architecturaux plutôt que bogues d'implémentation).\n\n\n    #### Impact sur votre système\n\n\n    * Flux de réinitialisation de mot de passe faibles\n\n    * Étapes d'autorisation manquantes\n\n    * Logique métier défectueuse permettant des contournements\n\n    * Modélisation des menaces inadéquate conduisant à des vulnérabilités\n\n    * Modèles de conception qui échouent dans des scénarios d'attaque\n\n\n    #### CWE notables\n\n\n    * [CWE-209 : Génération de messages d'erreur avec des informations sensibles](https://cwe.mitre.org/data/definitions/209.html)\n\n    * [CWE-522 : Identifiants avec protection insuffisante](https://cwe.mitre.org/data/definitions/522.html)\n\n    * [CWE-656 : Dépendance à la sécurité par l'obscurité](https://cwe.mitre.org/data/definitions/656.html)\n\n\n    ### A07 : Échecs d'authentification\n\n\n    #### Définition\n\n\n    Vulnérabilités qui permettent aux attaquants de tromper les systèmes pour qu'ils reconnaissent des utilisateurs invalides ou incorrects comme légitimes.\n\n\n    #### Impact sur votre système\n\n\n    * Prise de contrôle de compte et bourrage d'identifiants (credential stuffing) \n\n    * Détournement de session\n\n    * Attaques par force brute (brute force attacks) réussies\n\n    * Exploitation de mécanismes de récupération de mot de passe faibles\n\n    * Contournement de l'authentification multifacteur\n\n\n    #### CWE notables\n\n\n    * [CWE-287 : Authentification inappropriée](https://cwe.mitre.org/data/definitions/287.html)\n\n    * [CWE-306 : Authentification manquante pour fonction critique](https://cwe.mitre.org/data/definitions/306.html)\n\n    * [CWE-521 : Exigences de mot de passe faibles](https://cwe.mitre.org/data/definitions/521.html)\n\n\n    ### A08 : Défaillances d'intégrité des logiciels ou des données\n\n\n    #### Définition\n\n\n    Un code et une infrastructure qui ne parviennent pas à se protéger contre le code ou les données invalides ou non fiables traités comme fiables et valides.\n\n\n    #### Impact sur votre système\n\n\n    * Mises à jour non signées permettant l'injection de code malveillant\n\n    * Désérialisation non sécurisée conduisant à l'exécution de code à distance\n\n    * Compromission du pipeline CI/CD\n\n    * Mécanismes de mise à jour automatique exploités\n\n    * Artefacts logiciels altérés\n\n\n    #### CWE notables\n\n\n    * [CWE-345 : Vérification insuffisante de l'authenticité des données](https://cwe.mitre.org/data/definitions/345.html)\n\n    * [CWE-346 : Erreur de validation d'origine](https://cwe.mitre.org/data/definitions/346.html)\n\n    * [CWE-347 : Vérification inappropriée de la signature cryptographique](https://cwe.mitre.org/data/definitions/347.html)\n\n\n    ### A09 : Échecs de journalisation et d'alerte de sécurité\n\n\n    #### Définition\n\n\n    Une journalisation et surveillance insuffisantes avec des alertes inadéquates, ce qui complique la réponse rapide.\n\n\n    #### Impact sur votre système\n\n\n    * Non-détection des attaques pendant de longues périodes\n\n    * Enquête sur les violations impossible\n\n    * Violations de conformité dues à l'absence de pistes d'audit\n\n    * Réponse aux incidents retardée\n\n    * Incapacité à déterminer l'étendue de la compromission\n\n\n    #### CWE notables\n\n\n    * [CWE-117 : Neutralisation inappropriée des données de sortie pour les logs](https://cwe.mitre.org/data/definitions/117.html)\n\n    * [CWE-532 : Insertion d'informations sensibles dans le fichier log](https://cwe.mitre.org/data/definitions/532.html)\n\n    * [CWE-778 : Journalisation insuffisante](https://cwe.mitre.org/data/definitions/778.html)\n\n\n    ### A10 : Mauvaise gestion des conditions exceptionnelles\n\n\n    #### Définition\n\n\n    Programmes qui ne parviennent pas à prévenir et détecter des situations inhabituelles et imprévisibles, ni à y réagir, ce qui conduit à des plantages, des comportements inattendus ou des vulnérabilités.\n\n\n    #### Impact sur votre système\n\n\n    * Divulgation d'informations via des messages d'erreur détaillés\n\n    * Déni de service dû à des exceptions non gérées\n\n    * Corruption d'état due à une gestion inappropriée des erreurs\n\n    * Conditions de concurrence exploitées\n\n    * Systèmes échouant en mode ouvert au lieu de fermé\n\n    * Plantages d'application exposant des données sensibles\n\n\n    #### CWE notables\n\n\n    * [CWE-248 : Exception non capturée](https://cwe.mitre.org/data/definitions/248.html)\n\n    * [CWE-390 : Détection d'une condition d'erreur sans action](https://cwe.mitre.org/data/definitions/390.html)\n\n    * [CWE-391 : Condition d'erreur non vérifiée](https://cwe.mitre.org/data/definitions/391.html)\n\n\n    ## Bonnes pratiques de prévention et de correction\n\n\n    GitLab fournit des outils qui vous permettent non seulement de trouver et de corriger rapidement les vulnérabilités du classement OWASP Top 10, mais également de les empêcher d'atteindre votre système de production. Suivez les bonnes pratiques ci-dessous pour améliorer et maintenir votre posture de sécurité :\n\n\n    #### Scans de sécurité automatisés pour tous les dépôts\n\n\n    * Effectuez une [analyse SAST](https://docs.gitlab.com/user/application_security/sast/) pour détecter tôt dans le cycle de vie du développement les modèles de conception non sécurisés tels que le stockage de mots de passe en texte clair, la gestion inadéquate des erreurs et le chiffrement manquant lors de la revue de code.\n\n    * Effectuez une [détection de secrets](https://docs.gitlab.com/user/application_security/secret_detection/) pour identifier les identifiants dans les fichiers de configuration, les variables d'environnement et le code, en empêchant le stockage de mots de passe en texte clair et en garantissant que les secrets sont correctement gérés via les variables CI/CD de GitLab avec masquage et chiffrement.\n\n    * Effectuez une [analyse DAST](https://docs.gitlab.com/user/application_security/dast/) pour détecter les vulnérabilités de contrôle d'accès défaillant.\n\n    * Effectuez une [analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/) pour analyser les dépendances du projet dans les bases de données de vulnérabilités, identifier les CVE connus dans les dépendances directes et transitives sur plusieurs gestionnaires de paquets (npm, pip, Maven, etc.).\n\n    * Effectuez une [analyse de conteneurs](https://docs.gitlab.com/user/application_security/container_scanning/) pour analyser les images Docker à la recherche de couches de base et de paquets vulnérables et garantir la sécurité de la chaîne d'approvisionnement des conteneurs avant le déploiement.\n\n    * Effectuez une [analyse de l'IaC](https://docs.gitlab.com/user/application_security/iac_scanning/) pour vérifier vos fichiers de définition d'infrastructure à la recherche de vulnérabilités connues.\n\n    * Tirez parti des [outils de sécurité relatifs aux API](https://docs.gitlab.com/user/application_security/api_security/) pour sécuriser et protéger les API Web contre les accès non autorisés, les utilisations abusives et les attaques.\n\n    * Effectuez un [test de l'API web par injection de données aléatoires](https://docs.gitlab.com/user/application_security/api_fuzzing/) pour découvrir les bogues et les vulnérabilités potentielles que d'autres processus d'assurance qualité pourraient manquer.\n\n\n    ![Résultats de sécurité dans une merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639431/zs6xh8hz6mud3vuig3dy.png)\n\n\n    \u003Cp>\u003C/p>\n\n    \u003Ccenter>\u003Ci>Affichez les vulnérabilités détectées dans une merge request avec les diffs de la branche de fonctionnalité à la branche principale.\u003C/i>\u003C/center>\n\n\n    #### Votre posture de sécurité\n\n\n    * Générez une [nomenclature logicielle (SBOM)](https://docs.gitlab.com/user/application_security/dependency_list/) pour une visibilité complète des dépendances et des exigences de conformité.\n\n    * Tirez parti du [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/) pour trier et classer les vulnérabilités dans une vue consolidée des vulnérabilités de sécurité trouvées dans votre code source.\n\n    * Agissez rapidement sur les vulnérabilités en utilisant les [conseils de correction détaillés](https://docs.gitlab.com/user/application_security/vulnerabilities/) et les [données d'évaluation des risques](https://docs.gitlab.com/user/application_security/vulnerabilities/risk_assessment_data/).\n\n    * Utilisez l'[inventaire de sécurité](https://docs.gitlab.com/user/application_security/security_inventory/) pour visualiser les actifs que vous devez sécuriser et comprendre les actions que vous devez entreprendre pour améliorer la sécurité.\n\n    * Tirez parti du [Centre de conformité](https://docs.gitlab.com/user/compliance/compliance_center/) pour gérer les rapports d'adhésion aux normes de conformité, les rapports de violations et les frameworks de conformité.\n\n\n    ![Inventaire de sécurité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639429/e9vnakc8yiyjbjm8aj7s.png)\n\n\n    \u003Cp>\u003C/p>\n\n    \u003Ccenter>\u003Ci>Utilisez l'inventaire de sécurité pour afficher les scanners de sécurité activés et les vulnérabilités.\u003C/i>\u003C/center>\n\n\n    #### Configuration de la prévention et maintenance de la documentation\n\n\n    * Configurez des [politiques de sécurité](https://docs.gitlab.com/user/application_security/policies/) pour bloquer les merges ou les déploiements lorsque des vulnérabilités de gravité élevée sont détectées dans les dépendances, afin d'appliquer automatiquement des normes de sécurité.\n\n    * Utilisez les [frameworks de conformité](https://docs.gitlab.com/user/compliance/compliance_frameworks/) pour appliquer les normes de sécurité organisationnelles via des vérifications automatiques de politiques qui contrôlent que les exigences de chiffrement, les pratiques de gestion des identifiants et les implémentations de workflows sécurisés sont respectées.\n\n    * Utilisez le wiki GitLab et la documentation du dépôt pour maintenir les principes de conception de sécurité, les modèles approuvés et la documentation relative aux décisions architecturales qui guident les développeurs vers des [implémentations selon le principe Secure by Design](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/).\n\n    * Implémentez des règles d'approbation de merge request qui nécessitent une revue par un architecte de sécurité pour les fonctionnalités qui impliquent l'authentification, l'autorisation, le chiffrement ou le traitement de données sensibles afin de garantir une validation de sécurité au niveau de la conception.\n\n    * Créez des tests pour vérifier la validation des entrées et les approches de liste d'autorisation pour les chemins de fichiers.\n\n    * Utilisez les tickets et epics GitLab pour documenter les exigences de sécurité et les modèles de menaces pendant la phase de conception afin de créer une documentation suivie des décisions de sécurité et de garantir que les considérations de sécurité sont traitées avant le début de l'implémentation.\n\n\n    ![Tableau de bord des politiques de sécurité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639429/q4eelq3rqt0oonzhwoyb.png)\n\n\n    \u003Ccenter>\u003Ci>Affichez et définissez des politiques de sécurité au niveau de l'instance, du groupe ou du projet.\u003C/i>\u003C/center>\n\n\n    #### Utilisation de l'IA\n\n\n    * Utilisez les [suggestions de code](https://docs.gitlab.com/user/project/repository/code_suggestions/) pour obtenir des conseils proactifs pendant le développement. Les suggestions comprennent des modèles de conception sécurisés tels que le hachage approprié des mots de passe (bcrypt, Argon2), des mécanismes de stockage chiffrés et une gestion appropriée des erreurs qui ne divulgue pas d'informations sensibles.\n\n    * Utilisez l'[agent GitLab Duo Security Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/) pour examiner les vulnérabilités de conception non sécurisées détectées en contexte. L'agent explique les implications architecturales, évalue les risques en fonction du modèle de menace de votre application et fournit des stratégies de correction qui traitent les défauts de conception d'origine plutôt que les symptômes.\n\n    * [Révisez votre code à l'aide de l'IA](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code) pour garantir des normes de revue de code cohérentes dans votre projet.\n\n\n    ![Agent GitLab Duo Security Analyst](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639430/kqvgagepwleabt5zdkco.png)\n\n\n    \u003Cp>\u003C/p>\n\n    \u003Ccenter>\u003Ci>Tirez parti de l'agent GitLab Duo Security Analyst pour classer et évaluer rapidement les vulnérabilités de sécurité.\u003C/i>\u003C/center>\n\n\n    ## Points clés à retenir pour les équipes de développement\n\n\n    * **La sécurité de la chaîne d'approvisionnement est essentielle** : avec l'ajout de la catégorie A03 et les scores d'impact élevés, la sécurisation de votre chaîne d'approvisionnement logicielle est obligatoire. Implémentez le suivi SBOM, l'analyse des dépendances et la vérification de l'intégrité dans l'ensemble de votre pipeline.\n\n    * **La configuration est plus importante que jamais** : désormais à la 2e place du classement, la sécurité basée sur la configuration est devenue un vecteur d'attaque principal. Automatisez la vérification de la configuration et implémentez l'IaC avec la sécurité intégrée.\n\n    * **Les menaces traditionnelles persistent** : bien que l'injection et les défaillances cryptographiques aient chuté dans le classement, elles restent critiques. Ne les reléguez donc pas au second plan.\n\n    * **La gestion des erreurs est une question de sécurité** : la nouvelle catégorie A10 souligne que la gestion des échecs de votre application est une préoccupation de sécurité. Implémentez une gestion sécurisée des erreurs dès le départ.\n\n    * **Les tests doivent évoluer** : la couverture CWE élargie (589 contre 400 en 2021) signifie que les stratégies de test doivent être complètes. Combinez les SAST, les DAST, l'analyse du code source et des tests de pénétration manuels pour garantir une couverture efficace.\n\n\n    > Explorez les [solutions de sécurité et de gouvernance GitLab](https://about.gitlab.com/fr-fr/solutions/application-security-testing/) et notre [documentation sur l'analyse de sécurité](https://docs.gitlab.com/ee/user/application_security/) pour commencer à renforcer votre posture de sécurité dès aujourd'hui.\nconfig:\n  featured: false\n  template: BlogPost\n  slug: 2025-owasp-top-10-whats-changed-and-why-it-matters\n",{"config":30,"title":5,"description":31,"ogImage":17},{"noIndex":13},"Découvrez les risques liés à la chaîne d'approvisionnement et à la gestion des erreurs, les changements dans le classement et les stratégies de correction.","fr-fr/blog/2025-owasp-top-10-whats-changed-and-why-it-matters",[11,34],"open-source",[11,22],"83gNQYeqdco1v-Pf8hsxn3RBfoQ6_gGlzpxKiKRfOT8",{"logo":38,"freeTrial":43,"sales":48,"login":53,"items":58,"search":379,"minimal":414,"duo":433,"switchNav":442,"pricingDeployment":453},{"config":39},{"href":40,"dataGaName":41,"dataGaLocation":42},"/fr-fr/","gitlab logo","header",{"text":44,"config":45},"Commencer un essai gratuit",{"href":46,"dataGaName":47,"dataGaLocation":42},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":49,"config":50},"Contacter l'équipe commerciale",{"href":51,"dataGaName":52,"dataGaLocation":42},"/fr-fr/sales/","sales",{"text":54,"config":55},"Connexion",{"href":56,"dataGaName":57,"dataGaLocation":42},"https://gitlab.com/users/sign_in/","sign in",[59,88,190,195,298,359],{"text":60,"config":61,"menu":63},"Plateforme",{"dataNavLevelOne":62},"platform",{"type":64,"columns":65},"cards",[66,72,80],{"title":60,"description":67,"link":68},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":69,"config":70},"Explorer notre plateforme",{"href":71,"dataGaName":62,"dataGaLocation":42},"/fr-fr/platform/",{"title":73,"description":74,"link":75},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":76,"config":77},"Découvrir GitLab Duo",{"href":78,"dataGaName":79,"dataGaLocation":42},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":81,"description":82,"link":83},"Pourquoi GitLab ?","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":84,"config":85},"En savoir plus",{"href":86,"dataGaName":87,"dataGaLocation":42},"/fr-fr/why-gitlab/","why gitlab",{"text":89,"left":26,"config":90,"menu":92},"Produit",{"dataNavLevelOne":91},"solutions",{"type":93,"link":94,"columns":98,"feature":169},"lists",{"text":95,"config":96},"Voir toutes les solutions",{"href":97,"dataGaName":91,"dataGaLocation":42},"/fr-fr/solutions/",[99,124,147],{"title":100,"description":101,"link":102,"items":107},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":42},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[108,112,115,120],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":42,"dataGaName":109},"/fr-fr/solutions/continuous-integration/",{"text":73,"config":113},{"href":78,"dataGaLocation":42,"dataGaName":114},"gitlab duo agent platform - product menu",{"text":116,"config":117},"Gestion du code source",{"href":118,"dataGaLocation":42,"dataGaName":119},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"Livraison de logiciels automatisée",{"href":105,"dataGaLocation":42,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":42,"icon":131},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[133,137,142],{"text":134,"config":135},"Tests de sécurité des applications",{"href":129,"dataGaName":136,"dataGaLocation":42},"Application security testing",{"text":138,"config":139},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":140,"dataGaLocation":42,"dataGaName":141},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":143,"config":144},"Conformité logicielle",{"href":145,"dataGaName":146,"dataGaLocation":42},"/fr-fr/solutions/software-compliance/","software compliance",{"title":148,"link":149,"items":154},"Mesures",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":42},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"Visibilité et mesures",{"href":152,"dataGaLocation":42,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Gestion de la chaîne de valeur",{"href":162,"dataGaLocation":42,"dataGaName":163},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"Données d'analyse et informations clés",{"href":167,"dataGaLocation":42,"dataGaName":168},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"type":93,"items":171},"GitLab",[172,178,184],{"text":173,"config":174},"Pour les entreprises",{"icon":175,"href":176,"dataGaLocation":42,"dataGaName":177},"Building","/fr-fr/enterprise/","enterprise",{"text":179,"config":180},"Pour les PME",{"icon":181,"href":182,"dataGaLocation":42,"dataGaName":183},"Work","/fr-fr/small-business/","small business",{"text":185,"config":186},"Pour le secteur public",{"icon":187,"href":188,"dataGaLocation":42,"dataGaName":189},"Organization","/fr-fr/solutions/public-sector/","public sector",{"text":191,"config":192},"Tarifs",{"href":193,"dataGaName":194,"dataGaLocation":42,"dataNavLevelOne":194},"/fr-fr/pricing/","pricing",{"text":196,"config":197,"menu":199},"Ressources",{"dataNavLevelOne":198},"resources",{"type":93,"link":200,"columns":204,"feature":284},{"text":201,"config":202},"Afficher toutes les ressources",{"href":203,"dataGaName":198,"dataGaLocation":42},"/fr-fr/resources/",[205,238,256],{"title":206,"items":207},"Premiers pas",[208,213,218,223,228,233],{"text":209,"config":210},"Installation",{"href":211,"dataGaName":212,"dataGaLocation":42},"/fr-fr/install/","install",{"text":214,"config":215},"Guides de démarrage",{"href":216,"dataGaName":217,"dataGaLocation":42},"/fr-fr/get-started/","quick setup checklists",{"text":219,"config":220},"Apprentissage",{"href":221,"dataGaLocation":42,"dataGaName":222},"https://university.gitlab.com/","learn",{"text":224,"config":225},"Documentation",{"href":226,"dataGaName":227,"dataGaLocation":42},"https://docs.gitlab.com/","product documentation",{"text":229,"config":230},"Vidéos sur les bonnes pratiques",{"href":231,"dataGaName":232,"dataGaLocation":42},"/fr-fr/getting-started-videos/","best practice videos",{"text":234,"config":235},"Intégrations",{"href":236,"dataGaName":237,"dataGaLocation":42},"/fr-fr/integrations/","integrations",{"title":239,"items":240},"Découvrir",[241,246,251],{"text":242,"config":243},"Témoignages clients",{"href":244,"dataGaName":245,"dataGaLocation":42},"/fr-fr/customers/","customer success stories",{"text":247,"config":248},"Blog",{"href":249,"dataGaName":250,"dataGaLocation":42},"/fr-fr/blog/","blog",{"text":252,"config":253},"Travail à distance",{"href":254,"dataGaName":255,"dataGaLocation":42},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":257,"items":258},"Connecter",[259,264,269,274,279],{"text":260,"config":261},"Services GitLab",{"href":262,"dataGaName":263,"dataGaLocation":42},"/fr-fr/services/","services",{"text":265,"config":266},"Communauté",{"href":267,"dataGaName":268,"dataGaLocation":42},"/community/","community",{"text":270,"config":271},"Forum",{"href":272,"dataGaName":273,"dataGaLocation":42},"https://forum.gitlab.com/","forum",{"text":275,"config":276},"Événements",{"href":277,"dataGaName":278,"dataGaLocation":42},"/events/","events",{"text":280,"config":281},"Partenaires",{"href":282,"dataGaName":283,"dataGaLocation":42},"/fr-fr/partners/","partners",{"config":285,"text":288,"image":289,"link":293},{"background":286,"textColor":287},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":290,"config":291},"carte promo The Source",{"src":292},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":294,"config":295},"Lire les articles les plus récents",{"href":296,"dataGaName":297,"dataGaLocation":42},"/fr-fr/the-source/","the source",{"text":299,"config":300,"menu":302},"Société",{"dataNavLevelOne":301},"company",{"type":93,"columns":303},[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"À propos",{"href":309,"dataGaName":310,"dataGaLocation":42},"/fr-fr/company/","about",{"text":312,"config":313,"footerGa":316},"Carrières",{"href":314,"dataGaName":315,"dataGaLocation":42},"/jobs/","jobs",{"dataGaName":315},{"text":275,"config":318},{"href":277,"dataGaName":278,"dataGaLocation":42},{"text":320,"config":321},"Leadership",{"href":322,"dataGaName":323,"dataGaLocation":42},"/company/team/e-group/","leadership",{"text":325,"config":326},"Équipe",{"href":327,"dataGaName":328,"dataGaLocation":42},"/company/team/","team",{"text":330,"config":331},"Manuel",{"href":332,"dataGaName":333,"dataGaLocation":42},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"Relations avec les investisseurs",{"href":337,"dataGaName":338,"dataGaLocation":42},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"Trust Center",{"href":342,"dataGaName":343,"dataGaLocation":42},"/fr-fr/security/","trust center",{"text":345,"config":346},"Centre pour la transparence de l'IA",{"href":347,"dataGaName":348,"dataGaLocation":42},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"Newsletter",{"href":352,"dataGaName":353,"dataGaLocation":42},"/company/contact/#contact-forms","newsletter",{"text":355,"config":356},"Presse",{"href":357,"dataGaName":358,"dataGaLocation":42},"/press/","press",{"text":360,"config":361,"menu":362},"Nous contacter",{"dataNavLevelOne":301},{"type":93,"columns":363},[364],{"items":365},[366,369,374],{"text":49,"config":367},{"href":51,"dataGaName":368,"dataGaLocation":42},"talk to sales",{"text":370,"config":371},"Assistance GitLab",{"href":372,"dataGaName":373,"dataGaLocation":42},"https://support.gitlab.com","support portal",{"text":375,"config":376},"Portail clients GitLab",{"href":377,"dataGaName":378,"dataGaLocation":42},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":380,"login":381,"suggestions":388},"Fermer",{"text":382,"link":383},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":384,"config":385},"GitLab.com",{"href":56,"dataGaName":386,"dataGaLocation":387},"search login","search",{"text":389,"default":390},"Suggestions",[391,393,398,400,405,410],{"text":73,"config":392},{"href":78,"dataGaName":73,"dataGaLocation":387},{"text":394,"config":395},"Suggestions de code (IA)",{"href":396,"dataGaName":397,"dataGaLocation":387},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":399},{"href":111,"dataGaName":109,"dataGaLocation":387},{"text":401,"config":402},"GitLab sur AWS",{"href":403,"dataGaName":404,"dataGaLocation":387},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":406,"config":407},"GitLab sur Google Cloud",{"href":408,"dataGaName":409,"dataGaLocation":387},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":411,"config":412},"Pourquoi utiliser GitLab ?",{"href":86,"dataGaName":413,"dataGaLocation":387},"Why GitLab?",{"freeTrial":415,"mobileIcon":420,"desktopIcon":425,"secondaryButton":428},{"text":416,"config":417},"Commencer votre essai gratuit",{"href":418,"dataGaName":47,"dataGaLocation":419},"https://gitlab.com/-/trials/new/","nav",{"altText":421,"config":422},"Icône GitLab",{"src":423,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":421,"config":426},{"src":427,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":429,"config":430},"Commencer",{"href":431,"dataGaName":432,"dataGaLocation":419},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/get-started/","get started",{"freeTrial":434,"mobileIcon":438,"desktopIcon":440},{"text":435,"config":436},"En savoir plus sur GitLab Duo",{"href":78,"dataGaName":437,"dataGaLocation":419},"gitlab duo",{"altText":421,"config":439},{"src":423,"dataGaName":424,"dataGaLocation":419},{"altText":421,"config":441},{"src":427,"dataGaName":424,"dataGaLocation":419},{"button":443,"mobileIcon":448,"desktopIcon":450},{"text":444,"config":445},"/switch",{"href":446,"dataGaName":447,"dataGaLocation":419},"#contact","switch",{"altText":421,"config":449},{"src":423,"dataGaName":424,"dataGaLocation":419},{"altText":421,"config":451},{"src":452,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":454,"mobileIcon":459,"desktopIcon":461},{"text":455,"config":456},"Retour aux tarifs",{"href":193,"dataGaName":457,"dataGaLocation":419,"icon":458},"back to pricing","GoBack",{"altText":421,"config":460},{"src":423,"dataGaName":424,"dataGaLocation":419},{"altText":421,"config":462},{"src":427,"dataGaName":424,"dataGaLocation":419},{"title":464,"button":465,"config":470},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":466,"config":467},"S'inscrire à GitLab Transcend le 10 juin",{"href":468,"dataGaName":469,"dataGaLocation":42},"/fr-fr/releases/whats-new/#sign-up","transcend event",{"layout":471,"icon":472,"disabled":13},"release","AiStar",{"data":474},{"text":475,"source":476,"edit":482,"contribute":487,"config":492,"items":497,"minimal":702},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence.",{"text":477,"config":478},"Afficher le code source de la page",{"href":479,"dataGaName":480,"dataGaLocation":481},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":483,"config":484},"Modifier cette page",{"href":485,"dataGaName":486,"dataGaLocation":481},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":488,"config":489},"Veuillez contribuer",{"href":490,"dataGaName":491,"dataGaLocation":481},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":493,"facebook":494,"youtube":495,"linkedin":496},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[498,543,596,640,667],{"title":191,"links":499,"subMenu":514},[500,504,509],{"text":501,"config":502},"Voir les forfaits",{"href":193,"dataGaName":503,"dataGaLocation":481},"view plans",{"text":505,"config":506},"GitLab Premium",{"href":507,"dataGaName":508,"dataGaLocation":481},"/fr-fr/pricing/premium/","why premium",{"text":510,"config":511},"GitLab Ultimate",{"href":512,"dataGaName":513,"dataGaLocation":481},"/fr-fr/pricing/ultimate/","why ultimate",[515],{"title":360,"links":516},[517,519,521,523,528,533,538],{"text":49,"config":518},{"href":51,"dataGaName":52,"dataGaLocation":481},{"text":370,"config":520},{"href":372,"dataGaName":373,"dataGaLocation":481},{"text":375,"config":522},{"href":377,"dataGaName":378,"dataGaLocation":481},{"text":524,"config":525},"Statut",{"href":526,"dataGaName":527,"dataGaLocation":481},"https://status.gitlab.com/","status",{"text":529,"config":530},"Conditions d'utilisation",{"href":531,"dataGaName":532,"dataGaLocation":481},"/terms/","terms of use",{"text":534,"config":535},"Politique de confidentialité",{"href":536,"dataGaName":537,"dataGaLocation":481},"/fr-fr/privacy/","privacy statement",{"text":539,"config":540},"Gérer vos cookies",{"dataGaName":541,"dataGaLocation":481,"id":542,"isOneTrustButton":26},"cookie preferences","ot-sdk-btn",{"title":89,"links":544,"subMenu":553},[545,549],{"text":546,"config":547},"Plateforme DevSecOps",{"href":71,"dataGaName":548,"dataGaLocation":481},"devsecops platform",{"text":550,"config":551},"Développement assisté par l'IA",{"href":78,"dataGaName":552,"dataGaLocation":481},"ai-assisted development",[554],{"title":555,"links":556},"Thèmes",[557,561,566,571,576,581,586,591],{"text":109,"config":558},{"href":559,"dataGaName":560,"dataGaLocation":481},"/fr-fr/topics/ci-cd/","cicd",{"text":562,"config":563},"GitOps",{"href":564,"dataGaName":565,"dataGaLocation":481},"/fr-fr/topics/gitops/","gitops",{"text":567,"config":568},"DevOps",{"href":569,"dataGaName":570,"dataGaLocation":481},"/fr-fr/topics/devops/","devops",{"text":572,"config":573},"Contrôle de version",{"href":574,"dataGaName":575,"dataGaLocation":481},"/fr-fr/topics/version-control/","version control",{"text":577,"config":578},"DevSecOps",{"href":579,"dataGaName":580,"dataGaLocation":481},"/fr-fr/topics/devsecops/","devsecops",{"text":582,"config":583},"Cloud-native",{"href":584,"dataGaName":585,"dataGaLocation":481},"/fr-fr/topics/cloud-native/","cloud native",{"text":587,"config":588},"IA pour la programmation",{"href":589,"dataGaName":590,"dataGaLocation":481},"/fr-fr/topics/devops/ai-for-coding/","ai for coding",{"text":592,"config":593},"IA agentique",{"href":594,"dataGaName":595,"dataGaLocation":481},"/fr-fr/topics/agentic-ai/","agentic ai",{"title":597,"links":598},"Solutions",[599,602,604,609,612,615,618,621,624,627,630,635],{"text":134,"config":600},{"href":129,"dataGaName":601,"dataGaLocation":481},"Application Security Testing",{"text":121,"config":603},{"href":105,"dataGaName":106,"dataGaLocation":481},{"text":605,"config":606},"Développement Agile",{"href":607,"dataGaName":608,"dataGaLocation":481},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":116,"config":610},{"href":118,"dataGaName":611,"dataGaLocation":481},"source code management",{"text":109,"config":613},{"href":111,"dataGaName":614,"dataGaLocation":481},"continuous integration & delivery",{"text":160,"config":616},{"href":162,"dataGaName":617,"dataGaLocation":481},"value stream management",{"text":562,"config":619},{"href":620,"dataGaName":565,"dataGaLocation":481},"/fr-fr/solutions/gitops/",{"text":622,"config":623},"Entreprises",{"href":176,"dataGaName":177,"dataGaLocation":481},{"text":625,"config":626},"PME",{"href":182,"dataGaName":183,"dataGaLocation":481},{"text":628,"config":629},"Secteur public",{"href":188,"dataGaName":189,"dataGaLocation":481},{"text":631,"config":632},"Éducation",{"href":633,"dataGaName":634,"dataGaLocation":481},"/fr-fr/solutions/education/","education",{"text":636,"config":637},"Services financiers",{"href":638,"dataGaName":639,"dataGaLocation":481},"/fr-fr/solutions/finance/","financial services",{"title":196,"links":641},[642,644,646,648,651,653,655,657,659,661,663,665],{"text":209,"config":643},{"href":211,"dataGaName":212,"dataGaLocation":481},{"text":214,"config":645},{"href":216,"dataGaName":217,"dataGaLocation":481},{"text":219,"config":647},{"href":221,"dataGaName":222,"dataGaLocation":481},{"text":224,"config":649},{"href":226,"dataGaName":650,"dataGaLocation":481},"docs",{"text":247,"config":652},{"href":249,"dataGaName":250,"dataGaLocation":481},{"text":242,"config":654},{"href":244,"dataGaName":245,"dataGaLocation":481},{"text":252,"config":656},{"href":254,"dataGaName":255,"dataGaLocation":481},{"text":260,"config":658},{"href":262,"dataGaName":263,"dataGaLocation":481},{"text":265,"config":660},{"href":267,"dataGaName":268,"dataGaLocation":481},{"text":270,"config":662},{"href":272,"dataGaName":273,"dataGaLocation":481},{"text":275,"config":664},{"href":277,"dataGaName":278,"dataGaLocation":481},{"text":280,"config":666},{"href":282,"dataGaName":283,"dataGaLocation":481},{"title":299,"links":668},[669,671,673,675,677,679,681,686,691,693,695,697],{"text":307,"config":670},{"href":309,"dataGaName":301,"dataGaLocation":481},{"text":312,"config":672},{"href":314,"dataGaName":315,"dataGaLocation":481},{"text":320,"config":674},{"href":322,"dataGaName":323,"dataGaLocation":481},{"text":325,"config":676},{"href":327,"dataGaName":328,"dataGaLocation":481},{"text":330,"config":678},{"href":332,"dataGaName":333,"dataGaLocation":481},{"text":335,"config":680},{"href":337,"dataGaName":338,"dataGaLocation":481},{"text":682,"config":683},"Développement durable",{"href":684,"dataGaName":685,"dataGaLocation":481},"/sustainability/","Sustainability",{"text":687,"config":688},"Diversité, inclusion et appartenance (DIB)",{"href":689,"dataGaName":690,"dataGaLocation":481},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":692},{"href":342,"dataGaName":343,"dataGaLocation":481},{"text":350,"config":694},{"href":352,"dataGaName":353,"dataGaLocation":481},{"text":355,"config":696},{"href":357,"dataGaName":358,"dataGaLocation":481},{"text":698,"config":699},"Déclaration de transparence sur l'esclavage moderne",{"href":700,"dataGaName":701,"dataGaLocation":481},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":703},[704,706,709],{"text":529,"config":705},{"href":531,"dataGaName":532,"dataGaLocation":481},{"text":707,"config":708},"Gestion des cookies",{"dataGaName":541,"dataGaLocation":481,"id":542,"isOneTrustButton":26},{"text":534,"config":710},{"href":536,"dataGaName":537,"dataGaLocation":481},[712],{"id":713,"title":9,"body":24,"config":714,"content":716,"description":24,"extension":23,"meta":720,"navigation":26,"path":721,"seo":722,"stem":723,"__hash__":724},"blogAuthors/en-us/blog/authors/fernando-diaz.yml",{"template":715},"BlogAuthor",{"name":9,"config":717},{"headshot":718,"ctfId":719},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659556/Blog/Author%20Headshots/fern_diaz.png","fjdiaz",{},"/en-us/blog/authors/fernando-diaz",{},"en-us/blog/authors/fernando-diaz","lxRJIOydP4_yzYZvsPcuQevP9AYAKREF7i8QmmdnOWc",[726,741,752],{"content":727,"config":739},{"title":728,"description":729,"authors":730,"heroImage":732,"date":733,"category":11,"tags":734,"body":738},"Réduire les faux positifs à grande échelle grâce aux politiques de rejet automatique","Découvrez comment filtrer les faux positifs dans les résultats des scanners et vous concentrer sur les vulnérabilités critiques grâce à la sécurité GitLab, avec des cas d'utilisation et des templates prêts à l'emploi.",[731],"Grant Hickman","https://res.cloudinary.com/about-gitlab-com/image/upload/v1774375772/kpaaaiqhokevxxeoxvu0.png","2026-05-01",[11,735,577,736,737],"tutorial","features","product","Les scanners de sécurité sont indispensables, mais tous les résultats ne nécessitent pas une intervention. Le code de test, les dépendances embarquées, les fichiers générés et les faux positifs connus créent une couche qui masque les vulnérabilités critiques. Les équipes de sécurité perdent des heures à rejeter manuellement les mêmes résultats non pertinents d'un projet et d'un pipeline à l'autre. Résultat : le classement prend plus de temps, une lassitude face aux alertes s'installe et les frictions avec les équipes de développement compromettent l'adoption des scans de sécurité.\n\nLes politiques de rejet automatique des vulnérabilités de GitLab vous permettent de codifier vos décisions de classement une seule fois et de les appliquer automatiquement à chaque exécution du pipeline sur la branche par défaut. Définissez des critères basés sur le chemin de fichier, le répertoire ou l'identifiant de vulnérabilité (vulnérabilités ou expositions communes – CVE, CWE), choisissez un motif de rejet et laissez GitLab faire le reste.\n\n## Pourquoi utiliser les politiques de rejet automatique ?\nLes politiques de rejet automatique des vulnérabilités permettent aux équipes de sécurité :\n- **D'éliminer les faux positifs du classement :** rejetez automatiquement les résultats dans le code de test, les dépendances embarquées et les fichiers générés.\n- **D'appliquer des décisions à grande échelle :** déployez des politiques centralisées pour rejeter les faux positifs connus dans l'ensemble de votre organisation.\n- **De garantir la transparence des audits :** chaque résultat rejeté automatiquement inclut un motif documenté et un lien vers la politique qui l'a déclenché.\n- **De conserver l'historique :** contrairement aux exclusions de scanners, les vulnérabilités rejetées restent dans votre rapport, ce qui vous permet de réexaminer vos décisions si les conditions évoluent.\n\n## Fonctionnement des politiques de rejet automatique\n\n1. **Définissez votre politique** dans un fichier YAML de politique de gestion des vulnérabilités. Indiquez les critères de correspondance (chemin de fichier, répertoire ou identifiant) et un motif de rejet.\n\n2. **Fusionnez et activez.** Créez la politique via **Sécurisation > Politiques > Nouvelle politique > Politique de gestion des vulnérabilités**. Fusionnez la merge request pour l'activer.\n3. **Exécutez votre pipeline.** À chaque exécution du pipeline sur la branche par défaut, les vulnérabilités correspondantes se voient automatiquement attribuer le statut « Rejeté » avec le motif indiqué. Jusqu'à 1 000 vulnérabilités sont traitées par exécution.\n4. **Mesurez l'impact.** Filtrez votre rapport de vulnérabilités avec le statut « Rejeté » pour voir exactement ce qui a été traité et vérifier que les bons résultats sont pris en charge.\n\n## Cas d'utilisation avec des configurations prêtes à l'emploi\n\nChaque exemple ci-dessous inclut une configuration de politique que vous pouvez copier, personnaliser et appliquer immédiatement.\n\n### 1. Rejeter les vulnérabilités du code de test\n\nLes scanners de test statique de sécurité des applications (SAST) et de dépendances signalent des identifiants codés en dur, des données de test non sécurisées et des dépendances de développement dans les répertoires de test. Ces résultats ne représentent pas des risques en production.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Dismiss test code vulnerabilities\"\n    description: \"Auto-dismiss findings in test directories\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: file_path\n            value: \"test/**/*\"\n      - type: detected\n        criteria:\n          - type: file_path\n            value: \"tests/**/*\"\n      - type: detected\n        criteria:\n          - type: file_path\n            value: \"spec/**/*\"\n      - type: detected\n        criteria:\n          - type: directory\n            value: \"__tests__/*\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: used_in_tests\n\n```\n\n### 2. Rejeter le code tiers et embarqué\n\nLes vulnérabilités dans les répertoires `vendor/`, `third_party/` ou `node_modules` versionnés sont gérées en amont, et votre équipe ne peut pas y toucher.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Dismiss vendored dependency findings\"\n    description: \"Findings in vendored code are managed upstream\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: directory\n            value: \"vendor/*\"\n      - type: detected\n        criteria:\n          - type: directory\n            value: \"third_party/*\"\n      - type: detected\n        criteria:\n          - type: directory\n            value: \"vendored/*\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: not_applicable\n\n```\n\n### 3. Rejeter les CVE identifiées comme faux positifs\n\nCertaines CVE sont signalées de manière récurrente, mais ne s'appliquent pas à votre contexte d'utilisation. Les équipes les rejettent manuellement à chaque apparition. Remplacez les CVE de l'exemple ci-dessous par les vôtres.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Dismiss known false positive CVEs\"\n    description: \"CVEs confirmed as false positives for our environment\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CVE-2023-44487\"\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CVE-2024-29041\"\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CVE-2023-26136\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: false_positive\n\n```\n\n### 4. Rejeter le code créé et généré automatiquement\n\nLes générateurs Protobuf, gRPC, OpenAPI et les outils de génération automatique de structure de code ORM produisent des fichiers contenant des motifs signalés que votre équipe ne peut pas corriger.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Dismiss generated code findings\"\n    description: \"Generated files are not authored by us\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: directory\n            value: \"generated/*\"\n      - type: detected\n        criteria:\n          - type: file_path\n            value: \"**/*.pb.go\"\n      - type: detected\n        criteria:\n          - type: file_path\n            value: \"**/*.generated.*\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: not_applicable\n\n```\n\n### 5. Rejeter les vulnérabilités atténuées par l'infrastructure\n\nCette politique concerne les classes de vulnérabilités telles que XSS (CWE-79) ou l'injection SQL (CWE-89) déjà couvertes par des règles WAF ou une protection au niveau de l'exécution. N'utilisez cette politique que lorsque les contrôles d'atténuation sont vérifiés et appliqués de manière systématique.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Dismiss CWEs mitigated by WAF\"\n    description: \"XSS and SQLi mitigated by WAF rules\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CWE-79\"\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CWE-89\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: mitigating_control\n\n```\n\n### 6. Rejeter des familles de CVE dans l'ensemble de votre organisation\n\nVotre équipe a déjà évalué une série de CVE liées à une bibliothèque très répandue ? Appliquez la politique au niveau du groupe pour les rejeter dans des dizaines de projets. Le motif générique (par exemple, `CVE-2021-44*`) correspond à toutes les CVE avec ce préfixe.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Accept risk for log4j CVE family\"\n    description: \"Log4j CVEs mitigated by version pinning and WAF\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CVE-2021-44*\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: acceptable_risk\n\n```\n\n## Référence\n\n| Paramètre | Détails |\n|-----------|---------|\n| **Types de critères** | `file_path` (motifs glob, par exemple `test/**/*`), `directory` (par exemple `vendor/*`), `identifier` (CVE/CWE avec caractères génériques, par exemple `CVE-2023-*`) |\n| **Motifs de rejet** | `acceptable_risk`, `false_positive`, `mitigating_control`, `used_in_tests`, `not_applicable` |\n| **Logique des critères** | Plusieurs critères dans une règle = ET (tous doivent correspondre). Plusieurs règles dans une politique = OU (au moins une doit correspondre). |\n| **Limites** | 3 critères par règle, 5 règles par politique, 5 politiques par projet de politique de sécurité. Les actions de politique de gestion des vulnérabilités traitent 1 000 vulnérabilités par exécution de pipeline dans le projet cible, jusqu'à ce que toutes les vulnérabilités correspondantes soient traitées. |\n| **Statuts concernés** | Nécessite un classement, Confirmé |\n| **Portée** | Au niveau du projet ou du groupe (une politique de groupe s'applique à tous les projets) |\n\n## Premiers pas\nVoici comment définir vos premières politiques de rejet automatique :\n\n1. **Identifiez les faux positifs.** Ouvrez votre rapport de vulnérabilités et triez par « Nécessite un classement ». Recherchez des tendances : fichiers de test, code tiers, la même CVE dans plusieurs projets.\n\n2. **Choisissez un scénario.** Commencez par le cas d'utilisation ci-dessus qui couvre le plus grand nombre de résultats.\n\n3. **Enregistrez votre référence initiale.** Notez le nombre de vulnérabilités avec le statut « Nécessite un classement » avant de créer une politique.\n\n4. **Créez et activez.** Accédez à **Sécurisation > Politiques > Nouvelle politique > Politique de gestion des vulnérabilités**. Collez la configuration du cas d'utilisation ci-dessus, puis fusionnez la merge request.\n\n5. **Validez les résultats.** Après la prochaine exécution du pipeline sur la branche par défaut, filtrez par statut « Rejeté » pour confirmer que les bons résultats ont été traités.\n\nPour tous les détails de configuration, consultez la [documentation sur les politiques de gestion des vulnérabilités](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/#auto-dismiss-policies).\n\n> Vous souhaitez maîtriser la gestion des faux positifs liés aux vulnérabilités ? [Démarrez un essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/) et configurez votre première politique de rejet automatique dès aujourd'hui.\n",{"slug":740,"featured":26,"template":14},"auto-dismiss-vulnerability-management-policy",{"content":742,"config":750},{"tags":743,"category":11,"body":744,"date":745,"heroImage":746,"authors":747,"description":748,"title":749},[11,735],"Les vulnérabilités dans les conteneurs n'attendent pas votre prochain\ndéploiement. Elles peuvent apparaître à tout moment, de la création d'une\nimage à l'exécution des conteneurs en production. Pour remédier à ce\nproblème, GitLab propose plusieurs approches d'analyse des conteneurs,\nchacune conçue pour une étape spécifique du cycle de développement logiciel ([SDLC](https://about.gitlab.com/fr-fr/blog/what-is-sdlc/ \"Qu'est-ce que le SDLC ?\")).\n\n\nDans ce guide, nous explorons les différents types d'analyse de conteneurs proposés par GitLab, vous expliquons comment les activer et vous partageons les configurations les plus courantes pour bien démarrer.\n\n\n## Qu'est-ce que l'analyse des conteneurs ? \n\n\nLes vulnérabilités de sécurité présentes dans les images de conteneurs constituent un risque tout au long du cycle de vie applicatif. Les images de base, les paquets de systèmes d'exploitation et les dépendances applicatives peuvent tous receler des vulnérabilités activement exploitées par des attaquants. L'analyse des conteneurs permet de détecter ces risques en amont, avant qu'ils n'atteignent l'environnement de production, et propose des pistes de remédiation le cas échéant.\n\n\nL'analyse des conteneurs est un élément essentiel de l'analyse de la composition logicielle (SCA), qui vous aide à comprendre et à sécuriser les dépendances externes dont vos applications conteneurisées dépendent.\n\n\n## 5 types d'analyses de conteneurs dans GitLab\n\n\nGitLab propose cinq approches distinctes d'analyse de conteneurs, chacune répondant à un objectif précis dans votre stratégie de sécurité.\n\n\n### 1. Analyse des conteneurs dans le pipeline\n\n\n* Fonctionnement : analyse les images de conteneurs lors de l'exécution du [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") afin de détecter les vulnérabilités avant le déploiement\n\n* Cas d'utilisation idéal : contrôles de sécurité en amont (shift-left) pour bloquer les images vulnérables avant qu'elles n'atteignent la production\n\n* Disponibilité : version gratuite de GitLab, GitLab Premium et GitLab Ultimate (avec des fonctionnalités supplémentaires dans GitLab Ultimate)\n\n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n\nGitLab utilise le scanner de sécurité Trivy pour analyser les images de conteneurs et rechercher de vulnérabilités connues. Lors de l'exécution du pipeline, le scanner examine vos images et génère un rapport détaillé.\n\n\n#### Activer l'analyse des conteneurs dans le pipeline\n\n\n**Option A : merge request préconfigurée**\n\n\n* Accédez à **Sécurisation > Configuration de la sécurité** dans votre projet.\n\n* Repérez la ligne « Analyse de conteneurs ».\n\n* Sélectionnez **Configurer avec une merge request**.\n\n* Une merge request intégrant la configuration nécessaire est automatiquement créée.\n\n\n**Option B : configuration manuelle**\n\n\n* Ajoutez le contenu suivant à votre fichier `.gitlab-ci.yml` :\n\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n```  \n\n\n#### Configurations courantes\n\n\n**Analyser une image spécifique :**\n\n\nPour analyser une image spécifique, remplacez la variable `CS_IMAGE` dans le job `container_scanning`.\n\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_IMAGE: myregistry.com/myapp:latest\n```\n\n\n**Filtrer par seuil de gravité :**\n\n\nPour n'afficher que les vulnérabilités dépassant un certain niveau de gravité, remplacez la variable `CS_SEVERITY_THRESHOLD` dans le job `container_scanning`. Dans l'exemple ci-dessous, seules les vulnérabilités d'un niveau de gravité **Élevé** ou supérieur seront affichées.\n\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_SEVERITY_THRESHOLD: \"HIGH\"\n```\n\n\n#### Consulter les vulnérabilités dans une merge request\n\n\nL'affichage direct des vulnérabilités détectées par l'analyse des conteneurs au sein des merge requests rend les revues de sécurité plus fluides et plus efficaces. Une fois l'analyse des conteneurs configurée dans votre pipeline CI/CD, GitLab affiche automatiquement les vulnérabilités détectées dans le [widget Sécurité](https://docs.gitlab.com/user/project/merge_requests/widgets/#application-security-scanning) de la merge request.\n\n\n![Vulnérabilités détectées lors de l'analyse des conteneurs affichées dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/lt6elcq6jexdhqatdy8l.png \"Vulnérabilités détectées lors de l'analyse des conteneurs affichées dans la merge request\")\n\n\n* Accédez à n'importe quelle merge request et faites défiler jusqu'à la section « Analyse de sécurité » pour obtenir un résumé des vulnérabilités nouvellement introduites et existantes détectées dans vos images de conteneurs.\n\n* Cliquez sur une **vulnérabilité** pour accéder à des informations détaillées, notamment le niveau de gravité, les paquets affectés et les recommandations de remédiation disponibles.\n\n\n![GitLab Security – détails dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/hplihdlekc11uvpfih1p.png)\n\n\n![GitLab Security – détails dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/jnxbe7uld8wfeezboifs.png \"Détails d'une vulnérabilité détectée par l'analyse des conteneurs dans la merge request\")\n\n\nCette visibilité permet aux équipes de développement et de sécurité de détecter et de traiter les vulnérabilités des conteneurs avant qu'elles n'atteignent la production : la sécurité devient une composante à part entière du processus de revue de code plutôt qu'un contrôle distinct.\n\n\n#### Consulter les vulnérabilités dans le rapport de vulnérabilités\n\n\nAu-delà des revues dans les merge requests, GitLab met à disposition un [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/) centralisé, qui offre aux équipes de sécurité une visibilité complète sur l'ensemble des résultats de l'analyse des conteneurs dans votre projet.\n\n\n![Rapport de vulnérabilités avec classement selon l'analyse des conteneurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547524/gagau279fzfgjpnvipm5.png \"Rapport de vulnérabilités avec classement selon l'analyse des conteneurs\")\n\n\n* Accédez à ce rapport via **Sécurité et conformité > Rapport de vulnérabilités** dans la barre latérale de votre projet.\n\n* Vous y trouverez une vue agrégée de toutes les vulnérabilités de conteneurs détectées dans vos branches, avec des options de filtrage permettant de trier les vulnérabilités par gravité, statut, type de scanner ou image de conteneur spécifique.\n\n* Cliquez sur une vulnérabilité pour accéder à sa page dédiée.\n\n\n![Page de vulnérabilité – vue 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547520/e1woxupyoajhrpzrlylj.png)\n\n\n![Page de vulnérabilité – vue 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547521/idzcftcgjc8eryixnbjn.png)\n\n\n![Page de vulnérabilité – vue 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547522/mbbwbbprtf9anqqola10.png \"Détails d'une vulnérabilité détectée par l'analyse des conteneurs\")\n\n\nLes [détails de la vulnérabilité](https://docs.gitlab.com/user/application_security/vulnerabilities/) indiquent précisément les images et couches de conteneurs concernées pour faciliter la traçabilité jusqu'à la source du problème. Vous pouvez assigner des vulnérabilités à des membres de l'équipe, modifier leur statut (détectée, confirmée, résolue, rejetée), ajouter des commentaires pour faciliter la collaboration et associer des tickets connexes pour suivre la remédiation.\n\n\nCe workflow transforme la [gestion des vulnérabilités](https://about.gitlab.com/fr-fr/blog/what-is-vulnerability-management/ \"Qu'est-ce que la gestion des vulnérabilités ?\"), autrefois cantonnée à des tableurs, en une composante intégrée de votre processus de développement, garantissant que les résultats de sécurité des conteneurs sont suivis, priorisés et résolus de manière systématique.\n\n\n#### Consulter la liste des dépendances\n\n\nLa [liste des dépendances](https://docs.gitlab.com/user/application_security/dependency_list/) de GitLab fournit une nomenclature logicielle complète ([SBOM](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"Qu'est-ce qu'une SBOM ?\")) qui répertorie chaque composant de vos images de conteneurs afin d'offrir une transparence totale sur votre [chaîne d'approvisionnement logicielle](https://about.gitlab.com/fr-fr/blog/software-supply-chain-security-guide-why-organizations-struggle/).\n\n\n* Accédez à **Sécurité et conformité > Liste des dépendances** pour consulter l'inventaire de tous les paquets, bibliothèques et dépendances détectés par l'analyse des conteneurs dans votre projet.\n\n* Cet affichage répertorie les éléments qui s'exécutent réellement dans vos conteneurs, des paquets du système d'exploitation de base aux dépendances applicatives.\n\n\n![Liste des dépendances de GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/vjg6dk3nhajqamplroji.png \"Liste des dépendances de GitLab (SBOM)\")\n\n\nVous pouvez filtrer la liste par gestionnaire de paquets, type de licence ou statut de vulnérabilité afin d'identifier rapidement les composants qui présentent des risques de sécurité ou des problèmes de conformité. Chaque entrée de dépendance affiche les vulnérabilités associées pour traiter les problèmes de sécurité dans le contexte des composants logiciels réels, plutôt que comme des résultats isolés.\n\n\n### 2. Analyse des conteneurs pour le registre\n\n\n* Fonctionnement : analyse automatiquement les images envoyées vers le registre de conteneurs de GitLab (GitLab Container Registry) avec le tag `latest`\n\n* Cas d'utilisation idéal : surveillance continue des images du registre, sans déclenchement manuel du pipeline\n\n* Disponibilité : GitLab Ultimate uniquement\n\n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/#container-scanning-for-registry)\n\n\nLorsque vous effectuez un push d'une image de conteneur avec le tag `latest`, le bot de politique de sécurité de GitLab déclenche automatiquement une analyse sur la branche par défaut. Contrairement à l'analyse dans le pipeline, cette approche fonctionne conjointement avec l'analyse continue des vulnérabilités pour surveiller les nouveaux avis de sécurité publiés.\n\n\n#### Activer l'analyse des conteneurs pour le registre\n\n\n1. Accédez à **Sécurisation > Configuration de la sécurité**.\n\n2. Faites défiler jusqu'à la section **Analyse des conteneurs pour le registre**.\n\n3. Activez la fonctionnalité.\n\n\n![Analyse des conteneurs pour le registre](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547512/vntrlhtmsh1ecnwni5ji.png \"Bouton d'activation de l'analyse des conteneurs pour le registre\")\n\n\n#### Prérequis\n\n\n* Rôle de Chargé de maintenance ou supérieur dans le projet\n\n* Le projet ne doit pas être vide (au moins un commit sur la branche par défaut est requis)\n\n* Les notifications du registre de conteneurs doivent être configurées\n\n* La base de données de métadonnées des paquets doit être configurée (activée par défaut sur GitLab.com)\n\n\nLes vulnérabilités apparaissent sous l'onglet **Vulnérabilités du registre de conteneurs** dans votre rapport de vulnérabilités.\n\n\n### 3. Analyse multi-conteneurs\n\n\n* Fonctionnement : analyse plusieurs images de conteneurs en parallèle au sein d'un même pipeline\n\n* Cas d'utilisation idéal : [architectures de microservices](https://about.gitlab.com/fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture/ \"Qu'est-ce qu'une architecture de microservices ?\") et projets avec plusieurs images de conteneurs\n\n* Disponibilité : version gratuite de GitLab, GitLab Premium et GitLab Ultimate (actuellement en version bêta)\n\n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/multi_container_scanning/)\n\n\nL'analyse multi-conteneurs utilise des pipelines enfants dynamiques pour exécuter des analyses simultanées afin de réduire considérablement le temps d'exécution global du pipeline lorsque plusieurs images doivent être analysées.\n\n\n#### Activer l'analyse multi-conteneurs\n\n\n1. Créez un fichier `.gitlab-multi-image.yml` à la racine de votre dépôt :\n\n\n```yaml\nscanTargets:\n  - name: alpine\n    tag: \"3.19\"\n  - name: python\n    tag: \"3.9-slim\"\n  - name: nginx\n    tag: \"1.25\"\n```\n\n\n2. Incluez le template dans votre fichier `.gitlab-ci.yml` :\n\n\n```yaml\ninclude:\n  - template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml\n```\n\n\n#### Configuration avancée\n\n\n**Analyser des images depuis des registres privés :**\n\n\n```yaml\nauths:\n  registry.gitlab.com:\n    username: ${CI_REGISTRY_USER}\n    password: ${CI_REGISTRY_PASSWORD}\n\nscanTargets:\n  - name: registry.gitlab.com/private/image\n    tag: latest\n```\n\n\n**Inclure les informations de licence :**\n\n\n```yaml\nincludeLicenses: true\n\nscanTargets:\n  - name: postgres\n    tag: \"15-alpine\"\n```\n\n\n### 4. Analyse continue des vulnérabilités\n\n\n* Fonctionnement : crée automatiquement des vulnérabilités lors de la publication de nouveaux avis de sécurité, sans nécessiter l'exécution de pipeline\n\n* Cas d'utilisation idéal : surveillance proactive de la sécurité entre les déploiements\n\n* Disponibilité : GitLab Ultimate uniquement\n\n* [Documentation](https://docs.gitlab.com/user/application_security/continuous_vulnerability_scanning/)\n\n\nL'analyse traditionnelle ne détecte les vulnérabilités qu'au moment où elle est effectuée. Mais que se passe-t-il lorsqu'une nouvelle vulnérabilité et exposition commune (CVE) est publiée le lendemain pour un paquet analysé la veille ? L'analyse continue des vulnérabilités résout ce problème en surveillant la base de données d'avis de GitLab et en enregistrant automatiquement les vulnérabilités lorsque de nouveaux avis affectent vos composants.\n\n\n#### Fonctionnement\n\n\n1. Votre job d'analyse des conteneurs ou d'analyse des dépendances génère une SBOM CycloneDX.\n\n2. GitLab enregistre les composants de votre projet à partir de cette SBOM.\n\n3. Lors de la publication de nouveaux avis, GitLab vérifie si vos composants sont concernés.\n\n4. Les vulnérabilités sont automatiquement créées dans votre rapport de vulnérabilités.\n\n\n#### Points importants\n\n\n* Les analyses s'exécutent via des jobs en arrière-plan (Sidekiq), et non via des pipelines CI.\n\n* Seules les alertes publiées au cours des 14 derniers jours sont prises en compte pour la détection de nouveaux composants.\n\n* Les vulnérabilités utilisent « GitLab SBoM Vulnerability Scanner » comme nom de scanner.\n\n* Pour marquer des vulnérabilités comme résolues, vous devez toujours exécuter une analyse basée sur un pipeline.\n\n\n### 5. Analyse opérationnelle des conteneurs\n\n\n* Fonctionnement : analyse les conteneurs en cours d'exécution dans votre cluster [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\") selon une cadence planifiée\n\n* Cas d'utilisation idéal : surveillance de la sécurité après déploiement et détection des vulnérabilités au moment de l'exécution\n\n* Disponibilité : GitLab Ultimate uniquement\n\n* [Documentation](https://docs.gitlab.com/user/clusters/agent/vulnerabilities/)\n\n\nL'analyse opérationnelle des conteneurs comble l'écart entre la sécurité au moment du build et la sécurité à l'exécution. Grâce à l'agent GitLab pour Kubernetes, cette approche analyse les conteneurs réellement en cours d'exécution dans vos clusters pour détecter les vulnérabilités qui apparaissent après le déploiement.\n\n\n#### Activer l'analyse opérationnelle des conteneurs\n\n\nSi vous utilisez l'[agent GitLab pour Kubernetes](https://docs.gitlab.com/user/clusters/agent/install/), vous pouvez ajouter le contenu suivant à votre fichier de configuration de l'agent :\n\n\n```yaml\ncontainer_scanning:\n  cadence: '0 0 * * *'  # Daily at midnight\n  vulnerability_report:\n    namespaces:\n      include:\n        - production\n        - staging\n```\n\n\nVous pouvez également créer une [politique d'exécution des analyses](https://docs.gitlab.com/user/clusters/agent/vulnerabilities/#enable-via-scan-execution-policies) qui impose une analyse selon un planning défini par l'agent GitLab pour Kubernetes.\n\n\n![Politique d'exécution des analyses – analyse opérationnelle des conteneurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547515/gsgvjcq4sas4dfc8ciqk.png \"Conditions d'une politique d'exécution des analyses pour l'analyse opérationnelle des conteneurs\")\n\n\n#### Consulter les résultats\n\n\n* Accédez à **Opération > Clusters Kubernetes**.\n\n* Sélectionnez l'onglet **Agent** et choisissez votre agent.\n\n* Sélectionnez ensuite l'onglet **Sécurité** pour consulter les vulnérabilités du cluster.\n\n* Les résultats apparaissent également sous l'onglet **Vulnérabilités opérationnelles** dans le **rapport de vulnérabilités**.\n\n\n## Renforcer la posture de sécurité avec les politiques de sécurité de GitLab\n\n\nLes politiques de sécurité de GitLab vous permettent d'appliquer des normes de sécurité cohérentes dans l'ensemble de vos workflows de conteneurs, grâce à des contrôles automatisés pilotés par des politiques. Ces politiques intègrent la sécurité en amont en intégrant les exigences directement dans votre pipeline de développement afin de garantir que les vulnérabilités sont détectées et traitées avant que le code n'atteigne l'environnement de production.\n\n\n#### Politiques d'exécution des scans et des pipelines\n\n\nLes [politiques d'exécution des scans](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/) automatisent le moment et la manière dont l'analyse des conteneurs s'exécute dans vos projets. Définissez des politiques qui déclenchent des analyses de conteneurs sur chaque merge request, planifiez des analyses récurrentes de votre branche principale, et plus encore. Ces politiques assurent une couverture complète sans que les équipes de développement aient à configurer manuellement l'analyse dans le pipeline CI/CD de chaque projet.\n\n\nVous pouvez préciser les versions de scanner à utiliser et configurer les paramètres de scan de manière centralisée pour garantir la cohérence dans toute votre organisation tout en vous adaptant aux nouvelles menaces qui pèsent sur la sécurité des conteneurs.\n\n\n![Configuration d'une politique d'exécution des scans](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/z36dntxslqem9udrynvx.png \"Configuration d'une politique d'exécution des scans\")\n\n\nLes [politiques d'exécution des pipelines](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) offrent des contrôles flexibles pour injecter (ou remplacer) des jobs personnalisés dans un pipeline en fonction de vos besoins en matière de conformité.\n\n\nCes politiques permettent d'injecter automatiquement des jobs d'analyse des conteneurs dans votre pipeline, de faire échouer les builds lorsque les vulnérabilités de conteneurs dépassent votre seuil de tolérance au risque, de déclencher des contrôles de sécurité supplémentaires pour des branches ou des tags spécifiques, ou encore d'imposer des exigences de conformité pour les images de conteneurs destinées aux environnements de production. Les politiques d'exécution des pipelines agissent comme des garde-fous automatisés pour appliquer vos normes de sécurité de manière cohérente dans l'ensemble de vos déploiements de conteneurs, sans intervention manuelle.\n\n\n![Politique d'exécution des pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/ddhhugzcr2swptgodof2.png \"Actions d'une politique d'exécution de pipeline\")\n\n\n#### Politiques d'approbation des merge requests\n\n\nLes [politiques d'approbation des merge requests](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) imposent des contrôles de sécurité : les approbateurs désignés examinent et valident les merge requests contenant des vulnérabilités de conteneurs.\n\n\nConfigurez des politiques qui bloquent le merge lorsque des vulnérabilités de gravité critique ou élevée sont détectées, ou qui exigent l'approbation de l'équipe de sécurité pour toute merge request introduisant de nouveaux résultats liés aux conteneurs. Ces politiques empêchent les images de conteneurs vulnérables de progresser dans votre pipeline tout en préservant la vélocité de développement pour les changements à faible risque.\n\n\n![Politique d'approbation des merge requests avec blocage dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/hgnbc1vl4ssqafqcyuzg.png \"Politique d'approbation des merge requests avec blocage dans la merge request\")\n\n\n## Choisir la bonne approche\n\n\n| Type d'analyse | Utilisation | Avantage clé |\n|--------------|-------------|-------------|\n| Analyse dans le pipeline | À chaque build | Contrôles de sécurité en amont, blocage des builds vulnérables |\n| Analyse de registre | Surveillance continue | Détection des nouvelles CVE dans les images stockées |\n| Analyse multi-conteneurs | Microservices | Analyse en parallèle, pipelines plus rapides |\n| Analyse continue des vulnérabilités | Entre les déploiements | Surveillance proactive des avis |\n| Analyse opérationnelle | Surveillance en production | Détection des vulnérabilités dans l'environnement d'exécution |\n\n\nPour une approche complète en matière de sécurité, combinez plusieurs approches : l'analyse dans le pipeline pour détecter les problèmes pendant le développement, l'analyse des conteneurs pour le registre afin d'assurer une surveillance continue et l'analyse opérationnelle pour la visibilité en production.\n\n\n## Lancez-vous dès aujourd'hui\n\n\nActivez l'analyse dans le pipeline pour commencer à appliquer des mesures de sécurité dans les conteneurs :\n\n\n1. Accédez à **Sécurisation > Configuration de la sécurité** dans votre projet.\n\n2. Cliquez sur **Configurer avec une merge request** pour lancer l'analyse des conteneurs.\n\n3. Fusionnez la merge request.\n\n4. Votre prochain pipeline inclura l'analyse des vulnérabilités.\n\n\nAjoutez ensuite des analyses supplémentaires en fonction de vos exigences de sécurité et de votre abonnement GitLab.\n\n\nLa sécurité des conteneurs n'est pas une tâche ponctuelle, mais un processus continu. Grâce aux capacités complètes d'analyse des conteneurs de GitLab, vous pouvez détecter les vulnérabilités à chaque étape du cycle de vie de vos conteneurs, du build à l'exécution.\n\n\n> Pour en savoir plus sur la façon dont GitLab peut contribuer à renforcer votre posture de sécurité, consultez la [page sur les solutions de sécurité et de gouvernance de GitLab](https://about.gitlab.com/fr-fr/solutions/application-security-testing/).\n","2026-04-13","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1772721753/frfsm1qfscwrmsyzj1qn.png",[9],"Découvrez les différentes méthodes d'analyse des conteneurs proposées par GitLab et apprenez à sécuriser vos conteneurs à chaque étape du cycle de développement logiciel.","Analyse des conteneurs de GitLab : le guide complet",{"featured":13,"template":14,"slug":751},"complete-guide-to-gitlab-container-scanning",{"content":753,"config":763},{"title":754,"description":755,"tags":756,"category":11,"authors":758,"date":761,"body":762,"heroImage":732},"Orchestration de l'IA agentique au service des équipes sécurité","Découvrez comment l'orchestration d'agents d’IA au sein d'une plateforme DevSecOps unifiée peut transformer le quotidien des équipes AppSec.",[757,11],"AI/ML",[759,760],"Chloe Cartron","Benjamin Skierlak","2026-04-07","> *Cet article de blog est un résumé de notre démo animée par Chloé Cartron (Senior Solutions Architect) et Benjamin Skierlak (Customer Success Engineer, EMEA) lors du Forum InCyber 2026.*\n\nLes équipes sécurité applicative font face à une équation de plus en plus difficile à résoudre avec un volume croissant de code, de failles et de contraintes réglementaires, sans pour autant voir leurs effectifs augmenter. L'intelligence artificielle est souvent présentée comme la solution miracle, mais encore faut-il l'intégrer de façon structurée et maîtrisée dans les processus existants.\n\nDécouvrez dans cet article comment l'orchestration d'agents d’IA au sein d'une plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") unifiée transforme le quotidien des équipes AppSec, de la gestion du backlog de vulnérabilités jusqu'à la génération de rapports de conformité.\n\n> **🎯 Essayez [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) dès aujourd'hui !**\n\n## Le paradoxe de l'IA dans le développement logiciel\n\nL'intelligence artificielle a profondément transformé la façon dont les équipes de développement conçoivent et produisent leurs applications. [IDE](https://about.gitlab.com/fr-fr/blog/what-is-an-ide/ \"Qu'est-ce qu'un IDE ?\"), CLI, assistants de code ou encore générateurs d'applications : il est désormais possible de produire des milliers de lignes de code par jour. Une vélocité sans précédent, mais qui dissimule un problème structurel majeur.\n\nCar plus le code s'écrit vite, plus la surface d'attaque s'étend, et les équipes sécurité n’augmentent pas proportionnellement, puisqu’en moyenne **[4 personne sont dédiées à la sécurité pour 100 développeurs](https://codific.com/bsimm-building-security-in-maturity-model-a-complete-guide/)**. Résultat, les backlogs de vulnérabilités s'accumulent, les délais de remédiation s'allongent, et la conformité devient un chantier sans fin.\n\nC'est ce que nous appelons le **paradoxe de l'IA** : la vitesse, seule, n'est pas un avantage si elle engendre une dette de sécurité incontrôlable.\n\nLa réponse ne réside donc pas dans un ralentissement du développement, mais dans un changement de paradigme : utiliser l'IA non plus seulement pour écrire du code, mais pour **orchestrer la sécurité** à chaque étape du cycle de vie logiciel.\n\n## Une plateforme unifiée pour mettre fin à la fragmentation des outils\n\nLa **fragmentation des outils d’IA** constitue l'un des problèmes structurels les plus répandus au sein des équipes AppSec. À chaque changement d'outil, le contexte se perd, et des agents d’IA qui ne partagent pas de contexte commun reproduisent la fragmentation des outils.\n\nC'est pourquoi l'approche de GitLab repose sur un **modèle de données unifié** où le code, les pipelines, les issues, les merge requests et les résultats de scan coexistent dans un seul et même environnement. Les agents disposent ainsi d'une vision complète du cycle de développement, ce qui leur permet de prendre des décisions mieux informées, à chaque étape.\n\nCette architecture ouvre également la voie à de nouvelles formes de collaboration. En plus des agents d’IA disponibles par défaut sur GitLab, les équipes peuvent également créer et publier des agents dans un **[catalogue d’IA](https://docs.gitlab.com/user/duo_agent_platform/ai_catalog/)**, ce qui les rend réutilisables d'un projet à l'autre. Ils s'intègrent également avec des agents externes, et peuvent opérer en parallèle au sein de flows multi-agents, traitant plusieurs tâches simultanément. Une flexibilité qui permet à chaque organisation de construire progressivement un écosystème d'automatisation aligné sur ses propres besoins.\n\nMais qu'est-ce que cela signifie concrètement pour une équipe AppSec au quotidien ? Découvrons ensemble trois cas d’usage applicables pour vous aider à accélérer le traitement et la correction des vulnérabilités  et à informer votre organisation sur vos efforts en matière de sécurité et de conformité.\n\n## Trois cas d'usage concrets pour les équipes AppSec\n\n### 1. Trier et prioriser le backlog de vulnérabilités\n\nToutes les équipes sécurité connaissent ce défi : générer un [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/) et se retrouver face à des dizaines, voire des centaines d'alertes. La question n'est pas « y a-t-il des risques ? » mais « lesquels traiter en priorité ? »\n\nPrenons l’exemple d’une équipe AppSec chargée d’analyser le backlog de vulnérabilités, d’identifier les risques et de prioriser la résolution à travers l’ensemble des applications de l’organisation.\n\nPour cela, accédons au [rapport de vulnérabilités](https://gitlab.com/groups/gitlab-com/-/security/vulnerabilities), un tableau de bord qui offre une vue d'ensemble sur la posture sécurité d'une application. Les vulnérabilités qui y figurent sont identifiées par un ensemble de scanners de sécurité exécutés systématiquement dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") et regroupés en un seul endroit : SAST, DAST, analyse des dépendances, analyse des conteneurs, détection des secrets, etc.\n\nFace à un grand nombre de risques identifiés, l'enjeu est de distinguer rapidement ce qui représente un danger réel et urgent de ce qui peut être traité ultérieurement. C'est ici que l'IA apporte une première valeur ajoutée, puisque certaines vulnérabilités sont automatiquement signalées comme de **potentiels faux positifs**.\n\n![Signalement de potentiels faux positifs avec GitLab Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775581815/cxvus9f5hzfaqsbsqchc.png)\n\nEn plus des scanners de sécurité qui analysent la base de code, une analyse intelligente complémentaire à l’aide de l’IA est effectuée sur chaque vulnérabilité dans le contexte global du projet.\n\nPour en savoir plus sur ces potentiels faux positifs, nous allons interroger l’agent **[Security Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/)** de GitLab Duo en lui demandant « Pourquoi les secrets sont-ils identifiés comme potentiels faux positifs ». L’agent va effectuer une analyse intelligente dans le contexte pour déterminer s’il y a un réel risque ou non et partager ses retours à l'équipe AppSec.\n\nDans notre cas, il n’existe aucun risque puisque ce sont des secrets d’exemple. Nous allons donc demander à l'agent d'écarter ces vulnérabilités en masse en passant le statut à « dismissed » de toutes les vulnérabilités générées par le scanner de détection des secrets et identifiées comme faux positifs, puis d'ajuster les règles de détection pour affiner les futurs scans.\n\nL'étape suivante consiste à identifier les **risques réels prioritaires**. En posant la question « Quelles vulnérabilités posent le plus grand risque pour la production ? », l'agent analyse l'ensemble des vulnérabilités, génère des rapports de priorisation avec l'impact estimé et propose un plan d'action recommandé.\n\nPour chaque vulnérabilité critique, il est possible d'obtenir une explication détaillée : sa localisation, le scanner qui l’a identifié et les recommandations de remédiation.\n\n![Analyse des risques par l'agent Security Analyst de GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775571832/vkkor8ynqmxfdloaqyc9.png)\n\nEn cliquant sur le bouton **AI vulnerability management > Explain with AI**, nous allons demander à l'IA de nous aider à obtenir une meilleure compréhension du risque en nous donnant une explication avec des recommandations et des préconisations.\n\nUne fois les priorités établies, l'agent peut **confirmer les vulnérabilités critiques et créer automatiquement une issue** pour chacune d'entre elles, permettant de tracer la remédiation. En quelques minutes, le backlog de vulnérabilités critiques et de nombreuses vulnérabilités de sévérité moyenne est réduit à un nombre maîtrisé de risques effectivement triés et assignés.\n\nUne fois les risques identifiés, encore faut-il les corriger, et le faire rapidement. C'est là qu'intervient la **génération automatique de merge requests correctives**.\n\nDepuis un ticket lié à une vulnérabilité, la fonction « **Generate MR with Duo** » lance un flow agentique qui récupère le contexte de l’issue, du projet et des informations connexes, puis génère automatiquement une merge request contenant le correctif. Chaque modification suggérée par GitLab Duo suit un processus rigoureux : passage par le pipeline CI/CD et revue de code obligatoire avec approbation par un pair pour valider le changement de code.\n\nCette [création de merge requests correctives peut être également automatisée via des **flows agentiques**](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/agentic_sast_vulnerability_resolution/), permettant de passer à l'échelle en générant systématiquement des propositions de correction pour chaque vulnérabilité confirmée.\n\nNote : la fonction « **Generate MR with Duo** » ne se limite pas aux vulnérabilités, elle s’applique aussi à d'autres cas d'usage comme le développement de fonctionnalités à partir d'une spécification ou la résolution de bugs.\n\n### 2. Collaborer avec les développeurs pour prévenir l'introduction de nouvelles vulnérabilités\n\nLe deuxième enjeu est d'empêcher l'introduction de nouveaux risques le plus tôt possible dans le cycle de développement logiciel. Lorsqu'un développeur ouvre une merge request pour implémenter une nouvelle fonctionnalité, un ensemble de vérifications automatiques s'exécutent comme la **revue de code automatique de GitLab Duo** qui permet de fournir des premiers retours sur la qualité des changements apportés.\n\n![Revue de code automatique avec GitLab Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775581351/k5hm27hsnnovffqdo5z1.png)\n\nCependant, il arrive qu’une merge request se retrouve **bloquée par une [règle de sécurité](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/)** définie au niveau de l'organisation. Ces règles déterminent le seuil critique à respecter. Au-delà d'un certain niveau de risque (par exemple, des dépendances critiques), le merge est bloqué et une validation par un expert sécurité est requise.\n\nL'expert AppSec, sollicité pour faire une revue et donner son avis, doit alors se familiariser rapidement avec le changement et comprendre la vulnérabilité dans son contexte. Plutôt que de passer un temps considérable à analyser manuellement le code, les discussions et les tickets associés, ce dernier peut faire appel à GitLab Duo pour obtenir un **résumé contextuel sur les aspects liés à la sécurité** : modifications du code, discussions, issues associées et failles problématiques.\n\nSur la base de cette analyse, l’expert AppSec demande à l'agent de **publier sa recommandation directement en commentaire sur la merge request**, en taguant l'auteur de la merge request. Le développeur dispose ainsi immédiatement des préconisations de remédiation et comprend pourquoi la merge request est en échec.\n\n![Recommandation GitLab Duo en commentaire d'une merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775581459/ojd9klqyodu0mwladnv3.png)\n\nCe processus permet une collaboration fluide et rapide entre les équipes chargées de la sécurité et du développement, réduisant considérablement le temps nécessaire pour contextualiser un risque et communiquer les actions correctives.\n\n### 3. Générer des rapports de conformité et d’audit\n\nLe dernier cas d'usage répond à un besoin récurrent : donner de la **visibilité au management et aux auditeurs** sur la posture sécurité et la conformité des applications. Dans GitLab, un projet peut être associé à un **framework de conformité** (par exemple, la [norme ISO 27001)](https://about.gitlab.com/fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey/ \"ISO 27001\"), indiquant qu'il est soumis à un ensemble de règles spécifiques auquel il doit se conformer.\n\nEn demandant à l'agent Security Analyst de générer un résumé de l'état actuel de l'application en matière de sécurité et de conformité, celui-ci produit un **rapport complet** comprenant : une évaluation globale des risques, une analyse détaillée des vulnérabilités (y compris celles déjà triées et confirmées), des indicateurs de progression, une priorisation des actions restantes et des retours spécifiques par rapport à la norme de conformité applicable.\n\n![Rapport de l'agent Security Analyst](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775581612/mxiamj7z71rqrocxx2lx.png)\n\nCe rapport, généré en quelques minutes, permet de démontrer l'amélioration continue et de partager un état des lieux clair et structuré, là où ce travail aurait traditionnellement nécessité un effort manuel considérable.\n\nÀ travers ces trois cas d'usage, GitLab Duo permet aux équipes AppSec d'accélérer de façon significative la priorisation des risques, l'assignation et la réalisation des corrections, la collaboration avec les développeurs et la production de rapports de conformité. Des tâches qui prenaient habituellement des heures se réalisent désormais en quelques minutes, tout en maintenant les exigences de qualité, de traçabilité et de validation humaine à chaque étape.\n\n## L'équipe AppSec devient chef d'orchestre\n\nCe changement de paradigme est fondamental. Les équipes sécurité ne sont plus un goulot d'étranglement que l’on vient solliciter en dernier recours. Elles deviennent les **architectes des workflows** que les agents exécutent, tout en gardant la maîtrise de bout en bout.\n\nConcrètement, cela se traduit par trois responsabilités clés :\n\n* **Définir les règles** : quelles politiques de sécurité s'appliquent, à quel seuil bloque-t-on une merge request, quels frameworks de conformité sont requis ?\n* **Choisir les workflows** : quels agents activer, pour quels types de vulnérabilités, avec quelles automatisations ?\n* **Garder le contrôle** : toutes les actions des agents restent auditables et les validations humaines sont maintenues aux étapes critiques.\n\nEn déléguant l'exécution aux agents, les experts sécurité se concentrent sur la stratégie et peuvent couvrir un périmètre toujours plus large, sans avoir besoin de multiplier les effectifs. C'est la réponse concrète au paradoxe de l'IA : la vitesse du développement augmente, mais la sécurité suit le rythme grâce à une orchestration maîtrisée.\n\n## Déployer l'IA en toute souveraineté\n\nAdopter l'IA dans un contexte de sécurité soulève légitimement des questions sur la maîtrise des données. Pour y répondre, GitLab propose plusieurs modèles de déploiement adaptés aux exigences de chaque organisation :\n\n* **GitLab Self-Managed** : hébergé dans votre propre infrastructure, pour un contrôle total.\n* **GitLab.com** : une offre SaaS entièrement gérée par GitLab.\n* **GitLab Dedicated** : un SaaS dédié, déployé dans la région de votre choix.\n\nQuel que soit le modèle retenu, les organisations conservent la maîtrise de leurs données. Elles peuvent choisir leurs propres [grands modèles de langage (LLM)](https://about.gitlab.com/fr-fr/blog/large-language-model/ \"Qu'est-ce qu'un LLM ?\") et disposent d'options air-gapped avec des LLM auto-hébergés, garantissant qu'aucune donnée n'est retenue par les fournisseurs d'IA. La souveraineté n'est pas une contrainte à gérer après coup : elle est intégrée dès la conception. Pour en savoir plus, [consultez notre documentation](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/).\n\n## En résumé\n\nL'orchestration d'agents d’IA au service des équipes sécurité répond à un problème concret : faire plus avec les mêmes équipes, sans sacrifier la qualité ni le contrôle.\n\nLes trois enseignements clés à retenir :\n\n* **L’IA sans gouvernance crée autant de risques qu’elle en résout** : accélérer le développement sans intégrer la sécurité en amont amplifie l’exposition. La vitesse seule n’est pas un avantage si elle génère une dette de sécurité.\n* **Le contexte unifié est la clé de l’orchestration agentique** : des agents qui ne partagent pas de contexte reproduisent la fragmentation des outils. Avec le modèle de données unifié de GitLab, les agents peuvent agir avec une vision complète du cycle de vie.\n* **L'équipe AppSec orchestre, les agents exécutent** : avec les bons garde-fous et les bons agents, les équipes sécurité couvrent un périmètre qui grandit en permanence. En déléguant l’exécution, elles se concentrent sur la stratégie.\n\n> **🎯 Prêt à accélérer votre sécurité applicative ? Essayez [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) dès aujourd'hui !**",{"featured":26,"template":14,"slug":764},"orchestrating-agentic-ai-to-boost-your-security-teams",{"header":766,"blurb":767,"button":768,"secondaryButton":772},"Commencez à développer plus rapidement dès aujourd'hui","Découvrez ce que votre équipe peut accomplir avec la plateforme d'orchestration intelligente pour le DevSecOps.\n",{"text":44,"config":769},{"href":770,"dataGaName":47,"dataGaLocation":771},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":49,"config":773},{"href":51,"dataGaName":52,"dataGaLocation":771},{"promotions":775},[776,790,801,812],{"id":777,"categories":778,"header":780,"text":781,"button":782,"image":787},"ai-modernization",[779],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":783,"config":784},"Get your AI maturity score",{"href":785,"dataGaName":786,"dataGaLocation":250},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":788},{"src":789},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":791,"categories":792,"header":793,"text":781,"button":794,"image":798},"devops-modernization",[737,580],"Are you just managing tools or shipping innovation?",{"text":795,"config":796},"Get your DevOps maturity score",{"href":797,"dataGaName":786,"dataGaLocation":250},"/assessments/devops-modernization-assessment/",{"config":799},{"src":800},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":802,"categories":803,"header":804,"text":781,"button":805,"image":809},"security-modernization",[11],"Are you trading speed for security?",{"text":806,"config":807},"Get your security maturity score",{"href":808,"dataGaName":786,"dataGaLocation":250},"/assessments/security-modernization-assessment/",{"config":810},{"src":811},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":813,"paths":814,"header":817,"text":818,"button":819,"image":824},"github-azure-migration",[815,816],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":820,"config":821},"See how GitLab compares to GitHub",{"href":822,"dataGaName":823,"dataGaLocation":250},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":825},{"src":800},1777934965276]