[{"data":1,"prerenderedAt":779},["ShallowReactive",2],{"/fr-fr/blog/how-to-choose-the-right-security-scanning-approach":3,"navigation-fr-fr":38,"banner-fr-fr":442,"footer-fr-fr":452,"blog-post-authors-fr-fr-Matt Genelin|Mathias Ewald":662,"blog-related-posts-fr-fr-how-to-choose-the-right-security-scanning-approach":688,"assessment-promotions-fr-fr":731,"next-steps-fr-fr":770},{"id":4,"title":5,"authorSlugs":6,"body":9,"categorySlug":10,"config":11,"content":15,"description":9,"extension":27,"isFeatured":12,"meta":28,"navigation":29,"path":30,"publishedDate":20,"seo":31,"stem":34,"tagSlugs":35,"__hash__":37},"blogPosts/fr-fr/blog/how-to-choose-the-right-security-scanning-approach.yml","How To Choose The Right Security Scanning Approach",[7,8],"matt-genelin","mathias-ewald",null,"security",{"featured":12,"template":13,"slug":14},false,"BlogPost","how-to-choose-the-right-security-scanning-approach",{"tags":16,"category":10,"body":19,"date":20,"heroImage":21,"title":22,"description":23,"authors":24},[10,17,18],"tutorial","CI/CD","L'intégration de scans de sécurité dans votre pipeline CI/CD est cruciale pour maintenir des applications robustes et sécurisées. Mais qui est responsable de ces scans ? Qui doit s'assurer de leur intégration dans chaque pipeline CI/CD pour tous les projets ? Et qui décide d'accepter ou de corriger les vulnérabilités identifiées ? Pour les organisations qui évoluent dans des secteurs réglementés, ces questions sont primordiales.\n\nDans cet article, vous découvrirez comment GitLab [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) permet à chaque membre du cycle de développement logiciel d'intégrer des scans de sécurité. Vous découvrirez également les avantages et inconvénients des différentes options pour ajouter des scans aux pipelines de projets GitLab. Des exemples de code vous aideront aussi à lancer rapidement des scans de sécurité sur la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"DevSecOps\") de GitLab.\n\n> **[→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr)**\n\n## Les bases de la configuration des scans de sécurité\n\nGitLab utilise des [personas fictifs](https://handbook.gitlab.com/handbook/product/personas/#user-personas) pour décrire le membre d'une équipe qui utiliserait généralement une fonctionnalité ou une approche de sécurité donnée. En vous mettant dans la peau d'un **Software Developer (Sasha)**, d'une **Application Security Engineer (Amy)**, ou d'une **Platform Engineer (Priyanka)**, vous pourrez mieux comprendre les besoins de chaque personne dans votre équipe.\n\nGitLab suit un principe de « pipeline par projet », stocké dans le fichier nommé `.gitlab-ci.yml`. Ce fichier contient la définition du [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Pipeline CI/CD\") du projet et est géré par [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"contrôle de version\") comme n'importe quel autre fichier du projet. Vous découvrirez ces pipelines de projet, ainsi que les pipelines de conformité et les pipelines de politiques. Bien que les pipelines de conformité et les pipelines de politiques fassent également référence aux fichiers YAML dans les projets GitLab, ils ont généralement un nom de fichier différent et servent à des fins différentes.\n\nSi vous connaissez déjà les scans de sécurité dans GitLab, les pipelines de sécurité disponibles vous paraîtront clairs. Nous aborderons chacune des approches en fonction des critères suivants :\n\n- **Facilité d'utilisation :** à quel point est-il simple d'ajouter des scans de sécurité aux pipelines de projet ? Est-ce une tâche pour Sasha, ou une tâche qu'Amy et Priyanka devraient gérer ?\n\n- **Personnalisation :** à quel niveau peut-on personnaliser les configurations des scanners avec cette approche ? Les configurations par défaut sont utiles et couvrent un large éventail de besoins clients, mais elles nécessitent toujours des ajustements.\n\n- **Application :** cette approche convient-elle aux entreprises opérant dans des secteurs réglementés ou ayant des politiques globales en place ? Pouvons-nous garantir que chaque projet pertinent exécute le scanner X avec la configuration Y ?\n\n## Le mot-clé `include`\n\nLes [mots-clés `include` des pipelines de projet GitLab](https://docs.gitlab.com/ee/ci/yaml/includes.html) permettent d'intégrer des pipelines externes dans le pipeline de projet `.gitlab-ci.yml`. Ce mécanisme est similaire à l'inclusion d'une bibliothèque dans de nombreux langages de programmation. Cette fonctionnalité puissante permet d'intégrer de façon transparente vos propres templates, ainsi que des templates fournis par GitLab, pour servir d'éléments de base dans vos pipelines. Les mots-clés `include` peuvent être utilisés dans les pipelines de projet ou d'autres fichiers de pipeline. Les pipelines de scan de sécurité sont des pipelines externes souvent inclus dans les pipelines de projet GitLab.\n\nVoici les types courants de mots-clés `include`, qui utilisent l'exemple du scanner de sécurité.\n\n### Templates\n\nGitLab propose des [templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Jobs) prêts à l'emploi qui peuvent être inclus dans un pipeline de projet pour faciliter l'ajout de divers éléments préconçus par les équipes. Voici un exemple de code :\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n  - template: Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\n```\nCe code inclut les templates GitLab pour la [détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/), les [tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/), l'[analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), et l'[analyse des conteneurs](https://docs.gitlab.com/ee/user/application_security/container_scanning/), le tout en seulement cinq lignes de code.\n\nPour modifier le comportement des jobs inclus via des templates, vous pouvez soit utiliser des variables, soit utiliser les [capacités de merge de propriétés de GitLab](https://docs.gitlab.com/ee/ci/yaml/includes.html#merge-method-for-include).\n\nVous trouverez ci-dessous un exemple de modification du pipeline d'analyse des conteneurs de GitLab à l'aide de variables. Le [template d'analyse des conteneurs](https://gitlab.com/gitlab-org/gitlab/-/blob/59f08760feaab1eb0489f694d4f28408af9c2e8d/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml) doit connaître l'emplacement de l'image et utilise la variable `CS_IMAGE` pour ce faire, comme documenté dans le code du template ci-dessus.\n```yaml\nvariables:\n  CS_IMAGE: \"$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA\"\n\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\n```\nLes variables du pipeline de projet sont disponibles pour les template de jobs inclus en définissant la variable `CS_IMAGE` avant le template de pipeline inclus. Le template d'analyse des conteneurs hérite de la valeur de la variable `CS_IMAGE`.\n\nSi nous voulions apporter des modifications à la [propriété `allow_failure` définie](https://gitlab.com/gitlab-org/gitlab/-/blob/59f08760feaab1eb0489f694d4f28408af9c2e8d/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml#L38), nous devrions fusionner les propriétés, car les templates de jobs n'utilisent aucune variable pour la valeur. (La propriété `allow_failure` est une propriété généralement disponible pour chaque job de pipeline GitLab. Consultez notre [documentation](https://docs.gitlab.com/ee/ci/yaml/#allow_failure) pour plus de détails.)\n\nDans cet exemple, `allow_failure` est défini sur `false`, ce qui signifie que l'ensemble du pipeline s'arrête en cas d'échec de l'analyse des conteneurs : tout conteneur non scanné ne peut avancer dans le pipeline.\n```yaml\ninclude:\n  # Includes a job called \"container_scanning\"\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\n# Define a job with same name for merging\ncontainer_scanning:\n  allow_failure: false\n\n```\nGitLab charge le template de job et, comme défini dans le code du template, enregistre le job `container_scanning`. Comme la définition du pipeline déclare un autre job avec ce nom, GitLab fusionne cette spécification avec le job déjà enregistré.\n\nBien que cette fonctionnalité offre de nombreuses possibilités, elle empêche également de protéger certaines propriétés contre l'écrasement. Nous n'en sommes qu'au point de modification du pipeline de projet, et nous ne pouvons contrôler ce paramètre. Mais vous verrez plus tard que cela peut poser problème lorsque la sécurité doit être appliquée sur un projet.\n\n### Composants\n\nLes templates constituent un excellent point de départ pour partager des pipelines GitLab réutilisables. Pour abstraire davantage le code réutilisable dans l'ensemble d'une organisation ou d'une instance GitLab, GitLab a introduit les [composants](https://docs.gitlab.com/ee/ci/components/). Les composants sont la prochaine étape logique dans l'évolution des pipelines de GitLab. Ils sont conçus pour simplifier la création et l'utilisation de blocs fonctionnels dans les pipelines, ou même pour empaqueter et livrer des pipelines entiers si nécessaire. Ils offrent une interface bien définie, qui accepte des « intrants » pour la configuration. Les composants sont complètement isolés, ce qui en fait d'excellents candidats pour partager le travail au sein d'une organisation et pour servir d'éléments de base consultables et réutilisables.\n \nLes équipes de développement peuvent utiliser le [catalogue CI/CD](https://gitlab.com/explore/catalog) pour parcourir et rechercher la collection de composants GitLab disponibles pour le public. Ces composants sont officiellement créés et maintenus par GitLab. GitLab utilise le catalogue CI/CD [pour publier nos composants livrés](https://gitlab.com/components) tels que les scanners de sécurité aux côtés des composants fournis par la communauté.\n\nLes composants sont consommés de manière similaire aux templates via le mot-clé `include`. Dans un exemple ci-dessus, nous avons montré comment le job d'analyse des conteneurs avait besoin de connaître l'emplacement de l'image. Cet « intrant » utilise le composant `cs_image` pour l'[analyse des conteneurs](https://gitlab.com/components/container-scanning/-/blob/19fd5b83bc631cb9890b4fadb08d31b3150853ce/templates/container-scanning.yml). La configuration équivalente à l'exemple précédent est la suivante :\n```yaml\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n    inputs:\n      cs_image: \"$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA\"\n\n```\nDans cet exemple, le composant SAST est épinglé à la version 2.0.2, le composant d'analyse des dépendances à la version 0.2.0, le composant de détection des secrets à la version 1.1.2 et le composant d'analyse des conteneurs à la version 4.1.0. `~latest` et [d'autres tags sont disponibles](https://docs.gitlab.com/ee/ci/components/#component-versions) pour une utilisation de composants de pointe et d'autres besoins de développement.\n\nQue vous utilisiez des templates ou des composants, votre pipeline pourrait ressembler à l'image ci-dessous. Les quatre premiers jobs de l'étape de test sont le résultat des quatre instructions avec `include` dans le code ci-dessus.\n\n![Un exemple de pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097983863.png)\n\n### Avantages et inconvénients de l'utilisation du mot-clé `include`\n\n#### Facilité d'utilisation\n\nL'un des avantages de l'utilisation du mot-clé `include` de pipeline dans GitLab est sa facilité d'utilisation. Avec seulement six lignes de code, nous avons inclus quatre scanners de sécurité couramment utilisés. Toute la logique et la configuration complexes sont gérées au sein des templates ou des composants. Ainsi, Sasha gagne du temps grâce à une solution prête à l'emploi.\n\n#### Personnalisation\n\nBien que les templates offrent une flexibilité maximale (variables et merge), il est important de ne pas oublier qu'elles impliquent de grandes responsabilités. La flexibilité des templates permet une personnalisation étendue, mais nécessite une gestion et une supervision minutieuses pour éviter des résultats inattendus.\n\nEn revanche, les composants fournissent un mécanisme plus structuré pour la création, le partage et la maintenance d'éléments de base pour un public plus large. Même s'ils sont moins personnalisables, les composants améliorent la stabilité et la fiabilité, et constituent une fonctionnalité précieuse, réutilisable et reproductible.\n\n#### Application\n\nComme le nom *include* le suggère, le pipeline de projet GitLab doit inclure des templates ou des composants. Bien que les templates soient simples à utiliser, Amy et Priyanka ne peuvent pas être sûres que Sasha les a inclus (correctement). Il est donc nécessaire d'appliquer une utilisation des scanners.\n\n## Les frameworks de conformité\n\nGitLab a identifié l'écart entre l'application des scans de sécurité dans les pipelines de projet et le besoin de [respecter les frameworks de conformité réglementaire](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/) tels que PCI DSS, NIST et bien d'autres. L'introduction des frameworks de conformité en tant que fonctionnalité répond précisément à ce défi.\n\nÀ première vue, un framework de conformité dans GitLab n'est qu'un label attaché à un projet et serait généralement nommé d'après le framework réglementaire qu'il est censé implémenter. Tout prend forme avec le lien entre ce label et le fichier YAML de pipeline de conformité, qui est responsable de la mise en œuvre des étapes nécessaires pour assurer la conformité.\n\nLe mécanisme est simple : chaque fois que le pipeline de projet est déclenché, GitLab exécute le pipeline de conformité à la place. Ce dernier s'exécute avec les [variables CI/CD](https://docs.gitlab.com/ee/ci/variables/) et les [variables CI/CD prédéfinies](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) du pipeline de projet.\n\nDeux principaux modèles de conception émergent : un « pipeline englobant », où le pipeline de conformité inclut le pipeline de projet, et un « pipeline de remplacement », où il ne l'inclut pas.\n\n**Remarque :** les pipelines de conformité ont été dépréciés dans la version 17.3 de GitLab et devraient être supprimés dans la version 19.0. À ce stade, nous ne recommandons pas d'implémenter cette approche pour les nouvelles plateformes de développement. Cependant, si vous les utilisez déjà, ne manquez pas de consulter les sections ci-dessous.\n\n### Pipelines englobants\n\nDans cette approche, le pipeline de conformité définit ses propres jobs selon des besoins de conformité spécifiques. Il inclut le pipeline de projet de la même manière que les templates dans la section précédente. Cette configuration est possible car les variables CI/CD prédéfinies proviennent du pipeline de projet et permettent au système d'identifier l'emplacement de la définition du pipeline pour l'inclure.\n\nVoici un exemple de ce à quoi pourrait ressembler un pipeline de conformité simple.\n```yaml\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n  - project: '$CI_PROJECT_PATH'\n    file: '$CI_CONFIG_PATH'\n    ref: '$CI_COMMIT_SHA'\n\n```\nLes trois dernières lignes incluent le pipeline de projet basé sur les variables disponibles.\n\n### Pipelines de remplacement\n\nContrairement aux pipelines englobants, qui incluent le pipeline de projet, les pipelines de remplacement l'ignorent entièrement et n'exécutent que leurs propres jobs. Ce type de pipeline définit chaque étape et englobe tous les jobs nécessaires pour construire, tester et déployer l'application.\n\nVoici un pipeline de conformité fictif qui illustre cette approche.\n```yaml\nstages: [\"build\", \"test\", \"deploy\"]\n\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n\nbuild-job:\n  stage: build\n  script: echo \"Building the container image\"\n\ntest-job:\n  stage: test\n  script: echo \"Running unit tests\"\n\ndeploy-job:\n  stage: deploy\n  script: echo \"Deploying app\"\n\n```\n### Avantages et inconvénients des frameworks de conformité\n\n#### Facilité d'utilisation\n\nBien que les frameworks de conformité ne soient pas très compliqués, ils ne sont pas aussi simples et directs que les mots-clés `include`. Ils sont destinés à être écrits et attribués aux projets par Amy et Priyanka, qui doivent maintenant interagir avec le code YAML du pipeline. Un framework doit être déclaré dans l'espace de nommage principal, des pipelines de conformité doivent être créés et maintenus, et les frameworks de conformité doivent être attachés aux bons projets.\n\n#### Personnalisation\n\nAmy et Priyanka sont les auteures des pipelines de conformité. Comme Sasha dans la section précédente sur les mots-clés `include`, elles ont un contrôle total sur ce qu'elles incluent et comment elles l'incluent : elles peuvent personnaliser les jobs de conformité comme les scanners de sécurité.\n\n#### Application\n\nL'application des pipelines soulève la question de savoir si les équipes de développement peuvent altérer les jobs de sécurité. Dans un environnement avec une forte séparation des tâches, cette nuance nécessite une attention supplémentaire. Pour répondre à cette question, nous devons examiner chaque modèle séparément :\n\n##### Pipelines englobants\n\nComme nous l'avons vu précédemment, les pipelines de projet sont inclus dans les pipelines de conformité. En plus des variables CI/CD au niveau du groupe ou du projet, chaque élément de ce pipeline de projet doit être considéré comme une menace potentielle pour le pipeline de conformité, en particulier les variables et les jobs. Ces derniers peuvent et vont influencer le comportement des jobs de sécurité s'ils sont utilisés de manière malveillante.\n\nVoici un exemple simple pour illustrer le problème.\n\nPipeline de conformité :\n```yaml\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n  - project: '$CI_PROJECT_PATH'\n    file: '$CI_CONFIG_PATH'\n    ref: '$CI_COMMIT_SHA'\n\n```\nPipeline de projet :\n```yaml\nvariables:\n  SECRET_DETECTION_DISABLED: true\n\nsemgrep-sast:\n  rules:\n    - when: never\n\n```\nCe pipeline de projet déclare la variable `SECRET_DETECTION_DISABLED` (également possible via des variables CI/CD au niveau du projet ou du groupe), qui est évaluée dans le template de détection de secrets inclus. De plus, les trois dernières lignes utilisent le mécanisme de merge vu précédemment, qui n'exécute pas le job.\n\nLes deux remplacements pourraient être évités en utilisant des composants. Ces derniers peuvent être sujets à de telles attaques en raison des valeurs par défaut de leurs intrants, qui utilisent aussi souvent des variables. Voyons comment cette vulnérabilité pourrait être exploitée.\n\nPipeline de conformité :\n```yaml\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - project: '$CI_PROJECT_PATH'\n    file: '$CI_CONFIG_PATH'\n    ref: '$CI_COMMIT_SHA'\n\n```\nPipeline de projet :\n```yaml\nvariables:\n  CI_TEMPLATE_REGISTRY_HOST: \"docker.io\"\n\n```\nPour comprendre ce fonctionnement, regardez la [ligne 6 du composant du scanner SAST](https://gitlab.com/components/sast/-/blob/main/templates/sast.yml?ref_type=heads#L6) :\n```yaml\nspec:\n  inputs:\n    stage:\n      default: test\n    image_prefix:\n      default: \"$CI_TEMPLATE_REGISTRY_HOST/security-products\"\n\n```\nL'intrant `image_prefix` utilise `CI_TEMPLATE_REGISTRY_HOST` pour construire la valeur par défaut. En définissant cette variable sur une fausse valeur de la même manière que nous avons défini `SECRET_DETECTION_DISABLED` sur `true` auparavant, Sasha peut faire en sorte que le job charge une mauvaise image et casse les SAST.\n\nPour empêcher cette capacité de remplacement par une personne ayant un rôle de développeur, privilégiez les composants au lieu des templates. Vous pourrez ainsi corriger de nombreuses failles introduites par les développeurs. Pour garantir la conformité, codez en dur les valeurs pour les intrants des composants.\n\n##### Pipelines de remplacement\n\nLes développeurs ne peuvent pas injecter du code de pipeline réel dans le pipeline de conformité. Cependant, les pipelines de conformité s'exécutent avec les variables CI/CD du projet. Par conséquent, toute variable au niveau du groupe ou du projet pourrait modifier le comportement du pipeline de conformité. Avec `SECRET_DETECTION_DISABLED` défini sur `true` dans les variables CI/CD du projet, le pipeline de conformité suivant peut être modifié à nouveau :\n```yaml\nstages: [\"build\", \"test\", \"deploy\"]\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nbuild-job: ...\ntest-job: ...\ndeploy-job: ...\n```\nLes composants peuvent résoudre ce problème, mais, comme auparavant, les intrants des composants peuvent utiliser des variables CI/CD définies par les développeurs. Les auteurs de pipelines de conformité doivent identifier et gérer ces situations.\n\n## Politiques\n\nLes lacunes des pipelines de conformité ont entraîné la création de [politiques](https://docs.gitlab.com/ee/user/application_security/policies/). GitLab a introduit les politiques comme la voie à suivre en matière de gestion de la conformité. Les auteurs stockent un ensemble de politiques dans un projet séparé sous forme de fichiers YAML et les appliquent aux projets au niveau du groupe ou du projet. Amy et Priyanka peuvent cibler des projets individuels avec des exigences spécifiques, mais aussi assurer la conformité dans toute l'organisation. L'accès au projet contenant les politiques peut être contrôlé au sein du projet de politiques et audité dans GitLab.\n\nIl existe différents types de politiques pour différents usages. Ceux qui nous intéressent sont les politiques d'exécution des scans (SEP) et les politiques d'exécution des pipelines (PEP).\n### Politiques d'exécution des scans\nComme leur nom l'indique, les SEP exigent qu'un scan particulier, ou un ensemble de scans, soit exécuté dans le cadre du pipeline de projet et injectent les jobs de scan respectifs dans les pipelines des projets associés. Elles incluent le [template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Jobs) respectif dans le pipeline selon les variables et les règles définies par Amy et Priyanka.\n\nGitLab aide les auteurs de politiques avec une interface utilisateur complète en plus d'un workflow [Git](https://about.gitlab.com/fr-fr/blog/2024/10/08/what-is-git/ \"Qu'est-ce que Git ?\") basé sur YAML. La capture d'écran et l'extrait de code suivants illustrent un exemple très basique d'une SEP :\n![Exemple de politiques d'exécution des scans](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097983864.png)\n```yaml\nname: Secret Scanner\ndescription: ''\nenabled: true\nactions:\n- scan: secret_detection\nrules:\n- type: pipeline\n  branches:\n  - \"*\"\n\n```\nPour plus de détails sur les paramètres des SEP dans l'interface utilisateur et YAML, veuillez vous référer à notre [documentation](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html).\n\n#### Avantages et inconvénients des politiques d'exécution des scans\n\n##### Facilité d'utilisation\n\nLes SEP sont un mécanisme léger et facile à utiliser qui applique la sécurité sur les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") existants et nouveaux dans l'organisation ou à un niveau granulaire. Le support de l'interface utilisateur en fait un outil viable pour tous les personas pertinents.\n\n##### Personnalisation\n\nLes SEP sont limitées aux jobs de scanner prédéfinis, et il n'est pas possible d'étendre cette liste avec des jobs personnalisés à ce stade. Cette limitation peut être restrictive pour les équipes avec des exigences de scan uniques.\n\n##### Application\n\nUne fois qu'une SEP est appliquée à un projet (directement ou indirectement), Sasha n'a aucun moyen de se débarrasser de ce job de scan. Cependant, il peut y avoir des moyens (intentionnels ou non) de manipuler le comportement du job de scan.\n\nLes jobs injectés via les SEP sont généralement réceptifs aux variables CI/CD et respectent les règles générales de [précédence des variables](https://docs.gitlab.com/ee/ci/variables/index.html#cicd-variable-precedence). Pour cette injection, les politiques intègrent une logique qui refuse les modifications de certaines variables prédéfinies comme décrit [ici](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html#cicd-variables) et refuse généralement la configuration de variables qui suivent certains templates tels que `_DISABLED` ou `_EXCLUDED_PATHS`.\n\nMalgré ces mesures de sécurité, une utilisation inconsidérée des politiques peut entraîner des falsifications: dans notre test, nous avons pu définir une variable CI/CD au niveau du projet `SECURE_ANALYZERS_PREFIX` sur une mauvaise valeur (un emplacement inexistant). Comme vous pouvez le voir [ici](https://gitlab.com/gitlab-org/gitlab/-/blob/a2d4b8df0095c1363a105a1fa212daf227eca063/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml), le template de détection des secrets l'utilise pour construire l'emplacement de l'image du scanner.\n\nBien que le job de scan soit inclus dans l'exécution du pipeline, il échoue très tôt et, par conséquent, ne fournit aucun résultat. En raison de la [configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/a2d4b8df0095c1363a105a1fa212daf227eca063/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml#L18) `allow_failure: true`, le pipeline continuera à s'exécuter et finira par exécuter un job de déploiement.\n\nÉtant donné que les variables SEP ont la plus haute précédence parmi les variables, il existe une solution facile pour réduire la surface d'attaque de la politique : codez simplement en dur la valeur correcte dans votre fichier YAML de politique ou via l'interface utilisateur :\n```yaml\n- name: Secret Scanner\n  actions:\n  - scan: secret_detection\n    variables:\n      SECURE_ANALYZERS_PREFIX: registry.gitlab.com/security-products\n\n```\n### Politiques d'exécution des pipelines\n\nLes SEP permettent l'injection d'un ensemble de jobs liés à la sécurité dans n'importe quel pipeline de projet. En revanche, les PEP appliquent des configurations de pipeline entières aux projets et offrent beaucoup plus de flexibilité en ce qui concerne la personnalisation des contraintes de sécurité.\n\nIl existe deux méthodes pour implémenter ces politiques, appelées « actions » : `inject` et `override`. Ces actions fonctionnent de manière similaire aux templates que nous avons vus dans la section des frameworks de conformité et fournissent des moyens flexibles d'améliorer et d'appliquer les normes de sécurité au sein du workflow de développement.\n\n#### Injection de pipelines\n\nL'injection de pipelines implique l'ajout des jobs et autres éléments définis dans le pipeline de politique dans le pipeline de projet. Actuellement, les jobs ne doivent être injectés que dans des étapes réservées, à savoir `.pipeline-policy-pre` et `.pipeline-policy-post` pour éviter des résultats imprévisibles.\n\nGitLab gère en toute efficacité les conflits de nommage entre les jobs ou les variables dans les pipelines de politique et de projet en construisant chaque pipeline de manière isolée avant de les combiner. Cette approche garantit la transparence du processus d'intégration et n'impacte pas les workflows ou les configurations existants.\n\n![Scan de sécurité – image4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097983865.png)\n\nLa capture d'écran ci-dessus montre un exemple de pipeline de politique injecté. Les jobs du pipeline de projet contiennent le préfixe `prj-` pour faciliter l'identification.\n\n#### Pipelines de remplacement\n\nDans cette approche, le pipeline de projet est entièrement remplacé par le pipeline de politique. Cette méthode est similaire aux pipelines de conformité qui n'incluent pas le fichier `.gitlab-ci.yml` du projet. Malgré le remplacement, les pipelines s'exécutent en utilisant les variables CI/CD du projet et maintiennent la cohérence avec les configurations spécifiques au projet. Le pipeline de conformité que nous avons utilisé précédemment peut également servir de pipeline de politique :\n```yaml\nstages: [\"build\", \"test\", \"deploy\"]\n\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n\nbuild-job:\n  stage: build\n  script: echo \"Building the container image\"\n\ntest-job:\n  stage: test\n  script: echo \"Running unit tests\"\n\ndeploy-job:\n  stage: deploy\n  script: echo \"Deploying app\"\n\n```\nL'image ci-dessous montre un pipeline légèrement plus complet que le pipeline fictif ci-dessus :\n\n![Pipeline plus complet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097983866.png)\n\n**Remarque :** cette approche ne fonctionne actuellement pas avec les SEP.\n\nCependant, l'existence d'un Dockerfile n'est pas toujours un indicateur valide, car les équipes peuvent développer sans Dockerfile en utilisant Cloud Native Buildpacks, Heroku Buildpacks, Kaniko ou d'autres outils. Les pipelines gérés ne rencontrent pas ce défi, car ils sont plus contrôlés et centralisés.\n\n### Projets avec plusieurs images de conteneurs\n\nPour les projets qui produisent plusieurs images de conteneurs, plusieurs jobs de scan de conteneurs seraient nécessaires pour une couverture adéquate. Cette approche soulève les mêmes questions qu'auparavant : « Comment savons-nous qu'il y en a plusieurs ? » et « La source de cette information est-elle digne de confiance ? ». Si nous voulions nous appuyer sur l'existence de `Dockerfile`, une [approche dynamique](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html#dynamic-child-pipelines) avec un job de scan de conteneurs pour chaque `Dockerfile` détecté serait nécessaire.\n\n## Utilisez les scans de sécurité\n\nDans cet article, vous avez découvert diverses approches pour ajouter des scans de sécurité aux pipelines CI/CD et exploré leur facilité d'utilisation, leur personnalisation et leur application. Vous avez appris qu'un auteur de pipeline chargé de la conformité du projet doit garder quelques éléments à l'esprit pendant le processus pour éviter des surprises par la suite. Nous vous recommandons de créer un petit espace de test sur votre instance GitLab, puis d'exécuter quelques tests pour reproduire les principaux points de cet article.\n\nGitLab fournit une assistance en fonction des besoins. Toutes les approches sont faciles à implémenter grâce à la fonctionnalité intégrée de la plateforme. Il existe plusieurs façons de sécuriser vos jobs de scan, et si vous avez des questions, n'hésitez pas à ouvrir un ticket auprès de notre assistance.\n\n**Testez les scans de sécurité dès aujourd'hui !**\n> **[→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr)**","2025-01-02","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097969/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750097968823.jpg","Scans de sécurité : comment choisir la bonne approche","Découvrez les principes de base, les configurations, ainsi que les avantages et les inconvénients des scans de sécurité.",[25,26],"Matt Genelin","Mathias Ewald","yml",{},true,"/fr-fr/blog/how-to-choose-the-right-security-scanning-approach",{"config":32,"ogImage":21,"title":22,"description":33},{"noIndex":12},"GitLab propose plusieurs méthodes de scan pour les pipelines CI/CD. Découvrez les bases, configurations et avantages/inconvénients de chaque approche.","fr-fr/blog/how-to-choose-the-right-security-scanning-approach",[10,17,36],"cicd","oqJK6prVhjGP9ByaGW9-PkASINUq_1dt470gzba7-D0",{"data":39},{"logo":40,"freeTrial":45,"sales":50,"login":55,"items":60,"search":369,"minimal":404,"duo":423,"pricingDeployment":432},{"config":41},{"href":42,"dataGaName":43,"dataGaLocation":44},"/fr-fr/","gitlab logo","header",{"text":46,"config":47},"Commencer un essai gratuit",{"href":48,"dataGaName":49,"dataGaLocation":44},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":51,"config":52},"Contacter l'équipe commerciale",{"href":53,"dataGaName":54,"dataGaLocation":44},"/fr-fr/sales/","sales",{"text":56,"config":57},"Connexion",{"href":58,"dataGaName":59,"dataGaLocation":44},"https://gitlab.com/users/sign_in/","sign in",[61,88,184,189,290,350],{"text":62,"config":63,"cards":65},"Plateforme",{"dataNavLevelOne":64},"platform",[66,72,80],{"title":62,"description":67,"link":68},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":69,"config":70},"Découvrir notre plateforme",{"href":71,"dataGaName":64,"dataGaLocation":44},"/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":44},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":81,"description":82,"link":83},"Choisir GitLab","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":84,"config":85},"En savoir plus",{"href":86,"dataGaName":87,"dataGaLocation":44},"/fr-fr/why-gitlab/","why gitlab",{"text":89,"left":29,"config":90,"link":92,"lists":96,"footer":166},"Produit",{"dataNavLevelOne":91},"solutions",{"text":93,"config":94},"Voir toutes les solutions",{"href":95,"dataGaName":91,"dataGaLocation":44},"/fr-fr/solutions/",[97,121,144],{"title":98,"description":99,"link":100,"items":105},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":101},{"icon":102,"href":103,"dataGaName":104,"dataGaLocation":44},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[106,109,112,117],{"text":18,"config":107},{"href":108,"dataGaLocation":44,"dataGaName":18},"/fr-fr/solutions/continuous-integration/",{"text":73,"config":110},{"href":78,"dataGaLocation":44,"dataGaName":111},"gitlab duo agent platform - product menu",{"text":113,"config":114},"Gestion du code source",{"href":115,"dataGaLocation":44,"dataGaName":116},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":118,"config":119},"Livraison de logiciels automatisée",{"href":103,"dataGaLocation":44,"dataGaName":120},"Automated software delivery",{"title":122,"description":123,"link":124,"items":129},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":125},{"href":126,"dataGaName":127,"dataGaLocation":44,"icon":128},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[130,134,139],{"text":131,"config":132},"Tests de sécurité des applications",{"href":126,"dataGaName":133,"dataGaLocation":44},"Application security testing",{"text":135,"config":136},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":137,"dataGaLocation":44,"dataGaName":138},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":140,"config":141},"Conformité logicielle",{"href":142,"dataGaName":143,"dataGaLocation":44},"/fr-fr/solutions/software-compliance/","Software Compliance",{"title":145,"link":146,"items":151},"Mesures",{"config":147},{"icon":148,"href":149,"dataGaName":150,"dataGaLocation":44},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[152,156,161],{"text":153,"config":154},"Visibilité et mesures",{"href":149,"dataGaLocation":44,"dataGaName":155},"Visibility and Measurement",{"text":157,"config":158},"Gestion de la chaîne de valeur",{"href":159,"dataGaLocation":44,"dataGaName":160},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":162,"config":163},"Données d'analyse et informations clés",{"href":164,"dataGaLocation":44,"dataGaName":165},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":167,"items":168},"GitLab pour",[169,174,179],{"text":170,"config":171},"Entreprises",{"href":172,"dataGaLocation":44,"dataGaName":173},"/fr-fr/enterprise/","enterprise",{"text":175,"config":176},"PME",{"href":177,"dataGaLocation":44,"dataGaName":178},"/fr-fr/small-business/","small business",{"text":180,"config":181},"Secteur public",{"href":182,"dataGaLocation":44,"dataGaName":183},"/fr-fr/solutions/public-sector/","public sector",{"text":185,"config":186},"Tarifs",{"href":187,"dataGaName":188,"dataGaLocation":44,"dataNavLevelOne":188},"/fr-fr/pricing/","pricing",{"text":190,"config":191,"link":193,"lists":197,"feature":277},"Ressources",{"dataNavLevelOne":192},"resources",{"text":194,"config":195},"Afficher toutes les ressources",{"href":196,"dataGaName":192,"dataGaLocation":44},"/fr-fr/resources/",[198,231,249],{"title":199,"items":200},"Premiers pas",[201,206,211,216,221,226],{"text":202,"config":203},"Installation",{"href":204,"dataGaName":205,"dataGaLocation":44},"/fr-fr/install/","install",{"text":207,"config":208},"Guides de démarrage",{"href":209,"dataGaName":210,"dataGaLocation":44},"/fr-fr/get-started/","quick setup checklists",{"text":212,"config":213},"Apprentissage",{"href":214,"dataGaLocation":44,"dataGaName":215},"https://university.gitlab.com/","learn",{"text":217,"config":218},"Documentation sur le produit",{"href":219,"dataGaName":220,"dataGaLocation":44},"https://docs.gitlab.com/","product documentation",{"text":222,"config":223},"Vidéos sur les bonnes pratiques",{"href":224,"dataGaName":225,"dataGaLocation":44},"/fr-fr/getting-started-videos/","best practice videos",{"text":227,"config":228},"Intégrations",{"href":229,"dataGaName":230,"dataGaLocation":44},"/fr-fr/integrations/","integrations",{"title":232,"items":233},"Découvrir",[234,239,244],{"text":235,"config":236},"Témoignages clients",{"href":237,"dataGaName":238,"dataGaLocation":44},"/fr-fr/customers/","customer success stories",{"text":240,"config":241},"Blog",{"href":242,"dataGaName":243,"dataGaLocation":44},"/fr-fr/blog/","blog",{"text":245,"config":246},"Travail à distance",{"href":247,"dataGaName":248,"dataGaLocation":44},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":250,"items":251},"Connecter",[252,257,262,267,272],{"text":253,"config":254},"Services GitLab",{"href":255,"dataGaName":256,"dataGaLocation":44},"/fr-fr/services/","services",{"text":258,"config":259},"Communauté",{"href":260,"dataGaName":261,"dataGaLocation":44},"/community/","community",{"text":263,"config":264},"Forum",{"href":265,"dataGaName":266,"dataGaLocation":44},"https://forum.gitlab.com/","forum",{"text":268,"config":269},"Événements",{"href":270,"dataGaName":271,"dataGaLocation":44},"/events/","events",{"text":273,"config":274},"Partenaires",{"href":275,"dataGaName":276,"dataGaLocation":44},"/fr-fr/partners/","partners",{"backgroundColor":278,"textColor":279,"text":280,"image":281,"link":285},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":282,"config":283},"carte promo The Source",{"src":284},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":286,"config":287},"Lire les articles les plus récents",{"href":288,"dataGaName":289,"dataGaLocation":44},"/fr-fr/the-source/","the source",{"text":291,"config":292,"lists":294},"Société",{"dataNavLevelOne":293},"company",[295],{"items":296},[297,302,308,310,315,320,325,330,335,340,345],{"text":298,"config":299},"À propos",{"href":300,"dataGaName":301,"dataGaLocation":44},"/fr-fr/company/","about",{"text":303,"config":304,"footerGa":307},"Carrières",{"href":305,"dataGaName":306,"dataGaLocation":44},"/jobs/","jobs",{"dataGaName":306},{"text":268,"config":309},{"href":270,"dataGaName":271,"dataGaLocation":44},{"text":311,"config":312},"Leadership",{"href":313,"dataGaName":314,"dataGaLocation":44},"/company/team/e-group/","leadership",{"text":316,"config":317},"Équipe",{"href":318,"dataGaName":319,"dataGaLocation":44},"/company/team/","team",{"text":321,"config":322},"Manuel",{"href":323,"dataGaName":324,"dataGaLocation":44},"https://handbook.gitlab.com/","handbook",{"text":326,"config":327},"Relations avec les investisseurs",{"href":328,"dataGaName":329,"dataGaLocation":44},"https://ir.gitlab.com/","investor relations",{"text":331,"config":332},"Centre de confiance",{"href":333,"dataGaName":334,"dataGaLocation":44},"/fr-fr/security/","trust center",{"text":336,"config":337},"Centre pour la transparence de l'IA",{"href":338,"dataGaName":339,"dataGaLocation":44},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":341,"config":342},"Newsletter",{"href":343,"dataGaName":344,"dataGaLocation":44},"/company/contact/#contact-forms","newsletter",{"text":346,"config":347},"Presse",{"href":348,"dataGaName":349,"dataGaLocation":44},"/press/","press",{"text":351,"config":352,"lists":353},"Nous contacter",{"dataNavLevelOne":293},[354],{"items":355},[356,359,364],{"text":51,"config":357},{"href":53,"dataGaName":358,"dataGaLocation":44},"talk to sales",{"text":360,"config":361},"Portail d’assistance",{"href":362,"dataGaName":363,"dataGaLocation":44},"https://support.gitlab.com","support portal",{"text":365,"config":366},"Portail clients GitLab",{"href":367,"dataGaName":368,"dataGaLocation":44},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":370,"login":371,"suggestions":378},"Fermer",{"text":372,"link":373},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":374,"config":375},"gitlab.com",{"href":58,"dataGaName":376,"dataGaLocation":377},"search login","search",{"text":379,"default":380},"Suggestions",[381,383,388,390,395,400],{"text":73,"config":382},{"href":78,"dataGaName":73,"dataGaLocation":377},{"text":384,"config":385},"Suggestions de code (IA)",{"href":386,"dataGaName":387,"dataGaLocation":377},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":18,"config":389},{"href":108,"dataGaName":18,"dataGaLocation":377},{"text":391,"config":392},"GitLab sur AWS",{"href":393,"dataGaName":394,"dataGaLocation":377},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":396,"config":397},"GitLab sur Google Cloud ",{"href":398,"dataGaName":399,"dataGaLocation":377},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":401,"config":402},"Pourquoi utiliser GitLab ?",{"href":86,"dataGaName":403,"dataGaLocation":377},"Why GitLab?",{"freeTrial":405,"mobileIcon":410,"desktopIcon":415,"secondaryButton":418},{"text":406,"config":407},"Commencer votre essai gratuit",{"href":408,"dataGaName":49,"dataGaLocation":409},"https://gitlab.com/-/trials/new/","nav",{"altText":411,"config":412},"Icône GitLab",{"src":413,"dataGaName":414,"dataGaLocation":409},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":411,"config":416},{"src":417,"dataGaName":414,"dataGaLocation":409},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":419,"config":420},"Commencer",{"href":421,"dataGaName":422,"dataGaLocation":409},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/get-started/","get started",{"freeTrial":424,"mobileIcon":428,"desktopIcon":430},{"text":425,"config":426},"En savoir plus sur GitLab Duo",{"href":78,"dataGaName":427,"dataGaLocation":409},"gitlab duo",{"altText":411,"config":429},{"src":413,"dataGaName":414,"dataGaLocation":409},{"altText":411,"config":431},{"src":417,"dataGaName":414,"dataGaLocation":409},{"freeTrial":433,"mobileIcon":438,"desktopIcon":440},{"text":434,"config":435},"Retour aux tarifs",{"href":187,"dataGaName":436,"dataGaLocation":409,"icon":437},"back to pricing","GoBack",{"altText":411,"config":439},{"src":413,"dataGaName":414,"dataGaLocation":409},{"altText":411,"config":441},{"src":417,"dataGaName":414,"dataGaLocation":409},{"title":443,"button":444,"config":449},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":445,"config":446},"Regarder GitLab Transcend maintenant",{"href":447,"dataGaName":448,"dataGaLocation":44},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":450,"icon":451,"disabled":29},"release","AiStar",{"data":453},{"text":454,"source":455,"edit":461,"contribute":466,"config":471,"items":476,"minimal":653},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":456,"config":457},"Afficher le code source de la page",{"href":458,"dataGaName":459,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":462,"config":463},"Modifier cette page",{"href":464,"dataGaName":465,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":467,"config":468},"Veuillez contribuer",{"href":469,"dataGaName":470,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":472,"facebook":473,"youtube":474,"linkedin":475},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[477,500,554,586,621],{"title":62,"links":478,"subMenu":483},[479],{"text":480,"config":481},"Plateforme DevSecOps",{"href":71,"dataGaName":482,"dataGaLocation":460},"devsecops platform",[484],{"title":185,"links":485},[486,490,495],{"text":487,"config":488},"Voir les forfaits",{"href":187,"dataGaName":489,"dataGaLocation":460},"view plans",{"text":491,"config":492},"Pourquoi choisir GitLab Premium ?",{"href":493,"dataGaName":494,"dataGaLocation":460},"/fr-fr/pricing/premium/","why premium",{"text":496,"config":497},"Pourquoi choisir GitLab Ultimate ?",{"href":498,"dataGaName":499,"dataGaLocation":460},"/fr-fr/pricing/ultimate/","why ultimate",{"title":501,"links":502},"Solutions",[503,508,511,513,518,523,527,530,533,538,540,542,544,549],{"text":504,"config":505},"Transformation digitale",{"href":506,"dataGaName":507,"dataGaLocation":460},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":509,"config":510},"Sécurité et conformité",{"href":126,"dataGaName":133,"dataGaLocation":460},{"text":118,"config":512},{"href":103,"dataGaName":104,"dataGaLocation":460},{"text":514,"config":515},"Développement agile",{"href":516,"dataGaName":517,"dataGaLocation":460},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":519,"config":520},"Transformation cloud",{"href":521,"dataGaName":522,"dataGaLocation":460},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":524,"config":525},"SCM",{"href":115,"dataGaName":526,"dataGaLocation":460},"source code management",{"text":18,"config":528},{"href":108,"dataGaName":529,"dataGaLocation":460},"continuous integration & delivery",{"text":157,"config":531},{"href":159,"dataGaName":532,"dataGaLocation":460},"value stream management",{"text":534,"config":535},"GitOps",{"href":536,"dataGaName":537,"dataGaLocation":460},"/fr-fr/solutions/gitops/","gitops",{"text":170,"config":539},{"href":172,"dataGaName":173,"dataGaLocation":460},{"text":175,"config":541},{"href":177,"dataGaName":178,"dataGaLocation":460},{"text":180,"config":543},{"href":182,"dataGaName":183,"dataGaLocation":460},{"text":545,"config":546},"Formation",{"href":547,"dataGaName":548,"dataGaLocation":460},"/fr-fr/solutions/education/","education",{"text":550,"config":551},"Services financiers",{"href":552,"dataGaName":553,"dataGaLocation":460},"/fr-fr/solutions/finance/","financial services",{"title":190,"links":555},[556,558,561,563,566,568,571,574,576,578,580,582,584],{"text":202,"config":557},{"href":204,"dataGaName":205,"dataGaLocation":460},{"text":559,"config":560},"Guides de démarrage rapide",{"href":209,"dataGaName":210,"dataGaLocation":460},{"text":212,"config":562},{"href":214,"dataGaName":215,"dataGaLocation":460},{"text":217,"config":564},{"href":219,"dataGaName":565,"dataGaLocation":460},"docs",{"text":240,"config":567},{"href":242,"dataGaName":243},{"text":569,"config":570},"Histoires de réussite client",{"href":237,"dataGaLocation":460},{"text":572,"config":573},"Histoires de succès client",{"href":237,"dataGaName":238,"dataGaLocation":460},{"text":245,"config":575},{"href":247,"dataGaName":248,"dataGaLocation":460},{"text":253,"config":577},{"href":255,"dataGaName":256,"dataGaLocation":460},{"text":258,"config":579},{"href":260,"dataGaName":261,"dataGaLocation":460},{"text":263,"config":581},{"href":265,"dataGaName":266,"dataGaLocation":460},{"text":268,"config":583},{"href":270,"dataGaName":271,"dataGaLocation":460},{"text":273,"config":585},{"href":275,"dataGaName":276,"dataGaLocation":460},{"title":291,"links":587},[588,590,593,595,597,599,601,605,610,612,614,616],{"text":298,"config":589},{"href":300,"dataGaName":293,"dataGaLocation":460},{"text":591,"config":592},"Emplois",{"href":305,"dataGaName":306,"dataGaLocation":460},{"text":311,"config":594},{"href":313,"dataGaName":314,"dataGaLocation":460},{"text":316,"config":596},{"href":318,"dataGaName":319,"dataGaLocation":460},{"text":321,"config":598},{"href":323,"dataGaName":324,"dataGaLocation":460},{"text":326,"config":600},{"href":328,"dataGaName":329,"dataGaLocation":460},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":460},"/sustainability/",{"text":606,"config":607},"Diversité, inclusion et appartenance (DIB)",{"href":608,"dataGaName":609,"dataGaLocation":460},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":331,"config":611},{"href":333,"dataGaName":334,"dataGaLocation":460},{"text":341,"config":613},{"href":343,"dataGaName":344,"dataGaLocation":460},{"text":346,"config":615},{"href":348,"dataGaName":349,"dataGaLocation":460},{"text":617,"config":618},"Déclaration de transparence sur l'esclavage moderne",{"href":619,"dataGaName":620,"dataGaLocation":460},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":351,"links":622},[623,626,631,633,638,643,648],{"text":624,"config":625},"Échanger avec un expert",{"href":53,"dataGaName":54,"dataGaLocation":460},{"text":627,"config":628},"Aide",{"href":629,"dataGaName":630,"dataGaLocation":460},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":365,"config":632},{"href":367,"dataGaName":368,"dataGaLocation":460},{"text":634,"config":635},"Statut",{"href":636,"dataGaName":637,"dataGaLocation":460},"https://status.gitlab.com/","status",{"text":639,"config":640},"Conditions d'utilisation",{"href":641,"dataGaName":642},"/terms/","terms of use",{"text":644,"config":645},"Déclaration de confidentialité",{"href":646,"dataGaName":647,"dataGaLocation":460},"/fr-fr/privacy/","privacy statement",{"text":649,"config":650},"Préférences en matière de cookies",{"dataGaName":651,"dataGaLocation":460,"id":652,"isOneTrustButton":29},"cookie preferences","ot-sdk-btn",{"items":654},[655,657,660],{"text":639,"config":656},{"href":641,"dataGaName":642,"dataGaLocation":460},{"text":658,"config":659},"Politique de confidentialité",{"href":646,"dataGaName":647,"dataGaLocation":460},{"text":649,"config":661},{"dataGaName":651,"dataGaLocation":460,"id":652,"isOneTrustButton":29},[663,676],{"id":664,"title":25,"body":9,"config":665,"content":667,"description":9,"extension":27,"meta":671,"navigation":29,"path":672,"seo":673,"stem":674,"__hash__":675},"blogAuthors/en-us/blog/authors/matt-genelin.yml",{"template":666},"BlogAuthor",{"name":25,"config":668},{"headshot":669,"ctfId":670},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664522/Blog/Author%20Headshots/matty_genelin.png","6x9dTYZik3lSViI8hu6dYQ",{},"/en-us/blog/authors/matt-genelin",{},"en-us/blog/authors/matt-genelin","BNd-jZWck4DOyJIDc9GI-734vQkyzXJgudpPaFgn5pM",{"id":677,"title":26,"body":9,"config":678,"content":679,"description":9,"extension":27,"meta":683,"navigation":29,"path":684,"seo":685,"stem":686,"__hash__":687},"blogAuthors/en-us/blog/authors/mathias-ewald.yml",{"template":666},{"name":26,"config":680},{"headshot":681,"ctfId":682},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664526/Blog/Author%20Headshots/mathias_ewald_headshot.png","7vLTPhU3yvh4xTToXcLpg9",{},"/en-us/blog/authors/mathias-ewald",{},"en-us/blog/authors/mathias-ewald","6h3mh_Isl2z7n-akRG5H9ijs9YS5wqTMLWKfyPjjDyQ",[689,703,717],{"content":690,"config":701},{"tags":691,"category":10,"title":694,"description":695,"authors":696,"heroImage":698,"date":699,"body":700},[692,693,17,10],"AI/ML","product","Classez les vulnérabilités avec l’agent Security Analyst","Découvrez comment GitLab Duo Agent Platform utilise l'IA pour prioriser les vulnérabilités, réduire la fatigue liée aux alertes et aider les équipes à se concentrer sur les risques de sécurité critiques.",[697],"Fernando Diaz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756122536/akivvcnafog9c4dhhzkp.png","2026-03-09","Les applications modernes présentent constamment des failles de sécurité. Les équipes de développement sont souvent confrontées à des centaines, voire des milliers de résultats provenant des scanners de sécurité, ce qui complique l'identification des vulnérabilités qui représentent les risques les plus importants et doivent être traitées en priorité. C'est là qu'un classement efficace des vulnérabilités devient essentiel.\n\nDécouvrez dans cet article comment les [fonctionnalités intégrées de scan de sécurité de GitLab](https://docs.gitlab.com/user/application_security/) combinées avec [l'agent GitLab Duo Security Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/) peuvent transformer 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 ?\") d'un processus manuel chronophage en un workflow intelligent et efficace.\n\n## Qu'est-ce que le classement des vulnérabilités ?\n\nLe classement des vulnérabilités est le processus d'analyse, de priorisation et de traitement des problèmes de sécurité détectés dans vos applications. Toutes les vulnérabilités ne se valent pas : certaines représentent des risques critiques et nécessitent une attention immédiate, tandis que d'autres peuvent être des faux positifs ou constituent une menace minime dans votre contexte spécifique.\n\nLe classement traditionnel comprend les éléments suivants :\n\n- **L'examen des résultats d'analyse** provenant de plusieurs outils de sécurité\n- **L'évaluation de la gravité** en fonction des scores CVSS et l'exploitabilité\n- **La compréhension du contexte**, par exemple si le code vulnérable est réellement accessible\n- **La priorisation de la remédiation** en fonction de l'impact métier et du risque\n- **Le suivi de la résolution** jusqu'au déploiement\n\nCe processus devient extrêmement fastidieux lorsqu’il s’agit de codes sources volumineux et de scans fréquents. C'est là que GitLab entre en jeu : la plateforme relève ces défis grâce à des scans de sécurité intégrés et une analyse alimentée par l'IA.\n\n## Comment ajouter des scanners de sécurité intégrés dans GitLab ?\n\n\nGitLab fournit des scanners de sécurité qui s'intègrent de manière transparente dans vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"). Ces scanners s'exécutent automatiquement pendant l'exécution du pipeline et alimentent le [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/) de GitLab avec les résultats de la branche par défaut.\n\n### Quels sont les scanners de sécurité disponibles ?\n\nGitLab propose les scanners suivants :\n\n- **[Tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/user/application_security/sast/)** : analysent le code source à la recherche de vulnérabilités\n - **[Analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/)** : identifie les vulnérabilités dans les dépendances du projet\n- **[Analyse des conteneurs](https://docs.gitlab.com/user/application_security/container_scanning/)** : analyse les images [Docker](https://about.gitlab.com/fr-fr/blog/what-is-docker-comprehensive-guide/ \"Qu'est-ce que Docker ?\") à la recherche de vulnérabilités connues\n- **[Tests dynamiques de sécurité des applications (DAST)](https://docs.gitlab.com/user/application_security/dast/browser/)** : testent les applications en cours d'exécution à la recherche de vulnérabilités\n- **[Détection des secrets](https://docs.gitlab.com/user/application_security/secret_detection/)** : détecte les secrets et identifiants validés accidentellement\n- **[Analyse de l'Infrastructure as Code (IaC)](https://docs.gitlab.com/user/application_security/iac_scanning/)** : analyse l'[Infrastructure as Code](https://about.gitlab.com/fr-fr/topics/gitops/infrastructure-as-code/ \"Qu'est-ce que l'Infrastructure as Code ?\") à la recherche de mauvaises configurations\n- **[Tests de sécurité des API](https://docs.gitlab.com/user/application_security/api_security_testing/)** : testent les API Web pour détecter les bogues et les problèmes de sécurité potentiels\n- **[Test de l’API web par injection de données aléatoires](https://docs.gitlab.com/user/application_security/api_fuzzing/)** : transmet des valeurs inattendues aux paramètres de fonctionnement des API pour provoquer des comportements et erreurs inattendus dans le backend\n\n### Exemple : ajouter des scanners SAST et l'analyse des dépendances\n\nPour activer le scan de sécurité, ajoutez les scanners à votre fichier `.gitlab-ci.yml`.\n\nDans cet exemple, nous incluons les templates SAST et analyse des dépendances qui exécutent automatiquement ces scanners lors de la phase de test. Chaque scanner peut être remplacé à l'aide de variables (qui diffèrent pour chaque scanner). Par exemple, la variable `SAST_EXCLUDED_PATHS` indique aux SAST d'ignorer les répertoires/fichiers fournis. Les jobs de sécurité peuvent être remplacés à l'aide de la [syntaxe des jobs GitLab](https://docs.gitlab.com/ci/yaml/).\n\n```yaml\ninclude:\n  - template: Security/SAST.gitlab-ci.yml\n  - template: Security/Dependency-Scanning.gitlab-ci.yml\n\nstages:\n  - test\n\nvariables:\n  SAST_EXCLUDED_PATHS: \"spec/, test/, tests/, tmp/\"\n\n```\n\n### Exemple : ajouter l'analyse des conteneurs\n\nGitLab fournit un [registre de conteneurs](https://docs.gitlab.com/user/packages/container_registry/) intégré dans lequel vous pouvez stocker des images de conteneurs pour chaque projet GitLab. Pour analyser ces conteneurs à la recherche de vulnérabilités, activez l'analyse des conteneurs.\n\nDans cet exemple, un conteneur est compilé, puis un push est effectué dans le job `build-container` à l'étape `build`. Le conteneur est ensuite analysé dans le même pipeline à l'étape `test` :\n\n```yaml\ninclude:\n  - template: Security/Container-Scanning.gitlab-ci.yml\n\nstages:\n  - build\n  - test\n\nbuild-container:\n  stage: build\n  variables:\n    IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA\n  before_script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker build -t $IMAGE .\n    - docker push $IMAGE\n\ncontainer_scanning:\n  variables:\n    CS_IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA\n\n```\n\nUne fois configurés, ces scanners s'exécutent automatiquement dans votre pipeline et transmettent leurs résultats dans le [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/).\n\n**Remarque :** bien que cela ne soit pas abordé dans cet article, veuillez noter que dans les merge requests, les scanners affichent la diff entre les vulnérabilités d'une branche de fonctionnalité et celles de la branche cible. De plus, des [politiques de sécurité](https://docs.gitlab.com/user/application_security/policies/) granulaires peuvent être créées pour empêcher le merge du code vulnérable (sans approbation) si des vulnérabilités sont détectées, ainsi que pour forcer l'exécution des scanners, indépendamment de la façon dont le fichier `.gitlab-ci.yml` est défini.\n\n## Classement des résultats avec le rapport de vulnérabilités et GitLab Pages\n\nUne fois les scanners exécutés, GitLab regroupe tous les résultats dans des vues centralisées pour faciliter le classement.\n\n### Accès au rapport de vulnérabilités\n\nAccédez à **Sécurisation > Rapport de vulnérabilités** dans votre projet ou groupe. Cette page affiche toutes les vulnérabilités découvertes avec les informations clés suivantes :\n\n- Niveaux de gravité (critique, élevé, moyen, faible, info)\n- Statut (détecté, confirmé, rejeté, résolu)\n- Type de scanner ayant détecté la vulnérabilité\n- Fichiers et lignes de code concernés\n- Date de détection et informations sur le pipeline\n\n![Rapport de vulnérabilités](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072457/jsz5qcti9pse1myyzktd.png)\n\n### Filtrage et organisation des vulnérabilités\n\nLe rapport de vulnérabilités fournit de puissantes options de filtrage :\n\n- Filtrer par gravité, statut, scanner, identifiant et accessibilité\n- Regrouper par gravité, statut, scanner, Open Web Application Security Project Top 10 (OWASP)\n- Rechercher des vulnérabilités et expositions communes (CVE) ou des noms de vulnérabilités spécifiques\n- Trier par date de détection ou gravité\n- Afficher les tendances dans le temps avec le tableau de bord de sécurité\n\n### Classement manuel du workflow\n\nLe classement traditionnel dans GitLab implique :\n\n1. **L'examen de chaque vulnérabilité** en cliquant sur la page de détails\n2. **L'évaluation de la description** et la compréhension de l'impact potentiel\n3. **L'examen du code affecté** via des liens intégrés\n4. **La vérification des correctifs existants** ou des correctifs dans les dépendances\n5. **La définition du statut** (confirmer, rejeter avec motif ou créer un ticket)\n6. **L'attribution de la responsabilité** pour la correction\n\nVoici un exemple de données de vulnérabilité fournies pour permettre le classement, y compris le flux de code :\n\n![Page de vulnérabilités 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072471/imy4qfc89ajoc42auqs3.png)\n\n\n![Page de vulnérabilités 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072473/g7dfge2acunebf9oa99g.png)\n\n\n![Flux de code de vulnérabilités](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072468/wr2i9ry5rgzwhimmo793.png)\n\n\nSur la page des données relatives aux vulnérabilités, vous pouvez sélectionner **Éditer la vulnérabilité** pour modifier son statut et fournir un motif. Vous pouvez ensuite créer un ticket et l'attribuer pour la remédiation.\n\n\n![Page de vulnérabilités – changement de statut](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072466/t0m8ewo82wbgo12d3vip.png)\n\n\nBien que ce workflow soit complet, il nécessite une expertise en matière de sécurité et peut prendre beaucoup de temps lorsqu'il s'agit de traiter des centaines de résultats. C'est là que l'agent GitLab Duo Security Analyst, qui fait partie de [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/), devient indispensable.\n\n## Agent GitLab Duo Security Analyst : définition et configuration\n\nL'agent GitLab Duo Security Analyst est un outil alimenté par l'IA qui automatise l'analyse et le classement des vulnérabilités. L'agent comprend le contexte de votre application, évalue intelligemment les risques et fournit des recommandations exploitables.\n\n### Comment fonctionne l'agent GitLab Duo Security Analyst ?\n\nL'agent analyse les vulnérabilités en :\n\n- **Évaluant l'exploitabilité** dans le contexte spécifique de votre code source\n- **Évaluant l'accessibilité** pour déterminer si les chemins de code vulnérables sont réellement utilisés\n- **Priorisant en fonction du risque** plutôt que de simples scores CVSS\n- **Expliquant les vulnérabilités** dans un langage clair et exploitable\n- **Recommandant des mesures correctives** spécifiques à votre application\n- **Réduisant les faux positifs** grâce à une analyse contextuelle\n\n### Prérequis\n\nPour utiliser l'agent Security Analyst, vous avez besoin des éléments suivants :\n\n- Un abonnement [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"GitLab Ultimate\") avec GitLab Duo Agent Platform activé\n- Des scanners de sécurité configurés dans votre projet\n- Au moins une vulnérabilité dans votre rapport de vulnérabilités\n\n### Activation de l'agent Security Analyst\n\nL'agent Security Analyst est un [agent par défaut](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/). Contrairement à l'agent GitLab Duo, les agents par défaut comprennent les workflows, frameworks et bonnes pratiques propres à leurs domaines spécialisés. Les agents par défaut sont accessibles directement depuis votre projet sans configuration supplémentaire.\n\nVous pouvez trouver l'agent Security Analyst dans le [catalogue d'IA](https://docs.gitlab.com/user/duo_agent_platform/ai_catalog/) :\n\n![Catalogue d'IA de GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072458/nv1qwisln1hxbgzeva7a.png)\n\n\nPour approfondir et voir les détails de l'agent, tels que son invite système et ses outils :\n\n1. Accédez à **gitlab.com/explore/**.\n2. Sélectionnez **Catalogue d'IA** dans l'onglet latéral.\n3. Sélectionnez **Security Analyst Agent** dans la liste.\n\n\n![Détails de l'agent GitLab Duo Security Analyst 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072470/wjbwpgy6ipbblderxfdb.png)\n\n\n\n![Détails de l'agent GitLab Duo Security Analyst 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072469/dzhbqxt2cmwwvxeaqxfe.png)\n\n\n\nL'agent s’intègre directement à votre workflow existant et ne requiert aucune configuration supplémentaire au-delà des prérequis définis.\n\n## Identification des vulnérabilités critiques avec l'agent Security Analyst\n\nVoyons maintenant comment tirer parti de l'agent Security Analyst pour identifier et prioriser rapidement les vulnérabilités les plus importantes.\n\n### Analyse\n\nPour démarrer une analyse, accédez à votre projet GitLab (assurez-vous qu'il répond aux prérequis). Vous pouvez ensuite ouvrir GitLab Duo Chat et sélectionner **Security Analyst**.\n\n![Sélection de l'agent GitLab Duo Security Analyst](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072464/rrdk9aidkck2oeddtjm0.png)\n\n\n\nDans le chat, sélectionnez le modèle à utiliser avec l'agent et assurez-vous d'activer le mode agentique.\n\n![Agent GitLab Duo Security Analyst – sélection du modèle](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072458/hvccofv3nadkpkzfevx0.png)\n\n\n\nUn chat s'ouvrira où vous pourrez interagir avec l'agent GitLab Duo Security Analyst en utilisant l'interface conversationnelle de l'agent. Cet agent peut effectuer les actions suivantes :\n\n- **Classement des vulnérabilités** : analyser et prioriser les résultats de sécurité sur différents types de scan.\n- **Évaluation des risques** : évaluer la gravité, l'exploitabilité et l'impact métier des vulnérabilités.\n- **Identification des faux positifs** : distinguer les menaces réelles des résultats sans danger.\n- **Gestion de la conformité** : comprendre les exigences réglementaires et les délais de correction.\n- **Rapports de sécurité** : générer des résumés de la posture de sécurité et des progrès de remédiation.\n- **Planification des corrections** : créer des plans d'action pour traiter les vulnérabilités.\n- **Automatisation du workflow de sécurité** : rationaliser les tâches répétitives d'évaluation de la sécurité.\n\nDe plus, voici les outils dont dispose l'agent Security Analyst :\n\n![Agent GitLab Duo Security Analyst – outils](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072470/bgg2icxb0hp5g0zmerj3.png)\n\n\n\nPar exemple, il est possible de demander « **Quelles sont les vulnérabilités les plus critiques et lesquelles dois-je traiter en priorité ?** » pour déterminer facilement ce qui est important.\n\nL'agent répondra comme suit :\n\n![Agent GitLab Duo Security Analyst 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072476/hic8szspoobbmntxw5js.png)\n\n\n\n![Agent GitLab Duo Security Analyst 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072463/iytr116dfkno3akr2xgf.png)\n\n\n\n![Agent GitLab Duo Security Analyst 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072464/gzmggi6xu1bzobqdyxhg.png)\n\n\n\n![Agent GitLab Duo Security Analyst 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072457/gv7ncdauqw8eszaxdcpf.png)\n\n\n\n![Agent GitLab Duo Security Analyst 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072457/ifj4xp8kfv9ranfwav3h.png)\n\n\n\n![Agent GitLab Duo Security Analyst 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1766072457/arr8jfqn52zy1q72jqh5.png)\n\n### Exemples de requêtes pour un classement efficace\n\nVoici des requêtes efficaces à utiliser avec l'agent Security Analyst :\n\n**Identifier les problèmes critiques :**\n```text\n« Montre-moi les vulnérabilités qui sont activement exploitables dans notre code de production »\n```\n**Se concentrer sur les vulnérabilités accessibles :**\n```text\n« Quelles sont les vulnérabilités de gravité élevée qui se trouvent dans les chemins de code qui sont réellement exécutés ? »\n```\n**Comprendre les dépendances :**\n```text\n« Quelles sont les vulnérabilités de dépendances les plus critiques et des correctifs sont-ils disponibles ? »\n```\n**Obtenir des conseils de remédiation :**\n```text\n« Explique-moi comment corriger la vulnérabilité d'injection SQL dans l'authentification utilisateur »\n```\n\nVous pouvez également attribuer directement les vulnérabilités aux équipes de développement.\n\n### Les recommandations de l'agent\n\nLorsque l'agent Security Analyst analyse les vulnérabilités, il fournit les éléments suivants :\n\n**Évaluation des risques** : l'agent explique pourquoi une vulnérabilité est critique au-delà du simple score CVSS et tient compte de l'architecture et des modèles d'utilisation spécifiques de votre application.\n\n**Analyse d'exploitabilité** : il détermine si le code vulnérable est réellement accessible et exploitable dans votre environnement, ce qui aide à filtrer les risques théoriques.\n\n**Mesures correctives** : l'agent fournit des conseils spécifiques et concrets sur la façon de corriger les vulnérabilités, y compris des exemples de code le cas échéant.\n\n**Classement par ordre de priorité** : au lieu de vous submerger avec des centaines de résultats, l'agent vous aide à identifier les principaux problèmes qui doivent être traités en priorité.\n\n### Exemple concret de workflow\n\nVoici à quoi pourrait ressembler une session de classement type :\n\n1. **Commencer par une vue d'ensemble** : « Analyse la posture de sécurité de ce projet et met en évidence les 5 vulnérabilités les plus critiques. »\n\n2. **Entrer dans les détails** : pour chaque vulnérabilité critique identifiée, posez la question suivante : « Cette vulnérabilité est-elle réellement exploitable dans notre application ? »\n\n3. **Planifier la remédiation** : « Quel est le correctif recommandé pour ce problème d'injection SQL, et y a-t-il des conséquences à prendre en compte ? »\n\n4. **Suivre les progrès** : après avoir traité les problèmes critiques, posez la question suivante : « Quelles vulnérabilités dois-je prioriser ensuite ? »\n\n### Avantages du classement assisté par agent\n\nL'utilisation de l'agent Security Analyst transforme la gestion des vulnérabilités :\n\n- **Gain de temps** : réduisez les heures d'analyse manuelle à quelques minutes d'examen guidé\n- **Meilleure priorisation** : concentrez-vous sur les vulnérabilités qui présentent réellement un risque pour votre application\n- **Transfert de connaissances** : apprenez les bonnes pratiques de sécurité grâce aux explications de l'agent\n- **Normes cohérentes** : appliquez une logique de classement cohérente à tous les projets\n- **Réduction de la fatigue liée aux alertes** : filtrez efficacement le bruit et les faux positifs\n\n## Lancez-vous dès aujourd'hui\n\nLe classement des vulnérabilités ne doit pas forcément être un processus manuel et fastidieux. En combinant les scanners de sécurité intégrés de GitLab avec l'agent GitLab Duo Security Analyst, les équipes de développement peuvent rapidement identifier et prioriser les vulnérabilités qui comptent vraiment.\n\nLa capacité de l'agent à comprendre le contexte, à évaluer le risque réel et fournir des conseils pratiques transforme l'analyse de sécurité d'une simple case à cocher en matière de conformité en une tâche pratique et efficace de votre workflow de développement. Au lieu de vous plonger dans des centaines de rapports de vulnérabilités, vous pouvez concentrer votre énergie sur la résolution des problèmes qui menacent réellement la sécurité de votre application.\n\nCommencez par activer les scanners de sécurité dans vos pipelines GitLab, puis tirez parti de l'agent Security Analyst pour prendre des décisions intelligentes et éclairées concernant la correction des vulnérabilités.\n\n> **Prêt à vous lancer ?** Consultez la [documentation de GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/) et la [documentation sur l'analyse de sécurité](https://docs.gitlab.com/ee/user/application_security/) pour commencer à transformer votre workflow de gestion des vulnérabilités dès aujourd'hui.",{"featured":12,"template":13,"slug":702},"vulnerability-triage-made-simple-with-gitlab-security-analyst-agent",{"content":704,"config":715},{"title":705,"description":706,"authors":707,"heroImage":710,"date":711,"body":712,"category":10,"tags":713},"Mise à jour du tableau de bord de sécurité de GitLab : suivez la correction des vulnérabilités","Priorisez rapidement la correction de vos projets à risque et mesurez vos progrès à l'aide des informations relatives aux vulnérabilités.",[708,709],"Alisa Ho","Mike Clausen","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771438388/t6sts5qw4z8561gtlxiq.png","2026-02-23","Les équipes de sécurité et de développement font face à la même frustration : des milliers de vulnérabilités demandent leur attention, mais elles manquent d'informations pour les aider à hiérarchiser les mesures correctives. Où se concentrent les risques et à quelle vitesse sont-ils corrigés ? Où les mesures correctives auront-elles le plus d'impact ? La mise à jour apportée au tableau de bord de sécurité de GitLab aide à répondre à ces questions avec le suivi des tendances, la répartition des vulnérabilités en fonction de leur ancienneté et la notation des risques par projet.\n\n## Mesurer la correction, pas seulement la détection\nLes équipes chargées de la sécurité des applications ne peinent pas à trouver des vulnérabilités. En revanche, elles peinent à les comprendre. La plupart des tableaux de bord affichent des décomptes bruts sans contexte, ce qui les force à passer des heures à mettre en œuvre des mesures correctives sans comprendre quelles vulnérabilités les exposent aux risques les plus importants.\n\n[Le tableau de bord de sécurité de GitLab](https://docs.gitlab.com/user/application_security/security_dashboard/#new-security-dashboards) regroupe toutes les données relatives aux vulnérabilités en une vue unique qui couvre l'ensemble des projets, groupes et unités commerciales.\n\nDans la version 18.6, nous avons introduit la première mise à jour du tableau de bord de sécurité, où les équipes pouvaient visualiser les vulnérabilités au fil du temps et les filtrer en fonction du type de projet ou de rapport. Dans le cadre de la [version 18.9](https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/), les clients pourront profiter de nouveaux filtres et graphiques qui facilitent le découpage des données par gravité, statut, scanner ou projet et visualiser les tendances (vulnérabilités ouvertes, vitesse de correction, répartition des vulnérabilités en fonction de leur ancienneté et score de risque au fil du temps).\n\nLes scores de risque aident les équipes à prioriser la correction de leurs vulnérabilités les plus critiques. Le score de risque est calculé au moyen de facteurs tels que l'âge de la vulnérabilité, le système EPSS (Exploit Prediction Scoring System) et les scores KEV (Known Exploited Vulnerabilities) pour les dépôts associés et leurs postures de sécurité. Avec ces données, les équipes de sécurité des applications peuvent identifier les domaines à prioriser.\n\nLe tableau de bord de sécurité de GitLab aide les équipes chargées de la sécurité et du développement des applications à :\n* **Suivre l'efficacité des programmes** : surveiller la vitesse de correction, l'adoption des scanners et la posture de risque pour montrer une amélioration mesurable.\n* **Se concentrer sur les corrections ciblées** : corriger les vulnérabilités qui représentent le plus grand risque pour les systèmes de production.\n* **Identifier les domaines nécessitant une formation à la correction** : identifier les équipes qui ont des difficultés à corriger les vulnérabilités conformément à la politique de l'entreprise afin d'investir dans des formations supplémentaires.\n* **Réduire les rapports manuels** : éliminer le recours à des tableaux de bord et de feuilles de calcul externes en suivant tout depuis GitLab.\n\nCette mise à jour reflète l'engagement continu de GitLab en faveur de la sécurité mesurable, contextuelle et intégrée dans les workflows de développement quotidiens. Le tableau de bord de sécurité de GitLab transforme les résultats bruts en informations exploitables afin que les équipes de sécurité et de développement puissent fixer des priorités, réduire les risques plus rapidement et étayer leurs progrès.\n\n## Découvrez le tableau de bord de sécurité de GitLab en action\nImaginez un responsable en charge de la sécurité des applications qui se prépare pour une réunion avec sa direction. Il peut maintenant montrer si les investissements réalisés réduisent les risques à l'aide des points de tendance clairs : vulnérabilités ouvertes en baisse, ancienneté des vulnérabilités en baisse, types de failles CWE autrefois fréquentes en baisse, score de risque satisfaisant. Au lieu de présenter des informations bruts, il peut afficher la diminution du backlog et l'amélioration de la posture de risque d'un trimestre à l'autre.\n\nParallèlement, les équipes de développement peuvent accéder au même tableau de bord, où les vulnérabilités critiques sont mises en évidence dans leurs projets actifs, afin de concentrer leurs efforts de correction sans avoir à exporter de données ni à jongler entre plusieurs outils.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1166108924?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Security-Dashboard-Demo-Final\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> Pour plus d’informations sur l'utilisation du tableau de bord de sécurité de GitLab, consultez notre [documentation](https://docs.gitlab.com/user/application_security/security_dashboard/).",[10,693,714],"features",{"featured":12,"template":13,"slug":716},"track-vulnerability-remediation-with-the-updated-gitlab-security-dashboard",{"content":718,"config":729},{"tags":719,"category":10,"authors":722,"heroImage":724,"date":725,"body":726,"description":727,"title":728},[720,721,10,183],"DevSecOps","DevSecOps platform",[723],"Abubakar Siddiq Ango","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750098739/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098739024.jpg","2026-02-09","Des principes directeurs sous forme de normes ont toujours permis de garantir la livraison sécurisée et fiable de produits et services aux clients. Ces normes, généralement appliquées par des organismes légalement mandatés, réglementent les secteurs d'activité et empêchent la diffusion de produits de qualité inférieure.\n\nDans le secteur des technologies de l'information, le respect des normes va au-delà de la livraison du produit final ; il englobe l'ensemble du cycle de vie de la solution. Étant donné que tous les secteurs d'activité exploitent de plus en plus diverses formes de technologies afin d'accélérer les processus et d'améliorer l'efficacité, de vastes quantités de données souvent sensibles sont générées, stockées et transmises au moyen d'outils et de services informatiques. Le traitement inapproprié de ces données peut entraîner de graves conséquences et conduire à des pertes financières [de l'ordre de centaines de millions de dollars](https://tech.co/news/data-breaches-updated-list).\n\nCe guide complet présente des normes de conformité du monde entier et explique comment respecter les normes réglementaires avec la gestion des politiques de conformité et de sécurité de GitLab.\n## Normes de conformité informatiques courantes\n\nLes normes de conformité réglementaire prennent diverses formes et dépendent du secteur d'activité ou de la région dans laquelle une organisation opère. Nous examinerons d'abord les normes de conformité courantes, suivies des normes spécifiques à certaines régions et à certains secteurs.\n\n### RGPD\n\nLe [Règlement général sur la protection des données (RGPD)](https://gdpr-info.eu/) est une loi importante de l'Union européenne qui régit la protection des données personnelles. Mis en œuvre en 2018, le RGPD établit des directives strictes pour les organisations qui traitent les informations personnelles des résidents de l'UE. Il accorde aux individus un contrôle accru sur leurs données, notamment le droit d'accéder, de rectifier et d'effacer les informations personnelles détenues par les entreprises. Le RGPD exige que les organisations obtiennent un consentement explicite avant de collecter ou de traiter des données personnelles et qu'elles expliquent clairement l'objectif de la collecte de données. Le non-respect peut entraîner des sanctions financières importantes.\n\nBien qu'il s'agisse d'une réglementation de l'UE, le RGPD a des implications dans le monde entier et concerne toute organisation qui traite les données des résidents de l'UE. Cette législation a entraîné des changements généralisés dans les pratiques de traitement des données et a sensibilisé le monde entier aux questions de confidentialité.\n\n### NIST SSDF\n\nLe framework relatif au développement de logiciels sécurisés NIST, SSDF [(NIST Secure Software Development Framework, SSDF)](https://csrc.nist.gov/Projects/ssdf)  est un guide qui aide les organisations à créer des logiciels plus sûrs. Créé par le National Institute of Standards and Technology, ce framework propose [des pratiques de base pour le développement sécurisé de logiciels](https://about.gitlab.com/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab/).\n\nLe SSDF se concentre sur quatre domaines principaux : préparer l'organisation, protéger le logiciel, créer des logiciels sécurisés et gérer les vulnérabilités. Il aide les entreprises à intégrer la sécurité, y compris les protocoles de sécurité, pendant le développement et tout au long de la chaîne d'approvisionnement logicielle.\n\nEn suivant ces directives, les organisations peuvent créer des logiciels avec moins de points faibles et gérer les problèmes plus efficacement. Le SSDF est flexible et peut fonctionner avec différentes méthodes de développement logiciel, il est donc utile pour de nombreuses organisations.\n\n### PCI DSS\n\nLa norme de sécurité de l’industrie des cartes de paiement [(Payment Card Industry Data Security Standard, PCI DSS)](https://www.pcisecuritystandards.org/lang/fr-fr/) représente un ensemble de règles de sécurité pour les organisations qui traitent des informations de cartes de crédit. Créée par les principales sociétés de cartes de crédit, elle vise à protéger les données des titulaires de cartes et à prévenir la fraude. La norme PCI DSS exige que les entreprises mettent en place et maintiennent un réseau sécurisé, protègent les données des titulaires de cartes, utilisent des mesures strictes de contrôle d'accès, surveillent et testent régulièrement les réseaux et maintiennent une politique de sécurité de l'information. Ces règles s'appliquent à toute entreprise qui accepte, traite, stocke ou transmet des données de cartes de crédit.\n\nLa conformité à la norme PCI DSS est obligatoire pour ces entreprises, quelle que soit leur taille ou leur volume de transactions. En suivant cette norme, les entreprises peuvent mieux protéger les informations financières sensibles, réduire le risque de violations de données et maintenir la confiance des clients. Des audits réguliers garantissent le respect continu de ces mesures de sécurité importantes.\n\n### ISO 27000\n\nLa norme [ISO/IEC 27000](https://www.iso.org/fr/standard/iso-iec-27000-family) fournit le cadre fondamental de la famille de normes ISO/IEC 27000 et offre un aperçu complet des systèmes de gestion de la sécurité de l'information. Elle établit un vocabulaire normalisé grâce à des termes et concepts clés qui garantissent une compréhension cohérente entre les organisations dans le domaine de la sécurité de l'information.\n\nLa norme décrit les composants et processus essentiels qui établissent et maintiennent des systèmes de gestion de la sécurité de l'information efficaces. Ces directives permettent aux organisations de gérer systématiquement les risques liés à la sécurité de l'information et protègent les données confidentielles ainsi que la propriété intellectuelle.\n\nL'adhésion à la norme ISO/IEC 27000 permet aux organisations de construire des systèmes de gestion de la sécurité de l'information robustes, de renforcer leur résilience face aux menaces liées à la cybersécurité, de protéger des informations précieuses et de favoriser la confiance des parties prenantes.\n\n> [Découvrez comment GitLab peut vous aider dans votre parcours de conformité à la norme ISO 27001.](https://about.gitlab.com/fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey/)\n\n### HIPAA\n\nLa loi sur la portabilité et la responsabilité des assurances-maladie [(Health Insurance Portability and Accountability Act, HIPAA)](https://www.hhs.gov/hipaa/index.html) est une législation importante qui a un impact sur le secteur de la santé aux États-Unis. L'objectif principal de la loi HIPAA, adoptée en 1996, est de protéger les informations sensibles de santé des patients contre toute divulgation sans qu'ils n'y aient consenti ou n'en aient connaissance.\n\nIl est essentiel de préserver la confidentialité des patients, de garantir la sécurité des données et de normaliser les transactions électroniques des soins de santé. La loi HIPAA a contraint les prestataires de soins de santé, les assureurs et les entités connexes à mettre en œuvre des mesures strictes de protection des données afin de réduire considérablement l'accès non autorisé aux dossiers médicaux et de renforcer la confiance des patients.\n\n## Normes de conformité mondiales et régionales\n\n### Réglementations nationales/régionales\n\nBien que des normes de conformité comme la loi HIPAA et le RGPD soient connues dans le monde entier, il s'agit respectivement de normes américaines et européennes. Elles influencent d'autres normes régionales dans le monde, mais ne sont requises que pour les entreprises qui traitent des données provenant, par exemple, de l'UE. Plusieurs pays ont des normes de conformité qui doivent être respectées si une entreprise opère dans ces pays. Voici quelques autres normes spécifiques à certains pays :\n\n- [SOX](https://fr.wikipedia.org/wiki/Loi_Sarbanes-Oxley) (États-Unis, sociétés cotées) : Sarbanes-Oxley Act. Cette loi impose une tenue et une déclaration appropriées des documents comptables pour les sociétés cotées.\n\n- [LPRPDE](https://www.priv.gc.ca/fr/sujets-lies-a-la-protection-de-la-vie-privee/lois-sur-la-protection-des-renseignements-personnels-au-canada/la-loi-sur-la-protection-des-renseignements-personnels-et-les-documents-electroniques-lprpde/) (Canada, entreprises commerciales) : Loi sur la protection des renseignements personnels et les documents électroniques. Elle régit la manière dont les organisations du secteur privé collectent, utilisent et divulguent les informations personnelles.\n\n- [PDPA](https://www.pdpc.gov.sg/overview-of-pdpa/the-legislation/personal-data-protection-act) (Singapour, toutes les organisations) : Personal Data Protection Act. Cette loi sur la protection des données personnelles régit la collecte, l'utilisation et la divulgation de données personnelles par les organisations.\n\n- [APPI](https://www.ppc.go.jp/files/pdf/Act_on_the_Protection_of_Personal_Information.pdf) (Japon, tous les secteurs) : Act on the Protection of Personal Information. Cette loi sur la protection des informations personnelles réglemente l'utilisation d'informations personnelles au Japon.\n\n- [LGPD](https://lgpd-brazil.info/) (Brésil, tous les secteurs) : Lei Geral de Proteção de Dados. La loi brésilienne sur la protection des données est similaire au RGPD.\n\n- [FISMA](https://www.cisa.gov/topics/cyber-threats-and-advisories/federal-information-security-modernization-act) (États-Unis, agences fédérales) : Federal Information Security Management Act. Cette loi sur la gestion de la sécurité des informations fédérales définit un cadre pour la gestion de la sécurité de l'information des systèmes d'information fédéraux.\n\n- [POPI Act](https://popia.co.za/) (Afrique du Sud, tous les secteurs) : Protection of Personal Information Act. Cette loi sur la protection des données personnelles promeut la protection des informations personnelles traitées par des organismes publics et privés.\n\n- [PDPA](https://www.pwc.com/th/en/tax/personal-data-protection-act.html) (Thaïlande, tous les secteurs) : Personal Data Protection Act. Comme le RGPD, cette loi sur la protection des données personnelles réglemente la collecte, l'utilisation et la divulgation de données personnelles en Thaïlande.\n\n- [PIPL](https://en.wikipedia.org/wiki/Personal_Information_Protection_Law_of_the_People%27s_Republic_of_China) (Chine, tous les secteurs) : Personal Information Protection Law. La première loi complète sur la protection des données de la Chine est similaire au RGPD.\n\n- [NDPR](https://nitda.gov.ng/wp-content/uploads/2021/01/NDPR-Implementation-Framework.pdf) (Nigeria, tous les secteurs) : Nigeria Data Protection Regulation. Ce règlement sur la protection des données au Nigéria protège les droits des personnes physiques à la confidentialité des données.\n\n- [DIFC Data Protection Law](https://www.difc.ae/business/laws-and-regulations/legal-database/difc-laws/data-protection-law-difc-law-no-5-2020) (Dubaï, entreprises du Dubai International Financial Centre) : cette loi sur la protection des données du DIFC réglemente le traitement des données personnelles dans la zone franche du DIFC.\n\n- [PDPA](https://www.pdp.gov.my/jpdpv2/laws-of-malaysia-pdpa/personal-data-protection-act-2010/?lang=en) (Malaisie, transactions commerciales) : Personal Data Protection Act. Cette loi sur la protection des données personnelles réglemente le traitement des données personnelles dans les transactions commerciales.\n\n- [Privacy Act](https://www.ag.gov.au/rights-and-protections/privacy) (Australie, agences gouvernementales et certaines organisations du secteur privé). Cette loi relative à la confidentialité réglemente la manière dont les informations personnelles sont traitées par les agences gouvernementales australiennes et certaines organisations du secteur privé.\n\n- [KVKK](https://www.kvkk.gov.tr/Icerik/6649/Personal-Data-Protection-Law) (Turquie, tous les secteurs) : Turkish Personal Data Protection Law. La loi sur la protection des données personnelles turque réglemente le traitement des données personnelles et protège les droits individuels.\n\nCes normes reflètent la préoccupation croissante concernant la confidentialité et la sécurité des données. De nombreux pays développent leurs propres frameworks inspirés de réglementations établies comme le RGPD. Chaque norme est adaptée au contexte juridique, culturel et économique spécifique de son pays.\n\n### Normes spécifiques aux secteurs\n\n- [PCI DSS](https://www.pcisecuritystandards.org/lang/fr-fr/) (services financiers) : cette norme s'applique à toutes les organisations qui traitent des informations de cartes de crédit dans le monde entier.\n\n- [ISO 27001](https://www.iso.org/fr/standard/iso-iec-27000-family) (tous les secteurs) : cette norme de système de gestion de la sécurité de l'information fournit un framework pour les pratiques de gestion de la sécurité de l'information.\n\n- [GAMP 5](https://qbdgroup.com/en/blog/gamp-categories/) (secteur pharmaceutique) : Good Automated Manufacturing Practice. Directives pour les systèmes informatiques dans la fabrication pharmaceutique.\n\n- [ISO 13485](https://www.iso.org/fr/standard/59752.html) (dispositifs médicaux) : cette norme précise les exigences d'un système de gestion de la qualité pour les fabricants de dispositifs médicaux.\n\n- [COBIT](https://www.isaca.org/resources/cobit) (gestion informatique) : Control Objectives for Information and Related Technologies. Framework pour la gestion informatique et la gouvernance informatique.\n\n- [ITIL](https://fr.wikipedia.org/wiki/Information_Technology_Infrastructure_Library) (services informatiques) : Information Technology Infrastructure Library. Ensemble de pratiques détaillées pour la gestion des services informatiques.\n\n- [NIST CSF](https://www.nist.gov/cyberframework) (cybersécurité) : National Institute of Standards and Technology Cybersecurity Framework. Conseils pour gérer et réduire les risques liés à la cybersécurité.\n\n- [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/fr) (accessibilité Web) : Web Content Accessibility Guidelines. Ces directives dédiées à l’accessibilité des contenus Web visent à rendre le Web plus accessible aux personnes handicapées.\n\n- [Basel III](https://www.bis.org/bcbs/basel3_fr.htm) (secteur bancaire). Dispositif réglementaire international pour les banques, qui comprend des exigences de gestion des risques informatiques.\n\n- [TISAX](https://portal.enx.com/en-US/TISAX/) (secteur automobile) : Trusted Information Security Assessment Exchange. Mécanisme d'évaluation et d'échange de sécurité de l'information pour l'industrie automobile.\n\nCes normes s'appliquent dans le monde entier à des secteurs spécifiques, et garantissent des pratiques cohérentes et des mesures de sécurité dans leurs domaines respectifs.\n\n## Importance de la conformité continue\n\nLes organisations doivent mettre en œuvre des systèmes qui assurent la conformité aux exigences réglementaires pertinentes. Elles peuvent y parvenir grâce à [la conformité continue des logiciels](https://about.gitlab.com/fr-fr/solutions/compliance/), un principe essentiel à tous les secteurs qui garantit la surveillance, l'évaluation et l'ajustement continus des systèmes, processus et pratiques d'une organisation afin de garantir que ces derniers respectent à tout moment les normes et réglementations pertinentes.\n\nLa conformité continue n'est pas seulement une case à cocher en matière de réglementation, mais une nécessité stratégique pour le développement logiciel aujourd'hui. Elle permet aux organisations de naviguer de manière proactive face aux menaces émergentes, aux changements technologiques et aux évolutions réglementaires, tout en favorisant la confiance des parties prenantes, l'efficacité opérationnelle et l'avantage concurrentiel dans un environnement commercial de plus en plus complexe.\n\n## Conformité réglementaire ou normes auto-imposées ?\n\nLa conformité réglementaire et les normes auto-imposées sont deux approches distinctes de la gouvernance organisationnelle. La conformité réglementaire implique le respect de lois et de réglementations obligatoires établies par des autorités externes, qui ont une portée large et des conséquences juridiques potentielles en cas de non-respect. Elle se concentre sur le respect des exigences légales minimales et est généralement moins flexible. Le RGPD et la loi HIPAA en sont des exemples.\n\nEn revanche, les normes auto-imposées sont des directives volontaires adoptées par les organisations pour améliorer la qualité, la sécurité ou les performances. Elles peuvent être adaptées à des besoins spécifiques et visent généralement à dépasser les exigences minimales. Bien que le non-respect des normes auto-imposées puisse avoir un impact sur la réputation d'une organisation, il n'entraîne généralement pas de conséquences juridiques. Les principales différences résident dans leur origine, leur motivation, leur adaptabilité et leur portée. De nombreuses organisations mettent en œuvre les deux approches pour créer une stratégie complète de gestion de la qualité, de la sécurité et des performances.\n\n## Gestion de la conformité\n\nPour respecter des normes, les organisations doivent évaluer les [indicateurs de conformité](https://advisory.kpmg.us/articles/2018/compliance-metrics.html) appropriés et les intégrer dans leurs procédures opérationnelles standard. L'objectif est de fournir des informations permettant la détection et la prévention précoces des risques de conformité actuels et futurs. La gestion de la conformité doit être efficace et représente bien plus qu'une simple liste de contrôle avec des tâches à effectuer périodiquement ; il s'agit d'un processus continu complet à l'échelle de l'organisation.\n\n## Gestion de la conformité avec GitLab\n\nAvec GitLab, les organisations peuvent créer des [frameworks de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html), des [politiques de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/) et une [gestion des audits](https://docs.gitlab.com/ee/administration/audit_reports.html). GitLab permet également aux équipes de conformité ou de direction de surveiller les indicateurs de conformité avec les [rapports de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html).\n\n### Frameworks et pipelines de conformité\n\nLes organisations peuvent créer un [framework de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) qui identifie les projets dans GitLab avec des exigences de conformité définies, qui peuvent être appliquées au moyen de [pipelines de conformité](https://docs.gitlab.com/ee/user/group/compliance_pipelines.html). Par exemple, une entreprise FinTech peut créer un [framework de conformité par défaut](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#default-compliance-frameworks) pour tous les projets afin de garantir que chaque étape de son cycle de développement logiciel respecte les exigences PCI DSS pour le traitement des données des titulaires de cartes.\n\nCes exigences sont ensuite appliquées en veillant à ce que chaque modification introduite dans le code source soit suffisamment testée automatiquement avec les [fonctionnalités de sécurité des applications](https://docs.gitlab.com/ee/user/application_security/) de GitLab, qui couvrent le code source, les dépendances, les licences, les vulnérabilités dans l'application en cours d'exécution et les configurations d'infrastructure. Vous pouvez en savoir plus sur la façon dont GitLab vous aide à atteindre la conformité PCI et d'autres [normes de conformité réglementaires](https://about.gitlab.com/fr-fr/solutions/continuous-software-compliance/) avec les frameworks de conformité.\n\nLes vidéos suivantes vous aident à configurer et à utiliser des frameworks et pipelines de conformité.\n\n**Tutoriel vidéo : créer des frameworks de conformité**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/IDswzRI-8VQ\" title=\"Comment configurer les frameworks et pipelines de conformité dans GitLab\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Tutoriel vidéo : appliquer des pipelines de conformité**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jKA_e_jimoI\" title=\"GitLab Compliance Pipelines & Overriding Settings\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Gestion des politiques de sécurité\n\nLes équipes de sécurité et de conformité peuvent utiliser GitLab pour appliquer les exigences de conformité en veillant à ce que des scanners de sécurité s'exécutent dans certains pipelines ou exigent une approbation sur les merge requests lorsque les [politiques de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/) sont enfreintes. GitLab prend en charge les politiques d'[exécution des scans](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) et de [résultats des scans](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html). Ces politiques sont définies dans un [projet de politique de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/#security-policy-project) dédié qui sépare les responsabilités entre les équipes de sécurité et de développement. Les politiques de sécurité peuvent être appliquées de manière granulaire au niveau du groupe, du sous-groupe et du projet. Les politiques peuvent être modifiées en mode règle, qui utilise l'[éditeur de politique](https://docs.gitlab.com/ee/user/application_security/policies/#policy-editor), ou en mode yaml.\n\n#### Politiques d'exécution des scans\n\nLes politiques d'exécution des scans peuvent être configurées pour s'exécuter sur un [GitLab Runner](https://docs.gitlab.com/runner/) spécifié :\n\n- [Test statique de sécurité des applications (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n- [Infrastructure as Code](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)\n- [Test dynamique de sécurité des applications (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n- [Détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/)\n- [Analyse des conteneurs](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n- [Analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n\nLes jobs de scans peuvent être exécutés selon un calendrier ou chaque fois qu'un pipeline s'exécute. Les équipes de conformité et de sécurité peuvent utiliser les politiques d'exécution des analyses pour vérifier périodiquement et prévenir de manière proactive l'escalade des vulnérabilités dans le cadre d'une stratégie de gestion des vulnérabilités. Elles peuvent également renforcer les contrôles lorsque de nouvelles tendances sont observées à partir des résultats des scans.\n\n**Tutoriel vidéo : configurer des politiques d'analyse de sécurité dans GitLab**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZBcqGmEwORA\" title=\"Comment configurer des politiques des scans de sécurité dans GitLab\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Politiques de résultats des scans\n\nLes politiques de résultats des scans ajoutent une révision et une approbation requises pour les merge requests lorsque les résultats des analyses de sécurité spécifiées enfreignent les règles des politiques. Par exemple, une politique peut exiger qu'un membre de l'équipe de sécurité prenne des mesures lorsqu'une nouvelle vulnérabilité SAST critique est détectée. De cette façon, les membres des équipes de sécurité et de conformité peuvent venir en aide aux développeurs tout en veillant à ce que les modifications introduites dans la base de code soient sécurisées et respectent les exigences de conformité.\n\n**Tutoriel vidéo : aperçu des politiques de résultats des scans de GitLab**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/w5I9gcUgr9U\" title=\"Aperçu des politiques de résultats des scans de GitLab\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Politiques d'approbation des licences\n\nLors de la sélection des types de scans pour les règles de politique de résultats des scans, vous pouvez choisir entre le scan de sécurité, le comportement par défaut pour les politiques de résultats d'analyse, et l'analyse de licence, qui aide à garantir la conformité des licences. L'analyse des licences dépend des résultats du job [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) d'[analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) qui vérifie si les licences identifiées correspondent aux critères spécifiés, puis ajoute des exigences d'approbation avant qu'une merge request ouverte puisse être fusionnée. Cette étape est cruciale pour garantir que seules les dépendances avec des licences approuvées sont utilisées dans votre organisation.\n\n**Démonstration vidéo : politiques d'approbation des licences**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/34qBQ9t8qO8\" title=\"Démonstration des politiques d'approbation des licences\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Gestion des audits\n\n#### Préparation aux audits\n\nLes audits sont essentiels pour la gestion de la conformité, car ils permettent de comprendre la posture de sécurité et de conformité de votre organisation. Les audits externes requis par les régulateurs sont souvent détaillés et exhaustifs. Pour s'y préparer, les organisations doivent :\n\n- Déterminer les réglementations ou normes qui seront évaluées et les domaines de l'organisation qui seront examinés.\n- Analyser les résultats d'audit passés et s'assurer que tous les problèmes précédemment identifiés ont été résolus.\n- Collecter toutes les politiques, procédures et dossiers pertinents qui démontrent la conformité.\n- Effectuer un audit interne avant l'audit officiel pour identifier et combler toute lacune de conformité potentielle.\n- Informer les employés du processus d'audit et de leurs rôles. Effectuer une formation si nécessaire.\n- S'assurer que toute la documentation requise est facilement accessible et bien organisée.\n- Veiller à ce que toutes les politiques et procédures liées à la conformité soient à jour et alignées sur les réglementations actuelles.\n- Vérifier que toutes les mesures de protection techniques et tous les contrôles sont en place et fonctionnent correctement.\n- Identifier le personnel clé qui pourrait être interrogé et le briefer sur les questions potentielles.\n- Traiter les problèmes connus : s'il existe des problèmes de conformité connus, élaborer et documenter des plans d'action pour y remédier.\n\nPour faciliter votre préparation, les [événements d'audit](https://docs.gitlab.com/ee/administration/audit_events.html) et le [Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html) de GitLab offrent une vue détaillée de la conformité de l'organisation.\n\n#### Utilisation efficace des journaux d'audit GitLab\n\nLes [événements d'audit](https://docs.gitlab.com/ee/administration/audit_events.html) vous permettent de connaître chaque action effectuée sur l'instance GitLab. Les rapports d'audit indiquent chaque événement significatif avec son auteur et le moment où il a été effectué. Vous pouvez également générer des rapports détaillés à partir des événements d'audit en utilisant les [rapports d'audit](https://docs.gitlab.com/ee/administration/audit_reports.html), ce qui vous permet de prouver votre conformité aux auditeurs ou aux régulateurs.\n\n![Événements d'audit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098755/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098755493.png)\n\n[Le Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html#compliance-violations-report) est un composant important de la gestion des audits dans GitLab qui offre une visibilité sur la posture de conformité de votre organisation. Les rapports de conformité détaillent chaque violation découverte avec le [rapport sur les violations de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html) et les frameworks utilisés par les projets au sein de votre organisation avec le [rapport sur les frameworks de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html).\n\n![Respect des exigences réglementaires – image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098756/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098755493.png)\n\n\u003Ccenter>\u003Ci>Exemple d'un rapport sur les violations de conformité d'un groupe GitLab parent\u003C/i>\u003C/center>\n\n![Respect des exigences réglementaires – image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098755/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098755495.png)\n\n\u003Ccenter>\u003Ci>Exemple d'un rapport de framework de conformité pour tous les projets dans un groupe\u003C/i>\u003C/center>\n\n#### Streaming des événements d'audit\n\nLa plupart des organisations disposent de systèmes pour surveiller les activités dans leurs systèmes en temps réel. Avec le [streaming des événements d'audit](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) de GitLab, vous pouvez intégrer des solutions tierces comme Splunk pour la surveillance d'infrastructure ou DataDog pour la surveillance des flux afin d'obtenir des analyses des événements d'audit en temps réel. Toutes les données d'événements d'audit sont envoyées à la destination de streaming (il est essentiel de diffuser vers un service de confiance). Le streaming des événements d'audit peut être [configuré au niveau des groupes principaux](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html#top-level-group-streaming-destinations) et au [niveau de l'instance](https://docs.gitlab.com/ee/administration/audit_event_streaming/#instance-streaming-destinations) pour les instances GitLab autogérées.\n\n## Bonnes pratiques pour la gestion de la conformité\n\nVoici quelques bonnes pratiques pour une gestion efficace de la conformité :\n\n- Établissez une solide culture de conformité qui favorise la sensibilisation à la conformité au sein de l'organisation et garantit l'engagement et le soutien de la direction.\n- Développez un programme de conformité complet avec des politiques et procédures claires et révisez-le régulièrement pour refléter les changements réglementaires.\n- Mettez en œuvre l'évaluation et la gestion des risques pour identifier et évaluer régulièrement les risques de conformité, en hiérarchisant les risques en fonction de l'impact potentiel et de la probabilité.\n- Organisez régulièrement des formations sur la conformité adaptée aux rôles et responsabilités spécifiques pour tous les employés.\n- Mettez en œuvre une gestion de la conformité pour automatiser la surveillance de la conformité et les rapports de conformité dans la mesure du possible.\n- Effectuez des audits internes pour identifier les lacunes et les domaines d'amélioration. Il est également essentiel de considérer les audits externes de manière impartiale et d'utiliser les résultats d'audit pour affiner et améliorer les processus de conformité.\n- Tenez-vous informé des changements réglementaires en assignant à une personne ou équipe la surveillance des mises à jour réglementaires et en rejoignant des associations ou en participant à des forums du secteur.\n- Intégrez la conformité dans les processus métier, intégrez des contrôles de conformité dans les workflows opérationnels et prenez en compte la conformité dans la prise de décision stratégique. Alignez les objectifs de conformité avec les objectifs commerciaux.\n- Développez des plans de réponse pour les violations potentielles de conformité et effectuez des scénarios fictifs pour tester la préparation aux incidents et violations.\n\n## En savoir plus\n\nLa conformité est un processus continu de gestion efficace des risques, qui implique la mise en œuvre de garde-fous et la surveillance des indicateurs de conformité. GitLab permet aux organisations de respecter les normes réglementaires avec des fonctionnalités de [gestion de la conformité](https://about.gitlab.com/fr-fr/solutions/compliance/). Avec GitLab, vous pouvez améliorer l'expérience de la chaîne d'approvisionnement logicielle, créer des logiciels plus sécurisés plus rapidement et maintenir la confiance de vos utilisateurs, de vos clients et de votre communauté.\n\n> Pour en savoir plus sur la conformité et la gestion des politiques de sécurité, consultez le [tutoriel GitLab DevSecOps](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/), qui couvre le cycle de vie complet de la sécurité des applications dans GitLab.\n\n## Pour aller plus loin\n\n- [GitLab Dedicated pour le secteur public](https://about.gitlab.com/blog/introducing-gitlab-dedicated-for-government/)\n- [Comment garantir la séparation des tâches et appliquer la conformité avec GitLab](https://about.gitlab.com/fr-fr/blog/ensuring-compliance/)\n- [Accès avec le principe de moindre privilège avec GitLab : notre guide](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)","La conformité est un processus continu de gestion des risques qui requiert la mise en œuvre de garde-fous et le suivi d'indicateurs spécifiques. Découvrez la marche à suivre dans ce guide complet.","Sécurité et conformité : respectez les normes réglementaires avec GitLab",{"featured":12,"template":13,"slug":730},"meet-regulatory-standards-with-gitlab",{"promotions":732},[733,747,759],{"id":734,"categories":735,"header":737,"text":738,"button":739,"image":744},"ai-modernization",[736],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":740,"config":741},"Get your AI maturity score",{"href":742,"dataGaName":743,"dataGaLocation":243},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":745},{"src":746},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":748,"categories":749,"header":751,"text":738,"button":752,"image":756},"devops-modernization",[693,750],"devsecops","Are you just managing tools or shipping innovation?",{"text":753,"config":754},"Get your DevOps maturity score",{"href":755,"dataGaName":743,"dataGaLocation":243},"/assessments/devops-modernization-assessment/",{"config":757},{"src":758},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":760,"categories":761,"header":762,"text":738,"button":763,"image":767},"security-modernization",[10],"Are you trading speed for security?",{"text":764,"config":765},"Get your security maturity score",{"href":766,"dataGaName":743,"dataGaLocation":243},"/assessments/security-modernization-assessment/",{"config":768},{"src":769},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":771,"blurb":772,"button":773,"secondaryButton":777},"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":46,"config":774},{"href":775,"dataGaName":49,"dataGaLocation":776},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":51,"config":778},{"href":53,"dataGaName":54,"dataGaLocation":776},1773871241738]