Apr\u00e8s avoir examin\u00e9 des impl\u00e9mentations de CI\/CD dans des environnements r\u00e9glement\u00e9s \u2014 services financiers, sant\u00e9, infrastructures critiques et entreprises technologiques soumises \u00e0 SOC 2, ISO 27001, DORA, NIS2 et PCI DSS \u2014, certains constats d’audit reviennent avec une r\u00e9gularit\u00e9 remarquable. Il ne s’agit pas de cas marginaux obscurs. Ce sont des d\u00e9faillances syst\u00e9miques de gouvernance que les auditeurs rencontrent \u00e0 r\u00e9p\u00e9tition, dans des organisations de toutes tailles et de tous niveaux de maturit\u00e9.<\/p>\n
Cet article pr\u00e9sente les dix constats d’audit les plus courants dans les pipelines CI\/CD, r\u00e9dig\u00e9 \u00e0 l’intention des auditeurs, des responsables de la conformit\u00e9 et des gestionnaires de risques. Pour chaque constat, nous d\u00e9crivons de quoi il s’agit, pourquoi il est important d’un point de vue r\u00e9glementaire, comment il appara\u00eet g\u00e9n\u00e9ralement lors d’un audit, et \u00e0 quoi devrait ressembler la rem\u00e9diation. Les \u00e9quipes de conformit\u00e9 devraient l’utiliser comme une liste de contr\u00f4le d’auto-\u00e9valuation pr\u00e9alable \u00e0 l’audit, afin d’identifier et de corriger les faiblesses avant qu’un auditeur externe ne le fasse.<\/p>\n
Plusieurs personnes ou \u00e9quipes utilisent des comptes de service partag\u00e9s dot\u00e9s de privil\u00e8ges \u00e9lev\u00e9s (souvent administratifs) pour ex\u00e9cuter des op\u00e9rations de pipeline. Les actions individuelles ne peuvent pas \u00eatre attribu\u00e9es \u00e0 des personnes pr\u00e9cises.<\/p>\n
La responsabilit\u00e9 individuelle est un principe fondateur du contr\u00f4le d’acc\u00e8s. Lorsque les actions ne peuvent pas \u00eatre rattach\u00e9es \u00e0 une personne pr\u00e9cise, l’investigation des incidents devient impossible et l’effet dissuasif contre les abus dispara\u00eet. Les contr\u00f4les de s\u00e9paration des t\u00e2ches perdent tout leur sens si plusieurs personnes op\u00e8rent sous la m\u00eame identit\u00e9.<\/p>\n
Les journaux du pipeline montrent que le m\u00eame compte de service ex\u00e9cute des builds, des d\u00e9ploiements et des actions administratives pour plusieurs \u00e9quipes. Les revues d’acc\u00e8s r\u00e9v\u00e8lent que les identifiants du compte de service sont partag\u00e9s entre plusieurs personnes. Aucune correspondance n’existe entre les actions du compte de service et les op\u00e9rateurs individuels.<\/p>\n
Mettre en place des comptes utilisateurs individuels pour toutes les interactions avec le pipeline. Lorsque des comptes de service sont techniquement n\u00e9cessaires, mettre en \u0153uvre des contr\u00f4les qui relient les actions du compte de service \u00e0 la personne qui les a initi\u00e9es (par exemple, par des d\u00e9clencheurs de pipeline li\u00e9s \u00e0 des utilisateurs authentifi\u00e9s). R\u00e9aliser une revue des privil\u00e8ges et appliquer les principes du moindre privil\u00e8ge.<\/p>\n
Des points d’approbation existent dans le pipeline, mais ils peuvent \u00eatre contourn\u00e9s par des utilisateurs disposant de privil\u00e8ges suffisants, ou la m\u00eame personne qui initie un changement peut approuver son propre d\u00e9ploiement en production. La s\u00e9paration des t\u00e2ches n’est pas impos\u00e9e.<\/p>\n
Les points d’approbation sont le principal m\u00e9canisme d’application de la s\u00e9paration des t\u00e2ches dans les environnements CI\/CD. S’ils peuvent \u00eatre contourn\u00e9s ou auto-approuv\u00e9s, le contr\u00f4le est inefficace, qu’il existe ou non sur le papier. Il s’agit d’une d\u00e9faillance de conception, et non d’une simple faiblesse op\u00e9rationnelle.<\/p>\n
La configuration du pipeline montre que les utilisateurs dot\u00e9s des r\u00f4les \u00ab admin \u00bb ou \u00ab maintainer \u00bb peuvent contourner les exigences d’approbation. Les journaux de d\u00e9ploiement montrent des cas o\u00f9 la m\u00eame personne a valid\u00e9 le code et approuv\u00e9 le d\u00e9ploiement. Des proc\u00e9dures de contournement d’urgence existent, mais sans contr\u00f4les de gouvernance ni revue a posteriori.<\/p>\n
Imposer des points d’approbation qui ne peuvent \u00eatre contourn\u00e9s que par un processus gouvern\u00e9 de changement d’urgence. Mettre en place des r\u00e8gles de s\u00e9paration des t\u00e2ches qui emp\u00eachent l’auto-approbation. Journaliser et examiner tous les cas o\u00f9 les processus d’approbation standard ne sont pas respect\u00e9s.<\/p>\n
Les journaux d’ex\u00e9cution du pipeline ne sont soit pas conserv\u00e9s au-del\u00e0 d’une courte fen\u00eatre op\u00e9rationnelle (par exemple 30 jours), soit stock\u00e9s dans des syst\u00e8mes o\u00f9 ils peuvent \u00eatre modifi\u00e9s ou supprim\u00e9s par le personnel d’exploitation.<\/p>\n
Les journaux du pipeline constituent une preuve de premier plan pour les contr\u00f4les de gestion des changements, d’autorisation des d\u00e9ploiements et de tests de s\u00e9curit\u00e9. Sans conservation ad\u00e9quate, les organisations ne peuvent pas d\u00e9montrer aux auditeurs que les contr\u00f4les fonctionnaient au cours de p\u00e9riodes pass\u00e9es. Des journaux modifiables compromettent l’int\u00e9grit\u00e9 des preuves \u2014 un auditeur ne peut pas se fier \u00e0 une preuve qui aurait pu \u00eatre alt\u00e9r\u00e9e.<\/p>\n
Les demandes de journaux du pipeline datant de six mois ne donnent aucun r\u00e9sultat. Le stockage des journaux se trouve dans le m\u00eame syst\u00e8me o\u00f9 les op\u00e9rateurs disposent d’un acc\u00e8s en \u00e9criture. Aucun m\u00e9canisme de v\u00e9rification de l’int\u00e9grit\u00e9 des journaux n’existe (pas de sommes de contr\u00f4le, pas de stockage immuable).<\/p>\n
Mettre en place des politiques de conservation des journaux align\u00e9es sur les exigences r\u00e9glementaires. Stocker les journaux dans un stockage immuable ou en \u00e9criture unique. Mettre en \u0153uvre des m\u00e9canismes de v\u00e9rification de l’int\u00e9grit\u00e9 des journaux. S’assurer que la conservation des journaux couvre l’int\u00e9gralit\u00e9 de la p\u00e9riode d’audit, \u00e0 laquelle s’ajoutent les exigences r\u00e9glementaires de conservation.<\/p>\n
Des identifiants, cl\u00e9s d’API, certificats ou autres secrets sont int\u00e9gr\u00e9s directement dans les d\u00e9p\u00f4ts de code source ou les fichiers de configuration du pipeline, plut\u00f4t que g\u00e9r\u00e9s au moyen d’une capacit\u00e9 d\u00e9di\u00e9e de gestion des secrets.<\/p>\n
Les secrets cod\u00e9s en dur sont accessibles \u00e0 quiconque dispose d’un acc\u00e8s au d\u00e9p\u00f4t, ne peuvent pas \u00eatre renouvel\u00e9s sans modification du code et persistent dans l’historique du syst\u00e8me de gestion de versions m\u00eame apr\u00e8s leur suppression. Cela cr\u00e9e une exposition incontr\u00f4l\u00e9e des identifiants et rend la gestion des identifiants \u2014 renouvellement, r\u00e9vocation, journalisation des acc\u00e8s \u2014 pratiquement impossible.<\/p>\n
L’analyse des d\u00e9p\u00f4ts r\u00e9v\u00e8le des secrets dans le code ou les fichiers de configuration. L’historique du syst\u00e8me de gestion de versions contient des identifiants m\u00eame s’ils ont \u00e9t\u00e9 supprim\u00e9s des versions actuelles. Aucune solution de gestion des secrets n’est utilis\u00e9e, ou elle l’est mais sans adoption universelle.<\/p>\n
Retirer tous les secrets cod\u00e9s en dur des d\u00e9p\u00f4ts et des configurations de pipeline. Mettre en place une capacit\u00e9 centralis\u00e9e de gestion des secrets. Renouveler tous les identifiants expos\u00e9s. Mettre en \u0153uvre une d\u00e9tection automatis\u00e9e des secrets dans les pipelines afin de pr\u00e9venir toute r\u00e9currence.<\/p>\n
Des outils d’analyse de s\u00e9curit\u00e9 (SAST, DAST, SCA, analyse de conteneurs) sont int\u00e9gr\u00e9s aux pipelines, mais leurs r\u00e9sultats ne conditionnent pas les d\u00e9ploiements. Des vuln\u00e9rabilit\u00e9s \u00e9lev\u00e9es ou critiques sont identifi\u00e9es, mais le code passe en production malgr\u00e9 tout.<\/p>\n
Ex\u00e9cuter des analyses de s\u00e9curit\u00e9 sans agir sur les r\u00e9sultats rel\u00e8ve de la mise en sc\u00e8ne de s\u00e9curit\u00e9. Cela cr\u00e9e l’apparence de tests de s\u00e9curit\u00e9 sans en fournir la substance. Du point de vue de la gouvernance, l’organisation a connaissance<\/em> des vuln\u00e9rabilit\u00e9s mais choisit de ne pas les traiter \u2014 ce qui peut \u00eatre pire que de ne pas analyser du tout, car cela t\u00e9moigne d’une acceptation consciente d’un risque non ma\u00eetris\u00e9.<\/p>\n Les rapports d’analyse font \u00e9tat de constats critiques sur des p\u00e9riodes prolong\u00e9es sans rem\u00e9diation. Les configurations du pipeline montrent que les analyses s’ex\u00e9cutent, mais que leurs r\u00e9sultats n’influent pas sur la progression du pipeline. Aucun seuil d\u00e9fini n’existe pour d\u00e9terminer quels r\u00e9sultats d’analyse devraient bloquer le d\u00e9ploiement.<\/p>\n D\u00e9finir des seuils de s\u00e9curit\u00e9 clairs qui conditionnent la progression du pipeline. Mettre en place des points de contr\u00f4le de politique qui bloquent le d\u00e9ploiement lorsque les constats d\u00e9passent des seuils de gravit\u00e9 d\u00e9finis. \u00c9tablir un processus gouvern\u00e9 de d\u00e9rogation pour les constats accept\u00e9s \u2014 avec une acceptation du risque document\u00e9e par l’autorit\u00e9 appropri\u00e9e.<\/p>\n L’organisation ne g\u00e9n\u00e8re pas de nomenclatures logicielles (SBOM) et ne tient pas d’inventaire complet des composants tiers et open source utilis\u00e9s dans ses applications.<\/p>\n Sans SBOM, l’organisation ne peut pas identifier quelles applications sont concern\u00e9es lorsqu’une vuln\u00e9rabilit\u00e9 est divulgu\u00e9e dans un composant tiers (comme cela s’est produit avec Log4Shell, Spring4Shell et d’autres incidents de cha\u00eene d’approvisionnement similaires). La r\u00e9ponse aux incidents devient une devinette, et les exigences r\u00e9glementaires en mati\u00e8re de gestion des risques de la cha\u00eene d’approvisionnement ne peuvent pas \u00eatre satisfaites.<\/p>\n Aucun fichier SBOM n’existe pour les applications d\u00e9ploy\u00e9es. \u00c0 la question \u00ab lesquelles de vos applications utilisent le composant X ? \u00bb, l’organisation ne peut pas r\u00e9pondre rapidement. Aucune analyse automatis\u00e9e des d\u00e9pendances n’est int\u00e9gr\u00e9e aux pipelines.<\/p>\n Mettre en place la g\u00e9n\u00e9ration automatis\u00e9e de SBOM dans le cadre du pipeline CI\/CD. Utiliser des formats standard (CycloneDX ou SPDX). Tenir un r\u00e9f\u00e9rentiel central des SBOM pour toutes les applications d\u00e9ploy\u00e9es. Mettre en \u0153uvre des processus permettant de recouper les nouvelles divulgations de vuln\u00e9rabilit\u00e9s avec l’inventaire des SBOM.<\/p>\n Les d\u00e9veloppeurs ou les op\u00e9rateurs peuvent acc\u00e9der directement aux environnements de production et y effectuer des changements en dehors du pipeline CI\/CD, contournant tous les contr\u00f4les du pipeline, y compris les points d’approbation, les analyses de s\u00e9curit\u00e9 et la journalisation d’audit.<\/p>\n Si des changements de production peuvent \u00eatre effectu\u00e9s en dehors du pipeline gouvern\u00e9, l’ensemble du cadre de contr\u00f4le est compromis. Chaque contr\u00f4le int\u00e9gr\u00e9 au pipeline \u2014 approbations, analyses, journalisation, s\u00e9paration des t\u00e2ches \u2014 peut \u00eatre contourn\u00e9 simplement en effectuant les changements directement. Le pipeline devient optionnel, et non obligatoire.<\/p>\n Les journaux d’acc\u00e8s \u00e0 la production montrent des connexions directes par du personnel de d\u00e9veloppement ou d’exploitation. Les changements en production ne correspondent pas aux enregistrements de d\u00e9ploiement du pipeline. Les configurations de l’environnement de production diff\u00e8rent de ce que le pipeline a d\u00e9ploy\u00e9 en dernier.<\/p>\n Restreindre l’acc\u00e8s \u00e0 la production \u00e0 des comptes de service autoris\u00e9s contr\u00f4l\u00e9s par le pipeline. Mettre en place un acc\u00e8s juste-\u00e0-temps pour les sc\u00e9narios d’urgence, avec journalisation compl\u00e8te et revue a posteriori de l’acc\u00e8s. Surveiller tout changement direct en production en dehors du pipeline et d\u00e9clencher des alertes le cas \u00e9ch\u00e9ant.<\/p>\n Des constats d’analyse de s\u00e9curit\u00e9 sont supprim\u00e9s, \u00e9cart\u00e9s ou marqu\u00e9s comme \u00ab accept\u00e9s \u00bb sans documentation formelle d’acceptation du risque. Aucune trace n’existe indiquant qui a accept\u00e9 le risque, quelle en \u00e9tait la justification, ou quand l’acceptation expire.<\/p>\n L’acceptation du risque est une option l\u00e9gitime de traitement du risque \u2014 mais seulement lorsqu’il s’agit d’une d\u00e9cision consciente, document\u00e9e et autoris\u00e9e. Des suppressions non gouvern\u00e9es ne sont pas une acceptation du risque ; c’est une ignorance du risque. Elles cr\u00e9ent des poches cach\u00e9es de risque non ma\u00eetris\u00e9 que les auditeurs identifieront et signaleront.<\/p>\n Les configurations d’analyse de s\u00e9curit\u00e9 contiennent des listes de suppression sans documentation associ\u00e9e. Les constats supprim\u00e9s incluent des vuln\u00e9rabilit\u00e9s de gravit\u00e9 critique ou \u00e9lev\u00e9e. Aucun flux d’approbation n’existe pour l’ajout de constats aux listes de suppression. Les suppressions n’ont ni date d’expiration ni cycle de revue.<\/p>\n Mettre en place un processus formel d’acceptation du risque exigeant une justification document\u00e9e, l’approbation de l’autorit\u00e9 appropri\u00e9e, des dates d’expiration d\u00e9finies et une revue p\u00e9riodique. R\u00e9examiner r\u00e9trospectivement toutes les suppressions existantes et, soit documenter l’acceptation du risque, soit retirer la suppression.<\/p>\n Les environnements de d\u00e9veloppement, de pr\u00e9production (ou de test) et de production ne sont pas suffisamment s\u00e9par\u00e9s. Ils peuvent partager une infrastructure, des identifiants, des donn\u00e9es ou des segments de r\u00e9seau, ou le personnel de d\u00e9veloppement peut disposer d’un acc\u00e8s \u00e9quivalent \u00e0 tous les environnements.<\/p>\n La s\u00e9paration des environnements est un contr\u00f4le fondamental qui prot\u00e8ge les syst\u00e8mes de production contre les changements non autoris\u00e9s, emp\u00eache les activit\u00e9s de d\u00e9veloppement d’affecter les services en production et garantit que les tests sont men\u00e9s dans des conditions qui se rapprochent de la production \u2014 sans la compromettre. Sans cette s\u00e9paration, le risque de changements incontr\u00f4l\u00e9s, de fuite de donn\u00e9es et de contamination entre environnements augmente consid\u00e9rablement.<\/p>\n La revue de l’infrastructure r\u00e9v\u00e8le des ressources partag\u00e9es entre les environnements. Les m\u00eames identifiants fonctionnent en d\u00e9veloppement et en production. Le personnel de d\u00e9veloppement dispose d’un acc\u00e8s administratif aux environnements de production. Des donn\u00e9es de production sont utilis\u00e9es en d\u00e9veloppement ou en test sans anonymisation.<\/p>\n Mettre en place des fronti\u00e8res claires entre les environnements, avec une infrastructure, des identifiants et des contr\u00f4les d’acc\u00e8s distincts. Restreindre l’acc\u00e8s \u00e0 la production au personnel d’exploitation autoris\u00e9 et aux comptes de service du pipeline. Mettre en \u0153uvre l’anonymisation des donn\u00e9es ou des donn\u00e9es synth\u00e9tiques pour les environnements hors production.<\/p>\n Les contr\u00f4les sont appliqu\u00e9s de mani\u00e8re incoh\u00e9rente au sein de l’organisation. Certaines \u00e9quipes disposent de pipelines bien gouvern\u00e9s, avec des points d’approbation, des analyses de s\u00e9curit\u00e9 et une conservation des preuves, tandis que d’autres \u00e9quipes fonctionnent avec des contr\u00f4les de pipeline minimaux, voire inexistants.<\/p>\n La conformit\u00e9 est une obligation organisationnelle, et non une option au niveau de l’\u00e9quipe. Une application incoh\u00e9rente des contr\u00f4les signifie que la posture de conformit\u00e9 de l’organisation n’est jamais plus solide que son pipeline le plus faible. Cela signale \u00e9galement une lacune de gouvernance : l’absence d’une norme d’entreprise pour les contr\u00f4les de pipeline et l’absence d’un m\u00e9canisme pour faire respecter cette norme.<\/p>\n La comparaison des configurations de pipeline entre les \u00e9quipes r\u00e9v\u00e8le des variations importantes dans la mise en \u0153uvre des contr\u00f4les. Certains pipelines ne disposent pas des points d’approbation, des analyses de s\u00e9curit\u00e9 ou de la conservation des preuves que d’autres poss\u00e8dent. Aucune norme de gouvernance des pipelines \u00e0 l’\u00e9chelle de l’organisation n’existe, ou elle existe mais n’est pas appliqu\u00e9e.<\/p>\n D\u00e9finir une norme de gouvernance des pipelines \u00e0 l’\u00e9chelle de l’organisation pr\u00e9cisant les contr\u00f4les minimaux requis. Mettre en place des m\u00e9canismes pour faire respecter cette norme (mod\u00e8les de pipeline, politique-en-tant-que-code, analyse de conformit\u00e9 des configurations de pipeline). R\u00e9aliser une \u00e9valuation des \u00e9carts sur tous les pipelines et corriger les non-conformit\u00e9s.<\/p>\n Comprendre comment les auditeurs d\u00e9couvrent ces constats aide les \u00e9quipes de conformit\u00e9 \u00e0 mieux se pr\u00e9parer :<\/p>\n Les constats isol\u00e9s sont pr\u00e9occupants, mais les combinaisons de constats r\u00e9v\u00e8lent des probl\u00e8mes de gouvernance plus profonds. Lorsque le constat 1 (comptes de service partag\u00e9s) et le constat 2 (points d’approbation contournables) apparaissent ensemble, ils signalent une absence fondamentale de gouvernance des acc\u00e8s \u2014 et non de simples lacunes de contr\u00f4le isol\u00e9es. De m\u00eame, si le constat 5 (analyses sans points de contr\u00f4le) et le constat 8 (suppressions non gouvern\u00e9es) coexistent, le programme de tests de s\u00e9curit\u00e9 de l’organisation est en r\u00e9alit\u00e9 d\u00e9coratif.<\/p>\n Les auditeurs devraient rechercher ces sch\u00e9mas, car ils indiquent si les constats sont des faiblesses isol\u00e9es pouvant \u00eatre corrig\u00e9es individuellement, ou les sympt\u00f4mes d’une lacune plus large de maturit\u00e9 de la gouvernance n\u00e9cessitant une r\u00e9ponse plus globale.<\/p>\n Utilisez cette liste comme une liste de contr\u00f4le d’auto-\u00e9valuation pr\u00e9alable \u00e0 l’audit<\/strong>. Pour chaque constat :<\/p>\n L’identification et la rem\u00e9diation proactives de ces constats courants t\u00e9moignent d’une maturit\u00e9 de gouvernance et r\u00e9duisent consid\u00e9rablement le risque d’issues d’audit d\u00e9favorables.<\/p>\n Pour des recommandations compl\u00e9mentaires sur la pr\u00e9paration aux audits CI\/CD et l’identification des signaux d’alerte, voir :<\/p>\nR\u00e9f\u00e9rences r\u00e9glementaires<\/h3>\n
\n
Preuve typique du constat<\/h3>\n
Rem\u00e9diation attendue<\/h3>\n
Gravit\u00e9 : \u00e9lev\u00e9e<\/h3>\n
\nConstat 6 : absence de g\u00e9n\u00e9ration de SBOM ou d’inventaire des composants tiers<\/h2>\n
Description<\/h3>\n
Pourquoi c’est important<\/h3>\n
R\u00e9f\u00e9rences r\u00e9glementaires<\/h3>\n
\n
Preuve typique du constat<\/h3>\n
Rem\u00e9diation attendue<\/h3>\n
Gravit\u00e9 : moyenne \u00e0 \u00e9lev\u00e9e<\/h3>\n
\nConstat 7 : acc\u00e8s direct \u00e0 la production sans gestion des changements<\/h2>\n
Description<\/h3>\n
Pourquoi c’est important<\/h3>\n
R\u00e9f\u00e9rences r\u00e9glementaires<\/h3>\n
\n
Preuve typique du constat<\/h3>\n
Rem\u00e9diation attendue<\/h3>\n
Gravit\u00e9 : critique<\/h3>\n
\nConstat 8 : suppressions de vuln\u00e9rabilit\u00e9s sans acceptation du risque document\u00e9e<\/h2>\n
Description<\/h3>\n
Pourquoi c’est important<\/h3>\n
R\u00e9f\u00e9rences r\u00e9glementaires<\/h3>\n
\n
Preuve typique du constat<\/h3>\n
Rem\u00e9diation attendue<\/h3>\n
Gravit\u00e9 : \u00e9lev\u00e9e<\/h3>\n
\nConstat 9 : absence de s\u00e9paration entre les environnements de d\u00e9veloppement, de pr\u00e9production et de production<\/h2>\n
Description<\/h3>\n
Pourquoi c’est important<\/h3>\n
R\u00e9f\u00e9rences r\u00e9glementaires<\/h3>\n
\n
Preuve typique du constat<\/h3>\n
Rem\u00e9diation attendue<\/h3>\n
Gravit\u00e9 : \u00e9lev\u00e9e<\/h3>\n
\nConstat 10 : application incoh\u00e9rente des contr\u00f4les entre les \u00e9quipes ou les pipelines<\/h2>\n
Description<\/h3>\n
Pourquoi c’est important<\/h3>\n
R\u00e9f\u00e9rences r\u00e9glementaires<\/h3>\n
\n
Preuve typique du constat<\/h3>\n
Rem\u00e9diation attendue<\/h3>\n
Gravit\u00e9 : moyenne \u00e0 \u00e9lev\u00e9e<\/h3>\n
\nSynth\u00e8se : constats, impact r\u00e9glementaire et priorit\u00e9 de rem\u00e9diation<\/h2>\n
\n\n
\n \nConstat<\/th>\n DORA<\/th>\n NIS2<\/th>\n ISO 27001<\/th>\n SOC 2<\/th>\n PCI DSS<\/th>\n Gravit\u00e9<\/th>\n Priorit\u00e9 de rem\u00e9diation<\/th>\n<\/tr>\n<\/thead>\n \n 1. Comptes de service partag\u00e9s<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n \u00c9lev\u00e9e<\/td>\n Imm\u00e9diate<\/td>\n<\/tr>\n \n 2. Points d’approbation contournables<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n \u00c9lev\u00e9e<\/td>\n Imm\u00e9diate<\/td>\n<\/tr>\n \n 3. Absence de conservation \/ journaux modifiables<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n \u00c9lev\u00e9e<\/td>\n Imm\u00e9diate<\/td>\n<\/tr>\n \n 4. Secrets cod\u00e9s en dur<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Critique<\/td>\n Imm\u00e9diate<\/td>\n<\/tr>\n \n 5. Analyses de s\u00e9curit\u00e9 sans points de contr\u00f4le<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n \u00c9lev\u00e9e<\/td>\n \u00c9lev\u00e9e<\/td>\n<\/tr>\n \n 6. Absence de SBOM \/ inventaire des composants<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Partiel<\/td>\n Moyenne \u00e0 \u00e9lev\u00e9e<\/td>\n \u00c9lev\u00e9e<\/td>\n<\/tr>\n \n 7. Acc\u00e8s direct \u00e0 la production<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Critique<\/td>\n Imm\u00e9diate<\/td>\n<\/tr>\n \n 8. Suppression de vuln\u00e9rabilit\u00e9s non gouvern\u00e9e<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n \u00c9lev\u00e9e<\/td>\n \u00c9lev\u00e9e<\/td>\n<\/tr>\n \n 9. Absence de s\u00e9paration des environnements<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n \u00c9lev\u00e9e<\/td>\n \u00c9lev\u00e9e<\/td>\n<\/tr>\n \n 10. Contr\u00f4les incoh\u00e9rents entre \u00e9quipes<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Oui<\/td>\n Moyenne \u00e0 \u00e9lev\u00e9e<\/td>\n Moyenne<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Comment ces constats apparaissent g\u00e9n\u00e9ralement lors des audits<\/h2>\n
\n
Reconnaissance de sch\u00e9mas : ce que r\u00e9v\u00e8lent les combinaisons de constats<\/h2>\n
Recommandations pour les \u00e9quipes de conformit\u00e9<\/h2>\n
\n
Ressources connexes<\/h2>\n
\n
Ressources connexes pour les auditeurs<\/h3>\n