[{"data":1,"prerenderedAt":780},["ShallowReactive",2],{"/fr-fr/blog/how-to-choose-the-right-security-scanning-approach":3,"navigation-fr-fr":38,"banner-fr-fr":443,"footer-fr-fr":453,"blog-post-authors-fr-fr-Matt Genelin|Mathias Ewald":663,"blog-related-posts-fr-fr-how-to-choose-the-right-security-scanning-approach":689,"assessment-promotions-fr-fr":732,"next-steps-fr-fr":771},{"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":433},{"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/compare/gitlab-vs-github/","get started",{"freeTrial":424,"mobileIcon":429,"desktopIcon":431},{"text":425,"config":426},"En savoir plus sur GitLab Duo",{"href":427,"dataGaName":428,"dataGaLocation":409},"/fr-fr/gitlab-duo/","gitlab duo",{"altText":411,"config":430},{"src":413,"dataGaName":414,"dataGaLocation":409},{"altText":411,"config":432},{"src":417,"dataGaName":414,"dataGaLocation":409},{"freeTrial":434,"mobileIcon":439,"desktopIcon":441},{"text":435,"config":436},"Retour aux tarifs",{"href":187,"dataGaName":437,"dataGaLocation":409,"icon":438},"back to pricing","GoBack",{"altText":411,"config":440},{"src":413,"dataGaName":414,"dataGaLocation":409},{"altText":411,"config":442},{"src":417,"dataGaName":414,"dataGaLocation":409},{"title":444,"button":445,"config":450},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":446,"config":447},"Regarder GitLab Transcend maintenant",{"href":448,"dataGaName":449,"dataGaLocation":44},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":451,"icon":452},"release","AiStar",{"data":454},{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":654},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":457,"config":458},"Afficher le code source de la page",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Modifier cette page",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Veuillez contribuer",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,555,587,622],{"title":62,"links":479,"subMenu":484},[480],{"text":481,"config":482},"Plateforme DevSecOps",{"href":71,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":185,"links":486},[487,491,496],{"text":488,"config":489},"Voir les forfaits",{"href":187,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Pourquoi choisir GitLab Premium ?",{"href":494,"dataGaName":495,"dataGaLocation":461},"/fr-fr/pricing/premium/","why premium",{"text":497,"config":498},"Pourquoi choisir GitLab Ultimate ?",{"href":499,"dataGaName":500,"dataGaLocation":461},"/fr-fr/pricing/ultimate/","why ultimate",{"title":502,"links":503},"Solutions",[504,509,512,514,519,524,528,531,534,539,541,543,545,550],{"text":505,"config":506},"Transformation digitale",{"href":507,"dataGaName":508,"dataGaLocation":461},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":510,"config":511},"Sécurité et conformité",{"href":126,"dataGaName":133,"dataGaLocation":461},{"text":118,"config":513},{"href":103,"dataGaName":104,"dataGaLocation":461},{"text":515,"config":516},"Développement agile",{"href":517,"dataGaName":518,"dataGaLocation":461},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"Transformation cloud",{"href":522,"dataGaName":523,"dataGaLocation":461},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":115,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":18,"config":529},{"href":108,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":157,"config":532},{"href":159,"dataGaName":533,"dataGaLocation":461},"value stream management",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":461},"/fr-fr/solutions/gitops/","gitops",{"text":170,"config":540},{"href":172,"dataGaName":173,"dataGaLocation":461},{"text":175,"config":542},{"href":177,"dataGaName":178,"dataGaLocation":461},{"text":180,"config":544},{"href":182,"dataGaName":183,"dataGaLocation":461},{"text":546,"config":547},"Formation",{"href":548,"dataGaName":549,"dataGaLocation":461},"/fr-fr/solutions/education/","education",{"text":551,"config":552},"Services financiers",{"href":553,"dataGaName":554,"dataGaLocation":461},"/fr-fr/solutions/finance/","financial services",{"title":190,"links":556},[557,559,562,564,567,569,572,575,577,579,581,583,585],{"text":202,"config":558},{"href":204,"dataGaName":205,"dataGaLocation":461},{"text":560,"config":561},"Guides de démarrage rapide",{"href":209,"dataGaName":210,"dataGaLocation":461},{"text":212,"config":563},{"href":214,"dataGaName":215,"dataGaLocation":461},{"text":217,"config":565},{"href":219,"dataGaName":566,"dataGaLocation":461},"docs",{"text":240,"config":568},{"href":242,"dataGaName":243},{"text":570,"config":571},"Histoires de réussite client",{"href":237,"dataGaLocation":461},{"text":573,"config":574},"Histoires de succès client",{"href":237,"dataGaName":238,"dataGaLocation":461},{"text":245,"config":576},{"href":247,"dataGaName":248,"dataGaLocation":461},{"text":253,"config":578},{"href":255,"dataGaName":256,"dataGaLocation":461},{"text":258,"config":580},{"href":260,"dataGaName":261,"dataGaLocation":461},{"text":263,"config":582},{"href":265,"dataGaName":266,"dataGaLocation":461},{"text":268,"config":584},{"href":270,"dataGaName":271,"dataGaLocation":461},{"text":273,"config":586},{"href":275,"dataGaName":276,"dataGaLocation":461},{"title":291,"links":588},[589,591,594,596,598,600,602,606,611,613,615,617],{"text":298,"config":590},{"href":300,"dataGaName":293,"dataGaLocation":461},{"text":592,"config":593},"Emplois",{"href":305,"dataGaName":306,"dataGaLocation":461},{"text":311,"config":595},{"href":313,"dataGaName":314,"dataGaLocation":461},{"text":316,"config":597},{"href":318,"dataGaName":319,"dataGaLocation":461},{"text":321,"config":599},{"href":323,"dataGaName":324,"dataGaLocation":461},{"text":326,"config":601},{"href":328,"dataGaName":329,"dataGaLocation":461},{"text":603,"config":604},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":461},"/sustainability/",{"text":607,"config":608},"Diversité, inclusion et appartenance (DIB)",{"href":609,"dataGaName":610,"dataGaLocation":461},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":331,"config":612},{"href":333,"dataGaName":334,"dataGaLocation":461},{"text":341,"config":614},{"href":343,"dataGaName":344,"dataGaLocation":461},{"text":346,"config":616},{"href":348,"dataGaName":349,"dataGaLocation":461},{"text":618,"config":619},"Déclaration de transparence sur l'esclavage moderne",{"href":620,"dataGaName":621,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":351,"links":623},[624,627,632,634,639,644,649],{"text":625,"config":626},"Échanger avec un expert",{"href":53,"dataGaName":54,"dataGaLocation":461},{"text":628,"config":629},"Aide",{"href":630,"dataGaName":631,"dataGaLocation":461},"/support/","get help",{"text":365,"config":633},{"href":367,"dataGaName":368,"dataGaLocation":461},{"text":635,"config":636},"Statut",{"href":637,"dataGaName":638,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":640,"config":641},"Conditions d'utilisation",{"href":642,"dataGaName":643},"/terms/","terms of use",{"text":645,"config":646},"Déclaration de confidentialité",{"href":647,"dataGaName":648,"dataGaLocation":461},"/fr-fr/privacy/","privacy statement",{"text":650,"config":651},"Préférences en matière de cookies",{"dataGaName":652,"dataGaLocation":461,"id":653,"isOneTrustButton":29},"cookie preferences","ot-sdk-btn",{"items":655},[656,658,661],{"text":640,"config":657},{"href":642,"dataGaName":643,"dataGaLocation":461},{"text":659,"config":660},"Politique de confidentialité",{"href":647,"dataGaName":648,"dataGaLocation":461},{"text":650,"config":662},{"dataGaName":652,"dataGaLocation":461,"id":653,"isOneTrustButton":29},[664,677],{"id":665,"title":25,"body":9,"config":666,"content":668,"description":9,"extension":27,"meta":672,"navigation":29,"path":673,"seo":674,"stem":675,"__hash__":676},"blogAuthors/en-us/blog/authors/matt-genelin.yml",{"template":667},"BlogAuthor",{"name":25,"config":669},{"headshot":670,"ctfId":671},"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":678,"title":26,"body":9,"config":679,"content":680,"description":9,"extension":27,"meta":684,"navigation":29,"path":685,"seo":686,"stem":687,"__hash__":688},"blogAuthors/en-us/blog/authors/mathias-ewald.yml",{"template":667},{"name":26,"config":681},{"headshot":682,"ctfId":683},"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",[690,705,719],{"content":691,"config":703},{"title":692,"description":693,"authors":694,"heroImage":697,"date":698,"body":699,"category":10,"tags":700},"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.",[695,696],"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,701,702],"product","features",{"featured":12,"template":13,"slug":704},"track-vulnerability-remediation-with-the-updated-gitlab-security-dashboard",{"content":706,"config":717},{"tags":707,"category":10,"authors":710,"heroImage":712,"date":713,"body":714,"description":715,"title":716},[708,709,10,183],"DevSecOps","DevSecOps platform",[711],"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":718},"meet-regulatory-standards-with-gitlab",{"content":720,"config":730},{"title":721,"description":722,"heroImage":723,"date":724,"body":725,"category":10,"tags":726,"authors":728},"Mises à jour des politiques du programme de bug bounty de GitLab","Découvrez les améliorations apportées qui renforcent la précision et la portée du programme.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664844/Blog/Hero%20Images/AdobeStock_941867776.jpg","2026-01-20","GitLab a lancé [son programme de bug bounty HackerOne](https://about.gitlab.com/blog/gitlab-hackerone-bug-bounty-program-is-public-today/) pour la première fois en 2018. Nous avons depuis travaillé avec la communauté des chercheurs pour sécuriser notre plateforme DevSecOps complète alimentée par l'IA. Nous sommes ravis d'annoncer les mises à jour des politiques du programme, qui reflètent notre engagement envers la transparence, les retours des chercheurs et nos efforts continus en vue de fournir des attentes claires et des processus rationalisés.\n\n## Les changements apportés\n\n### Conseils améliorés pour les tests\n\nNous mettons davantage l'accent sur les environnements de test locaux pour protéger à la fois les chercheurs et notre infrastructure de production. Nous **recommandons fortement les tests locaux avec le [GitLab Development Kit (GDK)](https://gitlab-org.gitlab.io/gitlab-development-kit/)** pour la plupart des recherches en sécurité. Le GDK vous donne accès à des fonctionnalités de pointe avant leur publication et vous permet d'expérimenter sans devoir vous préoccuper de l'infrastructure de production.\n\nSi vous devez démontrer l'impact d'une attaque par déni de service (DoS), nous vous recommandons de le tester sur une instance GitLab auto-gérée avec des spécifications et des ressources égales ou supérieures aux [exigences d'installation des instances GitLab auto-gérées](https://docs.gitlab.com/install/requirements/).\n\nPour les vulnérabilités qui requièrent l'architecture de production de GitLab.com, vous devez utiliser des comptes de test créés avec votre alias de courrier électronique HackerOne : `yourhandle@wearehackerone.com`.\n\n### Portée affinée pour une meilleure concentration\n\nNous avons clarifié plusieurs domaines de portée en fonction des retours de la communauté :\n\n**Les attaques par DoS sortent du champ d'application :** des exceptions peuvent être envisagées pour les vulnérabilités DoS au niveau de l'application qui entraînent une interruption totale persistante du service et peuvent être exécutées via des points de terminaison non authentifiés (exemples : ReDoS, bombes logiques, etc.).\n\n**Injection de prompt :** l'injection de prompt autonome sort du champ d'application, mais peut être admise si elle sert de vecteur initial pour causer un préjudice au-delà de sa limite de sécurité.\n\n**Métadonnées et énumération** : la collecte générale d'informations sort du champ d'application, tandis que les violations de confidentialité exposant des données confidentielles tombent dans le champ d'application. Nous avons fourni de nouveaux exemples détaillés qui distinguent ces deux types de problèmes sur la [page des politiques du programme](https://hackerone.com/gitlab).\n\n## Période de transition pour les chercheurs\n\nNous sommes conscients que les changements de politique peuvent créer de l'incertitude pour les chercheurs qui mènent des enquêtes actives. Pour préserver la confiance pendant cette transition et éviter d'interférer avec les importantes recherches déjà en cours :\n\n* GitLab offre un délai de grâce de 7 jours pour les rapports DoS soumis avant **le 22 janvier 2026 à 21 h 00, heure du Pacifique (23 janvier 2026 à 6 h 00, heure française).** Les rapports soumis avant cette date seront évalués selon notre politique précédente.\n\nVotre investissement dans la sécurité de GitLab nous tient à cœur, et nous nous engageons à honorer la politique dans le cadre de laquelle vous avez commencé votre recherche.\n\n## Notre engagement envers la communauté\n\nCes changements reflètent notre engagement profond envers la communauté des chercheurs à travers trois principes clés.\n\n1\\. Nous mettons l'accent sur la transparence en établissant des limites plus claires et des critères objectifs qui réduisent l'ambiguïté et préviennent les différends.\n\n2\\. Nous renforçons la sécurité grâce à des conseils améliorés sur la plateforme de test qui protègent à la fois les systèmes de production et les chercheurs contre les interruptions accidentelles de service.\n\n3\\. Nous assurons l'équité grâce à des normes d'évaluation cohérentes et à des dispositions qui garantissent un traitement équitable pour tous les chercheurs, y compris ceux qui participent déjà au programme.\n\nLes ajustements apportés à la portée contribuent également à la durabilité du programme, car ils concentrent les ressources sur les problèmes de sécurité à fort impact et maintiennent une couverture large.\n\n## Lancez-vous\n\nEnvie de contribuer à la sécurité de GitLab ?\n\n* **Nouveaux chercheurs :** visitez notre [page consacrée au programme HackerOne](https://hackerone.com/gitlab).\n* **Configurer des tests locaux :** téléchargez le [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit).\n* **Examiner les politiques :** [consultez notre documentation complète pour obtenir des directives détaillées](https://hackerone.com/gitlab).\n* **Comprendre l'évaluation de la gravité :** explorez notre [calculateur CVSS](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nNous remercions la communauté des chercheurs dont l'engagement continu aide à maintenir la sécurité de GitLab. Votre expertise et votre dévouement font une réelle différence pour des millions d'utilisateurs dans le monde.\n\n---\n\n*Des questions sur ces changements ? Contactez notre équipe en [créant un ticket](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions/-/issues/new) dans notre projet de questions HackerOne sur GitLab.*",[10,727],"bug bounty",[729],"Kayla Hagopian",{"featured":12,"template":13,"slug":731},"gitlab-bug-bounty-program-policy-updates",{"promotions":733},[734,748,760],{"id":735,"categories":736,"header":738,"text":739,"button":740,"image":745},"ai-modernization",[737],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":741,"config":742},"Get your AI maturity score",{"href":743,"dataGaName":744,"dataGaLocation":243},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":746},{"src":747},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":749,"categories":750,"header":752,"text":739,"button":753,"image":757},"devops-modernization",[701,751],"devsecops","Are you just managing tools or shipping innovation?",{"text":754,"config":755},"Get your DevOps maturity score",{"href":756,"dataGaName":744,"dataGaLocation":243},"/assessments/devops-modernization-assessment/",{"config":758},{"src":759},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":761,"categories":762,"header":763,"text":739,"button":764,"image":768},"security-modernization",[10],"Are you trading speed for security?",{"text":765,"config":766},"Get your security maturity score",{"href":767,"dataGaName":744,"dataGaLocation":243},"/assessments/security-modernization-assessment/",{"config":769},{"src":770},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":772,"blurb":773,"button":774,"secondaryButton":778},"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":775},{"href":776,"dataGaName":49,"dataGaLocation":777},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":51,"config":779},{"href":53,"dataGaName":54,"dataGaLocation":777},1772652097159]