[{"data":1,"prerenderedAt":894},["ShallowReactive",2],{"/fr-fr/blog/categories/security/":3,"navigation-fr-fr":22,"banner-fr-fr":443,"footer-fr-fr":455,"security-category-page-fr-fr":667},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":17,"_source":18,"_file":19,"_stem":20,"_extension":21},"/fr-fr/blog/categories/security","categories",false,"",{"title":9,"description":10},"Sécurité","Browse articles related to Sécurité on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","security","content:fr-fr:blog:categories:security.yml","yaml","Security","content","fr-fr/blog/categories/security.yml","fr-fr/blog/categories/security","yml",{"_path":23,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":25,"_id":439,"_type":16,"title":440,"_source":18,"_file":441,"_stem":442,"_extension":21},"/shared/fr-fr/main-navigation","fr-fr",{"logo":26,"freeTrial":31,"sales":36,"login":41,"items":46,"search":380,"minimal":416,"duo":430},{"config":27},{"href":28,"dataGaName":29,"dataGaLocation":30},"/fr-fr/","gitlab logo","header",{"text":32,"config":33},"Commencer un essai gratuit",{"href":34,"dataGaName":35,"dataGaLocation":30},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":37,"config":38},"Contacter l'équipe commerciale",{"href":39,"dataGaName":40,"dataGaLocation":30},"/fr-fr/sales/","sales",{"text":42,"config":43},"Connexion",{"href":44,"dataGaName":45,"dataGaLocation":30},"https://gitlab.com/users/sign_in/","sign in",[47,91,190,195,301,361],{"text":48,"config":49,"cards":51,"footer":74},"Plateforme",{"dataNavLevelOne":50},"platform",[52,58,66],{"title":48,"description":53,"link":54},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":55,"config":56},"Découvrir notre plateforme",{"href":57,"dataGaName":50,"dataGaLocation":30},"/fr-fr/platform/",{"title":59,"description":60,"link":61},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":62,"config":63},"Découvrez GitLab Duo",{"href":64,"dataGaName":65,"dataGaLocation":30},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":67,"description":68,"link":69},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":70,"config":71},"En savoir plus",{"href":72,"dataGaName":73,"dataGaLocation":30},"/fr-fr/why-gitlab/","why gitlab",{"title":75,"items":76},"Démarrer avec",[77,82,87],{"text":78,"config":79},"Ingénierie de plateforme",{"href":80,"dataGaName":81,"dataGaLocation":30},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":83,"config":84},"Expérience développeur",{"href":85,"dataGaName":86,"dataGaLocation":30},"/fr-fr/developer-experience/","Developer experience",{"text":88,"config":89},"MLOps",{"href":90,"dataGaName":88,"dataGaLocation":30},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":92,"left":93,"config":94,"link":96,"lists":100,"footer":172},"Produit",true,{"dataNavLevelOne":95},"solutions",{"text":97,"config":98},"Voir toutes les solutions",{"href":99,"dataGaName":95,"dataGaLocation":30},"/fr-fr/solutions/",[101,127,150],{"title":102,"description":103,"link":104,"items":109},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":105},{"icon":106,"href":107,"dataGaName":108,"dataGaLocation":30},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[110,114,118,123],{"text":111,"config":112},"CI/CD",{"href":113,"dataGaLocation":30,"dataGaName":111},"/fr-fr/solutions/continuous-integration/",{"text":115,"config":116},"Développement assisté par l'IA",{"href":64,"dataGaLocation":30,"dataGaName":117},"AI assisted development",{"text":119,"config":120},"Gestion du code source",{"href":121,"dataGaLocation":30,"dataGaName":122},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"Livraison de logiciels automatisée",{"href":107,"dataGaLocation":30,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":30,"icon":134},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[136,140,145],{"text":137,"config":138},"Sécurité et conformité",{"href":132,"dataGaLocation":30,"dataGaName":139},"Security & Compliance",{"text":141,"config":142},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":143,"dataGaLocation":30,"dataGaName":144},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Conformité et gouvernance",{"href":148,"dataGaLocation":30,"dataGaName":149},"/fr-fr/solutions/continuous-software-compliance/","Compliance and governance",{"title":151,"link":152,"items":157},"Mesures",{"config":153},{"icon":154,"href":155,"dataGaName":156,"dataGaLocation":30},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[158,162,167],{"text":159,"config":160},"Visibilité et mesures",{"href":155,"dataGaLocation":30,"dataGaName":161},"Visibility and Measurement",{"text":163,"config":164},"Gestion de la chaîne de valeur",{"href":165,"dataGaLocation":30,"dataGaName":166},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":168,"config":169},"Données d'analyse et informations clés",{"href":170,"dataGaLocation":30,"dataGaName":171},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":173,"items":174},"GitLab pour",[175,180,185],{"text":176,"config":177},"Entreprises",{"href":178,"dataGaLocation":30,"dataGaName":179},"/fr-fr/enterprise/","enterprise",{"text":181,"config":182},"PME",{"href":183,"dataGaLocation":30,"dataGaName":184},"/fr-fr/small-business/","small business",{"text":186,"config":187},"Secteur public",{"href":188,"dataGaLocation":30,"dataGaName":189},"/fr-fr/solutions/public-sector/","public sector",{"text":191,"config":192},"Tarifs",{"href":193,"dataGaName":194,"dataGaLocation":30,"dataNavLevelOne":194},"/fr-fr/pricing/","pricing",{"text":196,"config":197,"link":199,"lists":203,"feature":288},"Ressources",{"dataNavLevelOne":198},"resources",{"text":200,"config":201},"Afficher toutes les ressources",{"href":202,"dataGaName":198,"dataGaLocation":30},"/fr-fr/resources/",[204,237,260],{"title":205,"items":206},"Premiers pas",[207,212,217,222,227,232],{"text":208,"config":209},"Installation",{"href":210,"dataGaName":211,"dataGaLocation":30},"/fr-fr/install/","install",{"text":213,"config":214},"Guides de démarrage rapide",{"href":215,"dataGaName":216,"dataGaLocation":30},"/fr-fr/get-started/","quick setup checklists",{"text":218,"config":219},"Apprentissage",{"href":220,"dataGaLocation":30,"dataGaName":221},"https://university.gitlab.com/","learn",{"text":223,"config":224},"Documentation sur le produit",{"href":225,"dataGaName":226,"dataGaLocation":30},"https://docs.gitlab.com/","product documentation",{"text":228,"config":229},"Vidéos sur les bonnes pratiques",{"href":230,"dataGaName":231,"dataGaLocation":30},"/fr-fr/getting-started-videos/","best practice videos",{"text":233,"config":234},"Intégrations",{"href":235,"dataGaName":236,"dataGaLocation":30},"/fr-fr/integrations/","integrations",{"title":238,"items":239},"Découvrir",[240,245,250,255],{"text":241,"config":242},"Histoires de succès client",{"href":243,"dataGaName":244,"dataGaLocation":30},"/fr-fr/customers/","customer success stories",{"text":246,"config":247},"Blog",{"href":248,"dataGaName":249,"dataGaLocation":30},"/fr-fr/blog/","blog",{"text":251,"config":252},"Travail à distance",{"href":253,"dataGaName":254,"dataGaLocation":30},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":256,"config":257},"TeamOps",{"href":258,"dataGaName":259,"dataGaLocation":30},"/fr-fr/teamops/","teamops",{"title":261,"items":262},"Connecter",[263,268,273,278,283],{"text":264,"config":265},"Services GitLab",{"href":266,"dataGaName":267,"dataGaLocation":30},"/fr-fr/services/","services",{"text":269,"config":270},"Communauté",{"href":271,"dataGaName":272,"dataGaLocation":30},"/community/","community",{"text":274,"config":275},"Forum",{"href":276,"dataGaName":277,"dataGaLocation":30},"https://forum.gitlab.com/","forum",{"text":279,"config":280},"Événements",{"href":281,"dataGaName":282,"dataGaLocation":30},"/events/","events",{"text":284,"config":285},"Partenaires",{"href":286,"dataGaName":287,"dataGaLocation":30},"/fr-fr/partners/","partners",{"backgroundColor":289,"textColor":290,"text":291,"image":292,"link":296},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":293,"config":294},"carte promo The Source",{"src":295},"/images/navigation/the-source-promo-card.svg",{"text":297,"config":298},"Lire les articles les plus récents",{"href":299,"dataGaName":300,"dataGaLocation":30},"/fr-fr/the-source/","the source",{"text":302,"config":303,"lists":305},"Société",{"dataNavLevelOne":304},"company",[306],{"items":307},[308,313,319,321,326,331,336,341,346,351,356],{"text":309,"config":310},"À propos",{"href":311,"dataGaName":312,"dataGaLocation":30},"/fr-fr/company/","about",{"text":314,"config":315,"footerGa":318},"Emplois",{"href":316,"dataGaName":317,"dataGaLocation":30},"/jobs/","jobs",{"dataGaName":317},{"text":279,"config":320},{"href":281,"dataGaName":282,"dataGaLocation":30},{"text":322,"config":323},"Leadership",{"href":324,"dataGaName":325,"dataGaLocation":30},"/company/team/e-group/","leadership",{"text":327,"config":328},"Équipe",{"href":329,"dataGaName":330,"dataGaLocation":30},"/company/team/","team",{"text":332,"config":333},"Manuel",{"href":334,"dataGaName":335,"dataGaLocation":30},"https://handbook.gitlab.com/","handbook",{"text":337,"config":338},"Relations avec les investisseurs",{"href":339,"dataGaName":340,"dataGaLocation":30},"https://ir.gitlab.com/","investor relations",{"text":342,"config":343},"Centre de confiance",{"href":344,"dataGaName":345,"dataGaLocation":30},"/fr-fr/security/","trust center",{"text":347,"config":348},"Centre pour la transparence de l'IA",{"href":349,"dataGaName":350,"dataGaLocation":30},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":352,"config":353},"Newsletter",{"href":354,"dataGaName":355,"dataGaLocation":30},"/company/contact/","newsletter",{"text":357,"config":358},"Presse",{"href":359,"dataGaName":360,"dataGaLocation":30},"/press/","press",{"text":362,"config":363,"lists":364},"Nous contacter",{"dataNavLevelOne":304},[365],{"items":366},[367,370,375],{"text":37,"config":368},{"href":39,"dataGaName":369,"dataGaLocation":30},"talk to sales",{"text":371,"config":372},"Aide",{"href":373,"dataGaName":374,"dataGaLocation":30},"/support/","get help",{"text":376,"config":377},"Portail clients GitLab",{"href":378,"dataGaName":379,"dataGaLocation":30},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":381,"login":382,"suggestions":389},"Fermer",{"text":383,"link":384},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":385,"config":386},"gitlab.com",{"href":44,"dataGaName":387,"dataGaLocation":388},"search login","search",{"text":390,"default":391},"Suggestions",[392,395,400,402,407,412],{"text":59,"config":393},{"href":64,"dataGaName":394,"dataGaLocation":388},"GitLab Duo (AI)",{"text":396,"config":397},"Suggestions de code (IA)",{"href":398,"dataGaName":399,"dataGaLocation":388},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":111,"config":401},{"href":113,"dataGaName":111,"dataGaLocation":388},{"text":403,"config":404},"GitLab sur AWS",{"href":405,"dataGaName":406,"dataGaLocation":388},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":408,"config":409},"GitLab sur Google Cloud ",{"href":410,"dataGaName":411,"dataGaLocation":388},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":413,"config":414},"Pourquoi utiliser GitLab ?",{"href":72,"dataGaName":415,"dataGaLocation":388},"Why GitLab?",{"freeTrial":417,"mobileIcon":422,"desktopIcon":427},{"text":418,"config":419},"Commencer votre essai gratuit",{"href":420,"dataGaName":35,"dataGaLocation":421},"https://gitlab.com/-/trials/new/","nav",{"altText":423,"config":424},"Icône GitLab",{"src":425,"dataGaName":426,"dataGaLocation":421},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":423,"config":428},{"src":429,"dataGaName":426,"dataGaLocation":421},"/images/brand/gitlab-logo-type.svg",{"freeTrial":431,"mobileIcon":435,"desktopIcon":437},{"text":432,"config":433},"En savoir plus sur GitLab Duo",{"href":64,"dataGaName":434,"dataGaLocation":421},"gitlab duo",{"altText":423,"config":436},{"src":425,"dataGaName":426,"dataGaLocation":421},{"altText":423,"config":438},{"src":429,"dataGaName":426,"dataGaLocation":421},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":444,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"title":445,"titleMobile":445,"button":446,"config":450,"_id":452,"_type":16,"_source":18,"_file":453,"_stem":454,"_extension":21},"/shared/fr-fr/banner","La plateforme GitLab Duo Agent est maintenant en bêta publique !",{"text":70,"config":447},{"href":448,"dataGaName":449,"dataGaLocation":30},"/fr-fr/gitlab-duo/agent-platform/","duo banner",{"layout":451},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":456,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":457,"_id":663,"_type":16,"title":664,"_source":18,"_file":665,"_stem":666,"_extension":21},"/shared/fr-fr/main-footer",{"text":458,"source":459,"edit":465,"contribute":470,"config":475,"items":480,"minimal":654},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":460,"config":461},"Afficher le code source de la page",{"href":462,"dataGaName":463,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":466,"config":467},"Modifier cette page",{"href":468,"dataGaName":469,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":471,"config":472},"Veuillez contribuer",{"href":473,"dataGaName":474,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":476,"facebook":477,"youtube":478,"linkedin":479},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[481,504,558,591,625],{"title":48,"links":482,"subMenu":487},[483],{"text":484,"config":485},"Plateforme DevSecOps",{"href":57,"dataGaName":486,"dataGaLocation":464},"devsecops platform",[488],{"title":191,"links":489},[490,494,499],{"text":491,"config":492},"Voir les forfaits",{"href":193,"dataGaName":493,"dataGaLocation":464},"view plans",{"text":495,"config":496},"Pourquoi choisir GitLab Premium ?",{"href":497,"dataGaName":498,"dataGaLocation":464},"/fr-fr/pricing/premium/","why premium",{"text":500,"config":501},"Pourquoi choisir GitLab Ultimate ?",{"href":502,"dataGaName":503,"dataGaLocation":464},"/fr-fr/pricing/ultimate/","why ultimate",{"title":505,"links":506},"Solutions",[507,512,515,517,522,527,531,534,537,542,544,546,548,553],{"text":508,"config":509},"Transformation digitale",{"href":510,"dataGaName":511,"dataGaLocation":464},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":137,"config":513},{"href":132,"dataGaName":514,"dataGaLocation":464},"security & compliance",{"text":124,"config":516},{"href":107,"dataGaName":108,"dataGaLocation":464},{"text":518,"config":519},"Développement agile",{"href":520,"dataGaName":521,"dataGaLocation":464},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":523,"config":524},"Transformation cloud",{"href":525,"dataGaName":526,"dataGaLocation":464},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":528,"config":529},"SCM",{"href":121,"dataGaName":530,"dataGaLocation":464},"source code management",{"text":111,"config":532},{"href":113,"dataGaName":533,"dataGaLocation":464},"continuous integration & delivery",{"text":163,"config":535},{"href":165,"dataGaName":536,"dataGaLocation":464},"value stream management",{"text":538,"config":539},"GitOps",{"href":540,"dataGaName":541,"dataGaLocation":464},"/fr-fr/solutions/gitops/","gitops",{"text":176,"config":543},{"href":178,"dataGaName":179,"dataGaLocation":464},{"text":181,"config":545},{"href":183,"dataGaName":184,"dataGaLocation":464},{"text":186,"config":547},{"href":188,"dataGaName":189,"dataGaLocation":464},{"text":549,"config":550},"Formation",{"href":551,"dataGaName":552,"dataGaLocation":464},"/fr-fr/solutions/education/","education",{"text":554,"config":555},"Services financiers",{"href":556,"dataGaName":557,"dataGaLocation":464},"/fr-fr/solutions/finance/","financial services",{"title":196,"links":559},[560,562,564,566,569,571,575,577,579,581,583,585,587,589],{"text":208,"config":561},{"href":210,"dataGaName":211,"dataGaLocation":464},{"text":213,"config":563},{"href":215,"dataGaName":216,"dataGaLocation":464},{"text":218,"config":565},{"href":220,"dataGaName":221,"dataGaLocation":464},{"text":223,"config":567},{"href":225,"dataGaName":568,"dataGaLocation":464},"docs",{"text":246,"config":570},{"href":248,"dataGaName":249},{"text":572,"config":573},"Histoires de réussite client",{"href":574,"dataGaLocation":464},"/customers/",{"text":241,"config":576},{"href":243,"dataGaName":244,"dataGaLocation":464},{"text":251,"config":578},{"href":253,"dataGaName":254,"dataGaLocation":464},{"text":264,"config":580},{"href":266,"dataGaName":267,"dataGaLocation":464},{"text":256,"config":582},{"href":258,"dataGaName":259,"dataGaLocation":464},{"text":269,"config":584},{"href":271,"dataGaName":272,"dataGaLocation":464},{"text":274,"config":586},{"href":276,"dataGaName":277,"dataGaLocation":464},{"text":279,"config":588},{"href":281,"dataGaName":282,"dataGaLocation":464},{"text":284,"config":590},{"href":286,"dataGaName":287,"dataGaLocation":464},{"title":302,"links":592},[593,595,597,599,601,603,605,609,614,616,618,620],{"text":309,"config":594},{"href":311,"dataGaName":304,"dataGaLocation":464},{"text":314,"config":596},{"href":316,"dataGaName":317,"dataGaLocation":464},{"text":322,"config":598},{"href":324,"dataGaName":325,"dataGaLocation":464},{"text":327,"config":600},{"href":329,"dataGaName":330,"dataGaLocation":464},{"text":332,"config":602},{"href":334,"dataGaName":335,"dataGaLocation":464},{"text":337,"config":604},{"href":339,"dataGaName":340,"dataGaLocation":464},{"text":606,"config":607},"Sustainability",{"href":608,"dataGaName":606,"dataGaLocation":464},"/sustainability/",{"text":610,"config":611},"Diversité, inclusion et appartenance (DIB)",{"href":612,"dataGaName":613,"dataGaLocation":464},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":342,"config":615},{"href":344,"dataGaName":345,"dataGaLocation":464},{"text":352,"config":617},{"href":354,"dataGaName":355,"dataGaLocation":464},{"text":357,"config":619},{"href":359,"dataGaName":360,"dataGaLocation":464},{"text":621,"config":622},"Déclaration de transparence sur l'esclavage moderne",{"href":623,"dataGaName":624,"dataGaLocation":464},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":362,"links":626},[627,630,632,634,639,644,649],{"text":628,"config":629},"Échanger avec un expert",{"href":39,"dataGaName":40,"dataGaLocation":464},{"text":371,"config":631},{"href":373,"dataGaName":374,"dataGaLocation":464},{"text":376,"config":633},{"href":378,"dataGaName":379,"dataGaLocation":464},{"text":635,"config":636},"Statut",{"href":637,"dataGaName":638,"dataGaLocation":464},"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":464},"/fr-fr/privacy/","privacy statement",{"text":650,"config":651},"Préférences en matière de cookies",{"dataGaName":652,"dataGaLocation":464,"id":653,"isOneTrustButton":93},"cookie preferences","ot-sdk-btn",{"items":655},[656,658,661],{"text":640,"config":657},{"href":642,"dataGaName":643,"dataGaLocation":464},{"text":659,"config":660},"Politique de confidentialité",{"href":647,"dataGaName":648,"dataGaLocation":464},{"text":650,"config":662},{"dataGaName":652,"dataGaLocation":464,"id":653,"isOneTrustButton":93},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",{"featuredPost":668,"allPosts":696,"totalPages":892,"initialPosts":893},{"_path":669,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":670,"content":678,"config":689,"_id":692,"_type":16,"title":693,"_source":18,"_file":694,"_stem":695,"_extension":21},"/fr-fr/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"ogTitle":671,"schema":672,"ogImage":673,"ogDescription":674,"ogSiteName":675,"noIndex":6,"ogType":676,"ogUrl":677,"title":671,"canonicalUrls":677,"description":674},"Intégrez la conformité à vos workflows DevSecOps avec GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Frameworks de conformité personnalisés de GitLab : intégrez la conformité à vos workflows DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-30\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097104/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097104092.png","Découvrez comment les frameworks de conformité personnalisés de GitLab transforment vos exigences réglementaires en composants intégrés et automatisés dans vos workflows.\n","https://about.gitlab.com","article","https://about.gitlab.com/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"title":671,"description":679,"authors":680,"heroImage":673,"date":682,"body":683,"category":14,"tags":684},"Découvrez comment les frameworks de conformité personnalisés de GitLab transforment vos exigences réglementaires en composants intégrés et automatisés dans vos workflows.",[681],"Fernando Diaz","2025-04-30","La conformité n'est plus une formalité, mais un vecteur stratégique : elle aide à maîtriser les risques opérationnels, renforce la confiance des clients et améliore la performance globale. Pourtant, trouver l'équilibre entre exigences de conformité et vélocité peut s'avérer particulièrement complexe pour les équipes de développement logiciel. Les [frameworks de conformité personnalisés](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/) de GitLab apportent une réponse concrète à cette problématique en intégrant la vérification de la conformité directement dans vos workflows de développement. \n\nDécouvrez dans cet article tout ce que vous devez savoir sur les frameworks de conformité personnalisés de GitLab et comment les utiliser de façon optimale.\n\n## Qu’est-ce qu’un framework de conformité personnalisé ?\n\nLes frameworks de conformité personnalisés de GitLab vous permettent de définir, d'appliquer et de faire respecter vos propres normes de conformité directement dans votre instance GitLab. GitLab propose déjà des fonctionnalités de conformité « prêtes à l’emploi », mais chaque entreprise a ses propres obligations. Avec les frameworks personnalisés, vous pouvez donc définir vos propres stratégies de conformité en fonction de réglementations spécifiques, de vos politiques internes ou des normes de votre secteur.\n\nCes frameworks offrent les principaux avantages suivants : \n\n* Réduction significative du suivi manuel  \n* Accélération de la préparation aux audits  \n* Intégration native des contrôles de conformité\n\n![Capture d'écran du centre de conformité avec les frameworks répertoriés](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097114254.png)\n\nGitLab propose à ce jour plus de 50 contrôles préconfigurés, modifiables, que vous pouvez activer selon vos besoins. Ils couvrent un large éventail de réglementations, comme la loi HIPAA dans le domaine de la santé, le RGPD pour la protection des données, la [norme SOC 2](https://about.gitlab.com/fr-fr/the-source/security/how-gitlab-can-help-you-prepare-for-your-soc-2-exam/ \"Norme SOC 2\") relative aux prestataires de services et bien d'autres réglementations propres à des secteurs d'activité spécifiques. En voici quelques exemples :\n\n* Séparation des tâches : au moins deux approbateurs requis, y compris l'auteur de la merge request  \n* Scanners de sécurité : scans [SAST](https://docs.gitlab.com/user/application_security/sast/) et [analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/) exécutés automatiquement  \n* Authentification/autorisation : visibilité du projet définie sur privé et authentification unique (SSO) activée  \n* Configuration de l'application : vérification obligatoire des statuts de conformité et utilisation de fichiers de configuration Terraform exigée\n\nEn outre, vous pouvez étendre les capacités de conformité de GitLab en configurant vos propres contrôles sur des environnements externes à l'aide de l'API GitLab.\n\n## Comment créer un framework de conformité personnalisé dans GitLab ?\n\nMaintenant que nous avons clarifié l’importance des frameworks de conformité personnalisés, voyons comment les mettre en œuvre dans votre environnement GitLab, en utilisant l'application de démonstration reprise dans la vidéo ci-dessous. \n\n**Remarque :** un abonnement [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"Qu'est-ce que GitLab Ultimate ?\") est requis.\n\n\u003C!-- TODO: EMBED_YT_VIDEO -->\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB\" title=\"Adhering to compliance requirements with built-in compliance controls\n\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Étape 1 : définissez vos exigences de conformité**\n\nAvant de créer votre framework de conformité personnalisé, vous devez définir clairement vos exigences en la matière :\n\n1. **Identifiez les réglementations applicables :** déterminez les obligations légales et normes qui s'appliquent à votre entreprise (par exemple, le RGPD, la norme PCI DSS ou la loi HIPAA). \n2. **Associez les exigences à des contrôles :** décomposez chaque exigence réglementaire identifiée en contrôles spécifiques et exploitables.  \n3. **Hiérarchisez les exigences :** concentrez vos efforts sur les domaines à haut risque et les exigences à fort impact.\n\n**Étape 2 : créez votre framework de conformité personnalisé dans GitLab**\n\nVoici comment procéder :\n\n1. Accédez à la section **Sécurisation > Centre de conformité** de votre groupe GitLab.  \n2. Cliquez sur le bouton **Nouveau framework**.  \n3. Sélectionnez **Créer un framework vide**.\n\n![Écran de création d'un framework de conformité personnalisé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097114255.png)\n\n4. Renseignez son nom, sa description et choisissez sa couleur.\n\n![Écran Nouveau framework de conformité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097114257.png)\n\n5. Ajoutez des exigences :\\\n   a. Accédez à l'onglet **Exigences**.\n\n   b. Cliquez sur le bouton **Nouvelle exigence**.\n\n   c. Fournissez un nom et une description.\\\n   d. Dans la section **Contrôles**, sélectionnez **Choisir un contrôle GitLab**.\\\n   e. Sélectionnez un contrôle dans la liste (par exemple, au moins deux approbations, l'exécution de scans SAST).\\\n   f. Cliquez ensuite sur le bouton **Créer une exigence**.\n\n![Bouton Créer une exigence](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097114258.png)\n\n6. Cliquez sur le bouton **Créer un framework**.\n\nUne fois créé, ce framework pourra être appliqué à vos projets selon les paramètres définis. Par ailleurs, GitLab permet également d'importer des frameworks de conformité au format JSON, selon le schéma prévu.\n\n**Étape 3 : appliquez le framework à vos projets**\n\nUne fois votre framework de conformité créé, suivez les étapes ci-dessous pour l’appliquer à un ou plusieurs projets :\n\n1. Accédez au **Centre de conformité** de GitLab, puis sélectionnez l'onglet **Projets**.  \n2. Utilisez la barre de recherche pour **Rechercher** ou **Filtrer** les projets concernés.  \n3. Sélectionnez le ou les projets dans la liste.  \n4. Cliquez sur le bouton **Choisir une action groupée**.  \n5. Sélectionnez **Appliquer les frameworks aux projets sélectionnés**.  \n6. Cliquez sur le bouton **Sélectionner des frameworks**.  \n7. Sélectionnez le ou les frameworks de votre choix dans la liste.  \n8. Cliquez sur le bouton **Appliquer**.\n\n![Écran du Centre de conformité avec la liste déroulante affichant le framework SOC 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097114260.png)\n\nUne fois cette opération effectuée, le framework sélectionné est associé aux projets choisis. Les exigences définies sont alors visibles et peuvent être vérifiées directement dans l'interface GitLab.\n\n**Étape 4 : surveillez et générez des rapports de conformité**\n\nUne fois votre framework de conformité en place, GitLab vous offre un suivi continu et centralisé dans le **Centre de conformité** :\n\n1. Suivez le statut de conformité de vos projets, y compris les détails sur les contrôles appliqués, ainsi que des correctifs suggérés pour les contrôles ayant échoué.\n2. Générez des **rapports de conformité** pour les audits et l'examen par les parties prenantes.  \n3. Configurez des **alertes de conformité** pour informer les parties prenantes des problèmes de conformité potentiels. \n4. Consultez les **événements d'audit** pour une vue d'ensemble des mesures prises concernant les paramètres de conformité.\n\n![Écran du Centre de conformité affichant le framework de test SOC 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097114263.png)\n\n## Exemple : mise en œuvre d'un framework de conformité SOC 2\n\nLe SOC 2 (System and Organization Controls 2), développée par l'American Institute of Certified Public Accountants, est une norme d'audit rigoureuse qui évalue les contrôles mis en œuvre par les prestataires de services en matière de sécurité, de disponibilité, d'intégrité du traitement des données, de confidentialité et de protection des données personnelles. Pour en savoir plus, consultez le [guide sur le respect des exigences de sécurité SOC 2 avec GitLab](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/).\n\nVoici un exemple concret d'implémentation d'un framework de conformité personnalisé GitLab dont l'objectif est de vérifier la conformité à la norme de sécurité SOC 2 à l’aide des contrôles GitLab préconfigurés suivants :\n\n* Contrôles contre les accès non autorisés  \n* Procédures d'identification et d'atténuation des risques  \n* Systèmes de détection et de gestion des incidents de sécurité\n\n**Avertissement :** il ne s'agit là que d'un exemple qui illustre certains des contrôles possibles pour vérifier l'adhésion à la norme SOC 2. Avant toute mise en production, validez votre configuration avec votre équipe sécurité ou conformité.\n\nCe framework se présentera comme suit :\n\n* **Nom :** Exigences de sécurité SOC 2  \n* **Description :** Ajout des exigences de sécurité pour la conformité au framework SOC 2  \n* **Exigences :**  \n\n  * **Contrôles contre les accès non autorisés**  \n\n    * Authentification SSO activée  \n    * Portée des tokens pour les jobs CI/CD activée \n    * Authentification multifacteur requise au niveau de l'entreprise\n* **Procédures d'identification et d'atténuation des risques**   \n\n  * Au moins deux approbations requises avant tout merge \n  * Merge request approuvée par l'auteur      \n  * Merge request approuvée par les validateurs \n  * Branche par défaut protégée    \n* **Systèmes de détection et de gestion des incidents de sécurité**  \n\n  * Analyse des dépendances activée  \n  * SAST activé \n  * DAST activé\n\nLorsqu'il est appliqué à vos projets, ce framework vous permet de surveiller toute erreur de conformité et d'identifier les corrections envisageables. Notez que vous pouvez associer plusieurs frameworks de conformité à vos projets, par exemple, pour couvrir les exigences d'intégrité des processus SOC 2.\n\n## Comment définir des stratégies de sécurité en accord avec les exigences de conformité ?\n\nBien que cet aspect ne soit pas obligatoire, il est fortement recommandé d'appliquer des stratégies de sécurité aux projets associés à un framework de conformité personnalisé. Cette approche garantit que les exigences de conformité critiques sont correctement appliquées de manière automatisée et cohérente dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"). Par exemple, si votre framework de conformité personnalisé impose que des scans de sécurité soient exécutés sur chaque pipeline, une stratégie de sécurité peut en forcer l’exécution.\n\nGitLab fournit différentes stratégies de sécurité pour répondre aux différents objectifs de sécurité et de conformité :\n\n* [Stratégie d'exécution des scans](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/) : impose l'exécution de scans de sécurité dans les pipelines ou selon un calendrier précis.  \n* [Politique d'approbation des merge requests](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) : définit des paramètres et règles d'approbation au niveau du projet en fonction des résultats des scans.  \n* [Stratégie d'exécution de pipeline](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) : force l'exécution de jobs CI/CD spécifiques dans les pipelines. \n* [Stratégie de gestion des vulnérabilités](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/) : corrige automatiquement les vulnérabilités afin qu’elles soient supprimées de la branche par défaut.\n\nSi votre framework de conformité personnalisé exige l'exécution de scans SAST, voici comment créer une stratégie de sécurité pour en garantir l’exécution automatique :\n\n1. Accédez à un projet qui dispose d'un framework de conformité personnalisé incluant les **scans SAST**. \n2. Dans la barre latérale du projet, sélectionnez **Sécurisation > Politiques**.\n3. Cliquez sur le bouton **Nouvelle stratégie**.  \n4. Dans la section **Stratégie d'exécution des scans**, cliquez sur le bouton **Sélectionner une stratégie**. \n5. Renseignez le **Nom** et la **Description**. \n6. Dans la section **Actions**, sélectionnez **SAST** comme type de scan à exécuter.\n\n![Écran des actions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097114264.png)\n\n7. Dans la section **Conditions**, sélectionnez tous les pipelines, quelle que soit la branche.\n\n![Écran des conditions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097114265.png)\n\n8. Cliquez sur le bouton **Configurer avec une merge request**.  \n9. Une merge request est alors créée dans un projet distinct dédié aux stratégies de sécurité appliquées à ce projet.\n10. Cliquez sur le bouton **Fusionner**.\n\nDésormais, les scans SAST s'exécuteront automatiquement sur toutes les branches du projet afin de garantir le respect continu des exigences de conformité. Nous vous conseillons de parcourir les autres types de stratégies de sécurité pour identifier celles qui répondent le mieux à vos besoins.\n\n## 5 bonnes pratiques pour des frameworks de conformité efficaces\n\nPour tirer pleinement parti des frameworks de conformité personnalisés de GitLab, nous vous conseillons de suivre les principes suivants :\n\n1. **Avancez pas à pas :** commencez par une seule réglementation ou norme critique avant d'aller plus loin.  \n2. **Impliquez les principales parties prenantes :** incluez les équipes de conformité, de sécurité et de développement dans la création du framework.  \n3. **Automatisez dans la mesure du possible :** utilisez GitLab CI/CD pour automatiser les contrôles de conformité.  \n4. **Documentez minutieusement votre approche :** conservez une documentation claire du lien entre chaque exigence réglementaire et les contrôles GitLab mis en place.  \n5. **Révisez régulièrement vos frameworks :** mettez à jour vos frameworks à mesure que les réglementations évoluent ou que de nouvelles exigences sont nécessaires.\n\n## Lancez-vous dès aujourd'hui\n\nLes frameworks de conformité personnalisés de GitLab marquent une avancée majeure pour intégrer la conformité directement dans le workflow de développement DevSecOps. En les adoptant, vous réduisez les frais liés à la conformité, améliorez votre gestion des risques et accélérez vos cycles de développement logiciel, tout en garantissant la meilleure conformité possible aux exigences réglementaires.\n\nGrâce à cette approche, vos équipes bénéficient à la fois de la flexibilité dont elles ont besoin pour répondre aux exigences réglementaires et de la structure indispensable pour garantir des pratiques de conformité cohérentes dans l'ensemble de l'entreprise.\n\nDans un contexte réglementaire de plus en plus exigeant, des outils comme les frameworks de conformité personnalisés de GitLab sont essentiels pour traiter la conformité comme un processus continu, sans compromettre la vélocité de développement.\n\n> Lancez-vous dès aujourd'hui avec un [essai gratuit de 60 jours de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/).\n\nPour en savoir plus, consultez nos ressources connexes :\n\n* [Documentation sur les frameworks de conformité personnalisés](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)\n* [Epic sur les frameworks de conformité personnalisés](https://gitlab.com/groups/gitlab-org/-/epics/13295)\n* [Documentation sur les stratégies de sécurité](https://docs.gitlab.com/user/application_security/policies/)\n* [Solutions de sécurité et de conformité de GitLab](https://about.gitlab.com/fr-fr/solutions/security-compliance/)",[14,685,686,687,688],"tutorial","DevSecOps platform","features","product",{"slug":690,"featured":93,"template":691},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","BlogPost","content:fr-fr:blog:how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","How To Use Gitlabs Custom Compliance Frameworks In Your Devsecops","fr-fr/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","fr-fr/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",[697,719,740,760,783,804,824,845,868],{"_path":698,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":699,"content":705,"config":713,"_id":715,"_type":16,"title":716,"_source":18,"_file":717,"_stem":718,"_extension":21},"/fr-fr/blog/enhance-application-security-with-gitlab-hackerone",{"title":700,"description":701,"ogTitle":700,"ogDescription":701,"noIndex":6,"ogImage":702,"ogUrl":703,"ogSiteName":675,"ogType":676,"canonicalUrls":703,"schema":704},"GitLab + HackerOne : pour une sécurité applicative renforcée","Découvrez le partenariat entre GitLab et HackerOne et comment cette intégration peut vous aider à renforcer la sécurité de vos applications.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097503/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2810%29_5ET24Q6i8ihqrAOkge7a1R_1750097503214.png","https://about.gitlab.com/blog/enhance-application-security-with-gitlab-hackerone","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab + HackerOne : pour une sécurité applicative renforcée\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-03\",\n      }",{"title":700,"description":701,"authors":706,"heroImage":702,"date":707,"body":708,"category":14,"tags":709,"updatedDate":712},[681],"2025-04-03","La sécurité doit désormais être intégrée dès le début du processus de développement. Les entreprises ont besoin de solutions robustes qui intègrent la sécurité à chaque étape du cycle de développement logiciel. Le partenariat entre HackerOne et GitLab offre une combinaison gagnante pour les équipes de développement d'applications modernes.\n\nGitLab, la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que l'approche DevSecOps ? \") complète et alimentée par l'IA, s'associe à HackerOne, leader de la sécurité collaborative, pour combiner le meilleur des deux univers : les workflows DevSecOps rationalisés de GitLab et les puissantes capacités de gestion des vulnérabilités de HackerOne.\n\nDécouvrez dans ce tutoriel comment améliorer la productivité de vos équipes de développement et renforcer votre posture de sécurité grâce à l'intégration de GitLab à HackerOne.\n\n## Une intégration pensée pour les développeurs\n\nL'intégration de GitLab à la plateforme de cybersécurité HackerOne est aussi simple à mettre en œuvre que puissante. Lorsqu'un chercheur en cybersécurité détecte une vulnérabilité via la plateforme HackerOne, celle-ci est automatiquement convertie en un ticket GitLab. \n\nCe workflow permet de :\n\n* détecter les vulnérabilités sur la plateforme HackerOne\n* créer automatiquement des tickets GitLab à partir des vulnérabilités validées\n* permettre aux équipes de développement de traiter ces tickets directement dans leur workflow existant\n* synchroniser le statut de résolution de ces vulnérabilités entre les deux plateformes\n\nVous pouvez tirer parti de cette [intégration](https://docs.hackerone.com/en/articles/8571227-gitlab-integration) en liant les tickets GitLab aux rapports HackerOne comme références. Cette synchronisation bidirectionnelle et fluide des données entre vos rapports HackerOne et les tickets GitLab améliore ainsi la coordination entre les équipes de développement et de sécurité tout en rationalisant le traitement des failles de sécurité.\n\nPour configurer cette intégration, référez-vous aux instructions détaillées de la [documentation HackerOne dédiée à l'intégration GitLab](https://docs.hackerone.com/en/articles/10394699-gitlab-setup), dont voici les principales étapes :\n\n1. [Créez une application OAuth 2.0](https://docs.gitlab.com/ee/integration/oauth_provider.html) pour votre instance GitLab à l'aide des paramètres fournis par HackerOne\n2. Connectez la plateforme HackerOne à votre instance GitLab en utilisant cette application OAuth 2.0\n3. Autorisez HackerOne à accéder à l'API GitLab\n4. Configurez le projet GitLab vers lequel vous souhaitez transférer les rapports HackerOne \n5. Sélectionnez les champs HackerOne à mapper aux champs GitLab correspondants\n6. Définissez les événements à synchroniser, de GitLab vers HackerOne et de HackerOne vers GitLab\n\nUne fois l'intégration mise en place, la synchronisation bidirectionnelle des données entre GitLab et HackerOne devient fluide, réduisant les changements de contexte et facilitant le suivi des vulnérabilités sur les deux systèmes. \n\nLes principales fonctionnalités de cette intégration sont les suivantes :\n\n* **Création de tickets GitLab depuis HackerOne** : créez de nouveaux tickets GitLab à partir des rapports que vous recevez dans HackerOne.\n* **Connexion des rapports HackerOne aux tâches GitLab existantes.**   \n* **Synchronisation des mises à jour apportées aux rapports HackerOne vers GitLab** : les informations suivantes sont envoyées sous forme de commentaires dans le ticket GitLab correspondant.\n  * Commentaires du rapport  \n  * Changements d'état  \n  * Récompenses  \n  * Changements d'assignation  \n  * Divulgation publique  \n  * Fermeture du ticket GitLab  \n* **Synchronisation des mises à jour de GitLab vers HackerOne** : lorsque certaines actions sont effectuées dans un ticket GitLab, ces mises à jour sont reprises automatiquement dans le rapport correspondant sur HackerOne, sous forme de commentaire interne :\n  * Commentaires  \n  * Changements d'état  \n* **Mappage des niveaux de gravité HackerOne avec les labels GitLab** : définissez une priorité personnalisée lorsque vous transférez un rapport HackerOne vers GitLab.  \n* **Mappage des dates d'échéance** : définissez automatiquement une date d'échéance personnalisée dans GitLab en fonction du niveau de gravité du rapport HackerOne.\n\n![GitLab + HackerOne : Ajouter des commentaires ou modifier l'état du rapport dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/sync_aHR0cHM6_1750097509644.png)\n\nCes fonctionnalités renforcent la coordination entre les équipes de développement et de sécurité et rationalisent le traitement des failles de sécurité. Pour en savoir plus sur le fonctionnement de l'intégration, consultez la [documentation](https://docs.hackerone.com/en/articles/8571227-gitlab-integration) fournie par HackerOne.\n\n## Aperçu des programmes de bug bounty de HackerOne\n\nHackerOne propose des programmes de bug bounty, c'est-à-dire des initiatives en matière de cybersécurité qui récompensent la découverte et le signalement de vulnérabilités dans les systèmes logiciels, les sites web ou les applications de ses clients. Ces programmes contribuent à renforcer la sécurité des applications en :\n\n* identifiant les failles de sécurité avant que des acteurs malveillants ne puissent les exploiter\n* tirant parti de l'expertise diversifiée d'une communauté mondiale de chercheurs en cybersécurité\n* offrant un moyen rentable d'améliorer la cybersécurité\n* complétant les efforts de sécurité internes et les tests de pénétration traditionnels\n\nGitLab s'appuie sur le programme de bug bounty de HackerOne pour permettre aux chercheurs en cybersécurité de signaler les vulnérabilités présentes dans ses applications ou son infrastructure. Cette approche collaborative aide GitLab à identifier et à résoudre plus efficacement les potentielles failles de sécurité.\n\n![Page du programme de bug bounty de GitLab de HackerOne](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/hackerone_gitlab_bug_bounty_page_aHR0cHM6_1750097509645.png)\n\nEn tirant parti de la plateforme HackerOne et de la communauté mondiale de hackers éthiques, les entreprises peuvent considérablement renforcer leur posture de sécurité, identifier plus rapidement les vulnérabilités et garder une longueur d'avance sur les menaces potentielles.\n\n## Sécurisez vos applications et améliorez votre productivité avec GitLab\n\nGitLab offre une plateforme DevSecOps complète, qui intègre des fonctionnalités couvrant l'ensemble du cycle de développement logiciel, y compris des outils de [sécurité et de conformité](https://about.gitlab.com/fr-fr/solutions/security-compliance/ \"Sécurité et conformité GitLab\"). GitLab prend en charge les types de scanners de sécurité suivants :\n- Tests statiques de sécurité des applications (SAST)\n- Tests dynamiques de sécurité des applications (DAST)\n- Analyse des conteneurs\n- Analyse des dépendances\n- Analyse de l'Infrastructure as Code (IaC)\n- Fuzzing guidé par la couverture de code\n- Test de l’API web par injection de données aléatoires\n\nAvec GitLab, vous pouvez simplement appliquer un template à votre fichier de définition de [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") pour activer un scanning de sécurité. Par exemple, l'activation de SAST ne nécessite que quelques lignes de code dans le fichier `.gitlab-ci.yml` :\n\n```yaml\nstage:\n  - test\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nCela exécutera SAST à l'étape de test et [détectera automatiquement les langages utilisés](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) dans votre application. Ainsi, chaque fois que vous créez une merge request, SAST analyse les différences entre la branche de fonctionnalité et la branche cible pour détecter les vulnérabilités et fournit des données précises sur chaque faille de sécurité afin d'en faciliter la correction.\n\n![Vulnérabilité d'injection NoSQL détectée dans une MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750097509647.png)\n\nLes résultats du scanner SAST peuvent bloquer le merge du code si des stratégies de sécurité sont appliquées. Les utilisateurs natifs de GitLab peuvent être définis comme approbateurs, ce qui permet d'effectuer les revues requises avant de fusionner du code non sécurisé. Cela garantit que toutes les vulnérabilités sont surveillées par les parties concernées.\n\n![Stratégie d'approbation des merge requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750097509649.png)\n\nHackerOne a intégré GitLab à ses processus opérationnels et à ses processus de développement de manière stratégique, ce qui lui a permis de les rendre plus fluides et plus efficaces, à grande échelle, et de renforcer la collaboration entre les équipes. Parmi ces améliorations, HackerOne profite désormais de déploiements plus rapides et d'une planification inter-équipes performante.\n\n## Principaux avantages d'intégrer GitLab à HackerOne\n\nL'utilisation conjointe de HackerOne et GitLab offre les avantages suivants :\n\n* **Visibilité accrue en matière de sécurité** : les équipes de développement bénéficient d'un accès immédiat aux failles de sécurité sans quitter leur environnement de workflow principal. Cette visibilité en temps réel aide les équipes à prioriser les problèmes de sécurité parallèlement au développement des fonctionnalités.\n* **Processus de correction rationalisé** : en convertissant automatiquement les rapports HackerOne en tickets GitLab, le processus de correction des vulnérabilités s'intègre naturellement au cycle de développement standard. Cela évite les changements de contexte entre les plateformes et garantit des correctifs de sécurité en parallèle des autres tâches de développement.\n* **Temps de correction réduit** : l'intégration raccourcit considérablement le délai entre la détection d'une vulnérabilité et sa résolution. Les soumissions de vulnérabilités dans HackerOne étant immédiatement disponibles dans GitLab, les équipes de développement peuvent réagir sans délai et renforcer ainsi la posture de sécurité globale.\n* **Collaboration améliorée** : cette intégration fluidifie les échanges entre les chercheurs en cybersécurité, les équipes de sécurité et de développement. Les commentaires et mises à jour circulent entre les deux plateformes, créant ainsi un environnement collaboratif axé sur le renforcement de la sécurité.\n* **Impact réel** : les entreprises qui ont opté pour l'intégration HackerOne + GitLab ont constaté les améliorations suivantes :\n    * Une réduction pouvant atteindre 70 % du temps nécessaire entre l'identification d'une vulnérabilité et sa correction\n    * Une satisfaction accrue des équipes de développement, qui peuvent continuer à travailler dans leur environnement préféré\n    * Une visibilité accrue de la sécurité à l'échelle de l'entreprise\n    * Une allocation plus efficace des ressources de sécurité\n\n## En savoir plus sur GitLag + HackerOne \n\nPour en savoir plus sur GitLab et HackerOne, et découvrir comment nous pouvons vous aider à renforcer votre posture de sécurité, consultez les ressources suivantes :\n\n* [Utilisation de l'intégration GitLab sur HackerOne](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)\n* [Programme de Bug Bounty de GitLab sur HackerOne](https://hackerone.com/gitlab?type=team)\n* [Solutions de sécurité et de conformité de GitLab](https://about.gitlab.com/fr-fr/solutions/security-compliance/)\n* [HackerOne réalise des déploiements 5  fois plus rapides avec la sécurité intégrée de GitLab](https://about.gitlab.com/fr-fr/customers/hackerone/) \n* [Documentation sur la sécurité des applications GitLab](https://docs.gitlab.com/ee/user/application_security/)\n",[14,685,236,287,686,710,711],"DevSecOps","bug bounty","2025-05-13",{"slug":714,"featured":6,"template":691},"enhance-application-security-with-gitlab-hackerone","content:fr-fr:blog:enhance-application-security-with-gitlab-hackerone.yml","Enhance Application Security With Gitlab Hackerone","fr-fr/blog/enhance-application-security-with-gitlab-hackerone.yml","fr-fr/blog/enhance-application-security-with-gitlab-hackerone",{"_path":720,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":721,"content":727,"config":734,"_id":736,"_type":16,"title":737,"_source":18,"_file":738,"_stem":739,"_extension":21},"/fr-fr/blog/the-ultimate-guide-to-token-management-at-gitlab",{"ogTitle":722,"schema":723,"ogImage":724,"ogDescription":725,"ogSiteName":675,"noIndex":6,"ogType":676,"ogUrl":726,"title":722,"canonicalUrls":726,"description":725},"Gestion des tokens sur GitLab : guide complet","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Guide complet pour la gestion des tokens sur GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hakeem Abdul-Razak\"}],\n        \"datePublished\": \"2025-02-25\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097408/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750097407860.jpg","Découvrez le processus de gestion, d'identification et de sécurisation des tokens et renforcez votre sécurité tout au long du cycle de développement logiciel.","https://about.gitlab.com/blog/the-ultimate-guide-to-token-management-at-gitlab",{"heroImage":724,"body":728,"authors":729,"updatedDate":731,"date":732,"title":722,"tags":733,"description":725,"category":14},"Imaginez le scénario suivant : un ingénieur travaille dans une entreprise technologique en pleine croissance et reçoit un appel urgent à 2 heures du matin. Un pipeline de déploiement critique a échoué, et son équipe essaie de comprendre les raisons de cet échec. Après des heures d'investigation, il réalise qu'un utilisateur a révoqué le jeton d'accès personnel d'un ingénieur qui a quitté l'entreprise une semaine plus tôt. Ce token étant lié à plusieurs processus d'automatisation clés, votre système est maintenant dans un état catastrophique. Comment faire en sorte que cette situation ne se reproduise plus ?\n\nDécouvrez dans cet article toutes les étapes de la gestion des tokens, de leur identification à leur sécurisation. Ce guide complète notre [documentation officielle sur les tokens](https://docs.gitlab.com/ee/security/tokens) et s'adresse aux administrateurs GitLab, aux équipes de développement et de sécurité qui doivent garantir une gestion efficace et sécurisée des tokens dans le cadre de leurs projets.\n\n## Sélection du token adapté au job\n\nChoisir le bon token garantit à la fois la sécurité et des fonctionnalités optimales selon votre cas d'utilisation. Les tokens peuvent servir à authentifier des requêtes API, à automatiser des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), à intégrer des outils tiers, à gérer des déploiements, à accéder aux dépôts et bien plus encore.\n\n![Guide de gestion des tokens - organigramme des jetons](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097434869.png)\n\nLe graphique ci-dessus illustre un cas d'utilisation classique lié à la propriété d'un seul utilisateur. Pour plus d'informations, consultez notre documentation sur les rôles et autorisations des utilisateurs dans chaque [espace de nommage](https://docs.gitlab.com/ee/user/permissions.html) (utilisateur/groupe) au sein de votre instance ou groupe principal.\n\nVoici quelques exemples d'utilisation :\n\n* Les **jetons d'accès personnel** ([PAT](https://docs.gitlab.com/user/profile/personal_access_tokens/#personal-access-token-scopes)) peuvent être utilisés lorsque l'accès personnel et les autorisations d'un utilisateur sont requis. Dans ce cas, les identifiants de connexion suivent le statut et les autorisations du compte de l'utilisateur, y compris sa révocation si le compte perd l'accès à un projet ou à un groupe spécifique (ou est entièrement bloqué).\n\n* Les **tokens d'accès au projet/groupe** ([PrAT](https://docs.gitlab.com/user/project/settings/project_access_tokens/#scopes-for-a-project-access-token) / [GrAT](https://docs.gitlab.com/user/group/settings/group_access_tokens/#scopes-for-a-group-access-token)) sont recommandés lorsque l'accès doit être limité aux ressources d'un projet/groupe spécifique. Ainsi, tout utilisateur disposant d'un PrAT/GrAT peut accéder à ces ressources via des mécanismes gérés par des portées attribuées.\n\n## Types de tokens\n\nVoici la liste des tokens GitLab, avec leurs préfixes par défaut et le principal cas d'utilisation associé. Pour plus de détails, consultez la [page de présentation des tokens GitLab](https://docs.gitlab.com/ee/security/tokens/#available-scopes).\n\n| Tokens                            | Préfixe | Description |\n| --------------------------------- | ------- | ----------- |\n| Jeton d'accès personnel           | glpat   | Accès aux données propres à l'utilisateur |\n| Token OAuth 2.0                   | gloas   | Authentification à l'aide du protocole OAuth2.0 pour des intégrations tierces |\n| Token d'emprunt d'identité        | glpat   | Possibilité d'agir au nom d'un autre utilisateur à des fins d'administration |\n| Token d'accès au projet           | glpat   | Accès aux données d'un projet spécifique |\n| Token d'accès au groupe           | glpat   | Accès aux données d'un groupe spécifique |\n| Token de déploiement              | gldt    | Accès aux images d'un registre de conteneurs pour cloner ou effectuer un push/pull sans identifiants utilisateur ni mot de passe |\n| Clés de déploiement               | N/A     | Accès en lecture seule ou en lecture-écriture aux dépôts |\n| Token d'accès au runner           | glrt    | Authentification des GitLab Runners |\n| Token de job CI/CD                | glcbt   | Automatisation des processus CI/CD |\n| Token de déclenchement            | glptt   | Déclenchement manuel ou automatique des pipelines |\n| Token de flux                     | glft    | Authentification de l'accès aux flux de paquets/RSS |\n| Token d'e-mail entrant            | glimt   | Traitement des e-mails entrants |\n| Token GitLab Agent for Kubernetes | glagent | Gestion des clusters [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\") via GitLab Agent |\n| Tokens SCIM                       | glsoat  | Activation des intégrations SCIM pour le provisionnement des utilisateurs |\n| Token client pour feature flags   | glffct  | Activation automatisée des feature flags |\n| Token de webhook                  | N/A     | Token de secret défini par l'utilisateur pour sécuriser les charges utiles des webhooks et vérifier que les requêtes proviennent de GitLab |\n\n## Identification des tokens utilisés\n\n### Inventaire des identifiants de connexion\n\nAvec GitLab Ultimate, les administrateurs (GitLab Self-Managed) et les propriétaires de groupe principal (GitLab.com, à partir de la version 17.5) peuvent surveiller les identifiants de connexion dans leur espace de nommage.\n\nCet inventaire permet de suivre les détails des tokens, notamment :\n\n* Le type de tokens\n* Les tokens disponibles sur [GitLab.com](https://docs.gitlab.com/ee/user/group/credentials_inventory.html)\n* Les tokens disponibles sur [GitLab Self-Managed](https://docs.gitlab.com/ee/administration/credentials_inventory.html)\n* Les comptes utilisateurs associés\n* Les portées des tokens, ainsi que leur date de création et d'expiration\n* Les adresses IP des derniers tokens utilisés (à partir de GitLab 17.10)\n* Le filtrage des tokens en fonction des paramètres définis par l'utilisateur\n* La possibilité de révoquer et de procéder à une rotation de ces tokens\n\nTenir correctement un inventaire des identifiants de connexion permet d'identifier les tokens avec des autorisations excessives et ceux dont la rotation est requise, ce qui garantit un workflow sécurisé et efficace.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/A9ONfnwswd0?si=4VIEUgJaD4daj81b&start=105\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n#### API dédiée pour l'inventaire des identifiants\n\nEn complément de l'interface utilisateur, une API d'inventaire des identifiants de connexion permet d’accéder à cet inventaire via le nouveau [point de terminaison](https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project) /group/:id/manage. Les identifiants de connexion accessibles sous ce point de terminaison sont réservés aux [comptes utilisateurs Entreprise](https://docs.gitlab.com/ee/user/enterprise_user/) ayant souscrit un abonnement GitLab. Ils ne peuvent être consultés que par le propriétaire du groupe principal du projet de l'entreprise concernée.\n\nVoici à quoi pourrait ressembler un appel API à l'avenir :\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cpat>\"\ncurl --header \"PRIVATE-TOKEN: \u003Cpat>\" \"https://verified_domain.com/api/v4/groups/\u003Cgroup_id>/manage/personal_access_tokens\"\n```\n\n### API GitLab\n\nL'API GitLab vous permet de répertorier et de gérer les tokens automatiquement (à l'aide de scripts ou d'applications) au sein de votre entreprise. Les points de terminaison clés liés à l'authentification prennent en charge [différents types de tokens](https://docs.gitlab.com/ee/api/rest/authentication.html), notamment les jetons d'accès personnel, les tokens d'accès au groupe, les tokens de job CI/CD, entre autres. Voici un exemple d'utilisation d'un jeton d'accès personnel qui répertorie tous les projets visibles sur GitLab pour l'utilisateur authentifié :\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cyour_access_token>\" \"https://gitlab.example.com/api/v4/projects\"\n```\n\nRegardez cette vidéo et découvrez comment effectuer des appels à l'API GitLab.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0LsMC3ZiXkA?si=vj871YH610jwQdFc\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n### Identification de l’utilisation des tokens\n\nVous pouvez identifier de différentes manières les emplacements ou les contextes dans lesquels les tokens sont utilisés :\n\n* Depuis **Paramètres utilisateur > [Jetons d'accès](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used)**\n* Dans l'inventaire des identifiants de connexion\n* Dans les événements d'audit\n* Via l'API\n\nLes informations sur l'utilisation des tokens sont mises à jour toutes les 10 minutes pour **last_used** et toutes les minutes pour **last_used_ip**.\n\nLa possibilité d'afficher les adresses IP a été introduite dans GitLab 17.9 et est contrôlée par le feature flag **:pat_ip**. Suivez ces [étapes pour afficher la dernière fois où un token a été utilisé](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used), ainsi que ses cinq dernières adresses IP distinctes.\n\n![Guide de gestion des tokens - paramètres des jetons d'accès personnels](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097434870.png)\n\n## Gestion des tokens dans l'API et l'interface utilisateur de GitLab\n\nLe tableau suivant répertorie des vidéos qui présentent plusieurs créations de tokens dans l'interface utilisateur et leur utilisation via l'API.\n\n| Tokens                  | UI GitLab | API GitLab |\n| ----------------------- | --------- | ---------- |\n| Jeton d'accès personnel | [Documentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=3) | [Documentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=43) |\n| Token d'accès au groupe | [Documentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#group-access-tokens) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=120) | [Documentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=157) |\n| Token d'accès au projet | [Documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#project-access-tokens) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=254) | [Documentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=285) |\n\n## Gestion de la rotation et de l'expiration des tokens\n\nLa mise en œuvre d'une rotation des tokens et de règles d'expiration strictes permet de réduire les risques de compromission et de garantir la conformité aux normes de sécurité. Une rotation régulière et des expirations contrôlées empêchent que les identifiants de connexion obsolètes ne deviennent des failles de sécurité.\n\nAuparavant, les tokens d'accès au groupe et au projet arrivés à expiration étaient automatiquement supprimés, ce qui compliquait les audits et les analyses de résultats des scans de sécurité en raison de l'absence d'historique de ces tokens inactifs. Pour remédier à ce problème, une [fonctionnalité](https://gitlab.com/gitlab-org/gitlab/-/issues/462217) a introduit la conservation dans l'interface utilisateur des enregistrements de tokens d'accès au groupe et au projet inactifs pendant 30 jours après leur expiration. Cette amélioration permet aux équipes de suivre l'utilisation, l'expiration et la révocation des tokens et offre ainsi une meilleure conformité et un meilleur contrôle.\n\nPour gérer de manière proactive la rotation et l'expiration de vos tokens, procédez comme suit :\n\n* Régénérez activement vos tokens via l'interface utilisateur ou l'API. Si vous utilisez l'API, tenez compte du mécanisme de sécurité de [détection automatique de la réutilisation des tokens](https://docs.gitlab.com/ee/api/personal_access_tokens.html#automatic-reuse-detection).\n\n* Définissez une [limite de durée de validité maximale](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-access-tokens) à l'échelle de l'instance pour les tokens d'accès.\n\n### API de rotation des tokens\n\nJusqu'à la version GitLab 17.7, les utilisateurs devaient effectuer une rotation automatique des tokens d'accès exclusivement via l'API. Cette fonctionnalité est maintenant disponible dans l'interface utilisateur. Pour en savoir plus, regardez les vidéos dans le tableau ci-dessous ou consultez notre [documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#use-the-ui).\n\n### Extraits de code pour la rotation des tokens\n\nLe tableau suivant regroupe des vidéos expliquant le processus de rotation des tokens dans GitLab.\n\n| Tokens                  | Prérequis | UI GitLab | API GitLab |\n| ----------------------- | --------- | --------- | ---------- |\n| Jeton d'accès personnel | Portée : API | [Documentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=76) | [Documentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html#rotate-a-personal-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=92) |\n| Token d'accès au groupe | Portée : API et rôle(s) : propriétaire | [Documentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#create-a-group-access-token-using-ui) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=203) | [Documentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=214) |\n| Token d'accès au projet | Portée : API et rôle(s) : propriétaire, chargé de maintenance | [Documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=335) | [Documentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=349) |\n\n## Bonnes pratiques de gestion des tokens\n\n### Principe de moindre privilège\n\nAtténuez les risques en limitant les autorisations attribuées aux tokens à celles strictement nécessaires à leurs tâches respectives. Vous pourrez ainsi anticiper et résoudre de manière proactive les points de défaillance de vos systèmes.\n\nPour ce faire, procédez comme suit :\n\n* Sélectionnez le token adapté au job. Consultez l'organigramme en cas de besoin.\n* Attribuez uniquement les portées nécessaires lors de la création d'un token. Par exemple, utilisez des portées en lecture seule pour les tokens employés à des fins d'audit. Consultez notre documentation sur les [rôles](https://docs.gitlab.com/ee/user/permissions.html#roles).\n* Évitez d'accorder des privilèges d'administrateur, sauf si cela est explicitement requis.\n* Appliquez une [durée de validité](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-a-lifetime-1) par défaut à l'échelle de l'instance.\n* Examinez et auditez régulièrement les autorisations octroyées aux tokens pour vous assurer de leur adéquation avec les besoins opérationnels actuels.\n* Révoquez les tokens une fois leur tâche terminée.\n\n\n\n### Comptes de service\n\nLes [comptes de service](https://docs.gitlab.com/ee/user/profile/service_accounts.html) associent les tokens à des entités non humaines, ce qui permet de les distinguer des comptes d'utilisateurs et de réduire la dépendance à des utilisateurs spécifiques. Au lieu d'utiliser des comptes personnels pour générer des tokens à des fins d'automatisation, créez des comptes de service avec des portées limitées.\n\nVoici les principaux avantages :\n\n* Utilisation de tokens de compte de service dans les pipelines CI/CD pour éviter les perturbations causées par les modifications de compte d'utilisateur\n* Automatisation des processus de rotation, sans impact sur les comptes personnels\n* Suivi ciblé et piste d'audit plus clairs des actions entreprises par les comptes de service\n* Comptes de service [sans date d'expiration](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-service-account-personal-access-token-with-no-expiry-date)\n* Aucun [siège de licence](https://docs.gitlab.com/user/profile/service_accounts/#create-a-service-account) consommé\n\nGitLab a lancé une nouvelle [interface utilisateur dédiée aux comptes de service](https://gitlab.com/groups/gitlab-org/-/epics/9965) en complément de leur [création via l'API](https://docs.gitlab.com/ee/api/user_service_accounts.html#create-a-service-account-user), afin de simplifier leur gestion et celle des tokens associés. Regardez la démo ci-dessous sur l'utilisation automatique des comptes de service.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/oZvjg0SCsqY?si=cj-0LjfeonLGXv9u\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n### Outils de détection des vulnérabilités\n\nTirez parti des outils de sécurité intégrés à la plateforme GitLab pour détecter et atténuer les vulnérabilités associées à l'utilisation des tokens. Pour une protection optimale, il est recommandé d'utiliser l'ensemble de ces outils de manière combinée.\n\n* [Détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/) : analyse votre dépôt à la recherche de secrets codés en dur, tels que les tokens d'API, les mots de passe et d'autres informations contenant des données sensibles. Consultez la [liste des secrets détectés](https://docs.gitlab.com/ee/user/application_security/secret_detection/detected_secrets.html).\n* [Tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) : analyse votre code source à la recherche de failles de sécurité et [fournit des rapports intégrés aux merge requests contenant les résultats de l'interface utilisateur](https://docs.gitlab.com/ee/user/application_security/sast/#features), entre autres fonctionnalités.\n* [Analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) : assure que les bibliothèques tierces utilisées dans votre projet ne présentent pas de vulnérabilités liées aux tokens.\n\n### Journaux d'audit et surveillance\n\nVeillez à l'intégrité de vos tokens en examinant régulièrement les journaux d'audit et les données d'utilisation des tokens au niveau de l'instance et/ou du groupe.\n\n* [Événements d'audit](https://docs.gitlab.com/ee/user/compliance/audit_events.html) : activez la journalisation des événements d'audit dans GitLab pour suivre les activités liées aux tokens, telles que la création, l'utilisation, la révocation et les appels API suspects (paramètres non autorisés dans les journaux, déclenchements répétés du limiteur de débit).\n* [Liste des adresses IP autorisées](https://docs.gitlab.com/ee/administration/reporting/ip_addr_restrictions.html#configure-ip-address-restrictions) : permet d'empêcher qu'un utilisateur malveillant masque ses activités derrière plusieurs adresses IP.\n* [Alertes](https://docs.gitlab.com/ee/operations/incident_management/alerts.html) : configurez des alertes pour les activités inhabituelles (déclenchement d'une remontée d'alerte d'incident lors des rotations d'astreinte ou création d'incidents).\n* [Inventaire des identifiants de connexion](https://docs.gitlab.com/ee/administration/credentials_inventory.html) : contrôlez l'ensemble des tokens d'accès disponibles avec la possibilité de les révoquer si nécessaire.\n* [Notifications](https://docs.gitlab.com/ee/user/profile/notifications.html) : gérez de manière proactive tous les e-mails de notification d'expiration de tokens (d'accès au groupe/projet et personnel) que vous recevez. Suite aux retours de nos clients, cette fonctionnalité a été étendue pour inclure des notifications à 30 jours et 60 jours, en plus de la notification par défaut à 7 jours.\n* [Webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#create-a-webhook) : les webhooks de tokens d'accès peuvent être configurés sur les groupes et les projets pour envoyer des événements d'expiration de tokens à sept jours. Cette fonctionnalité a également été étendue pour inclure des notifications à 30 jours et 60 jours via le feature flag **:extended_expiry_webhook_execution_setting** (désactivé par défaut).\n\n## Perspectives\n\nCompte tenu du vaste catalogue de tokens de GitLab, nous avons [prévu](https://gitlab.com/gitlab-org/gitlab/-/issues/502630) une consolidation axée sur la durée de validité, les portées affinées, la gestion cohérente et l'utilisation. En ce qui concerne les fonctionnalités liées aux tokens, nous avons identifié les priorités suivantes : une interface utilisateur complète pour les comptes de service, l'ajout de nouveaux types d'identifiants dans l'inventaire des identifiants de connexion et une amélioration de l'audit des tokens et comptes de service.\n\n> [Essayez GitLab Ultimate gratuitement pendant 60 jours](https://about.gitlab.com/free-trial/) et commencez à utiliser les fonctionnalités de gestion des tokens.\n",[730],"Hakeem Abdul-Razak","2025-07-01","2025-02-25",[685,14,686,687,688],{"slug":735,"featured":93,"template":691},"the-ultimate-guide-to-token-management-at-gitlab","content:fr-fr:blog:the-ultimate-guide-to-token-management-at-gitlab.yml","The Ultimate Guide To Token Management At Gitlab","fr-fr/blog/the-ultimate-guide-to-token-management-at-gitlab.yml","fr-fr/blog/the-ultimate-guide-to-token-management-at-gitlab",{"_path":741,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":742,"content":748,"config":754,"_id":756,"_type":16,"title":757,"_source":18,"_file":758,"_stem":759,"_extension":21},"/fr-fr/blog/how-gitlab-helps-meet-nis2-requirements",{"title":743,"description":744,"ogTitle":743,"ogDescription":744,"noIndex":6,"ogImage":745,"ogUrl":746,"ogSiteName":675,"ogType":676,"canonicalUrls":746,"schema":747},"Comment se conformer aux exigences de la directive NIS2 avec GitLab ","La directive NIS2 se concentre sur la résilience, la réponse aux incidents et la gestion des risques. Découvrez comment GitLab vous permet de répondre à ces exigences de conformité.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","https://about.gitlab.com/blog/how-gitlab-helps-meet-nis2-requirements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment se conformer aux exigences de la directive NIS2 avec GitLab \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2024-08-20\",\n      }",{"title":743,"description":744,"authors":749,"heroImage":745,"date":751,"body":752,"category":14,"tags":753},[750],"Joseph Longo","2024-08-20","Les organismes gouvernementaux et législatifs du monde entier promulguent régulièrement de nouvelles lois et exigences pour faire face au risque croissant posé par notre quotidien de plus en plus numérisé et les menaces de cybersécurité qui en résultent. La [directive NIS2](https://eur-lex.europa.eu/eli/dir/2022/2555) de l'Union européenne vise à renforcer la cybersécurité en se concentrant sur des compétences essentielles telles que la résilience, la réponse aux incidents et la gestion des risques.\n\nEn tant que plateforme DevSecOps alimentée par l'IA la plus complète, GitLab est utilisée dans le monde entier pour développer des logiciels de qualité plus rapidement. La diversité des fonctionnalités de GitLab en fait un atout unique et précieux, capable de répondre aux nombreux besoins de nos clients en matière de [sécurité et de conformité](https://about.gitlab.com/fr-fr/solutions/security-compliance/). \n\nDans cet article, explorons ensemble la façon dont vous pouvez vous appuyer sur notre plateforme pour accompagner vos efforts de conformité à la directive NIS2.\n\n## Article 7 : Stratégie nationale en matière de cybersécurité\n\n**Section 2(a) : la cybersécurité dans le cadre de la chaîne d’approvisionnement des produits et services TIC utilisés par des entités pour la fourniture de leurs services.**\n\nLa directive NIS2 exige que les États membres adoptent des politiques en matière de cybersécurité dans la chaîne d'approvisionnement. \n\nBien que celles-ci doivent encore être définies par chaque État membre, GitLab dispose d’une suite de fonctionnalités permettant aux clients de [gérer la sécurité](https://about.gitlab.com/fr-fr/solutions/security-compliance/ \"Sécurité et gouvernance de GitLab\") de leur offre de services, ainsi que celle de leur chaîne d'approvisionnement :\n\n- Les [tests statiques de sécurité des applications (SAST)](https://about.gitlab.com/features/?stage=secure#static_application_security_testing), l'[analyse de sécurité de l'infrastructure en tant que code](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) et les [tests dynamiques de sécurité des applications (DAST)](https://about.gitlab.com/features/?stage=secure#dynamic_application_security_testing) permettent aux clients d'analyser leur code source et leurs fichiers de définition d'infrastructure, ainsi que leurs applications en cours d'exécution pour détecter d'éventuelles vulnérabilités. Les résultats peuvent ensuite être triés et traités conformément aux processus de chaque entreprise.\n\n- La fonctionnalité d'[analyse des conteneurs](https://about.gitlab.com/features/?stage=secure#container_scanning) de GitLab aide les clients à identifier les vulnérabilités connues dans leurs images de conteneurs.\n\n![Rapport de l'analyse des conteneurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.38.54.png)\n\n- Au niveau de la chaîne d'approvisionnement, l'[analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) aide à identifier les vulnérabilités connues dans les dépendances des applications des clients. La [conformité des licences logicielles](https://docs.gitlab.com/ee/user/compliance/license_approval_policies.html) étend la portée de l'analyse des dépendances en déterminant si les licences des dépendances répondent à un ensemble de critères déterminés par l'entreprise.\n\n- Avec la [liste des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_list/) de GitLab, les entreprises peuvent créer une [nomenclature logicielle (SBOM)](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"Qu'est-ce qu'une nomenclature logicielle (SBOM) ?\") CycloneDX. Pour en savoir plus, consultez [ce tutoriel dédié à l'exportation d'une SBOM](https://docs.gitlab.com/ee/tutorials/export_sbom.html).\n\nLa combinaison de ces fonctionnalités d'analyse contribue à la création d'un ensemble de tests complet et efficace, capable de prendre en charge des processus robustes de développement d'applications et de gestion de la chaîne d'approvisionnement. Le DAST, l'analyse des dépendances et la conformité des licences logicielles sont disponibles avec un abonnement à GitLab Ultimate.\n\n> [Essayez GitLab Ultimate gratuitement pendant 30 jours](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n\n## Article 21 : Mesures de gestion des risques en matière de cybersécurité\n\nLa directive NIS2 exige des États membres qu'ils veillent à ce que les entités essentielles et importantes mettent en œuvre des mesures techniques, organisationnelles et opérationnelles appropriées visant à gérer correctement les risques et atténuer l'impact subi par les utilisateurs à la suite d'incidents affectant leurs services.\n\n**Section 2(d) : la sécurité de la chaîne d’approvisionnement, y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs ou prestataires de services directs.**\n\nL'étape de [sécurisation](https://about.gitlab.com/fr-fr/solutions/security-compliance/) de GitLab permet aux clients de mettre en place un large éventail de capacités de détection et de réponse qui améliorent la sécurité de leur code et résout les risques au sein de leurs chaînes d'approvisionnement.\n\nCes fonctionnalités peuvent être exploitées pour répondre aux exigences que les États membres définiront dans le cadre de cette section.\n\n**Section 2(e) : la sécurité de l’acquisition, du développement et de la maintenance des réseaux et des systèmes d’information, y compris le traitement et la divulgation des vulnérabilités.**\n\nEn tant que plateforme DevSecOps complète, les fonctionnalités de GitLab aident à sécuriser l'ensemble du cycle de livraison de logiciels de nos clients.\n\n- Les [outils de planification](https://about.gitlab.com/features/?stage=plan) de GitLab peuvent soutenir vos efforts de gestion de projet et assurer que la sécurité de l'information est correctement prise en compte à chaque phase du cycle de vie d'un projet. Pour en savoir plus, consultez l'article [ISO 27001: comment GitLab vous assiste dans votre démarche de conformité.](https://about.gitlab.com/fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey/#organizational-controls).\n\n- Grâce à des fonctionnalités telles que les [branches protégées](https://docs.gitlab.com/ee/user/project/protected_branches.html), les [approbations de merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/), les [règles en matière de push](https://docs.gitlab.com/ee/push_rules/push_rules.html) et les [validations signées](https://docs.gitlab.com/ee/user/project/repository/signed_commits/), l'[étape de création](https://about.gitlab.com/features/?stage=create) de GitLab propose une base sécurisée capable d'évoluer en fonction des besoins des développeurs au fur et à mesure de leur création de code sécurisé.\n\n![Validations signées](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.34.24.png)\n\n- Les fonctionnalités de l'[étape de sécurisation](https://about.gitlab.com/features/?stage=verify) de GitLab évoquées plus haut apportent une valeur basée sur la sécurité aux étapes [de vérification](https://about.gitlab.com/features/?stage=verify), [d'empaquetage](https://about.gitlab.com/features/?stage=package) et [de déploiement](https://about.gitlab.com/features/?stage=deploy) de GitLab. Ces étapes comprennent des fonctionnalités d'[intégration et de livraison continues](https://about.gitlab.com/fr-fr/solutions/continuous-integration/), telles que les [pipelines de merge request](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html) et les [runners protégés](https://docs.gitlab.com/ee/ci/runners/#prevent-runners-from-revealing-sensitive-information), ainsi que plusieurs registres d'artefacts pour répondre aux besoins de votre entreprise.\n\n- L'[étape de surveillance](https://about.gitlab.com/features/?stage=monitor) de GitLab offre des fonctionnalités telles que les [alertes](https://docs.gitlab.com/ee/operations/incident_management/alerts.html) et les [incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html) permettant aux entreprises de prendre connaissance des incidents et d'en suivre la progression depuis notre plateforme jusqu’à leur remédiation. \n\n- Les fonctionnalités de l'[étape de gouvernance](https://about.gitlab.com/fr-fr/solutions/security-compliance/) de GitLab établissent des normes quant à l'utilisation d’une instance de GitLab et à ses modalités. Elles soutiennent également les efforts globaux de conformité d'une entreprise.\n  - Des fonctionnalités telles que le [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html), le [SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) et [les rôles personnalisés](https://docs.gitlab.com/ee/user/custom_roles.html) prennent efficacement en charge les cycles de vie d'authentification et d'autorisation.\n  - Les [stratégies d'approbation des merge requests](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) constituent un outil puissant qui intègre une barrière de sécurité dans votre cycle de développement logiciel. À l'aide des stratégies d'approbation des merge requests, il est possible d'exiger des approbations supplémentaires pour des événements. Par exemple, lorsque des vulnérabilités sont détectées après un commit, lorsque certains types de licences sont détectés dans des dépendances ou lorsqu'une merge request est effectuée sur une branche protégée spécifique. Les stratégies d'approbation des merge requests sont incluses dans l'abonnement à GitLab Ultimate.\n  - Avec [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), les entreprises peuvent tirer parti de la fonctionnalité d'[explication des vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/index.html#explaining-a-vulnerability) pour : résumer une vulnérabilité, aider les développeurs et les analystes de sécurité à comprendre la vulnérabilité, comment elle pourrait être exploitée et comment la corriger, ou encore suggérer des mesures d’atténuation. \n\n  - Les [événements d'audit en streaming](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) permettent aux entreprises d'envoyer des événements d'audit de leur groupe principal vers un emplacement externe afin de recevoir tous les événements se rapportant au groupe, aux sous-groupes et aux projets. Les événements d'audit en streaming sont disponibles avec un abonnement GitLab Ultimate.\n  - Un programme complet de lutte contre les menaces internes combine plusieurs niveaux de contrôles de détection, de prévention et de réaction. La [limitation des requêtes pour la gestion des abus de Git](https://docs.gitlab.com/ee/user/group/reporting/git_abuse_rate_limit.html) avertit automatiquement les administrateurs lorsqu'un utilisateur télécharge, clone, effectue un pull, récupère ou duplique un nombre de dépôts supérieur à une certaine limite au cours d'une période donnée. Les entreprises peuvent aller plus loin et activer le bannissement automatique pour bannir l'utilisateur fautif du groupe et de ses sous-groupes. La limitation des requêtes pour la gestion des abus de Git est proposée dans l'abonnement GitLab Ultimate.\n  - Pour approfondir les vulnérabilités détectées, le [rapport de vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) de GitLab fournit des informations sur les vulnérabilités issues des scans de la branche par défaut. Les rapports de vulnérabilité sont disponibles avec un abonnement GitLab Ultimate.\n\n![Rapport de vulnérabilité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.32.02.png)\n\n**Section 2(j) : l’utilisation de solutions d’authentification à plusieurs facteurs ou d’authentification continue, de communications vocales, vidéo et textuelles sécurisées et de systèmes sécurisés de communication d’urgence au sein de l’entité, selon les besoins.**\n\nGitLab offre plusieurs options d'authentification à plusieurs facteurs pour renforcer le processus d'authentification. Les clients peuvent sélectionner l'[option d'authentification multifacteur](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) qui répond à leurs exigences, ou encore mettre en œuvre le [SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) pour améliorer davantage le processus d'authentification.\n\n## Quelles sont les prochaines étapes ?\n\nLa plateforme de GitLab est bien placée pour répondre aux exigences du cycle du développement logiciel au fur et à mesure de la mise en place des directives générales qui seront émises par les États membres en réponse à la directive NIS2.\n\nPour en savoir plus sur les fonctionnalités décrites tout au long de cet article, consultez notre bibliothèque de [tutoriels](https://docs.gitlab.com/ee/tutorials/).\n\n> [Essayez GitLab Ultimate gratuitement pendant 30 jours](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n",[686,14,688],{"slug":755,"featured":93,"template":691},"how-gitlab-helps-meet-nis2-requirements","content:fr-fr:blog:how-gitlab-helps-meet-nis2-requirements.yml","How Gitlab Helps Meet Nis2 Requirements","fr-fr/blog/how-gitlab-helps-meet-nis2-requirements.yml","fr-fr/blog/how-gitlab-helps-meet-nis2-requirements",{"_path":761,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":762,"content":768,"config":777,"_id":779,"_type":16,"title":780,"_source":18,"_file":781,"_stem":782,"_extension":21},"/fr-fr/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"ogTitle":763,"schema":764,"ogImage":765,"ogDescription":766,"ogSiteName":675,"noIndex":6,"ogType":676,"ogUrl":767,"title":763,"canonicalUrls":767,"description":766},"La séparation des tâches de GitLab pour le secteur financier","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Les fonctionnalités de séparation des tâches de GitLab pour le secteur financier\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cherry Han\"},{\"@type\":\"Person\",\"name\":\"Gavin Peltz\"}],\n        \"datePublished\": \"2024-08-13\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097688/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097687913.png","Découvrez comment GitLab garantit un développement logiciel sécurisé et conforme aux exigences de séparation des tâches dans le secteur financier.","https://about.gitlab.com/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"heroImage":765,"body":769,"authors":770,"updatedDate":773,"date":774,"title":775,"tags":776,"description":766,"category":14},"Dans le développement logiciel, des mesures rigoureuses de sécurité et de conformité sont indispensables, en particulier dans des secteurs tels que les services financiers, où l'intégrité des données et le respect des réglementations ne sont pas négociables. La séparation des tâches (Separation of Duties) joue un rôle clé dans le maintien de ces normes. Elle garantit qu'aucune personne ne contrôle totalement un processus du début à la fin, réduisant ainsi le risque d'erreurs et d'activités non autorisées. La séparation des tâches atténue les risques liés à la chaîne d'approvisionnement logicielle en empêchant les actes externes et malveillants susceptibles de compromettre l'intégrité du processus de développement logiciel.\n\n## L'importance de la séparation des tâches dans le secteur des services financiers\n\nDans le secteur des [services financiers](https://about.gitlab.com/fr-fr/solutions/finance/ \"Services financiers\"), la séparation des tâches joue un rôle essentiel pour protéger les données sensibles et garantir la conformité réglementaire. Sur le plan stratégique, voici comment la séparation des tâches contribue à ce secteur :\n\n* **Atténuation des risques :** en répartissant les responsabilités entre plusieurs personnes exerçant des rôles différents, la séparation des tâches réduit le risque d'erreurs, de fraudes et d'activités non autorisées qui pourraient compromettre l'intégrité des systèmes ou la conformité réglementaire.\n* **Renforcement de la responsabilité :** une répartition claire des tâches empêche quiconque d'initier, d'autoriser ou d'exécuter un processus complet de manière autonome. Cette transparence améliore la responsabilisation, essentielle pour maintenir la confiance avec les parties prenantes et les organismes régulateurs.\n* **Conformité réglementaire :** la séparation des tâches aide les entreprises à respecter les réglementations financières afin que les opérations sensibles soient menées dans le respect des règles strictes de surveillance et de contrôle. La conformité à ces normes protège non seulement contre les sanctions, mais préserve aussi la réputation de l'entreprise.\n* **Résilience opérationnelle :** en décentralisant la prise de décision et l'exécution des tâches, les entreprises deviennent moins vulnérables aux perturbations causées par des erreurs humaines, des actions malveillantes ou des événements inattendus.\n\n## Quelles sont les fonctionnalités de séparation des tâches de GitLab ?\n\nGitLab offre des fonctionnalités de séparation des tâches à chaque étape du workflow [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"DevSecOps\").\n\n![La séparation des tâches appliquée aux services financiers - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097695/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097695697.png)\n\nLe diagramme ci-dessus illustre l'intégration de fonctionnalités clés telles que les stratégies d'approbation des merge requests, les fonctionnalités protégées, les autorisations des utilisateurs, les frameworks de conformité et les événements d'audit, lesquelles fonctionnent de concert pour appliquer les principes de la séparation des tâches. Chaque fonctionnalité est détaillée dans les sections suivantes, qui vous expliquent comment mettre en place un environnement de développement sécurisé et conforme.\n\n### Les stratégies d'approbation des merge requests\n\nL’un des défis auxquels le secteur des services financiers est confronté est la mise en œuvre des mécanismes d'approbation qui bloquent l'intégration de modifications non autorisées ou non vérifiées. C'est là que les [stratégies d'approbation des merge requests](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) entrent en jeu. Elles renforcent la séparation des tâches entre les équipes de sécurité et de développement, en empêchant les développeurs et développeuses d'approuver leurs propres modifications de code, en particulier si elles contiennent des vulnérabilités. Elles veillent également à ce que le code ne soit pas déployé directement dans des environnements de production sans une supervision adéquate. \n\nLors de l'élaboration d'une stratégie d'approbation, il est conseillé de déterminer qui serait l'approbateur idéal pour garantir la qualité et la sécurité du code. Il peut s'agir d'un utilisateur individuel, d'un groupe tel que l'équipe de sécurité des applications, ou encore d'une personne exerçant une fonction spécifique, tel qu'un chargé de maintenance. Pour ajouter d'autres restrictions, vous devez prendre en compte les fonctionnalités stratégiques clés suivantes :\n\n* **Empêcher l'approbation par l'auteur :** cette mesure instaure un garde-fou afin que l'auteur d'une merge request ne puisse pas approuver ses propres modifications. En exigeant une revue de code indépendante, cette stratégie contribue à maintenir l'objectivité et l'impartialité du processus d'approbation.\n* **Empêcher les approbations par les utilisateurs ayant ajouté des commits :** les utilisateurs qui ajoutent des commits à une merge request ne peuvent pas non plus l'approuver. Cette stratégie renforce le principe de revue de code indépendante, de sorte que les modifications sont examinées par des membres de l'équipe qui n'ont pas directement contribué aux modifications.\n* **Empêcher la modification des règles d'approbation :** pour préserver l'intégrité du processus d'approbation, GitLab permet aux administrateurs d'empêcher la modification des règles d'approbation au niveau du projet ou de la merge request. Ainsi, une fois les stratégies d'approbation définies, ces règles ne peuvent plus être contournées ou modifiées par des utilisateurs non autorisés.\n* **Exiger le mot de passe de l'utilisateur lors de l'approbation :** pour encore plus de sécurité, GitLab peut demander aux utilisateurs de saisir leur mot de passe lors de l'approbation d'une merge request. \n\nAfin de maintenir une séparation claire des tâches, il est conseillé de [créer un groupe principal distinct](https://docs.gitlab.com/ee/user/application_security/policies/#enforce-policies-globally-in-gitlab-dedicated-or-your-gitlab-self-managed-instance) destiné à héberger vos stratégies de sécurité, ainsi que les stratégies d'approbation des merge requests. Cette configuration réduit le nombre d'utilisateurs ayant des autorisations héritées et permet un contrôle plus strict de la gestion des stratégies. À partir de ce groupe distinct, vous pouvez [relier les projets relatifs aux stratégies de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/#link-to-a-security-policy-project) au niveau du groupe le plus élevé qui correspond à vos objectifs. Ainsi, vous réduisez les frais généraux de gestion des stratégies et garantissez une couverture complète de votre environnement de développement.\n\nIl est également important de noter que lorsqu'une stratégie est activée par défaut, elle s'applique automatiquement à tous les projets au sein des groupes, sous-groupes et projets associés. Si vous souhaitez appliquer des stratégies de manière plus ciblée, GitLab vous recommande de les associer à un label de [framework de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html). Nos clients soumis à de fortes réglementations créent généralement des labels de conformité spécifiques pour répondre aux exigences réglementaires, telles que « SOX » et « PCI ». Associer ces labels à un framework permet également au [centre de conformité natif](https://docs.gitlab.com/ee/user/compliance/compliance_center/) de gérer des stratégies de sécurité adaptées à divers cas d'utilisation.\n\n### Les frameworks de conformité et contrôles\n\nLes grandes entreprises évoluant dans des secteurs réglementés rencontrent des défis importants liés au maintien de la conformité. Les processus manuels sont sujets aux erreurs et il peut être difficile de maintenir une application cohérente des stratégies au sein des différentes équipes.\n\nEn utilisant les frameworks de conformité de GitLab, ces entreprises peuvent automatiser et administrer des mesures préventives, gérer systématiquement les risques et mettre en œuvre la conformité réglementaire de manière fluide. Ces frameworks permettent d'intégrer des protocoles de sécurité et des jobs personnalisés dans n’importe quel pipeline. \n\nPour protéger les paramètres de conformité au niveau de l'entreprise, GitLab permet uniquement aux propriétaires de groupes ou de projets d'ajouter ou de supprimer des frameworks de conformité. Cette mesure empêche les équipes de développement ou les responsables de modifier les configurations de conformité sans disposer des autorisations appropriées, ajoutant ainsi un niveau de sécurité supplémentaire. Il est important de noter que lorsqu'une personne dispose des autorisations de chargé de maintenance, elle est autorisée à créer un sous-groupe, elle devient propriétaire de ce sous-groupe et elle peut en modifier le framework de conformité. Pour éviter cela, il convient de [limiter le nombre de personnes autorisées à créer des sous-groupes](https://docs.gitlab.com/ee/user/group/subgroups/#change-who-can-create-subgroups) via les paramètres d'autorisations et de gestion des groupes.\n\n### La séparation des tâches en fonction des autorisations et des rôles\n\nPour implémenter efficacement la séparation des tâches dans le secteur des services financiers, il est essentiel d'établir un contrôle d'accès clair et précis. GitLab propose un [modèle d'autorisations](https://docs.gitlab.com/ee/user/permissions.html) à plusieurs niveaux avec des rôles prédéfinis : invité, rapporteur, développeur, chargé de maintenance et propriétaire. Chaque rôle dispose d'un ensemble spécifique d'autorisations afin que les personnes concernées puissent accomplir leurs tâches sans outrepasser leurs attributions, évitant ainsi les conflits d'intérêts ou les risques pour la sécurité. GitLab recommande d'attribuer les rôles en suivant le [principe du moindre privilège en matière d'accès](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n\nPour les entreprises ayant besoin d'une gestion plus granulaire, en particulier celles qui utilisent [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"GitLab Ultimate\"), les [rôles personnalisés](https://docs.gitlab.com/ee/user/custom_roles.html) offrent encore plus de flexibilité. Ces rôles permettent de définir des autorisations spécifiques, adaptées à leurs workflows uniques et aux exigences de conformité associées. Ce système est particulièrement utile pour garantir la séparation des tâches, car aucune personne ne peut effectuer des tâches contradictoires.\n\nUn exemple courant est le rôle de déployeur : il s'agit d'une personne qui a l'autorisation de déployer des jobs, mais pas de modifier ou d'effectuer un push du code. GitLab répond à cette exigence par le biais des [environnements protégés](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments) qui vous permettent d'[inviter des groupes autorisés à déployer des jobs](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#deployment-only-access-to-protected-environments) tout en limitant le rôle des utilisateurs à celui de rapporteur. Notez que le job de déploiement doit inclure le mot-clé de l'environnement concerné. Cette configuration permet aux utilisateurs de déployer des jobs sans pouvoir modifier le code, garantissant ainsi le respect des exigences en matière de conformité réglementaire.\n\nEn définissant et en appliquant rigoureusement les rôles et autorisations, les entreprises peuvent créer un environnement de développement sécurisé et conforme. Si vous souhaitez examiner les autorisations de vos utilisateurs sur une plus grande échelle, vous pouvez utiliser ce [rapport sur les membres d'un groupe](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/gitlab-group-member-report). Il vous permet de voir le nombre de membres occupant chaque rôle dans votre environnement et d'évaluer les actions à entreprendre en conséquence.\n\n### Les fonctionnalités protégées\n\nGitLab propose plusieurs fonctionnalités « protégées » pour renforcer le contrôle de votre processus de développement. Ces fonctionnalités peuvent s'avérer essentielles pour maintenir la séparation des tâches de sorte que seules les personnes autorisées puissent apporter des modifications importantes.\n\n* **Branches protégées :** une branche protégée restreint l'accès à un nombre limité de personnes pouvant effectuer un push, fusionner ou effectuer un push forcé vers la branche. Cela s'avère particulièrement utile pour les branches telles que la branche « principale » ou la branche de « production », afin que seuls les utilisateurs autorisés puissent apporter des modifications.\n* **Tags Git protégés :** ces tags permettent de contrôler les personnes autorisées à créer des tags. Cela permet d'éviter les mises à jour ou les suppressions accidentelles une fois le tag créé, préservant ainsi l'intégrité de votre gestion des versions.\n* **Environnements protégés :** il est impératif de restreindre l'accès à certains environnements spécifiques, en particulier les environnements de production, contre tout accès non autorisé. Dans un environnement protégé, seuls les utilisateurs disposant des privilèges appropriés peuvent y effectuer des déploiements, afin de protèger l'environnement contre toute modification involontaire. Cela renvoie à la fonctionnalité du rôle de déployeur mentionnée précédemment, qui permet à certains utilisateurs de déployer des jobs sans pour autant modifier le code, garantissant ainsi la conformité et la sécurité.\n* **Paquets protégés :** l'utilisation de règles de protection des paquets permet de limiter le nombre d'utilisateurs pouvant apporter des modifications à ces paquets.\n  Ces fonctionnalités protégées contribuent collectivement à maintenir un environnement de développement sécurisé et conforme aux principes de la séparation des tâches.\n\n### Les événements d'audit et le centre de conformité\n\nNous avons exploré les stratégies d'approbation, les frameworks de conformité, les rôles et les fonctionnalités protégées. Il nous reste maintenant à découvrir comment GitLab permet de surveiller et d'auditer ces implémentations pour en garantir le respect. Les [événements d'audit](https://docs.gitlab.com/ee/user/compliance/audit_events.html) de GitLab fournissent aux propriétaires et administrateurs un enregistrement détaillé des activités et des modifications, telles que l'activité des utilisateurs et les ajustements apportés au niveau du projet. Cette journalisation est essentielle pour suivre les actions des utilisateurs et repérer tout comportement non autorisé. Le [streaming des événements d'audit](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) optimise ce processus en permettant aux entreprises de diffuser des événements d'audit vers des systèmes externes pour une analyse et une alerte en temps réel. Ce faisant, toute altération ou violation des exigences de conformité est détectée, ce qui permet d'y remédier rapidement.\n\nLe [centre de conformité de GitLab](https://docs.gitlab.com/ee/user/compliance/compliance_center/) centralise la gestion et la surveillance des activités de conformité. Il offre une vue d'ensemble de l'état de conformité des projets et des groupes. Ce centre met en évidence les violations des exigences de conformité, telles que le non-respect des règles d'approbation des merge requests ou d'autres stratégies. Les administrateurs peuvent ainsi traiter rapidement les tickets, en certifiant le respect des normes de conformité prédéfinies. Cette approche centralisée simplifie la gestion de la conformité tout en garantissant un niveau élevé de surveillance et de contrôle.\n\n> Si vous souhaitez en savoir plus sur la vision de GitLab en matière de séparation des tâches et de conformité, consultez la page [Direction du produit GitLab lié à la Gouvernance](https://about.gitlab.com/direction/govern/) et la [documentation sur la conformité de GitLab](https://docs.gitlab.com/ee/administration/compliance.html).",[771,772],"Cherry Han","Gavin Peltz","2024-11-18","2024-08-13","Les fonctionnalités de séparation des tâches de GitLab pour le secteur financier",[14,686,688,557],{"slug":778,"featured":6,"template":691},"finserv-how-to-implement-gitlabs-separation-of-duties-features","content:fr-fr:blog:finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","Finserv How To Implement Gitlabs Separation Of Duties Features","fr-fr/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","fr-fr/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"_path":784,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":785,"content":791,"config":798,"_id":800,"_type":16,"title":801,"_source":18,"_file":802,"_stem":803,"_extension":21},"/fr-fr/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"title":786,"description":787,"ogTitle":786,"ogDescription":787,"noIndex":6,"ogImage":788,"ogUrl":789,"ogSiteName":675,"ogType":676,"canonicalUrls":789,"schema":790},"Migrer de GitHub Advanced Security vers GitLab Ultimate : notre guide complet","Découvrez les similitudes et les différences entre GitLab Ultimate et GitHub Advanced Security, puis suivez notre tutoriel détaillé pour migrer vers GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666187/Blog/Hero%20Images/blog-image-template-1800x945__6_.png","https://about.gitlab.com/blog/migration-guide-github-advanced-security-to-gitlab-ultimate","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migrer de GitHub Advanced Security vers GitLab Ultimate : notre guide complet \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-05-01\",\n      }",{"title":786,"description":787,"authors":792,"heroImage":788,"date":793,"body":794,"category":14,"tags":795,"updatedDate":732},[681],"2024-05-01","GitLab est la plateforme DevSecOps alimentée par l'IA la plus complète, qui permet de livrer rapidement des logiciels plus sécurisés depuis une seule et même plateforme pour l'ensemble de votre cycle de développement logiciel. De son côté, GitHub fournit un module d'extension appelé Advanced Security, qui, comme son nom l'indique, active des fonctionnalités de sécurité supplémentaires dans GitHub, mais ne dispose pas de la profondeur et de l'étendue des fonctionnalités de sécurité fournies nativement par GitLab. \n\nSi vous souhaitez passer à GitLab Ultimate pour améliorer votre sécurité dans tous les domaines du SDLC, utilisez ce guide pour comparer les deux offres et effectuer votre migration.\n\n## Comparaison entre GitLab Ultimate et GitHub Advanced Security\n\n[GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/) est le niveau d'abonnement de GitLab dédié aux entreprises qui cherchent à livrer des logiciels sécurisés plus rapidement. GitHub Advanced Security est un module d'extension de GitHub Enterprise, qui active des fonctionnalités de sécurité supplémentaires.\n\n### Quelles sont les similitudes entre GitLab Ultimate et GitHub Advanced Security ?\n\nGitLab Ultimate et GitHub Advanced Security fournissent tous deux :\n- des tests statiques de sécurité des applications ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)), une analyse des secrets et une analyse des dépendances\n- une veille contextualisée recensant les vulnérabilités et des conseils pour y remédier\n- une liste des dépendances ou des nomenclatures logicielles ([SBOM](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"SBOM\"))\n- des métriques et des informations clés sur la sécurité\n\n### Quelles sont les différences entre GitLab Ultimate et GitHub Advanced Security ? \n\nGitLab Ultimate diffère de GitHub Advanced Security de la manière suivante :\n\n- GitLab fournit nativement des scanners de code de sécurité supplémentaires tels que l'analyse des conteneurs, les tests dynamiques de sécurité des applications ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/)), les tests d’API Web par injection de données aléatoires, et plus encore. Ces scanners sont un mélange de technologies propriétaires et open source optimisées avec des ensembles de règles personnalisés. Pour une liste complète, consultez notre [documentation pour sécuriser votre application avec GitLab](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html).\n- GitLab fournit des [garde-fous de sécurité granulaires](https://docs.gitlab.com/ee/user/application_security/policies/) pour empêcher que du code non sécurisé soit fusionné sans approbation.\n- Les scanners de sécurité de GitLab peuvent être exécutés dans des [environnements isolés ou à connectivité limitée](https://docs.gitlab.com/ee/user/application_security/offline_deployments/).\n- GitLab fournit un [Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/) qui permet de surveiller les violations des exigences de conformité dans l'ensemble de l'entreprise.\n\nGitLab Ultimate fournit également des fonctionnalités supplémentaires en matière de sécurité et de conformité, de gestion de portefeuilles et de la chaîne de valeur, d'assistance à la mise à niveau en direct et bien plus encore. Consultez notre [documentation GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/) pour en savoir plus sur ces fonctionnalités supplémentaires.\n\n## Comment migrer un dépôt GitHub vers GitLab ?\n\nGitLab fournit un outil d'importation intégré qui vous permet d'importer vos projets GitHub depuis GitHub.com ou GitHub Enterprise vers GitLab. Cet outil vous permet de migrer non seulement le dépôt GitHub vers GitLab, mais également plusieurs autres éléments, notamment des tickets, des collaborateurs (membres) et des pull requests. Pour obtenir la liste complète de ce qui peut être migré, consultez notre [documentation](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data). \n\nVous pouvez effectuer votre migration de GitHub vers GitLab en suivant les étapes ci-dessous :\n1. Dans la barre latérale gauche, en haut, sélectionnez **Créer un nouveau (+)**.\n2. Sélectionnez **Nouveau projet/dépôt**.\n3. Sélectionnez **Importer un projet**.\n\n![Sélection Importer un projet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/1-Import-Project.png)\n\n4. Cliquez sur le bouton **GitHub**.\n - Si vous utilisez GitLab Self-Managed, vous devez [activer l'outil d'importation GitHub](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources).\n - Notez que d'autres outils d'importation peuvent être lancés de la même manière.\n5. Maintenant, vous pouvez effectuer l'une des actions suivantes :\n    - Autoriser OAuth de GitHub en sélectionnant **Autoriser avec GitHub**.\n    - Utiliser un jeton d'accès personnel GitHub :\n       - Rendez-vous sur [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new).\n       - Dans le champ **Note**, saisissez une description du token.\n       - Sélectionnez la portée du **dépôt**.\n       - En option, pour importer des collaborateurs, sélectionnez la portée **read:org**.\n       - Cliquez sur le bouton **Générer un token**.\n       - Sur la page d'importation de GitLab, dans le champ **Jeton d'accès personnel**, collez le jeton d'accès personnel GitHub.\n6. Cliquez sur le bouton **Authentification**.\n7. Sélectionnez les éléments que vous souhaitez migrer.\n8. Sélectionnez les projets que vous souhaitez migrer et leur destination.\n9. Cliquez sur le bouton **Importer**.\n\nVotre projet importé devrait maintenant s'afficher dans votre espace de travail. Pour en savoir plus sur la migration de GitHub vers GitLab, regardez cette vidéo :\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=HEpZVy94cpfPfAky\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nVous pouvez également effectuer votre migration à l'aide d'un [jeton d'accès personnel GitHub](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token) ou de l'[API REST GitLab](https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api). L'outil d'importation permet également d'importer à partir d'autres sources telles que Bitbucket ou Gitea. Pour en savoir plus, consultez notre [documentation](https://docs.gitlab.com/ee/user/project/import/).\n\n## Comment migrer fonctionnalité par fonctionnalité ?\n\nVoyons comment tirer parti de chaque fonctionnalité fournie par GitHub Advanced Security dans GitLab Ultimate. Pour continuer, vous devez disposer d'une [licence GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/). \n\nCommencez un [essai gratuit de 60 jours](https://about.gitlab.com/fr-fr/free-trial/devsecops/) de GitLab Ultimate.\n\n### Mise en place d'un scanner de code de sécurité\n\nGitHub fournit un scanner de code de sécurité pour offrir une veille contextualisée recensant les vulnérabilités et des conseils pour le code source statique. Vous pouvez effectuer la même action au sein de GitLab en activant [SAST](https://docs.gitlab.com/ee/user/application_security/sast/). Les scanners SAST de GitLab couvrent un ensemble de langages de programmation et de frameworks plus large que le [CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql#about-codeql) de GitHub.\n\nPour activer la mise en place d'un scanner de code de sécurité dans GitLab, vous pouvez simplement ajouter le [template SAST](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) à votre fichier `.gitlab-ci.yml` :\n\n```yaml\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nUne fois le template ajouté, chaque fois qu'un nouveau code est enregistré, SAST détectera automatiquement les [langages de programmation](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) utilisés dans votre projet. Il analysera ensuite le code source afin de détecter des vulnérabilités connues.\n\n**Remarque :** des scanners de sécurité peuvent également être ajoutés à votre projet à l'aide de la [configuration de sécurité](https://docs.gitlab.com/ee/user/application_security/configuration/) de GitLab, qui peut créer automatiquement une merge request pour mettre à jour votre pipeline. Pour en savoir plus, consultez notre [documentation](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-by-using-the-ui).\n\nLes résultats SAST de la différence entre la branche de fonctionnalité et la branche cible s'affichent dans le widget de merge request. Le widget de merge request affiche les résultats et les résolutions SAST qui ont été introduits par les modifications apportées dans la merge request.\n\n![Analyse de sécurité dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/2-SAST-MR-View.png)\n\nChaque vulnérabilité affiche des données pour aider à la remédiation, y compris une description détaillée, la gravité, l'emplacement et des informations de résolution :\n\n![Détails de la vulnérabilité SAST](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/3-SAST-MR-View-Detailed.png)\n\nVous pouvez prendre des mesures pour corriger ces vulnérabilités :\n\n- **Ignorer la vulnérabilité** : permet aux équipes de développement d'ignorer la vulnérabilité avec un commentaire. Cela aide l'équipe de sécurité en charge de la revue.\n- **Créer un ticket** : permet de créer un ticket pour suivre une vulnérabilité nécessitant une surveillance supplémentaire.\n\nCes modifications peuvent également être visualisées lorsque vous basculez sur la vue **Modifications** de la merge request. \n\n![Vue des modifications de la vulnérabilité SAST](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/4-SAST-MR-View-Changes.png)\n\n#### Personnalisation des scanners SAST\n\nGitLab vous permet de remplacer une définition de job SAST afin de pouvoir modifier des propriétés telles que des variables, des dépendances ou des règles. Vous pouvez le faire en déclarant un job du même nom que le job SAST à remplacer. Ensuite, placez ce nouveau job après l'inclusion du template et spécifiez toutes les clés supplémentaires en dessous.\n\nPar exemple, la configuration suivante :\n- écrase la version utilisée par le scanner `semgrep-sast`\n- exécute un script pour récupérer des modules de projets privés avant d'exécuter `gosec-sast`\n- configure tous les scanners pour rechercher à une profondeur maximale de 10\n\n```yaml\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n\nvariables:\n  SEARCH_MAX_DEPTH: 10\n\nsemgrep-sast:\n  variables:\n    SAST_ANALYZER_IMAGE_TAG: \"3.7\"\n\ngosec-sast:\n  before_script:\n    - |\n      cat \u003C\u003CEOF > ~/.netrc\n      machine gitlab.com\n      login $CI_DEPLOY_user\n      password $CI_DEPLOY_PASSWORD\n      EOF\n```\n\n**Remarque :** Les jobs SAST disponibles sont inclus dans le [template `SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml). Vous trouverez les configurations dans notre [documentation sur les variables CI/CD SAST](https://docs.gitlab.com/ee/user/application_security/sast/#available-cicd-variables).\n\n#### Personnalisation des ensembles de règles SAST\n\nPour chaque scanner SAST, GitLab traite le code puis utilise des règles pour trouver d'éventuelles faiblesses dans le code source. Ces règles déterminent les types de faiblesses signalées par le scanner.\n\n- Pour les scanners SAST basés sur Semgrep, GitLab crée, maintient et prend en charge les règles utilisées. Il combine le moteur open source Semgrep, les règles de détection gérées par GitLab et la technologie propriétaire de GitLab pour le suivi des vulnérabilités et la détection des faux positifs.\n- Pour les autres scanners SAST, les règles sont définies dans les projets en amont pour chaque scanner.\n\nVous pouvez personnaliser le comportement des scanners SAST en définissant un fichier de configuration d'ensemble de règles dans le dépôt analysé :\n- Désactiver les règles prédéfinies (disponibles pour tous les scanners)\n- Remplacer les règles prédéfinies (disponibles pour tous les scanners)\n- Remplacer les règles prédéfinies en synthétisant une configuration personnalisée à l'aide de modes « passthrough »\n\nPour plus d'informations et d'exemples sur la configuration des règles SAST, consultez notre documentation sur les [règles SAST](https://docs.gitlab.com/ee/user/application_security/sast/rules.html) et sur la [personnalisation des ensembles de règles](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html).\n\n### Analyse des secrets\n\nGitHub fournit une analyse des secrets, qui peut trouver, bloquer et révoquer les secrets divulgués. Vous pouvez effectuer les mêmes opérations au sein de GitLab en activant la [détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/).\n\nPour activer la détection des secrets dans GitLab, vous pouvez simplement ajouter le template suivant à votre fichier `.gitlab-ci.yml` :\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n```\n\nUne fois le template ajouté, chaque fois qu'un nouveau code est enregistré (ou qu'un pipeline est exécuté), le scanner de secrets analysera le code source pour y détecter des secrets connus. La détection des secrets de pipeline analyse différents aspects de votre code, en fonction de la situation. Pour toutes les méthodes, à l'exception de la « branche par défaut », la détection des secrets de pipeline analyse les validations et non l'arborescence de travail. Consultez notre [documentation sur la couverture de la détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#coverage) pour en savoir plus sur le fonctionnement de l'analyse des secrets.\n\nLors de la création d'une merge request, la détection des secrets analyse chaque validation effectuée sur la branche source. Tout comme dans SAST, chaque vulnérabilité détectée fournit les informations (telles que l'emplacement) et les identifiants suivants pour aider au processus de correction :\n\n![Détails de la vulnérabilité de la détection des secrets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/5-Secret-Detection-MR-Detailed.png)\n\nComme pour le SAST, vous pouvez gérer ces vulnérabilités directement depuis la merge request, notamment en les ignorant ou en créant des tickets.\n\n#### Personnalisation des jobs de détection des secrets\n\nGitLab vous permet de remplacer une définition de job de détection des secrets afin de modifier des propriétés telles que des variables, des dépendances ou des règles. Vous pouvez le faire en déclarant un job du même nom que le job de détection des secrets. Ensuite, placez ce nouveau job après l'inclusion du template et spécifiez toutes les clés supplémentaires en dessous. Par exemple, la configuration suivante :\n\n- écrase l'étape du job de détection des secrets sur `sécurité`\n- permet l'analyse de l'historique\n- passe à la version 4.5 de Secrets Analyzer\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nsecret_detection:\n  stage: security\n  variables :\n    SECRET_DETECTION_HISTORIC_SCAN : \"true\"\n    SECRETS_ANALYZER_VERSION : \"4.5\"\n```\n\n**Remarque :** Les jobs de détection des secrets disponibles peuvent être trouvés dans le [template SAST.gitlab-ci.yml](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml). Vous trouverez les configurations disponibles dans notre [documentation sur les variables CI/CD de détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#customizing-analyzer-settings).\n\n#### Personnalisation des ensembles de règles de détection des secrets\n\nLe scanner de détection des secrets vous permet de personnaliser les secrets signalés dans l'interface utilisateur de GitLab. Les options de personnalisation suivantes peuvent être utilisées séparément ou en combinaison :\n\n- désactiver les règles prédéfinies\n- remplacer les règles prédéfinies\n- synthétiser une configuration personnalisée\n- spécifier un fichier de configuration à distance\n\nPar exemple, en créant le fichier `.gitlab/secret-detection-ruleset.toml`, dans le répertoire racine de votre projet, le paquet GitLeaks par défaut est étendu pour ignorer les jetons de test de la détection :\n\n```yaml\n### extended-gitleaks-config.toml\ntitle = \"extension of gitlab's default gitleaks config\"\n\n[extend]\n### Extends default packaged path\npath = \"/gitleaks.toml\"\n\n[allowlist]\n  description = \"allow list of test tokens to ignore in detection\"\n  regexTarget = \"match\"\n  regexes = [\n    '''glpat-1234567890abcdefghij''',\n  ]\n```\n\nPour plus d'informations sur le remplacement des règles prédéfinies du scanner, consultez notre [documentation sur la détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#override-predefined-analyzer-rules).\n\n#### Réponse automatique aux secrets divulgués\n\nLa détection des secrets de GitLab répond automatiquement lorsqu'elle trouve certains types de secrets divulgués. Les réponses automatiques peuvent :\n- révoquer automatiquement le secret\n- notifier le partenaire qui a émis le secret afin qu'il puisse le révoquer, notifier son propriétaire ou se protéger contre les abus\n\nGitLab peut également informer les partenaires lorsque les identifiants de connexion qu'ils émettent sont divulgués dans des dépôts publics sur GitLab.com. Si vous utilisez un produit cloud ou SaaS et que vous souhaitez recevoir ces notifications, vous pouvez implémenter une API partenaire, appelée par l'API de révocation de jetons GitLab. Consultez notre [documentation sur la réponse automatique aux secrets divulgués](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html) pour en savoir plus.\n\n### Sécurité de la chaîne d'approvisionnement\n\nGitHub vous permet de sécuriser, de gérer et de signaler des chaînes d'approvisionnement logicielles grâce à des mises à jour de sécurité et de version automatisées et à des [SBOM](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"Qu'est-ce qu'un SBOM ? \") en un clic. GitLab peut répondre à vos besoins en matière de sécurité de la chaîne d'approvisionnement à l'aide des fonctionnalités d'analyse des dépendances et de liste des dépendances (SBOM).\n\nPour activer l'analyse des dépendances dans GitLab, vous pouvez simplement ajouter le template suivant à votre fichier `.gitlab-ci.yml` :\n\n```yaml\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n```\n\nUne fois le template ajouté, chaque fois qu'un nouveau code est enregistré, l'analyse des dépendances détectera automatiquement les [gestionnaires de paquets](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers) utilisés dans votre projet. Elle analysera ensuite les dépendances utilisées pour détecter les vulnérabilités connues.\n\nLes résultats de l'analyse des dépendances de la différence entre la branche de fonctionnalité et la branche cible s'affichent dans le widget de merge request. Le widget de merge request affiche les résultats et les résolutions de l'analyse des dépendances qui ont été introduits par les modifications apportées à la merge request. Dans une merge request, chaque vulnérabilité affiche des informations pertinentes pour aider à la remédiation, telles que les identifiants, les preuves et les solutions :\n\n![Détails de la vulnérabilité de l'analyse des dépendances](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/6-Dependency-Scanner-MR-View-Detailed.png)\n\nComme pour SAST et la détection des secrets, vous pouvez remédier à ces vulnérabilités directement depuis la merge request, notamment en les ignorant ou en créant des tickets.\n\n#### Configuration de l'analyse des dépendances\n\nPour remplacer une définition de job (par exemple, pour modifier des propriétés telles que des variables ou des dépendances), déclarez un nouveau job du même nom que celui à remplacer. Placez ce nouveau job après l'inclusion du modèle et spécifiez toutes les clés supplémentaires en dessous. Par exemple, le code suivant :\n\n- désactive la correction automatique des dépendances vulnérables\n- nécessite un job de compilation à terminer avant l'analyse des dépendances\n\n```yaml\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n\ngemnasium-dependency_scanning:\n  variables:\n    DS_REMEDIATE: \"false\"\n  dependencies: [\"build\"]\n```\n\nPour en savoir plus sur la configuration des scanners de dépendances, consultez notre [documentation sur la personnalisation du comportement des scanners](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#customizing-analyzer-behavior).\n\n#### Génération d'une SBOM\n\nGitLab fournit une liste des dépendances (SBOM) pour examiner les dépendances de votre projet ou de votre groupe et les détails clés sur ces dépendances, notamment leurs vulnérabilités connues. Cette liste est un ensemble de dépendances dans votre projet qui comprend les résultats existants et nouveaux. La liste des dépendances est générée après l'exécution réussie du scanner de dépendances sur la [branche par défaut](https://docs.gitlab.com/ee/user/project/repository/branches/default.html). Pour accéder à la liste des dépendances :\n\n1. Dans la barre latérale gauche, sélectionnez **Rechercher ou accéder à** et trouvez votre projet.\n2. Sélectionnez **Sécurisation > Liste des dépendances**.\n\n![Liste des dépendances (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/7-Dependency-List.png)\n\nDe là, vous pouvez voir les informations suivantes sur vos dépendances :\n\n| Champ\t| Description |\n| ----- | ----------- | \n|Composant\t| Le nom et la version de la dépendance. |\n| Empaqueteur | L'empaqueteur utilisé pour installer la dépendance. |\n| Emplacement | Pour les dépendances système, cela répertorie l'image qui a été analysée. Pour les dépendances d'application, cela affiche un lien vers le fichier de verrouillage propre à l'empaqueteur dans votre projet qui a déclaré la dépendance. Il affiche également le chemin d'accès vers une dépendance racine le cas échéant, et si cette option est prise en charge. |\n| Licence | Liens vers les licences logicielles de la dépendance. Un badge d'avertissement qui inclut le nombre de vulnérabilités détectées dans la dépendance. |\n| Projets | Liens vers le projet avec la dépendance. Si plusieurs projets ont la même dépendance, le nombre total de ces projets est affiché. Pour accéder à un projet avec cette dépendance, sélectionnez le numéro du projet, puis recherchez et sélectionnez son nom. La fonctionnalité de recherche de projet n'est prise en charge que sur les groupes qui ont jusqu'à 600 occurrences dans leur hiérarchie de groupe. |\n\n\u003Cp>\u003C/p>\n\nConsultez notre [documentation sur la liste des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_list/) pour en savoir plus.\n\n### Administration de la sécurité et de la conformité\n\nGitHub Advanced Security vous permet de visualiser les métriques et les informations clés sur la sécurité et d'évaluer les risques de sécurité liés au code. Examinons maintenant comment faire de même avec GitLab Ultimate.\n\n#### Affichage des métriques et des informations clés sur la sécurité\n\nGitLab fournit des [tableaux de bord de sécurité](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) pour aider à évaluer la posture de sécurité de vos applications. Ces tableaux de bord affichent un ensemble de métriques, d'évaluations et de graphiques pour les vulnérabilités détectées par les scanners de sécurité exécutés sur votre projet :\n\n- tendances des vulnérabilités sur une période de 30, 60 ou 90 jours pour tous les projets d'un groupe\n- une note pour chaque projet en fonction de la gravité de la vulnérabilité\n- le nombre total de vulnérabilités détectées au cours des 365 derniers jours, y compris leur gravité\n\nPour accéder au tableau de bord de sécurité :\n\n1. Dans la barre latérale gauche, sélectionnez **Rechercher ou accéder à** et trouvez votre projet ou votre groupe.\n2. Dans l'onglet latéral, sélectionnez **Sécurisation > Tableau de bord de sécurité**.\n3. Filtrez et recherchez ce dont vous avez besoin.\n\nLa vue de groupe affiche votre posture de sécurité pour tous les projets de votre groupe :\n\n![Tableau de bord de sécurité de groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/8-SD-Group.png)\n\nLa vue du projet affiche votre posture de sécurité pour un seul projet :\n\n![Tableau de bord de sécurité de projet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/9-SD-Project.png)\n\n#### Évaluer le risque de sécurité du code\n\nGitLab Ultimate dispose d'un [rapport de vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/), qui fournit des informations sur les vulnérabilités des scans de la branche par défaut. Il contient les résultats cumulés de tous les jobs réussis, que l’exécution du pipeline ait réussi ou non. À tous les niveaux, le rapport de vulnérabilités contient :\n\n- le nombre total de vulnérabilités par niveau de gravité\n- les filtres des attributs de vulnérabilité courants\n- les détails de chaque vulnérabilité, présentés sous forme de tableau\n\n![Rapport de vulnérabilités](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/10-Vulnerability-Report.png)\n\nCliquer sur une vulnérabilité permet d'accéder à sa [page de vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/), qui contient un certain nombre d'informations : une description, un emplacement, des identifiants et plus encore. Voici un exemple de page pour une vulnérabilité d'injection SQL détectée par notre scanner SAST :\n\n![Page sur les vulnérabilités d'injection SQL](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/11-Vulnerability-Page-1.png)\n\nÀ partir de là, l'équipe de sécurité peut collaborer en [modifiant le statut d'une vulnérabilité](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#change-the-status-of-a-vulnerability), en ajoutant un motif et en [créant des tickets pour mieux suivre les changements apportés](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-gitlab-issue-for-a-vulnerability).\n\nDepuis la page de vulnérabilités, vous pouvez également tirer parti de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), notre suite de fonctionnalités alimentée par l'IA, pour expliquer la vulnérabilité et [créer automatiquement une merge request qui la résout](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution).\nL'[explication des vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-explanation) de GitLab Duo utilise un grand modèle de langage pour :\n\n- résumer la vulnérabilité\n- aider les équipes de développement et les analystes en sécurité à comprendre la vulnérabilité, comment elle pourrait être exploitée et comment y remédier\n- suggérer une atténuation\n\n![Explication via l'IA de GitLab Duo de l'injection SQL](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/13-Explain-Vulnerability.png)\n\n## Fonctionnalités de sécurité supplémentaires de GitLab Ultimate\n\nGitLab Ultimate contient de nombreuses autres fonctionnalités de sécurité. En voici quelques exemples : des scanners de sécurité supplémentaires pour le cycle de vie complet du développement logiciel (SDLC), des garde-fous de sécurité granulaires et des autorisations personnalisées.\n\n### Scanners de sécurité pour l'ensemble du SDLC\n\nNotre portefeuille de scanners de sécurité s'étend à l'ensemble du SDLC.\n\n| Nom du scanner | Scans | Langages/Fichiers analysés|\n|  -------------- | ----- | ------------------------- |\n| [Tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) | Code source statique | C/C++, Java, Python, Go, JavaScript, C# et plus encore |\n| [Tests dynamiques de sécurité des applications (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/) | Application Web en cours d'exécution, API en direct | Langage-agnostique |\n| [Analyse de l'Infrastructure as Code (IaC)](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) | Fichiers IaC |Terraform, AWS Cloud Formation, Ansible et plus encore |\n| [Analyse des conteneurs](https://docs.gitlab.com/ee/user/application_security/container_scanning/) | Images de conteneurs statiques et en cours d'exécution | Dockerfile |\n| [Analyse des dépendances et des licences](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) | Dépendances d'applications | Requirements.txt, Yarn, Gradle, Npm et plus encore |\n| [Tests d'API Web par injection de données aléatoires](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/) | Envoie des données aléatoires/invalides à l'API Web | OpenAPI, GraphQL, HAR, Collection Postman |\n| [Test à données aléatoires guidé par la couverture de code](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/) | Envoie des données aléatoires/invalides à la fonction | C/C++, Go, Swift, Python, Rust, Java, JavaScript, AFL |\n\n\u003Cp>\u003C/p>\n\nGitLab vous permet également d'intégrer des [scanners tiers](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/) et des [scanners personnalisés](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/) à la plateforme. Une fois intégrés, les résultats du scanner sont automatiquement présentés à différents emplacements dans GitLab, tels que dans la vue pipeline, le widget de merge request et le tableau de bord de sécurité. Consultez notre [documentation sur l'intégration du scanner de sécurité](https://docs.gitlab.com/ee/development/integrations/secure.html) pour en savoir plus.\n\n### Stratégies de sécurité et de conformité granulaires\n\nLes stratégies de GitLab fournissent aux équipes de sécurité et de conformité [un moyen d'appliquer des contrôles à l'échelle globale dans leur entreprise](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/). Les équipes de sécurité peuvent s'assurer que :\n\n- les scanners de sécurité sont appliqués dans les pipelines de l'équipe de développement selon une configuration appropriée\n- tous les jobs de scan s'exécutent sans modification ni altération\n- les approbations appropriées sont fournies sur les merge requests en fonction des résultats de ces constatations\n\n![Politiques de sécurité des requêtes de fusion](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/14-MR-Policy.png)\n\nLes équipes de conformité peuvent appliquer de manière centralisée plusieurs approbateurs à toutes les merge requests et s'assurer que divers paramètres sont activés sur les projets dans le cadre des exigences de leur entreprise, comme l'activation ou le verrouillage des paramètres de merge request et de dépôt. Pour en savoir plus, consultez notre documentation de la [stratégie de sécurité de GitLab](https://docs.gitlab.com/ee/user/application_security/policies/).\n\n### Rôles personnalisés et autorisations granulaires\n\n[GitLab Ultimate fournit des rôles personnalisés](https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles/), qui permettent la création de rôles utilisateur disposant des privilèges et des autorisations requis en fonction des besoins de l'entreprise. \n\nPar exemple, un utilisateur pourrait créer un rôle « Auditeur de sécurité » avec des autorisations lui permettant d'afficher les vulnérabilités de sécurité dans le système, mais sans être en mesure de voir le code source ni d'effectuer des modifications dans le dépôt. Cet ensemble granulaire d'autorisations permet une séparation bien définie des tâches.\n\n![Création de rôle personnalisé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/15-Custom-Roles.png)\n\nPour en savoir plus, consultez notre documentation sur les [rôles personnalisés](https://docs.gitlab.com/ee/user/custom_roles.html) et les [autorisations granulaires disponibles](https://docs.gitlab.com/ee/user/custom_roles/abilities.html).\n\n### Centre de conformité \n\nLe Centre de conformité permet aux équipes dédiées de gérer les rapports sur le respect des normes de conformité, les rapports sur les violations et les frameworks de conformité pour leur groupe. Le Centre de conformité comprend les éléments suivants :\n\n- Le [tableau de bord du respect des normes de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_standards_adherence_dashboard.html), qui répertorie l'état de conformité des projets répondant à la norme GitLab.\n- Le [rapport sur les violations des exigences de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html) affiche une vue d'ensemble des activités liées aux merge requests pour tous les projets du groupe.\n- Le [rapport sur les frameworks de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html) montre tous les frameworks de conformité au sein d'un groupe.\n- Le [rapport sur les projets de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_projects_report.html) montre les frameworks de conformité appliqués aux projets dans un groupe.\n\n![Centre de conformité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/16-Compliance-Center.png)\n\nCes tableaux de bord aident à s'assurer que la séparation des tâches est respectée pour optimiser la conformité au sein de votre entreprise. Pour en savoir plus, consultez notre [documentation sur notre Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/).\n\n## En savoir plus\n\nCet article ne couvre qu'une partie du large éventail de fonctionnalités de sécurité offertes par GitLab Ultimate. Consultez ces ressources pour en savoir plus sur la façon dont GitLab Ultimate peut vous aider à améliorer la sécurité de votre entreprise et l'efficacité des équipes de développement :\n\n- [Pourquoi GitLab Ultimate ?](https://about.gitlab.com/pricing/ultimate/)\n- [Tutoriel de prise en main de l'approche DevSecOps](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n- [Premiers pas avec l'exemple de projet DevSecOps](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n- [Importer votre projet de GitHub vers GitLab](https://docs.gitlab.com/ee/user/project/import/github.html)\n- [Migration depuis GitHub Actions](https://docs.gitlab.com/ee/ci/migration/github_actions.html)\n- [Tutoriel : créer et exécuter votre premier pipeline GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/)\n- [Tutoriel : créer un pipeline complexe](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html)\n- [Référence de la syntaxe YAML CI/CD](https://docs.gitlab.com/ee/ci/yaml/)",[685,796,14,686,797],"zero trust","testing",{"slug":799,"featured":93,"template":691},"migration-guide-github-advanced-security-to-gitlab-ultimate","content:fr-fr:blog:migration-guide-github-advanced-security-to-gitlab-ultimate.yml","Migration Guide Github Advanced Security To Gitlab Ultimate","fr-fr/blog/migration-guide-github-advanced-security-to-gitlab-ultimate.yml","fr-fr/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"_path":805,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":806,"content":812,"config":818,"_id":820,"_type":16,"title":821,"_source":18,"_file":822,"_stem":823,"_extension":21},"/fr-fr/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"title":807,"description":808,"ogTitle":807,"ogDescription":808,"noIndex":6,"ogImage":809,"ogUrl":810,"ogSiteName":675,"ogType":676,"canonicalUrls":810,"schema":811},"Comment intégrer vos propres scanners de sécurité dans GitLab","Découvrez comment enrichir votre usage de la plateforme DevSecOps en ajoutant des scanners de sécurité personnalisés à vos workflows.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097082/Blog/Hero%20Images/Blog/Hero%20Images/securitycheck_securitycheck.png_1750097081856.png","https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment intégrer vos propres scanners de sécurité dans GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-27\",\n      }",{"title":807,"description":808,"authors":813,"heroImage":809,"date":814,"body":815,"category":14,"tags":816,"updatedDate":817},[681],"2024-02-27","GitLab, la plateforme DevSecOps la plus complète, dispose de toutes les fonctionnalités nécessaires pour planifier, gérer, compiler, déployer, sécuriser, gouverner et surveiller vos applications. Vous pouvez toutefois utiliser en complément des outils tiers ou personnalisés, par exemple si vous devez migrer vers une plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ? \") à partir de solutions distinctes, évaluer des outils tiers ou intégrer des solutions propriétaires ou personnalisées dans GitLab.\n\n## Extensibilité de la plateforme DevSecOps de GitLab\n\nLa plateforme DevSecOps de GitLab peut être enrichie de nombreuses façons afin de prendre en charge les fonctionnalités améliorées dont votre entreprise a besoin. \n\nVoici quelques exemples d'intégrations courants :\n\n- Intégrations d'applications externes, telles que Jenkins et Slack\n- Intégrations de systèmes externes de gestion des tickets, tels que Bugzilla et Jira\n- Intégrations de fournisseurs d'authentification externes, tels que LDAP et SAML\n- Intégrations de scanners de sécurité externes, tels que Fortify et Checkmarx\n- Détection et gestion de secrets exposés, tels que les clés d'accès AWS et GCP\n\nConsultez notre [documentation](https://docs.gitlab.com/ee/integration/) pour connaître toutes les intégrations disponibles (liste non exhaustive). \n\n## Intégration de scanners de sécurité dans GitLab\n\nIl est possible d'intégrer des [scanners de sécurité tiers](https://docs.gitlab.com/ee/integration/#security-improvements) ou des [scanners de sécurité personnalisés](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration) dans GitLab. Ces scanners peuvent ainsi alimenter plusieurs sections clés de l'interface GitLab, telles que le widget de sécurité des merges requests, la section Sécurité des pipelines, le rapport de vulnérabilités, les pages de vulnérabilités, le tableau de bord de sécurité ainsi que les politiques d'approbation des merge requests. \n\nPassons en revue chacune de ces intégrations.\n\n### Widget de sécurité des merge requests\n\nUne merge request contient un widget de sécurité qui affiche un résumé des vulnérabilités récemment détectées.\n\n![intégration de scanners de sécurité - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097088837.png)\n\n\u003Ccenter>\u003Ci>Widget de sécurité des merge requests\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nLorsque vous cliquez sur une vulnérabilité, la fenêtre contextuelle qui s'affiche contient les informations suivantes :\n- Statut\n- Description\n- Projet\n- Fichier\n- Identifiants\n- Gravité\n- Outil\n- Fournisseur du scanner\n\n![intégration de scanners de sécurité - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097088838.png)\n\n\u003Ccenter>\u003Ci>Vulnérabilités exploitables et détails associés\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nCes vulnérabilités sont également exploitables, ce qui signifie qu'elles peuvent être rejetées ou qu'un ticket confidentiel peut être créé.\n\nLes résultats d'un scanner personnalisé peuvent être utilisés pour alimenter le widget de sécurité. Les données de vulnérabilité sont renseignées à partir du schéma JSON généré par le scanner.\n\n### Section Sécurité des pipelines\n\nTous les scanners de sécurité activés s'exécutent dans le pipeline et génèrent leurs résultats sous forme d'artefacts qui font l'objet d'un traitement (déduplication incluse). Les résultats sont ensuite répertoriés dans l'onglet Sécurité des pipelines. À partir de là, vous pouvez également télécharger les fichiers JSON générés.\n\n![intégration de scanners de sécurité - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097088840.png)\n\n\u003Ccenter>\u003Ci>Onglet Sécurité des pipelines\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nLes résultats d'un scanner personnalisé peuvent être utilisés pour alimenter l'onglet Sécurité des pipelines. Les colonnes sont remplies à l'aide du schéma JSON émis par le scanner.\n\n### Rapport de vulnérabilités\n\nLe rapport de vulnérabilités fournit des informations sur les vulnérabilités issues des scans de la branche par défaut, notamment :\n\n- Le nombre total de vulnérabilités par niveau de gravité\n- Les filtres d'attributs de vulnérabilité courants\n- Les détails de chaque vulnérabilité, présentés sous forme de tableau\n\n![intégration de scanners de sécurité - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097088842.png)\n\n\u003Ccenter>\u003Ci>Rapport de vulnérabilités\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nLes résultats d'un scanner personnalisé sur la branche par défaut peuvent être utilisés pour alimenter le rapport de vulnérabilités.\n\n### Pages de vulnérabilités\n\nEn cliquant sur une vulnérabilité présente dans le rapport de vulnérabilités, vous accédez à une page dédiée comprenant les informations suivantes : \n\n- sa description\n- la date de détection\n- son statut actuel\n- son emplacement  \n- les actions disponibles pour y remédier\n- les tickets liés à cette vulnérabilité\n- le log des actions effectuées sur cette vulnérabilité\n- les solutions proposées\n- un identifiant \n- des ressources de formation pour prévenir ce type de faille\n\nVous pouvez utiliser les données fournies dans la page de vulnérabilité pour évaluer l’importance du problème et prendre les mesures nécessaires pour corriger la vulnérabilité efficacement.\n\n![intégration de scanners de sécurité - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097088844.png)\n\n\u003Ccenter>\u003Ci>Page de vulnérabilité pour une faille relative à la détection des secrets\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nLes résultats d'un scanner personnalisé peuvent être utilisés pour alimenter la page de vulnérabilité. Les données de vulnérabilité sont renseignées à partir du schéma JSON généré par le scanner.\n\n### Tableau de bord de sécurité\n\nLes tableaux de bord de sécurité permettent d'évaluer la posture de sécurité de vos applications. GitLab vous fournit un ensemble d'indicateurs, d'évaluations et de graphiques correspondant aux vulnérabilités détectées par les scanners de sécurité exécutés sur votre projet. Le tableau de bord de sécurité fournit différentes données, notamment :\n\n- Les tendances des vulnérabilités sur une période de 30, 60 ou 90 jours pour tous les projets d'un groupe\n- Une note sous forme de lettre pour chaque projet en fonction de la gravité de la vulnérabilité\n- Le nombre total de vulnérabilités détectées au cours des 365 derniers jours et leurs niveaux de gravité\n\n![intégration de scanners de sécurité - image 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097088846.png)\n\n\u003Ccenter>\u003Ci>Tableau de bord de sécurité au niveau du groupe\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nÀ partir du tableau de bord de sécurité au niveau du groupe, vous pouvez cliquer sur un projet pour accéder au tableau de bord de sécurité associé, qui fournit une vue sur 365 jours.\n\n![intégration de scanners de sécurité - image 7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097088847.png)\n\n\u003Ccenter>\u003Ci>Tableau de bord de sécurité au niveau du projet\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n### Intégration des politiques d'approbation des merge requests \n\nLes politiques d'approbation des merge requests, anciennement désignées comme stratégies de sécurité basées sur les résultats de scan dans les versions précédentes de GitLab, sont utilisées pour exiger une approbation en fonction des résultats d'un ou de plusieurs jobs de scan de sécurité. L'objectif est d'éviter que du code non sécurisé ne soit fusionné et déployé en production. Ces politiques sont évaluées après l'exécution complète des jobs de scan dans les pipelines CI, en s'appuyant sur les rapports générés par les artefacts de job et publiés dans le pipeline une fois celui-ci terminé.\n\nPar exemple, vous pouvez créer une politique d'approbation des merge requests qui exige l'approbation des chargés de maintenance du projet dans le cas où le scanner de détection de secrets détecte des vulnérabilités. Voici comment procéder :\n\n1. Dans la barre latérale gauche, cliquez sur **Rechercher ou accéder à** et recherchez le projet auquel vous souhaitez ajouter une politique.\n\n2. Dans la barre latérale gauche du projet, accédez à **Sécurisation > Politiques**\n\n3. Sélectionnez **Nouvelle stratégie de sécurité**\n\n4. Dans la section **Politiques d'approbation des merge requests**, sélectionnez **Sélectionner une stratégie de sécurité**.\n\n5. Renseignez les champs suivants :\n- Nom : le nom de la politique d'approbation\n- Description : la description de la politique d'approbation\n- État : indique si la politique d'approbation est activée ou non\n- Règles : les conditions qui doivent être remplies pour déclencher une action (comme exiger une approbation)\n\n![intégration de scanners de sécurité - image 8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097088849.png)\n\u003Ccenter>\u003Ci>Règles de la politique d'approbation des merge requests\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- Actions : l'action à entreprendre chaque fois que les conditions définies dans les règles (vulnérabilités/licences détectées) sont remplies\n\n![intégration de scanners de sécurité - image 9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097088850.png)\n\n\u003Ccenter>\u003Ci>Actions associées à la politique d'approbation des merge requests\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- Remplacer les paramètres d'approbation du projet : si cette option est sélectionnée, les choix suivants écraseront les paramètres du projet, mais uniquement pour les branches spécifiées dans la politique d'approbation des merges requests.\n\n![intégration de scanners de sécurité - image 11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097088851.png)\n\n \u003Ccenter>\u003Ci>Paramètres d'approbation de la politique d'approbation des merge requests\u003C/i>\u003C/center>\n \u003Cp>\u003C/p>\n\n6. Cliquez sur le bouton **Configurer avec une merge request**.\n\nUne fois que la politique d'approbation des merge requests a été fusionnée, chaque fois que vous créez une merge request et que les critères définis dans les règles sont remplis, l'action définie est déclenchée. Dans ce cas, au moins une approbation de la part d'un chargé de maintenance sera requise avant que le code puisse être fusionné.\n\n![scanner de sécurité intégré - image 10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097088852.png)\n\n\u003Ccenter>\u003Ci>Merge request bloquée en raison de vulnérabilités détectées\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nLes résultats d'un scanner personnalisé peuvent être entièrement intégrés aux politiques d'approbation des merge requests. Si le scanner personnalisé détecte une vulnérabilité, une approbation sera alors requise avant que le code puisse être fusionné. Le scanner que vous sélectionnez dans une telle politique doit utiliser le schéma JSON approprié.\n\n## Tutoriel : intégration de scanners de sécurité personnalisés\n\nPassons maintenant à la partie la plus intéressante : l'intégration d'un scanner de sécurité personnalisé. Dans ce tutoriel, vous apprendrez à créer un scanner de sécurité personnalisé, ainsi qu'à l'intégrer à GitLab. Nous nous appuierons sur les projets suivants :\n\n- [Fern Pattern Scanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner) : analyse vos fichiers à la recherche de motifs spécifiques tels que les mots de passe, les clés privées et les numéros de sécurité sociale.\n- [Secret List](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/secret-list) : contient une liste répertoriant des mots de passe d'utilisateurs et de clients, et des clés. Ce projet sert à démontrer comment un scanner de sécurité personnalisé peut être intégré à GitLab.\n\nPour en savoir plus, consultez la vidéo suivante : \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/timMbl5SP-w?si=R2DKtZ5MmBR1rQFL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Création d'un scanner de sécurité personnalisé\n\nCréons maintenant un scanner personnalisé qui peut être intégré à GitLab. Avant qu'un scanner personnalisé puisse être entièrement intégré à GitLab, il doit respecter les conditions suivantes :\n- scanner un répertoire à la recherche de motifs définis\n- générer un fichier JSON conforme au schéma approprié\n- être conteneurisé et accessible depuis GitLab\n- fournir un template autorisant son exécution sur un autre projet\n\nLorsque le [Fern Pattern Scanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner) est exécuté sur un projet à l'aide du template fourni, il effectue les étapes suivantes :\n1. Il charge un ensemble de règles qui définissent les motifs (regex) à détecter.\n- Il permet la configuration des règles afin de s'adapter aux besoins en constante évolution de votre entreprise.\n2. Il scanne les fichiers à la recherche des motifs définis.\n3. Il génère un rapport JSON conforme au schéma de détection des secrets.\n- Il utilise des templates Go pour créer ce fichier JSON.\n- Veillez à utiliser le schéma adéquate, selon les éléments que votre scanner doit rechercher.\n\nUne fois le rapport JSON chargé en tant qu'artefact dans GitLab, il alimente le widget de sécurité des merges requests, le rapport de vulnérabilités, les pages de vulnérabilités, les politiques d'approbation des merge requests ainsi que les tableaux de bord de sécurité, comme décrit précédemment.\n\n### Intégration d'un scanner de sécurité personnalisé à GitLab\n\nUne fois que vous avez créé votre scanner personnalisé qui répond à tous les besoins d'intégration, vous pouvez l'exécuter sur GitLab.\n\nExécuter un scanner personnalisé est aussi simple que d'ajouter un template. Par exemple, le template Fern Pattern Scanner est chargé dans le fichier `.gitlab-ci.yml` sur le projet [Secret List](https://gitlab.com/gitlab-da/tutorials/security-and-governance/custom-scanner-integration/secret-list).\n\nVoici les étapes à suivre :\n\n1. Créez un [fichier .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/quick_start/#create-a-gitlab-ciyml-file) dans le projet sur lequel vous souhaitez exécuter le scanner.\n\n2. Incluez le [template du scanner personnalisé](https://docs.gitlab.com/ee/ci/yaml/includes.html).\n    - Vous pouvez également configurer ce template avec des variables d'environnement.\n\n3. Validez ce fichier dans la branche principale.\n\nUne fois le fichier validé, vous pouvez constater que le scanner personnalisé s'exécute dans votre pipeline. Une fois le pipeline terminé, le scanner alimentera toutes les zones définies ci-dessus dans la section [Intégration de scanners de sécurité dans GitLab](#gitlab-security-scanner-integration).\n\nPour en savoir plus, consultez les ressources ci-dessous et les autres possibilités d'extension de votre plateforme DevSecOps :\n\n- [Intégration du scanner de sécurité dans GitLab](https://docs.gitlab.com/ee/development/integrations/secure.html)\n- [Intégrations des partenaires GitLab](https://docs.gitlab.com/ee/integration/)\n- [Groupe de projets du scanner de sécurité personnalisé](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration)\n- [Réponse automatique à une fuite de secret](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html)\n",[685,14,797,686],"2025-06-09",{"slug":819,"featured":93,"template":691},"how-to-integrate-custom-security-scanners-into-gitlab","content:fr-fr:blog:how-to-integrate-custom-security-scanners-into-gitlab.yml","How To Integrate Custom Security Scanners Into Gitlab","fr-fr/blog/how-to-integrate-custom-security-scanners-into-gitlab.yml","fr-fr/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"_path":825,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":826,"content":832,"config":839,"_id":841,"_type":16,"title":842,"_source":18,"_file":843,"_stem":844,"_extension":21},"/fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey",{"title":827,"description":828,"ogTitle":827,"ogDescription":828,"noIndex":6,"ogImage":829,"ogUrl":830,"ogSiteName":675,"ogType":676,"canonicalUrls":830,"schema":831},"ISO 27001: comment GitLab vous assiste dans votre démarche de conformité ","Les fonctionnalités de sécurité logicielle de GitLab peuvent vous aider à vous conformer à la norme ISO 27001.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png","https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ISO 27001: comment GitLab vous assiste dans votre démarche de conformité \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2023-09-06\",\n      }",{"title":827,"description":828,"authors":833,"heroImage":829,"date":834,"body":835,"category":14,"tags":836,"updatedDate":838},[750],"2023-09-06","En tant que plateforme unique et complète, GitLab vous permet de gérer votre cycle de vie DevSecOps facilement. En effet, la plateforme GitLab permet aux développeurs de créer des logiciels de qualité plus rapidement, mais son efficacité s'étend toutefois au-delà du DevSecOps.\n\nEn octobre 2022, l'Organisation internationale de normalisation a publié la dernière édition de la norme ISO 27001. Cette norme ISO/IEC 27001:2022 comprend plusieurs modifications par rapport à sa version précédente, dont l'ajout de contrôles dans l'annexe A. Ceux-ci sont axés sur le codage sécurisé et la gestion de la configuration.\n\nChez GitLab, nous utilisons notre plateforme pour prendre en charge de nombreux aspects de notre programme de conformité en matière de sécurité : un concept que nous appelons en interne le [dogfooding](https://about.gitlab.com/direction/dogfooding/). Vous trouverez un aperçu des accréditations de conformité et d'assurance que nous conservons sur notre page dédiée au [Centre de gestion et protection des données](https://about.gitlab.com/security/).\n\nVoyons à présent les principales fonctions à votre disposition pour vous conformer à la norme ISO 27001.\n\n## Contrôles organisationnels\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 5.3 Séparation des tâches | Les tâches et les domaines de responsabilité incompatibles doivent être séparés. |\n| 5.15 Contrôle d'accès | Des règles visant à contrôler l'accès physique et logique aux informations et autres actifs associés en fonction des exigences métier et de sécurité de l'information doivent être définies et mises en œuvre. |\n| 5.16 Gestion des identités | Le cycle de vie complet des identités doit être géré. |\n| 8.2 Droits d'accès privilégiés | L'attribution et l'utilisation des droits d'accès privilégiés doivent être limitées et gérées.|\n| 8.4 Accès aux codes source | L'accès en lecture et en écriture au code source, aux outils de développement et aux bibliothèques de logiciels doit être géré de manière appropriée. |\n\nAvec GitLab, vous pouvez [attribuer un rôle aux utilisateurs](https://docs.gitlab.com/ee/user/permissions.html) lorsque vous les ajoutez à un projet ou à un groupe. Le rôle d'un utilisateur détermine les actions qu'il peut effectuer dans votre instance GitLab. Vous pouvez assigner les rôles suivants :\n* Invité (projets privés et internes uniquement)\n* Rapporteur\n* Développeur\n* Chargé de maintenance\n* Propriétaire\n* Accès minimal (disponible uniquement pour le groupe principal)\n\nLes rôles de GitLab vous permettent de limiter les autorisations d'un utilisateur, conformément au [principe de moindre privilège](https://csrc.nist.gov/glossary/term/least_privilege), ainsi qu'à vos exigences en matière de sécurité de l'information et de l’entreprise. \n\nGitLab vous permet également de centraliser les responsabilités d'authentification et d'autorisation pour votre instance GitLab via des intégrations d'[authentification unique basée sur le protocole SAML](https://docs.gitlab.com/ee/user/group/saml_sso/). GitLab intègre un large éventail de fournisseurs d'identité pour prendre en charge les diverses piles technologiques de notre clientèle. De plus, GitLab prend en charge le System for Cross-domain Identity Management ([SCIM](https://docs.gitlab.com/ee/user/group/saml_sso/scim_setup.html)). Ainsi, grâce aux intégrations SSO et SCIM de GitLab, vous pouvez automatiser le cycle de vie de vos identités d'utilisateur de manière sécurisée et efficace.\n\n[SSO](https://docs.gitlab.com/ee/integration/saml.html) et [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html) sont également disponibles pour les clients utilisant GitLab Auto-géré.\n\n**Note :** les contrôles technologiques des points 8.2 et 8.4 de l'annexe A ont été inclus dans le tableau ci-dessus en raison de leur proximité avec les contrôles organisationnels des points 5.3, 5.15 et 5.16. Vous pouvez recourir aux mêmes fonctionnalités de GitLab pour répondre à ces différentes exigences de contrôle.\n\n\u003Cbr>\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 5.8 Sécurité de l'information dans la gestion de projet | La sécurité de l'information doit être intégrée dans la gestion de projet. |\n\nSoutenez vos efforts de gestion de projet et de contrôle sur la sécurité de l'information dans toutes les phases du cycle de vie d'un projet grâce à nos [outils de planification](https://about.gitlab.com/features/?stage=plan).\n\n- Les fonctionnalités de [planification d'équipe](https://about.gitlab.com/features/?stage=plan#team_planning) de GitLab permettent aux utilisateurs d'organiser et de planifier les différentes étapes d'un projet et d’en suivre son avancement, de l'idée à la production.\n\n- Vous pouvez échanger sur vos idées, résoudre des problèmes et planifier vos tâches avec l'équipe de sécurité de l'information grâce aux [epics](https://docs.gitlab.com/ee/user/group/epics/), [tickets](https://docs.gitlab.com/ee/user/project/issues/) et [tâches](https://docs.gitlab.com/ee/user/tasks.html). Les [modèles de description](https://docs.gitlab.com/ee/user/project/description_templates.html) et les [check-lists](https://docs.gitlab.com/ee/user/markdown.html#task-lists) permettent aux utilisateurs d'appliquer systématiquement une description et un workflow aux tickets ou aux [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html). Ces modèles permettent une approche structurée de l'intégration de la sécurité de l'information dans votre cycle de vie de gestion de projet.\n\n- Les [labels](https://docs.gitlab.com/ee/user/project/labels.html) permettent aux utilisateurs d'organiser les tickets en fonction de leurs besoins. Pour assurer le maintien de la sécurité de l'information, utilisez les labels afin d'identifier le niveau de risque associé à un projet, l'étape à laquelle il se trouve, ou encore l'équipe de sécurité de l'information responsable d'un ensemble de tâches. Vous pouvez également profiter des [labels à portée limitée](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) (ou Scoped labels) pour ajouter une logique supplémentaire aux workflows en empêchant l'utilisation simultanée de certains labels. Chez GitLab, nous utilisons les [labels à portée limitée](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) pour identifier les équipes auxquelles sont attribuées les tâches, l'étape du projet dans laquelle elles se trouvent, et le produit ou l'ensemble de fonctionnalités qui leur sont associés.\n\n![Scoped Labels](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/scoped-labels.png)\n\nLabels à portée limitée\n\n- Vous pouvez organiser davantage votre travail et obtenir une vue d'ensemble de toutes les tâches associées à un groupe ou à un projet grâce aux tableaux des tickets du [groupe](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issue-boards) et du [projet](https://about.gitlab.com/stages-devops-lifecycle/issueboard/).\n\n## Contrôles technologiques\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 8.8 Gestion des vulnérabilités techniques | Des informations sur les vulnérabilités techniques des systèmes d'information utilisés doivent être obtenues, l'exposition de l'organisme à ces vulnérabilités doit être évaluée et des mesures appropriées doivent être prises. |\n| 8.9 Gestion des configurations | Les configurations, y compris les configurations de sécurité, du matériel, des logiciels, des services et des réseaux, doivent être définies, documentées, mises en œuvre, surveillées et révisées. |\n| 8.25 Cycle de développement sécurisé | Des règles pour le développement sécurisé des logiciels et des systèmes doivent être établies et appliquées. |\n| 8.26 Exigences de sécurité des applications | Les exigences en matière de sécurité de l'information doivent être identifiées, spécifiées et approuvées lors du développement ou de l'acquisition d'applications. |\n| 8.27 Principes d'ingénierie et d'architecture des systèmes sécurisés | Des principes d'ingénierie des systèmes sécurisés doivent être établis, documentés, tenus à jour et appliqués à toutes les activités de développement de systèmes d'information. |\n\nAvec GitLab, vous pouvez stocker vos configurations matérielles et logicielles, maintenir le contrôle de version, mettre à jour vos configurations via des [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html) et recourir aux [pipelines CI/CD](https://docs.gitlab.com/ee/ci/pipelines/) de GitLab pour pousser ces configurations vers vos applications et votre infrastructure. GitLab permet également aux entreprises d’adopter une approche [GitOps](https://about.gitlab.com/topics/gitops/) via une plateforme unique.\n\nLa fonctionnalité [d'analyse de l'infrastructure en tant que code](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) de GitLab vous permet d'analyser vos fichiers de configuration IaC à la recherche de vulnérabilités connues. L'analyse IaC de GitLab prend en charge une variété de fichiers et de langues de configuration IaC, ce qui la rend adaptable à différentes piles technologiques.\n\nGitLab permet aux professionnels de la conformité de mettre en œuvre l'automatisation via des [frameworks de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) et des [pipelines de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#compliance-pipelines). Ces fonctionnalités permettent aux utilisateurs d'identifier les projets critiques qui possèdent certaines exigences de conformité et d'y pousser des configurations via des pipelines. Elles permettent également une application uniforme des contrôles, soutenant ainsi votre posture de sécurité et facilitant le respect des exigences de conformité internes et externes de votre entreprise.\n\nPour les clients [Ultimate](https://about.gitlab.com/pricing/ultimate/), le [Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html) de GitLab fournit une vue centralisée de la posture de conformité d'un groupe en mettant par exemple en évidence les différents frameworks de conformité appliqués aux projets du groupe. Vous pouvez même évaluer votre degré de conformité à la [norme GitLab](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html#gitlab-standard).\n\n\u003Cbr>\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 8.15 Journalisation | Les journaux qui enregistrent les activités, les exceptions, les défaillances et autres événements pertinents doivent être générés, stockés, protégés et analysés. |\n| 8.16 Activités de surveillance | Les réseaux, systèmes et applications doivent être surveillés pour détecter les comportements anormaux et des mesures appropriées doivent être prises pour évaluer les éventuels incidents en matière de sécurité de l'information. |\n\nDans GitLab, vous pouvez utiliser les [événements d'audit](https://docs.gitlab.com/ee/administration/audit_events.html) pour suivre les événements importants, y compris l'auteur de chaque action et sa date d'exécution. Les événements d'audit couvrent un large éventail de catégories, notamment :\n* Gestion des groupes\n* Authentification et autorisation\n* Gestion des utilisateurs\n* Conformité et sécurité\n* CI/CD\n* GitLab Runners\n\n![Événements d'audit](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/example-of-an-audit-event.png)\n\nExemple d'événement d'audit\n{: .note.text-center}\n\nLe [streaming d'événements d'audit](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) est disponible pour les clients [Ultimate](https://about.gitlab.com/pricing/ultimate/). Le streaming d'événements d'audit permet aux utilisateurs de définir une destination de streaming pour un groupe principal ou une instance principale afin de recevoir tous les événements d'audit du groupe, des sous-groupes et des projets sous forme de document JSON structuré.\n\n\u003Cbr>\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 8.28 Codage sécurisé | Des principes de codage sécurisé doivent être appliqués au développement de logiciels. |\n| 8.29 Tests de sécurité dans le développement et l'acceptation | Des processus pour les tests de sécurité doivent être définis et mis en œuvre au cours du cycle de développement. | \n\nVous pouvez optimiser votre cycle de développement logiciel et améliorer la sécurité de vos produits grâce aux fonctionnalités de la phase de [sécurisation](https://about.gitlab.com/features/?stage=secure) de GitLab. Les fonctionnalités de cette phase comprennent :\n* [Des tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n* [Des tests dynamiques de sécurité des applications (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n* [La qualité du code](https://docs.gitlab.com/ee/ci/testing/code_quality.html)\n* [L'analyse des conteneurs](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n* [L'analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n\nEt bien plus encore !\n\n![Découvertes relatives à la qualité du code](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/code-quality-findings.png)\n\nDécouvertes relatives à la qualité du code\n{: .note.text-center}\n\nLes fuites de secrets sont à l'origine de nombreuses failles de sécurité. La [détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/) de GitLab analyse votre dépôt pour empêcher l'exposition de vos secrets.\n\nLa fonctionnalité [Stratégies](https://docs.gitlab.com/ee/user/application_security/policies/) de GitLab permet aux utilisateurs d'implémenter des stratégies d'[exécution d'analyse](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) et de [résultat d'analyse](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) basées sur une logique configurée. Ces stratégies combinent les capacités d'analyse de la phase de [sécurisation](https://about.gitlab.com/features/?stage=secure) avec les [approbations des merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) pour répondre davantage aux exigences de conformité.\n\nUne fois réunies, ces fonctionnalités établissent les bases d'un programme de cycle de vie de développement logiciel sécurisé et vous permettent d'implémenter des principes de codage sécurisé conformément aux exigences de votre entreprise.\n\n\u003Cbr>\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 8.32 Gestion des changements | Les changements apportés aux moyens de traitement de l'information et aux systèmes d'information doivent être soumis à des procédures de gestion des modifications. |\n\nGitLab offre de nombreuses fonctionnalités permettant de prendre en charge un programme complet de gestion des modifications.\n\nLes fonctionnalités de gestion du code source de GitLab permettent aux utilisateurs de créer des [branches protégées](https://docs.gitlab.com/ee/user/project/protected_branches.html). Elles permettent aux utilisateurs de GitLab d'imposer des restrictions à certaines branches considérées comme essentielles à leurs opérations. Une branche protégée permet de contrôler :\n* quels utilisateurs peuvent fusionner dans la branche\n* quels utilisateurs peuvent effectuer un push vers la branche\n* si les utilisateurs peuvent forcer un push vers la branche\n* si les modifications apportées aux fichiers répertoriés dans le fichier CODEOWNERS peuvent faire l’objet d’un push directement vers la branche\n* quels utilisateurs peuvent retirer la protection de la branche\n\nLa [branche par défaut](https://docs.gitlab.com/ee/user/project/repository/branches/default.html) d'un dépôt devient automatiquement une branche protégée.\n\n![Branches protégées](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/protected-branches-settings-within-gitlab.png)\n\nParamètres des branches protégées dans GitLab\n{: .note.text-center}\n\nLes merge requests (MR) sont essentielles dans le cycle de vie du développement logiciel. Les utilisateurs de GitLab peuvent configurer leurs MR de sorte qu'elles doivent être approuvées avant d'être fusionnées. Les utilisateurs peuvent définir le nombre minimum d'approbations requises avant qu'un travail puisse être fusionné dans un projet. Voici quelques exemples de règles que vous pouvez créer :\n* Les utilisateurs disposant d'autorisations spécifiques peuvent toujours approuver le travail.\n* Les [propriétaires du code](https://docs.gitlab.com/ee/user/project/codeowners/index.html) peuvent approuver le travail pour leurs fichiers.\n* Les utilisateurs disposant d'autorisations spécifiques peuvent approuver le travail, [même s'ils ne disposent pas des droits de fusion](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties) pour le dépôt.\n* Les utilisateurs disposant d'autorisations spécifiques peuvent être autorisés ou privés de la possibilité de [redéfinir les règles d'approbation d'une merge request spécifique](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#edit-or-override-merge-request-approval-rules).\n\nComme mentionné précédemment, vous pouvez utiliser les [tickets](https://docs.gitlab.com/ee/user/project/issues/) et les [tâches](https://docs.gitlab.com/ee/user/tasks.html) pour documenter les demandes de modification et collaborer à celles-ci. Les [modèles de description](https://docs.gitlab.com/ee/user/project/description_templates.html) permettent aux utilisateurs d'appliquer systématiquement une description aux tickets ou aux [MR](https://docs.gitlab.com/ee/user/project/merge_requests/index.html). Ces modèles permettent une approche structurée de la demande de modifications adaptée à vos besoins spécifiques.\n\n## En savoir plus\nEn tant que plateforme DevSecOps complète, GitLab vous permet de répondre à un large éventail d'exigences. La version 2022 de la norme ISO a ajouté des contrôles supplémentaires autour du codage sécurisé et de la gestion de la configuration. Ces ajouts prouvent que les organismes de certification se concentrent davantage sur la sécurité des logiciels. En tant que partenaire stratégique, GitLab peut vous aider à vous conformer à la norme ISO 27001 et à développer de meilleurs logiciels plus rapidement.\n\nPour en savoir plus sur ces fonctionnalités, consultez notre bibliothèque de [tutoriels](https://docs.gitlab.com/ee/tutorials/).",[14,687,837],"customers","2024-07-31",{"slug":840,"featured":6,"template":691},"how-gitlab-can-support-your-iso-compliance-journey","content:fr-fr:blog:how-gitlab-can-support-your-iso-compliance-journey.yml","How Gitlab Can Support Your Iso Compliance Journey","fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey.yml","fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey",{"_path":846,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":847,"content":853,"config":862,"_id":864,"_type":16,"title":865,"_source":18,"_file":866,"_stem":867,"_extension":21},"/fr-fr/blog/the-ultimate-guide-to-sboms",{"title":848,"description":849,"ogTitle":848,"ogDescription":849,"noIndex":6,"ogImage":850,"ogUrl":851,"ogSiteName":675,"ogType":676,"canonicalUrls":851,"schema":852},"Qu’est-ce qu’une nomenclature logicielle (SBOM) et quel est son rôle ?","Découvrez ce qu'est une nomenclature logicielle et pourquoi elle fait désormais partie intégrante du développement logiciel. Lisez notre guide complet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664571/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","https://about.gitlab.com/blog/the-ultimate-guide-to-sboms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Qu’est-ce qu’une nomenclature logicielle (SBOM) et quel est son rôle ?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-10-25\",\n      }",{"title":848,"description":849,"authors":854,"heroImage":850,"date":856,"body":857,"category":14,"tags":858,"updatedDate":861},[855],"Sandra Gittlen","2022-10-25","Une nomenclature logicielle (ou SBOM) est une liste complète des composants d’un logiciel qui facilite la compréhension du réseau complexe de bibliothèques, d'outils et de processus utilisés tout au long du cycle de développement. Associées à des outils de gestion des vulnérabilités, les SBOM ne se contentent pas de révéler les vulnérabilités potentielles des logiciels, mais ouvrent également la voie à une stratégie d'atténuation des risques. \n\nDécouvrez dans ce guide tout ce que vous devez savoir sur les SBOM, ainsi que le rôle central qu'elles jouent dans une stratégie [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") multifacette : \n\n- [Qu'est-ce qu'une SBOM ?](#quest-ce-quune-sbom)\n- [Pourquoi les SBOM sont-elles importantes ?](#pourquoi-les-sbom-sont-elles-importantes)\n- [Quels sont les types de normes d'échange de données SBOM ?](#quels-sont-les-types-de-normes-dechange-de-donnees-sbom)\n- [Quels sont les avantages de l'association des SBOM avec la gestion des vulnérabilités logicielles ?](#quels-sont-les-avantages-de-lassociation-des-sbom-avec-la-gestion-des-vulnerabilites-logicielles)\n- [GitLab et les SBOM dynamiques](#gitlab-et-les-sbom-dynamiques)\n- [L'avenir des fonctionnalités SBOM de GitLab](#lavenir-des-fonctionnalites-sbom-de-gitlab)\n- [Commencez à utiliser les SBOM](#commencez-à-utiliser-les-sbom)\n\n## Qu'est-ce qu'une SBOM ?\n\nUne SBOM est un inventaire imbriqué ou une [liste des ingrédients qui constituent les composants logiciels](https://www.cisa.gov/sbom# \"Définition d'une SBOM\"). Les SBOM comprennent des informations critiques sur les bibliothèques, outils et processus utilisés pour développer, construire et déployer un artefact logiciel. \n\nBien que les SBOM soient souvent créées avec des logiciels autonomes, des plateformes DevSecOps comme GitLab intègrent la génération de SBOM dans un workflow DevSecOps.\n\n![Sécurité de la chaîne d'approvisionnement SDLC](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/supply_chain_security_sdlc.png)\n\n### Pourquoi les SBOM sont-elles importantes ?\n\nAujourd'hui, le secteur du développement logiciel a tendance à prioriser rapidité et efficacité pour la livraison de logiciels. Cependant, cela induit parfois des __risques de sécurité__ via l'intégration de code moins sécurisé provenant de dépôts open source ou de paquets propriétaires.\n\nSelon le rapport « Open Source Security and Risk Analysis » de Synopsys (2024), qui a analysé plus de 1 000 bases de code commerciales issues de 17 industries différentes en 2023, 96 % de ces bases contenaient du code open source et 84 % de celles évaluées pour les risques contenaient des vulnérabilités.\n\nÀ la lecture de ce rapport, il devient clair qu'intégrer du code provenant de dépôts inconnus augmente le risque de failles exploitables par les hackers.\n\nUn exemple connu, l'[attaque de SolarWinds](https://fr.wikipedia.org/wiki/Cyberattaque_de_2020_contre_les_%C3%89tats-Unis \"Attaque de SolarWinds\") en 2020, a été déclenchée par l'activation d'une __injection malveillante de code__ dans un paquet utilisé par le produit Orion de SolarWinds. Cette dernière n'a pas été sans conséquences puisqu'elle a fortement affecté les clients de l’ensemble de la chaîne d'approvisionnement logicielle.\n\nCette attaque, comme bien d'autres (par exemple, la __vulnérabilité Log4j__) ont mis en lumière l'importance d'effectuer une analyse approfondie des dépendances des applications, y compris des __conteneurs et de l'infrastructure__, afin d'évaluer les [risques potentiels tout au long de la chaîne d'approvisionnement logicielle](https://about.gitlab.com/blog/the-ultimate-guide-to-software-supply-chain-security/ \"Sécurité de la chaîne d'approvisionnement logicielle\").\n\nLe coût lié à l'identification et à la correction d’une faille de sécurité est un facteur important à ne pas négliger. Mais au-delà de l'aspect financier, une attaque sur la chaîne d'approvisionnement logicielle peut gravement affecter __la réputation d'une entreprise__.\n\nNon seulement les SBOM permettent de __limiter les risques d'attaques__ (et donc de préserver votre réputation), mais elles contribuent également à optimiser les coûts liés à la gestion des vulnérabilités : \n\n- En offrant un aperçu de vos dépendances,\n- En identifiant les vulnérabilités ainsi que les licences non conformes aux protocoles de sécurité internes à votre entreprise. \n\n## Quels sont les types de normes d'échange de données SBOM ?\n\nLes SBOM fonctionnent de manière optimale lorsque la génération et l'interprétation d'informations telles que __le nom, la version, ou encore l’empaqueteur, peuvent être automatisées__. Cette automatisation est optimale si toutes les parties prenantes impliquées utilisent un format standard d'échange de données. \n\nIl existe deux principaux types de normes d'échange de données SBOM utilisées aujourd'hui :\n\n- [OWASP CycloneDX](https://cyclonedx.org/capabilities/sbom/ \"OWASP CycloneDX\")\n- [SPDX](https://spdx.dev/ \"SPDX\")\n\nGitLab utilise CycloneDX pour la génération de SBOM, car cette norme est :\n\n- prescriptive (marque un ensemble de normes objectives),\n- facile à comprendre et à prendre en main, \n- capable de simplifier les relations complexes, \n- extensible pour prendre en charge et s'adapter à des cas spécifiques.\n\nDe plus, il existe des outils open source comme cyclonedx-cli et cdx2spdx qui peuvent être utilisés pour convertir des fichiers CycloneDX au format SPDX si nécessaire.\n\n## Quels sont les avantages de l'association des SBOM avec la gestion des vulnérabilités logicielles ?\n\nLes SBOM sont très utiles pour les équipes DevSecOps et les utilisateurs de logiciels, et ce, pour plusieurs raisons :\n\n - Elles permettent une __approche standardisée__ pour comprendre quels composants logiciels supplémentaires sont présents dans une application et où ils sont déclarés.\n - Elles offrent une visibilité continue sur l'__historique de création d'une application__, y compris des détails sur les origines du code tiers et les dépôts hôtes.\n- Elles fournissent un haut niveau de transparence en matière de sécurité, tant pour le code développé en interne que pour les logiciels open source utilisés.\n- Les détails fournis par les SBOM permettent aux [équipes DevOps](https://about.gitlab.com/fr-fr/topics/devops/build-a-devops-team/ \"Construire une équipe DevOps\") d'identifier les vulnérabilités, d'évaluer les risques, puis de les atténuer. \n- Les SBOM fournissent la transparence désormais attendue par les acheteurs d'applications.\n\n## GitLab et les SBOM dynamiques\n\nPour que les SBOM soient les plus efficaces possibles, les entreprises doivent être en mesure :\n\n- de les générer automatiquement,\n- de les connecter à des outils d'analyse de sécurité des applications,\n- d’intégrer les vulnérabilités et les licences dans un tableau de bord (pour faciliter la compréhension et la prise de décision),\n- de les mettre à jour en continu.\n\nSachez que GitLab prend en charge tous ces objectifs. \n\n![Illustration de la gestion dynamique des SBOM](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/Screenshot_2024-05-03_at_10.53.28_AM.png)\n\n### Générer et gérer des SBOM à grande échelle\n\nPour se conformer aux réglementations ainsi qu'aux politiques internes de votre entreprise, il est essentiel de disposer de SBOM capables de couvrir tant les logiciels open source que les logiciels tiers et propriétaires.\n\nIl est également nécessaire de mettre en place un processus optimisé afin de créer, fusionner, valider et approuver les SBOM. C'est une condition essentielle à la bonne gestion des SBOM, et ce, pour chaque composant et version de produit.\n\nComment la plateforme GitLab peut-elle vous aider dans la génération de SBOM ? \n\n- La fonctionnalité « [Liste des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_list/ \"Liste des dépendances de GitLab\") » rassemble les données connues sur les vulnérabilités et les licences dans une vue unique disponible au sein de l'interface utilisateur de GitLab. \n- Des informations sur le graphe des dépendances sont générées dans le cadre du rapport d'analyse des dépendances. Cela permet aux utilisateurs d'obtenir une vue d'ensemble complète sur les dépendances et les vulnérabilités potentielles au sein de leurs projets ou groupes de projets.  \n- Un artefact au format JSON CycloneDX peut être produit dans le [pipeline CI](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI ?\"). Cette API propose une approche plus nuancée et personnalisée de la génération de SBOM. \n- Les SBOM sont exportables depuis l'interface utilisateur, un pipeline ou un projet spécifique, ou via l'API GitLab.\n\n### Ingérer et fusionner des SBOM\n\nEn ingérant des SBOM tiers, GitLab offre un haut degré de transparence en matière de sécurité, que ce soit pour le code développé par des tiers que pour les logiciels open source utilisés. \n\nGitLab vous permet d'utiliser un job [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ? \") pour fusionner simplement plusieurs SBOM CycloneDX. En s'appuyant sur les détails spécifiques à l'implémentation dans les métadonnées CycloneDX de chaque SBOM (comme l'emplacement des fichiers de compilation et de verrouillage), __GitLab élimine les doublons__. Ces données sont également enrichies automatiquement avec des informations sur les licences et les vulnérabilités des composants à l'intérieur de la nomenclature logicielle. \n\n### Accélérer l'atténuation des risques pour une meilleure gestion des SBOM\n\nPour pouvoir créer rapidement des produits de haute qualité, les équipes de développement ont besoin de données exploitables pour identifier et corriger les vulnérabilités critiques des applications. GitLab contribue à sécuriser votre chaîne d'approvisionnement logicielle en [analysant les vulnérabilités](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html \"Comment sécuriser son application ? \") dans le code source, dans les conteneurs, les dépendances et les applications en cours d'exécution.\n\nGitLab offre une couverture complète pour aider dans la gestion des vulnérabilités (vulnerability management) grâce à sa large panoplie de scanners de sécurité : \n\n- des tests statiques de sécurité des applications ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/ \"SAST\"))\n- des tests dynamiques de sécurité des applications ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/ \"DAST\"))\n- l'analyse des conteneurs\n- l'analyse de la composition logicielle ([SCA](https://about.gitlab.com/direction/secure/composition-analysis/software-composition-analysis/ \"SCA\")) \n\nPour aider les équipes de développement et d'ingénierie en sécurité à mieux comprendre et corriger les vulnérabilités, GitLab met à disposition de ses utilisateurs la fonctionnalité d'explication des vulnérabilités de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"GitLab Duo \"). Cette fonctionnalité alimentée par l'IA fournit une explication sur une vulnérabilité spécifique, comment elle peut être exploitée et, surtout, fournit une recommandation sur la manière de la corriger. Combinée à la [fonctionnalité de résolution des vulnérabilités de GitLab Duo](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities/ \"Développement de GitLab Duo : corriger les failles de sécurité avec l'IA\"), cette fonctionnalité permet aux équipes DevSecOps de rapidement identifier, analyser et corriger les vulnérabilités de leurs applications.\n\nLa plateforme prend également en charge la création de nouvelles règles (et le [respect de leur application](https://docs.gitlab.com/ee/administration/compliance.html)) basées sur les vulnérabilités nouvellement détectées.\n\n### Analyser les SBOM en continu \n\nL’analyse continue des vulnérabilités de GitLab déclenche une analyse sur tous les projets où l'analyse des conteneurs, l'analyse des dépendances, ou les deux, sont activées indépendamment d'un pipeline.\n\nLorsque de nouvelles CVE (Common Vulnerabilities and Exposures) sont signalées, les utilisateurs n'ont pas besoin de relancer leurs pipelines pour obtenir les dernières informations.\n\nEn effet, l'équipe de recherche sur les vulnérabilités de GitLab les ajoute à la base de données des avis ([GitLab Advisory Database](https://docs.gitlab.com/ee/user/application_security/gitlab_advisory_database/ \"GitLab Advisory Database\")) pour être intégrées dans la liste des vulnérabilités connues de GitLab. Cela rend la SBOM de GitLab véritablement dynamique. \n\n### Renforcer la confiance dans les SBOM\n\nGitLab permet aux entreprises nécessitant une [fonctionnalité de conformité](https://about.gitlab.com/fr-fr/solutions/compliance/ \"La conformité des logiciels avec GitLab\") de [générer des attestations pour tous les artefacts de compilation](https://about.gitlab.com/blog/securing-the-software-supply-chain-through-automated-attestation/ \"Sécuriser la chaîne d'approvisionnement logicielle grâce à l'attestation automatisée\") produits par le GitLab Runner. Le processus est sécurisé, car il est réalisé directement par le [GitLab Runner](https://docs.gitlab.com/runner/ \"GitLab Runner\"), sans qu'il y ait de transfert de données vers un service externe.\n\n## L'avenir des fonctionnalités SBOM de GitLab\n\nLes attaques fréquentes contre de grands fournisseurs de logiciels et sur les environnements open source obligent le monde du développement à renforcer ses défenses contre les menaces extérieures. Pour cette raison, la sécurité de la chaîne d'approvisionnement des logiciels est aujourd'hui un sujet central dans l'industrie de la cybersécurité et du logiciel. \n\nBien que les SBOM évoluent rapidement, des préoccupations subsistent néanmoins. Par exemple : \n\n- la manière et la fréquence dont elles sont générées\n- leur stockage\n- la combinaison de plusieurs SBOM pour des applications complexes\n- leur analyse et utilisation pour améliorer la santé des applications.\n\nGitLab a fait des SBOM une partie intégrante de sa stratégie en matière de [chaîne d'approvisionnement logicielle](https://about.gitlab.com/direction/supply-chain/ \"Chaîne d'approvisionnement logicielle\") et continue d'améliorer ses capacités SBOM en permanence, en intégrant régulièrement de nouvelles fonctionnalités.\n\nParmi ces améliorations, nous retrouvons entre autres : l'automatisation des attestations, la signature numérique des artefacts de compilation et la prise en charge des SBOM générées en externe.\n\nGitLab a également mis en place un [modèle de maturité SBOM](https://handbook.gitlab.com/handbook/security/security-assurance/dedicated-compliance/sbom-plan/ \"Modèle de maturité SBOM\") (SBOM Model Maturity) au sein de sa plateforme. Ce modèle inclut des étapes comme la génération automatique de SBOM, l’approvisionnement en SBOM depuis l'environnement de développement, l’analyse des SBOM pour les artefacts et la promotion de la signature numérique des SBOM.\n\n## Commencez à utiliser les SBOM\n\nLa demande en SBOM est déjà très forte.\n\nAux États-Unis, les agences gouvernementales recommandent, voire exigent des fournisseurs et des développeurs de logiciels fédéraux, et même des communautés open source qu'ils créent des SBOM. \n\nA l'échelle européenne, ce sujet est traité au sein du [règlement sur la cyberrésilience (CRA)](https://digital-strategy.ec.europa.eu/fr/news/cyber-resilience-act-enters-force-make-europes-cyberspace-safer-and-more-secure \"règlement sur la cyberrésilience\"). Quant à la France, c'est l'[Agence nationale de la sécurité des systèmes d'information](https://cyber.gouv.fr/ \"Agence nationale de la sécurité des systèmes d'information\") (ANSSI) qui tranche sur ce type de sujets. \n\nAinsi, que ce soit aux États-Unis, en France, mais aussi ailleurs dans le monde, les agences liées à la sécurité informatique informent sur les menaces grandissantes qui pèsent sur le monde du développement logiciel et numérique plus globalement. \n\nPour anticiper ces exigences, consultez les fonctionnalités SBOM de l'édition GitLab Ultimate disponibles dans la [plateforme DevSecOps de GitLab](https://gitlab.com/-/trials/new \"Essai gratuit de la plateforme GitLab \").\n\n## FAQ sur les SBOM\n\n### Qu'est-ce qu'une SBOM ?\n\nUne SBOM est un inventaire détaillé qui répertorie tous les composants, bibliothèques et outils utilisés pour créer, construire et déployer des logiciels. Cette liste exhaustive inclut des informations essentielles sur les origines du code. Cela favorise une compréhension plus approfondie de la composition d'une application et de ses vulnérabilités potentielles.\n\n### Pourquoi les SBOM sont-elles si importantes ?\n\nLes SBOM sont essentielles pour plusieurs raisons. Elles fournissent :\n\n- __Un aperçu des dépendances.__ Elles permettent de comprendre ce qui compose votre logiciel, et donc de mieux identifier et atténuer les risques associés aux composants tiers.\n- __Une sécurité renforcée.__ Avec une visibilité détaillée des composants de leurs applications, les entreprises peuvent rapidement identifier leurs vulnérabilités et prendre des mesures pour les résoudre.\n- __Une conformité réglementaire.__ De plus en plus, les réglementations et les meilleures pratiques recommandent ou exigent une SBOM pour l'empaquetage de logiciels, en particulier dans le secteur public.\n- __Un développement rationalisé.__ Les équipes de développement peuvent s'appuyer sur les SBOM pour obtenir des informations sur les bibliothèques et les composants utilisés, ce qui permet de gagner du temps et de réduire les erreurs dans le cycle de développement logiciel. \n\n### Quels formats sont utilisés pour l'échange de données SBOM ?\n\nIl existe deux normes prédominantes pour l'échange de données SBOM : \n\n- [CycloneDX](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/ \"CycloneDX\") : connue pour être particulièrement intuitive, CycloneDX simplifie les relations complexes entre les composants logiciels et prend en charge des cas d'utilisation spécifiques. \n- [SPDX](https://docs.gitlab.com/ee/raketasks/spdx.html \"SPDX\") : un autre framework largement utilisé pour l'échange de données SBOM. SPDX fournit des informations détaillées sur les composants au sein de l'environnement logiciel. \n\nEn raison de sa nature normative et de son adaptabilité, GitLab utilise spécifiquement CycloneDX pour sa génération de SBOM.\n\n### Quelle est l’approche de GitLab en matière de SBOM ?\n\nGitLab met l'accent sur la création de SBOM dynamiques qui peuvent être : \n\n- Générées automatiquement : garantir des informations à jour sur la composition logicielle\n- Intégrées avec des outils : se connecter à des outils d’analyse de vulnérabilités, pour une meilleure gestion des risques. \n- Faciles à gérer : prendre en charge l'ingestion et la fusion des SBOM pour une analyse complète \n- Analysées en continu : offrir une analyse continue des projets pour détecter les nouvelles vulnérabilités au fur et à mesure de leur apparition\n\n### Comment puis-je commencer à implémenter les SBOM dans mon entreprise ?\n\nPour les entreprises prêtes à adopter les SBOM, l'édition [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"GitLab Ultimate\") met à disposition des utilisateurs une plateforme robuste pour générer et gérer des SBOM au sein d'un workflow DevSecOps. En tirant parti des outils de GitLab, les équipes de développement peuvent garantir la conformité logicielle, renforcer la sécurité et optimiser les pratiques de développement.\n\nLa demande croissante de SBOM reflète l’importance grandissante accordée à la sécurité logicielle et à l'intégrité de la chaîne d'approvisionnement. En intégrant les fonctionnalités SBOM, les entreprises peuvent mieux se protéger contre les vulnérabilités et se conformer aux nouvelles réglementations en vigueur.\n\n> [Essayez GitLab Ultimate gratuitement pendant 60 jours.](https://about.gitlab.com/free-trial/fr-fr/devsecops/ \"Essai gratuit de GitLab Ultimate\")\n\n*Avertissement : cet article de blog contient des informations relatives aux produits, fonctionnalités et caractéristiques à venir. Il est important de noter que les informations contenues dans cet article de blog ne sont fournies qu'à titre informatif. Veuillez ne pas vous fier à ces informations à des fins d'achat ou de planification. Comme pour tout projet, les éléments mentionnés dans cet article (et les pages qui y sont liées) sont susceptibles de changer ou d'être retardés. Le développement, la sortie et le calendrier de tout produit ou fonctionnalité restent à la seule discrétion de GitLab.*\n",[14,710,859,860,189],"performance","open source","2024-12-16",{"slug":863,"featured":6,"template":691},"the-ultimate-guide-to-sboms","content:fr-fr:blog:the-ultimate-guide-to-sboms.yml","The Ultimate Guide To Sboms","fr-fr/blog/the-ultimate-guide-to-sboms.yml","fr-fr/blog/the-ultimate-guide-to-sboms",{"_path":869,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":870,"content":876,"config":886,"_id":888,"_type":16,"title":889,"_source":18,"_file":890,"_stem":891,"_extension":21},"/fr-fr/blog/ensuring-compliance",{"ogTitle":871,"schema":872,"ogImage":873,"ogDescription":874,"ogSiteName":675,"noIndex":6,"ogType":676,"ogUrl":875,"title":871,"canonicalUrls":875,"description":874},"Séparation des tâches et conformité avec GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Séparation des tâches et conformité avec GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Beatriz Barbosa\"},{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-04-04\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098232/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_479904468%20%281%29_4lmOEVlaXP0YC3hSFmOw6i_1750098232241.jpg","Maintenez la conformité sans compromettre la rapidité de développement grâce à votre plateforme DevSecOps.","https://about.gitlab.com/blog/ensuring-compliance",{"heroImage":873,"body":877,"authors":878,"updatedDate":880,"date":881,"title":882,"tags":883,"description":874,"category":14},"Découvrez dans cet article les différentes façons de garantir la **séparation des tâches** ainsi que la **[sécurité et conformité](https://about.gitlab.com/fr-fr/solutions/security-compliance/) logicielle continue** avec la plateforme DevSecOps de GitLab. Avant de commencer, définissons tout d'abord ces deux concepts clés.\n\n## Qu’est-ce que la conformité ?\n\nLa **conformité** désigne le fait de respecter les directives et les spécifications définies par votre entreprise ou par un organisme réglementaire. Elle permet de préserver l'éthique de l'entreprise, d'appliquer des règles d'utilisation appropriées, de respecter les normes de sécurité et plus largement, de protéger les utilisateurs.\n\nIl s'agit d'un aspect fondamental, car les manquements peuvent entraîner des sanctions juridiques et financières importantes. En plus d'assurer la conformité, les équipes [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") doivent également conjuguer vélocité de développement soutenue, simplicité, visibilité et contrôle.\n\n## Qu’est-ce que la séparation des tâches ?\n\nLa **séparation des tâches** vise à confier une tâche à plusieurs acteurs afin de limiter les risques d'erreurs et de prévenir les activités malveillantes. Cela signifie que chaque tâche ne peut être effectuée que par les rôles les plus adaptés. \n\nPrenons un exemple avec plusieurs rôles, chacun doté d'un objectif spécifique :\n\n* Un développeur est responsable de la création de nouvelles fonctionnalités.\n* Un responsable de la conformité est chargé de créer et d'imposer l'utilisation d'un [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\").\n* Un ingénieur en sécurité applicative a pour mission d'approuver les merge requests comportant des vulnérabilités.\n\nEn tenant compte de cette répartition des rôles, nous nous assurons qu'un développeur ne puisse pas modifier un pipeline CI/CD en cours d'exécution. Cette tâche est en effet réservée au responsable de la conformité, qui veille à ce que seul le code conforme puisse être fusionné sans nécessiter d'approbation supplémentaire.\n\nL'ingénieur en sécurité applicative, quant à lui, est chargé de vérifier et d'approuver le code comportant des vulnérabilités. Il met en place les mesures d'atténuation appropriées afin d'éviter toute mauvaise surprise lorsque le code atteint l'environnement de production. Dans ce scénario, les équipes de développement ne peuvent pas fusionner le code tant que les exigences de conformité et de sécurité ne sont pas satisfaites.\n\n## Règles de sécurité\n\nGitLab met à disposition de ses utilisateurs des **règles de sécurité** qui permettent aux équipes de sécurité d'exiger l'exécution de scans de sécurité conformément à une configuration spécifique, pour garantir que les scans n'ont pas été modifiés ou désactivés.\n\nLes règles de sécurité peuvent être associées à des **frameworks de conformité** spécifiques et, dans ce cas, votre projet intègre des exigences de conformité plus strictes et nécessite une supervision supplémentaire. Ce label de conformité peut être créé dans **Sécurisation > Centre de conformité > Frameworks** au niveau de votre groupe principal.\n\n![Label du framework de conformité](https://about.gitlab.com/images/blogimages/compliance-04-2022/cf-step-2.png)\n\n**Remarque :** les labels de conformité ne peuvent être attribués qu'à des projets du groupe principal dans lequel ils sont créés.\n\nIl existe trois types de règles : les [règles d'exécution des scans](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html), les [règles d'approbation des merge requests](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html) et les [règles d'exécution des pipelines](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html).\n\n* **Règles d'exécution des scans :** elles exigent l'exécution de scans de sécurité à une fréquence prédéfinie ou à chaque pipeline du projet.\n* **Règles d'approbation des merge requests :** elles permettent de définir les mesures à prendre en fonction des résultats des scans, par exemple d'exiger l'approbation de l'équipe de sécurité avant tout merge.\n* **Règles d'exécution des pipelines :** elles imposent l'exécution de certains jobs CI/CD pour les projets concernés.\n\nVous pouvez les configurer dans l'Éditeur de règle de GitLab en suivant quelques étapes simples.\n\n### Règle d'exécution des scans\n\n1. Accédez à **Sécurité et conformité > Politiques**.\n2. Créez une nouvelle règle en cliquant sur le bouton **Nouvelle règle**.\n3. Sélectionnez **Exécution des scans**.\n4. Créez une règle. Dans cet exemple, nous créons une règle qui exige qu'un [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) soit configuré pour qu'un pipeline puisse s'exécuter.\n\n```yaml\nname: force_sast\ndescription: 'require sast to run'\nenabled: true\nrules:\n- type: pipeline branches: - main actions:\n- scan: sast\n```\n\n5. Soumettez la règle en créant une merge request, puis fusionnez-la.\n\nL'ensemble des modifications apportées à la règle d'exécution des scans sont appliquées par le biais d'un job en arrière-plan qui s'exécute toutes les 10 minutes. Patientez le temps nécessaire pour que les modifications prennent effet après leur commit.\n\n6. Essayez ensuite d'exécuter votre pipeline. Celui-ci ne s'exécutera que si le SAST est correctement défini dans le fichier YAML.\n\n**Remarque** : vous pouvez également forcer l'exécution d'un SAST à intervalles réguliers. Consultez la [documentation](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) dédiée aux règles d'exécution des scans pour en savoir plus.\n\n### Règle d'approbation des merge requests\n\n1. Accédez à **Sécurisation > Politiques**.\n2. Créez une nouvelle règle en cliquant sur le bouton **Nouvelle règle**.\n3. Sélectionnez **Règle d'approbation des merge requests**.\n4. Définissez la portée de la règle.\n5. Créez une règle.\n\n![Création d'une règle d'approbation des merge requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098241214.png)\n\n6. Ajoutez l'action à effectuer.\n\n![Mise à jour de la séparation des tâches - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098241215.png)\n\n**Remarque :** la règle d'approbation des merge requests est appliquée en fonction des règles que vous avez définies. Si celles-ci ne sont pas valides ou inexploitables, GitLab exige alors une approbation manuelle. Pour éviter ce blocage automatique, vous pouvez modifier le champ « Comportement par défaut en cas d'erreur » et le régler sur `open`.\n\n![Mise à jour de la séparation des tâches - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098241217.png)\n\n1. Soumettez votre règle d'approbation en créant une merge request, puis en la fusionnant.\n2. Créez ensuite une merge request distincte contenant des vulnérabilités.\n3. Vérifiez que la règle d'approbation des merge requests s'applique en consultant votre merge request.\n\n### Règle d'exécution des pipelines\n\nPour configurer une règle d'exécution des pipelines, vous devez d'abord créer un projet contenant les fichiers CI que vous souhaitez exécuter. Assurez-vous de limiter l'accès à l'équipe de sécurité et/ou à l'administrateur pour garantir la séparation des tâches. \n\nNous avons créé un projet intitulé « Conformité et déploiement », qui contient le fichier YAML que nous souhaitons appliquer.\n\n1. Accédez à **Sécurisation > Politiques**.\n2. Cliquez sur le bouton **Nouvelle règle** pour créer une nouvelle règle.\n3. Sélectionnez **Règle d'exécution des pipelines**.\n4. Définissez la portée de la règle.\n5. Ajoutez l'action à effectuer.\n\n![Création d'une règle d'exécution des pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098241219.png)\n\n6. Ajoutez des conditions.\n7. Créez une merge request pour soumettre cette règle, puis fusionnez-la.\n8. Essayez ensuite d'exécuter votre pipeline. Les étapes et les jobs spécifiques à cette règle s'afficheront alors dans votre pipeline.\n\n## Tableau de bord de gestion des audits et de la conformité\n\nLa conformité implique également de s'assurer qu'elle est réellement appliquée dans vos groupes/projets. GitLab dispose d'une fonctionnalité d'événements d'audit et de rapports de conformité pour vous assister dans ce processus.\n\nLa **fonctionnalité d'événements d'audit** permet aux propriétaires et administrateurs de GitLab de suivre les événements importants, tels que des actions précises effectuées par certains membres de l'équipe et l'heure à laquelle elles se sont produites.\n\n![Fonctionnalité d'événements d'audit de GitLab ](https://about.gitlab.com/images/blogimages/compliance-04-2022/project-audit-events.png)\n\nElle enregistre différents types d'actions par groupe et par projet, comme indiqué dans la documentation dédiée à [la fonctionnalité d'événements d'audit](https://docs.gitlab.com/ee/administration/audit_events.html). Vous pouvez accéder à cette fonctionnalité dans **Sécurité et conformité > Événements d'audit**.\n\n\nVoici quelques exemples :\n\n* Un utilisateur a été ajouté à un projet ainsi qu’à ses autorisations.\n* Les autorisations d'un utilisateur affecté à un projet ont été modifiées.\n* Une variable CI/CD du projet a été ajoutée, supprimée, ou son statut de protection a été modifié.\n* Un utilisateur a été ajouté à un groupe ainsi qu’à ses autorisations.\n* Le nom ou le chemin d'accès d'un groupe a été modifié.\n\nLes événements d'audit peuvent également être envoyés à un point de terminaison HTTP à l'aide du streaming d'événements d'audit. Découvrez comment mettre en œuvre le streaming des événements d'audit dans cette [vidéo](https://youtu.be/zHwVF9-i7e4?t=52).\n\nLa fonctionnalité de **respect des normes** vous permet de suivre l'activité des merge requests d'un groupe. Elle fournit une vue d'ensemble de tous les projets du groupe.\n\n![Fonctionnalité de respect des normes dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098241222.png)\n\nGrâce à ce rapport, vous pouvez :\n\n* Obtenir un aperçu des dernières merge requests pour chaque projet.\n* Vérifier si les merge requests ont été approuvées, et par qui.\n* Identifier les auteurs des merge requests.\n* Afficher le dernier résultat du pipeline CI/CD pour chaque merge request.\n\nLe rapport de respect des normes est accessible dans le groupe principal en accédant à **Sécurisation > Centre de conformité**, puis en cliquant sur l'onglet **Respect des normes**.\n\n- - -\n\nMerci de votre intérêt pour cet article ! Découvrez plus d'informations sur la séparation des tâches au sein de GitLab [sur cette page](/solutions/compliance/).",[879,681],"Beatriz Barbosa","2025-07-21","2022-04-04","Séparation des tâches et conformité avec GitLab : le guide",[884,885],"CI","CD",{"slug":887,"featured":6,"template":691},"ensuring-compliance","content:fr-fr:blog:ensuring-compliance.yml","Ensuring Compliance","fr-fr/blog/ensuring-compliance.yml","fr-fr/blog/ensuring-compliance",1,[697,719,740,760,783,804,824,845,868],1753981681611]