{"id":559,"date":"2026-01-20T09:40:51","date_gmt":"2026-01-20T08:40:51","guid":{"rendered":"https:\/\/secure-pipelines.com\/?p=559"},"modified":"2026-03-24T13:00:35","modified_gmt":"2026-03-24T12:00:35","slug":"ci-cd-threat-modeling-trust-boundaries-attack-paths","status":"publish","type":"post","link":"https:\/\/secure-pipelines.com\/fr\/threats-attacks\/ci-cd-threat-modeling-trust-boundaries-attack-paths\/","title":{"rendered":"Threat Modeling CI\/CD : Identifier les Trust Boundaries et les chemins d\u2019attaque"},"content":{"rendered":"<p>Le threat modeling est une pratique bien \u00e9tablie en s\u00e9curit\u00e9 applicative. Les \u00e9quipes mod\u00e9lisent r\u00e9guli\u00e8rement les menaces pesant sur les API, les services backend et les environnements de production.<\/p>\n<p>Cependant, les pipelines CI\/CD sont souvent exclus des exercices formels de threat modeling, alors qu\u2019ils constituent l\u2019un des composants les plus critiques des syst\u00e8mes logiciels modernes.<\/p>\n<p>C\u2019est une lacune dangereuse.<\/p>\n<p>Les pipelines CI\/CD se situent \u00e0 l\u2019intersection d\u2019entr\u00e9es non fiables, de privil\u00e8ges \u00e9lev\u00e9s et de sorties de confiance. Ce sont pr\u00e9cis\u00e9ment le type de syst\u00e8mes o\u00f9 le threat modeling apporte le plus de valeur \u2014 et pourtant, ils sont fr\u00e9quemment consid\u00e9r\u00e9s comme de la \u00ab\u00a0simple automatisation\u00a0\u00bb.<\/p>\n<p>Cet article explique comment mod\u00e9liser efficacement les menaces des pipelines CI\/CD, en se concentrant sur l\u2019identification des trust boundaries, la compr\u00e9hension des chemins d\u2019attaque et la priorisation des contr\u00f4les qui r\u00e9duisent r\u00e9ellement les risques.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Pourquoi le threat modeling des pipelines CI\/CD est diff\u00e9rent<\/h2>\n<p>Les approches traditionnelles de threat modeling supposent g\u00e9n\u00e9ralement un p\u00e9rim\u00e8tre syst\u00e8me relativement stable : une application s\u2019ex\u00e9cutant en production, avec des utilisateurs, des flux de donn\u00e9es et des actifs bien d\u00e9finis.<\/p>\n<p>Les pipelines CI\/CD remettent en cause bon nombre de ces hypoth\u00e8ses.<\/p>\n<p>Un pipeline n\u2019est pas un syst\u00e8me unique. C\u2019est une cha\u00eene dynamique de syst\u00e8mes qui :<\/p>\n<ul class=\"wp-block-list\">\n<li>Consomme des entr\u00e9es provenant de sources multiples<\/li>\n<li>Ex\u00e9cute du code non fiable<\/li>\n<li>Op\u00e8re avec des privil\u00e8ges \u00e9lev\u00e9s<\/li>\n<li>Produit des artefacts auxquels les syst\u00e8mes en aval font implicitement confiance<\/li>\n<\/ul>\n<p>En d\u2019autres termes, les pipelines ne sont pas simplement partie int\u00e9grante du processus de livraison \u2014 ce sont des m\u00e9canismes de transformation de la confiance.<\/p>\n<p>Le threat modeling des pipelines CI\/CD n\u00e9cessite donc un changement de mentalit\u00e9 :<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>L\u2019objectif n\u2019est pas seulement de pr\u00e9venir les compromissions, mais de comprendre o\u00f9 la confiance est cr\u00e9\u00e9e, amplifi\u00e9e ou viol\u00e9e.<\/p>\n<\/blockquote>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Ce que nous prot\u00e9geons r\u00e9ellement<\/h2>\n<p>Avant d\u2019identifier les menaces, il est essentiel de clarifier quels actifs un pipeline CI\/CD est charg\u00e9 de prot\u00e9ger.<\/p>\n<p>Les actifs courants d\u2019un pipeline incluent :<\/p>\n<ul class=\"wp-block-list\">\n<li><strong>Int\u00e9grit\u00e9 du code source<\/strong> \u2014 garantir que le code n\u2019est pas modifi\u00e9 de mani\u00e8re inattendue<\/li>\n<li><strong>Int\u00e9grit\u00e9 du build<\/strong> \u2014 garantir que les builds s\u2019ex\u00e9cutent comme pr\u00e9vu<\/li>\n<li><strong>Int\u00e9grit\u00e9 des artefacts<\/strong> \u2014 garantir que les sorties correspondent aux entr\u00e9es<\/li>\n<li><strong>Secrets et identifiants<\/strong> \u2014 tokens, cl\u00e9s et identit\u00e9s utilis\u00e9s par l\u2019automatisation<\/li>\n<li><strong>Authenticit\u00e9 des releases<\/strong> \u2014 garantir que les livraisons sont l\u00e9gitimes et attribuables<\/li>\n<\/ul>\n<p>Une attaque r\u00e9ussie contre un pipeline n\u2019implique pas toujours le vol de donn\u00e9es ou le crash de syst\u00e8mes. Souvent, l\u2019objectif de l\u2019attaquant est bien plus subtil :<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>Introduire un comportement malveillant tout en pr\u00e9servant l\u2019apparence de l\u00e9gitimit\u00e9.<\/p>\n<\/blockquote>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Comprendre les trust boundaries dans le CI\/CD<\/h2>\n<p>Un trust boundary existe chaque fois que des donn\u00e9es ou un contr\u00f4le passent d\u2019un contexte moins fiable \u00e0 un contexte plus fiable.<\/p>\n<p>Dans les pipelines CI\/CD, les trust boundaries sont omnipr\u00e9sents \u2014 mais rarement explicites.<\/p>\n<p>Le threat modeling commence par identifier ces fronti\u00e8res et poser une question simple :<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>Quelles hypoth\u00e8ses faisons-nous sur la confiance \u00e0 ce stade ?<\/p>\n<\/blockquote>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">1. Entr\u00e9es de code source<\/h3>\n<p>Les pipelines consomment du code source provenant de d\u00e9p\u00f4ts, de branches, de tags et de pull requests. Toutes ces entr\u00e9es n\u2019ont pas le m\u00eame niveau de confiance.<\/p>\n<ul class=\"wp-block-list\">\n<li>Les branches principales peuvent \u00eatre restreintes et r\u00e9vis\u00e9es<\/li>\n<li>Les branches de fonctionnalit\u00e9s peuvent \u00eatre faiblement contr\u00f4l\u00e9es<\/li>\n<li>Les pull requests peuvent inclure des contributions non fiables<\/li>\n<\/ul>\n<p>Pourtant, de nombreux pipelines traitent toutes les entr\u00e9es de code comme \u00e9galement fiables.<\/p>\n<p>Cela cr\u00e9e une surface d\u2019attaque o\u00f9 du code non fiable peut influencer les processus de build et de d\u00e9ploiement de confiance.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">2. R\u00e9solution des d\u00e9pendances<\/h3>\n<p>Les builds modernes r\u00e9solvent les d\u00e9pendances dynamiquement \u00e0 partir d\u2019\u00e9cosyst\u00e8mes externes : registres de paquets, registres de conteneurs et d\u00e9p\u00f4ts d\u2019artefacts.<\/p>\n<p>Chaque \u00e9tape de r\u00e9solution de d\u00e9pendances franchit un trust boundary :<\/p>\n<ul class=\"wp-block-list\">\n<li>Du contr\u00f4le interne vers une infrastructure externe<\/li>\n<li>D\u2019entr\u00e9es v\u00e9rifi\u00e9es vers du code tiers<\/li>\n<\/ul>\n<p>Le threat modeling doit prendre en compte :<\/p>\n<ul class=\"wp-block-list\">\n<li>La dependency confusion<\/li>\n<li>Le typosquatting<\/li>\n<li>Les paquets upstream compromis<\/li>\n<\/ul>\n<p>Ignorer les d\u00e9pendances dans le threat modeling laisse un chemin d\u2019attaque majeur inexplor\u00e9.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">3. Runners CI\/CD et environnements d\u2019ex\u00e9cution<\/h3>\n<p>Les runners sont l\u2019endroit o\u00f9 la logique du pipeline s\u2019ex\u00e9cute r\u00e9ellement. Ils constituent l\u2019un des trust boundaries les plus critiques \u2014 et les plus mal compris.<\/p>\n<p>Les runners ex\u00e9cutent :<\/p>\n<ul class=\"wp-block-list\">\n<li>Du code source<\/li>\n<li>Des scripts de build<\/li>\n<li>Des actions ou plugins tiers<\/li>\n<\/ul>\n<p>Si les runners sont consid\u00e9r\u00e9s comme une infrastructure de confiance, mais qu\u2019ils ex\u00e9cutent des entr\u00e9es non fiables, le trust boundary s\u2019effondre.<\/p>\n<p>Le threat modeling doit explicitement consid\u00e9rer :<\/p>\n<ul class=\"wp-block-list\">\n<li>L\u2019isolation des runners<\/li>\n<li>La persistance entre les jobs<\/li>\n<li>L\u2019acc\u00e8s au r\u00e9seau et au syst\u00e8me de fichiers<\/li>\n<li>L\u2019acc\u00e8s aux secrets<\/li>\n<\/ul>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">4. Configuration et orchestration du pipeline<\/h3>\n<p>Les fichiers de configuration CI\/CD d\u00e9finissent ce qui s\u2019ex\u00e9cute, quand cela s\u2019ex\u00e9cute et avec quelles permissions.<\/p>\n<p>Ce sont en fait des <em>plans de contr\u00f4le<\/em> pour le processus de livraison.<\/p>\n<p>Toute modification de la configuration du pipeline peut :<\/p>\n<ul class=\"wp-block-list\">\n<li>Alt\u00e9rer le flux d\u2019ex\u00e9cution<\/li>\n<li>\u00c9tendre les privil\u00e8ges<\/li>\n<li>Introduire de nouveaux chemins d\u2019attaque<\/li>\n<\/ul>\n<p>Le threat modeling doit traiter les modifications de configuration avec la m\u00eame rigueur que les modifications du code de production.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">5. Artefacts et transfert vers le d\u00e9ploiement<\/h3>\n<p>Le dernier trust boundary est le transfert du pipeline vers la production.<\/p>\n<p>\u00c0 ce stade, les environnements de production supposent souvent :<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>Si cela provient du CI\/CD, c\u2019est s\u00fbr.<\/p>\n<\/blockquote>\n<p>Cette hypoth\u00e8se est pr\u00e9cis\u00e9ment ce que les attaquants exploitent.<\/p>\n<p>Sans v\u00e9rification d\u2019int\u00e9grit\u00e9 et contr\u00f4les de provenance, la production ne peut pas distinguer les artefacts l\u00e9gitimes des artefacts empoisonn\u00e9s.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Identifier les chemins d\u2019attaque courants en CI\/CD<\/h2>\n<p>Une fois les trust boundaries identifi\u00e9s, l\u2019\u00e9tape suivante consiste \u00e0 cartographier les chemins d\u2019attaque r\u00e9alistes.<\/p>\n<p>L\u2019objectif n\u2019est pas d\u2019\u00e9num\u00e9rer toutes les menaces th\u00e9oriques, mais de comprendre comment les attaquants se d\u00e9placent \u00e0 travers le syst\u00e8me.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">Chemin d\u2019attaque 1 : De la pull request \u00e0 l\u2019exfiltration de secrets<\/h3>\n<p>Un chemin d\u2019attaque courant implique :<\/p>\n<ol class=\"wp-block-list\">\n<li>Un attaquant soumet une pull request<\/li>\n<li>Le pipeline ex\u00e9cute le code de la PR<\/li>\n<li>Les secrets sont expos\u00e9s dans l\u2019environnement de build<\/li>\n<li>L\u2019attaquant exfiltre les identifiants<\/li>\n<\/ol>\n<p>Cette attaque n\u2019exploite pas une vuln\u00e9rabilit\u00e9 \u2014 elle exploite une hypoth\u00e8se de confiance implicite.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">Chemin d\u2019attaque 2 : De la compromission de d\u00e9pendance \u00e0 l\u2019empoisonnement du build<\/h3>\n<p>Un autre chemin courant :<\/p>\n<ol class=\"wp-block-list\">\n<li>Une d\u00e9pendance est compromise en amont<\/li>\n<li>Le pipeline r\u00e9sout la d\u00e9pendance<\/li>\n<li>Du code malveillant s\u2019ex\u00e9cute pendant le build<\/li>\n<li>Les artefacts sont modifi\u00e9s avant leur publication<\/li>\n<\/ol>\n<p>Sans contr\u00f4les d\u2019int\u00e9grit\u00e9 ni v\u00e9rification de provenance, l\u2019artefact empoisonn\u00e9 peut sembler parfaitement l\u00e9gitime.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">Chemin d\u2019attaque 3 : Manipulation de la configuration du pipeline<\/h3>\n<p>Les fichiers de configuration du pipeline font souvent l\u2019objet de moins de scrutin que le code applicatif.<\/p>\n<p>Un attaquant capable de modifier la configuration peut :<\/p>\n<ul class=\"wp-block-list\">\n<li>Ajouter des \u00e9tapes d\u2019ex\u00e9cution cach\u00e9es<\/li>\n<li>\u00c9tendre silencieusement les permissions<\/li>\n<li>Rediriger les sorties d\u2019artefacts<\/li>\n<\/ul>\n<p>Ce chemin d\u2019attaque est particuli\u00e8rement dangereux car il peut persister \u00e0 travers de multiples builds.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">Chemin d\u2019attaque 4 : Compromission des runners et mouvement lat\u00e9ral<\/h3>\n<p>Si les runners sont partag\u00e9s, persistants ou mal isol\u00e9s, un attaquant peut :<\/p>\n<ul class=\"wp-block-list\">\n<li>Persister entre les jobs<\/li>\n<li>Voler des secrets d\u2019autres pipelines<\/li>\n<li>Modifier les builds futurs<\/li>\n<\/ul>\n<p>Dans certains cas, la compromission d\u2019un runner fournit un acc\u00e8s aux r\u00e9seaux internes ou aux environnements cloud.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Cartographier visuellement les trust boundaries<\/h2>\n<p>Un threat modeling efficace b\u00e9n\u00e9ficie de repr\u00e9sentations visuelles.<\/p>\n<p>Pour les pipelines CI\/CD, les diagrammes doivent se concentrer sur :<\/p>\n<ul class=\"wp-block-list\">\n<li>O\u00f9 les entr\u00e9es non fiables p\u00e9n\u00e8trent<\/li>\n<li>O\u00f9 les privil\u00e8ges augmentent<\/li>\n<li>O\u00f9 les artefacts sont produits et consomm\u00e9s<\/li>\n<\/ul>\n<p>Chaque fl\u00e8che du diagramme repr\u00e9sente une transition de confiance. Chaque transition est un candidat pour l\u2019application de contr\u00f4les.<\/p>\n<p>La question cl\u00e9 \u00e0 chaque fronti\u00e8re est :<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>Quelles garanties avons-nous \u00e0 ce stade, et comment sont-elles appliqu\u00e9es ?<\/p>\n<\/blockquote>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Prioriser les contr\u00f4les en fonction du threat modeling<\/h2>\n<p>Le threat modeling n\u2019a de valeur que s\u2019il guide l\u2019action.<\/p>\n<p>Pour les pipelines CI\/CD, les contr\u00f4les \u00e0 plus fort impact incluent g\u00e9n\u00e9ralement :<\/p>\n<h3 class=\"wp-block-heading\">1. R\u00e9duire la confiance implicite<\/h3>\n<p>Distinguer explicitement les entr\u00e9es fiables des entr\u00e9es non fiables. Ne pas exposer les secrets ni les actions privil\u00e9gi\u00e9es aux contextes non fiables.<\/p>\n<h3 class=\"wp-block-heading\">2. Appliquer le principe du moindre privil\u00e8ge<\/h3>\n<p>Les identit\u00e9s des pipelines doivent \u00eatre limit\u00e9es par job, par \u00e9tape et par environnement. \u00c9viter les tokens \u00e0 longue dur\u00e9e de vie et \u00e0 port\u00e9e \u00e9tendue.<\/p>\n<h3 class=\"wp-block-heading\">3. Isoler les environnements d\u2019ex\u00e9cution<\/h3>\n<p>Les runners doivent \u00eatre \u00e9ph\u00e9m\u00e8res ou fortement isol\u00e9s. Les charges de travail non fiables ne doivent jamais partager un contexte d\u2019ex\u00e9cution avec celles de confiance.<\/p>\n<h3 class=\"wp-block-heading\">4. V\u00e9rifier l\u2019int\u00e9grit\u00e9 des artefacts<\/h3>\n<p>Les artefacts doivent \u00eatre sign\u00e9s, attest\u00e9s et v\u00e9rifi\u00e9s avant le d\u00e9ploiement. La production doit se fier \u00e0 la v\u00e9rification \u2014 pas aux hypoth\u00e8ses.<\/p>\n<h3 class=\"wp-block-heading\">5. Traiter la configuration du pipeline comme du code \u00e0 haut risque<\/h3>\n<p>Appliquer des revues, des politiques et des validations aux modifications de la configuration CI\/CD. Emp\u00eacher l\u2019extension silencieuse de l\u2019ex\u00e9cution ou des privil\u00e8ges.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Erreurs courantes dans le threat modeling CI\/CD<\/h2>\n<p>M\u00eame lorsque les organisations tentent de mod\u00e9liser les menaces des pipelines, elles tombent souvent dans des pi\u00e8ges pr\u00e9visibles.<\/p>\n<ul class=\"wp-block-list\">\n<li>Se concentrer uniquement sur les outils, pas sur les relations de confiance<\/li>\n<li>Supposer qu\u2019\u00ab\u00a0interne\u00a0\u00bb signifie \u00ab\u00a0de confiance\u00a0\u00bb<\/li>\n<li>Ignorer les composants tiers<\/li>\n<li>Mod\u00e9liser des architectures id\u00e9alis\u00e9es au lieu des pipelines r\u00e9els<\/li>\n<\/ul>\n<p>Un threat modeling efficace doit refl\u00e9ter le fonctionnement r\u00e9el des pipelines, et non la mani\u00e8re dont nous souhaiterions qu\u2019ils fonctionnent.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n<p>Les pipelines CI\/CD ne sont pas des syst\u00e8mes p\u00e9riph\u00e9riques. Ils sont au c\u0153ur de l\u2019int\u00e9grit\u00e9, de la s\u00e9curit\u00e9 et de la confiance dans les logiciels.<\/p>\n<p>Le threat modeling des pipelines r\u00e9v\u00e8le des chemins d\u2019attaque que les mod\u00e8les de menaces applicatifs traditionnels manquent, car l\u2019objectif de l\u2019attaquant n\u2019est pas d\u2019exploiter un comportement en production, mais de contr\u00f4ler ce qui est livr\u00e9 en premier lieu.<\/p>\n<p>En identifiant les trust boundaries, en cartographiant les chemins d\u2019attaque r\u00e9alistes et en priorisant des contr\u00f4les applicables, les organisations peuvent r\u00e9duire significativement le risque d\u2019attaques de la cha\u00eene d\u2019approvisionnement logicielle.<\/p>\n<p>Le changement le plus important est conceptuel :<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>Si vous ne mod\u00e9lisez pas explicitement la confiance dans votre pipeline, vous vous appuyez sur des hypoth\u00e8ses \u2014 et les attaquants exploitent les hypoth\u00e8ses.<\/p>\n<\/blockquote>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<div class=\"secure-pipelines-author-box\">\n    <strong>\u00c0 propos de l\u2019auteur<\/strong><\/p>\n<p>Cet article est r\u00e9dig\u00e9 par un architecte senior DevSecOps et s\u00e9curit\u00e9 disposant de plus de 15 ans d\u2019exp\u00e9rience en ing\u00e9nierie logicielle et en s\u00e9curit\u00e9 applicative. Le contenu refl\u00e8te une approche pragmatique, orient\u00e9e ing\u00e9nierie, ancr\u00e9e dans les contraintes du monde r\u00e9el.<\/p>\n<\/div>\n<p><script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"FAQPage\",\n  \"mainEntity\": [\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Qu\u2019est-ce que le threat modeling CI\/CD ?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Le threat modeling CI\/CD est le processus d\u2019identification des trust boundaries, des chemins d\u2019attaque et des risques de s\u00e9curit\u00e9 au sein des pipelines d\u2019int\u00e9gration et de livraison continues, afin de pr\u00e9venir les compromissions de la cha\u00eene d\u2019approvisionnement logicielle.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Pourquoi les trust boundaries sont-ils importants dans les pipelines CI\/CD ?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Les trust boundaries d\u00e9finissent o\u00f9 les entr\u00e9es non fiables deviennent des sorties de confiance. Dans les pipelines CI\/CD, ne pas mod\u00e9liser ces fronti\u00e8res permet aux attaquants d\u2019exploiter la confiance implicite et d\u2019injecter du code malveillant.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Quels sont les chemins d\u2019attaque courants dans les pipelines CI\/CD ?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Les chemins d\u2019attaque CI\/CD courants incluent l\u2019abus de pull requests, la compromission de d\u00e9pendances, la manipulation de la configuration du pipeline, la compromission des runners et l\u2019empoisonnement d\u2019artefacts.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"En quoi le threat modeling CI\/CD diff\u00e8re-t-il du threat modeling applicatif ?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Le threat modeling applicatif se concentre sur le comportement en production, tandis que le threat modeling CI\/CD se concentre sur la mani\u00e8re dont la confiance est \u00e9tablie, amplifi\u00e9e et transf\u00e9r\u00e9e avant que le logiciel n\u2019atteigne la production.\"\n      }\n    }\n  ]\n}\n<\/script><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Le threat modeling est une pratique bien \u00e9tablie en s\u00e9curit\u00e9 applicative. Les \u00e9quipes mod\u00e9lisent r\u00e9guli\u00e8rement les menaces pesant sur les API, les services backend et les environnements de production. Cependant, les pipelines CI\/CD sont souvent exclus des exercices formels de threat modeling, alors qu\u2019ils constituent l\u2019un des composants les plus critiques des syst\u00e8mes logiciels modernes. &#8230; <a title=\"Threat Modeling CI\/CD : Identifier les Trust Boundaries et les chemins d\u2019attaque\" class=\"read-more\" href=\"https:\/\/secure-pipelines.com\/fr\/threats-attacks\/ci-cd-threat-modeling-trust-boundaries-attack-paths\/\" aria-label=\"En savoir plus sur Threat Modeling CI\/CD : Identifier les Trust Boundaries et les chemins d\u2019attaque\">Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[54,49],"tags":[],"post_folder":[],"class_list":["post-559","post","type-post","status-publish","format-standard","hentry","category-threats-attacks","category-ci-cd-security"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/559","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/comments?post=559"}],"version-history":[{"count":1,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/559\/revisions"}],"predecessor-version":[{"id":564,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/559\/revisions\/564"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=559"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=559"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=559"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=559"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}