Ce glossaire explique les principaux termes techniques en langage clair, \u00e0 l’intention des auditeurs, des responsables conformit\u00e9 et des gestionnaires de risques. Pour chaque terme, nous expliquons ce que c’est<\/strong>, pourquoi les auditeurs s’en soucient<\/strong> et quelles preuves rechercher<\/strong>.<\/p>\n Ce que c’est :<\/strong> Un syst\u00e8me automatis\u00e9 qui construit, teste et d\u00e9ploie le logiciel \u00e0 chaque changement effectu\u00e9 par les d\u00e9veloppeurs. Voyez-le comme une cha\u00eene de montage num\u00e9rique pour le logiciel \u2014 le code entre d’un c\u00f4t\u00e9, un logiciel test\u00e9 et packag\u00e9 ressort de l’autre.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Les pipelines CI\/CD constituent la couche d’application des contr\u00f4les<\/em> de la livraison logicielle. Si les contr\u00f4les de s\u00e9curit\u00e9 ne sont pas int\u00e9gr\u00e9s \u00e0 ce pipeline, ils ne sont probablement pas appliqu\u00e9s du tout. Au titre de DORA et de NIS2, les syst\u00e8mes CI\/CD sont consid\u00e9r\u00e9s comme des syst\u00e8mes TIC r\u00e9glement\u00e9s.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Journaux d’ex\u00e9cution du pipeline horodat\u00e9s, enregistrements d’ach\u00e8vement des \u00e9tapes obligatoires, workflows d’approbation avant le d\u00e9ploiement en production.<\/p>\n Ce que c’est :<\/strong> Une s\u00e9quence d’\u00e9tapes automatis\u00e9es (construction, test, analyse, d\u00e9ploiement) que le code doit franchir avant d’atteindre la production. Chaque \u00e9tape peut imposer un point de contr\u00f4le de s\u00e9curit\u00e9.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> L’architecture du pipeline d\u00e9termine si les contr\u00f4les de s\u00e9curit\u00e9 sont obligatoires<\/em> ou optionnels<\/em>. Un pipeline bien con\u00e7u emp\u00eache tout code non approuv\u00e9 d’atteindre la production.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Fichiers de configuration du pipeline montrant les \u00e9tapes obligatoires, journaux de r\u00e9ussite\/\u00e9chec des points de contr\u00f4le, enregistrements des d\u00e9ploiements bloqu\u00e9s.<\/p>\n Ce que c’est :<\/strong> Analyse automatis\u00e9e du code source pour d\u00e9tecter les vuln\u00e9rabilit\u00e9s de s\u00e9curit\u00e9 avant<\/em> l’ex\u00e9cution du logiciel. Elle lit le code comme le ferait un relecteur, \u00e0 la recherche de sch\u00e9mas de vuln\u00e9rabilit\u00e9s connus.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> SAST fournit la preuve que les tests de s\u00e9curit\u00e9 se font t\u00f4t dans le d\u00e9veloppement. Il d\u00e9montre que l’organisation identifie proactivement les vuln\u00e9rabilit\u00e9s plut\u00f4t que de les d\u00e9couvrir en production.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Journaux de scan avec horodatages, application de politique montrant les builds bloqu\u00e9s sur les constats critiques, rapports de tendance montrant les taux de rem\u00e9diation dans le temps, processus de suppression\/exception document\u00e9s.<\/p>\n Ce que c’est :<\/strong> Test automatis\u00e9 d’une application en cours d’ex\u00e9cution en simulant de vraies attaques. Contrairement au SAST (qui lit le code), le DAST teste l’application comme le ferait un attaquant \u2014 de l’ext\u00e9rieur.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Le DAST valide que les applications d\u00e9ploy\u00e9es sont r\u00e9silientes face aux mod\u00e8les d’attaque connus. Il compl\u00e8te le SAST en testant le comportement r\u00e9el, pas seulement le code.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Rapports de scan DAST avec vuln\u00e9rabilit\u00e9s identifi\u00e9es et niveaux de gravit\u00e9, calendriers de rem\u00e9diation, planifications de scans r\u00e9currents, int\u00e9gration avec les journaux du pipeline CI\/CD.<\/p>\n Ce que c’est :<\/strong> Analyse automatis\u00e9e des biblioth\u00e8ques tierces et d\u00e9pendances utilis\u00e9es dans le logiciel. La plupart des applications modernes sont compos\u00e9es de 70 \u00e0 90 % de code tiers \u2014 le SCA v\u00e9rifie si ce code pr\u00e9sente des vuln\u00e9rabilit\u00e9s connues ou des risques de licence.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Le risque des composants tiers est une pr\u00e9occupation majeure selon l’article 28 de DORA et les exigences de cha\u00eene d’approvisionnement de NIS2. Le SCA fournit une visibilit\u00e9 sur la cha\u00eene d’approvisionnement logicielle.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Inventaires de d\u00e9pendances, rapports de vuln\u00e9rabilit\u00e9s pour les composants tiers, v\u00e9rifications de conformit\u00e9 de licence, blocage automatis\u00e9 des composants avec des vuln\u00e9rabilit\u00e9s critiques.<\/p>\n Ce que c’est :<\/strong> Un inventaire complet et lisible par machine de chaque composant (biblioth\u00e8ques, frameworks, d\u00e9pendances) inclus dans une application logicielle. Pensez-y comme une \u00e9tiquette nutritionnelle pour le logiciel.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Les SBOM sont de plus en plus exig\u00e9s par la r\u00e9glementation. Ils permettent la tra\u00e7abilit\u00e9 des composants de la cha\u00eene d’approvisionnement et l’\u00e9valuation rapide de l’impact lorsque de nouvelles vuln\u00e9rabilit\u00e9s sont divulgu\u00e9es.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Fichiers SBOM g\u00e9n\u00e9r\u00e9s (format SPDX ou CycloneDX), g\u00e9n\u00e9ration automatis\u00e9e de SBOM dans les pipelines CI\/CD, enregistrements de r\u00e9tention et de versioning des SBOM.<\/p>\n Ce que c’est :<\/strong> Une approche de test hybride qui surveille les applications de l’int\u00e9rieur pendant les tests. Un agent est int\u00e9gr\u00e9 dans l’application et observe les chemins d’ex\u00e9cution r\u00e9els du code pour identifier les vuln\u00e9rabilit\u00e9s avec une grande pr\u00e9cision.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> L’IAST fournit des r\u00e9sultats tr\u00e8s pr\u00e9cis avec moins de faux positifs que le SAST ou le DAST seuls, ce qui rend les constats plus exploitables et auditables.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Enregistrements de d\u00e9ploiement de l’agent IAST, rapports d’ex\u00e9cution des tests, constats de vuln\u00e9rabilit\u00e9s corr\u00e9l\u00e9s \u00e0 des chemins de code pr\u00e9cis.<\/p>\n Ce que c’est :<\/strong> Un agent de s\u00e9curit\u00e9 d’ex\u00e9cution int\u00e9gr\u00e9 \u00e0 l’application qui d\u00e9tecte et bloque les attaques en temps r\u00e9el. Contrairement \u00e0 un pare-feu (qui prot\u00e8ge le p\u00e9rim\u00e8tre), le RASP prot\u00e8ge depuis l’int\u00e9rieur de l’application.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Le RASP d\u00e9montre une protection \u00e0 l’ex\u00e9cution \u2014 un contr\u00f4le d\u00e9tectif et correctif qui fonctionne en continu, et pas seulement pendant les phases de test.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Configuration de d\u00e9ploiement du RASP, journaux des attaques bloqu\u00e9es, enregistrements d’int\u00e9gration aux alertes\/incidents, rapports de couverture.<\/p>\n Ce que c’est :<\/strong> Un conteneur<\/strong> est un package l\u00e9ger et isol\u00e9 qui regroupe une application avec tout ce dont elle a besoin pour s’ex\u00e9cuter. Une image<\/strong> est le mod\u00e8le utilis\u00e9 pour cr\u00e9er des conteneurs. Un registre<\/strong> est le d\u00e9p\u00f4t o\u00f9 les images sont stock\u00e9es et distribu\u00e9es.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Les conteneurs sont l’unit\u00e9 de d\u00e9ploiement standard dans les environnements modernes. Des images non sign\u00e9es ou non analys\u00e9es repr\u00e9sentent un risque pour la cha\u00eene d’approvisionnement. Les contr\u00f4les d’acc\u00e8s au registre d\u00e9terminent qui peut d\u00e9ployer quoi.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Rapports d’analyse des images, enregistrements de signature\/v\u00e9rification des images, politiques de contr\u00f4le d’acc\u00e8s au registre, politiques de mise \u00e0 jour des images de base.<\/p>\n Ce que c’est :<\/strong> G\u00e9rer l’infrastructure (serveurs, r\u00e9seaux, bases de donn\u00e9es) au moyen de fichiers de code plut\u00f4t que par une configuration manuelle. Les changements d’infrastructure passent par le m\u00eame pipeline que le code applicatif.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> L’IaC rend les changements d’infrastructure tra\u00e7ables, revus et auditables \u2014 les m\u00eames contr\u00f4les de gouvernance qui s’appliquent au code peuvent s’appliquer \u00e0 l’infrastructure.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Mod\u00e8les IaC sous contr\u00f4le de version, enregistrements d’approbation des changements, rapports de d\u00e9tection de d\u00e9rive, analyse de s\u00e9curit\u00e9 des mod\u00e8les IaC.<\/p>\n Ce que c’est :<\/strong> La pratique consistant \u00e0 stocker, distribuer et renouveler de fa\u00e7on s\u00e9curis\u00e9e les identifiants sensibles (cl\u00e9s d’API, mots de passe, certificats, jetons) utilis\u00e9s par les applications et les pipelines.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Les secrets expos\u00e9s comptent parmi les d\u00e9faillances de s\u00e9curit\u00e9 les plus fr\u00e9quentes et les plus graves. Une gestion des secrets rigoureuse d\u00e9montre la maturit\u00e9 du contr\u00f4le d’acc\u00e8s et r\u00e9duit le risque de compromission des identifiants.<\/p>\n Preuves \u00e0 rechercher :<\/strong> D\u00e9ploiement d’un coffre-fort\/gestionnaire de secrets centralis\u00e9, politiques de rotation automatis\u00e9es, absence de secrets cod\u00e9s en dur dans le code (v\u00e9rifi\u00e9e par analyse), journaux d’audit des acc\u00e8s.<\/p>\n Ce que c’est :<\/strong> Tout \u00e9l\u00e9ment produit par le pipeline CI\/CD \u2014 code compil\u00e9, images de conteneurs, packages, documentation. Les artefacts sont ce qui est d\u00e9ploy\u00e9 en production.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> L’int\u00e9grit\u00e9 des artefacts garantit que ce qui a \u00e9t\u00e9 test\u00e9 est exactement ce qui est d\u00e9ploy\u00e9. Des artefacts alt\u00e9r\u00e9s ou non sign\u00e9s repr\u00e9sentent un risque critique pour la cha\u00eene d’approvisionnement.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Enregistrements de signature des artefacts, m\u00e9tadonn\u00e9es de provenance, sommes de contr\u00f4le\/empreintes, stockage immuable des artefacts, tra\u00e7abilit\u00e9 du d\u00e9ploiement jusqu’\u00e0 des ex\u00e9cutions pr\u00e9cises du pipeline.<\/p>\n Ce que c’est :<\/strong> Codage des politiques de s\u00e9curit\u00e9 et de conformit\u00e9 sous forme de r\u00e8gles lisibles par machine, appliqu\u00e9es automatiquement par le pipeline CI\/CD. Au lieu d’un document de politique au format PDF, la politique devient du code ex\u00e9cutable.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> La politique en tant que code transforme les politiques, de documents d’intention en contr\u00f4les effectivement appliqu\u00e9s. Elle apporte la preuve que les politiques ne sont pas seulement r\u00e9dig\u00e9es, mais r\u00e9ellement appliqu\u00e9es.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Fichiers de d\u00e9finition des politiques sous contr\u00f4le de version, journaux d’application montrant les r\u00e9sultats d’\u00e9valuation des politiques, enregistrements des d\u00e9ploiements bloqu\u00e9s pour violation de politique.<\/p>\n Ce que c’est :<\/strong> D\u00e9placer les tests et les contr\u00f4les de s\u00e9curit\u00e9 plus t\u00f4t dans le cycle de d\u00e9veloppement logiciel \u2014 de l’apr\u00e8s-d\u00e9ploiement (\u00e0 droite) vers les phases de conception et de codage (\u00e0 gauche). L’objectif est de d\u00e9tecter les probl\u00e8mes lorsqu’ils sont moins co\u00fbteux et plus faciles \u00e0 corriger.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Le shift-left t\u00e9moigne d’une posture de s\u00e9curit\u00e9 proactive et pr\u00e9ventive plut\u00f4t que r\u00e9active. Les r\u00e9glementations attendent de plus en plus que la s\u00e9curit\u00e9 soit int\u00e9gr\u00e9e tout au long du SDLC, et non ajout\u00e9e \u00e0 la fin.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Exigences de s\u00e9curit\u00e9 dans les documents de conception, SAST int\u00e9gr\u00e9 dans les workflows des d\u00e9veloppeurs, enregistrements de mod\u00e9lisation des menaces, journaux de formation des d\u00e9veloppeurs \u00e0 la s\u00e9curit\u00e9.<\/p>\n Ce que c’est :<\/strong> Un mod\u00e8le op\u00e9rationnel qui int\u00e8gre la s\u00e9curit\u00e9 \u00e0 chaque phase du d\u00e9veloppement et de la livraison logicielle. Il d\u00e9finit les r\u00f4les, les responsabilit\u00e9s et les contr\u00f4les automatis\u00e9s pour garantir une s\u00e9curit\u00e9 continue \u2014 et non une phase ou une \u00e9quipe distincte.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> DevSecOps est le cadre de gouvernance qui rend la s\u00e9curit\u00e9 CI\/CD durable. Il d\u00e9termine qui est responsable de quoi, comment les exceptions sont trait\u00e9es et comment les contr\u00f4les sont appliqu\u00e9s.<\/p>\n Preuves \u00e0 rechercher :<\/strong> R\u00f4les et responsabilit\u00e9s d\u00e9finis (RACI), configurations des points de contr\u00f4le de s\u00e9curit\u00e9, workflows d’approbation des exceptions\/exclusions, indicateurs de s\u00e9curit\u00e9 et cadence de reporting.<\/p>\n Ce que c’est :<\/strong> Garantir qu’aucune personne ne puisse \u00e0 la fois d\u00e9velopper le code et approuver son d\u00e9ploiement en production. Des r\u00f4les diff\u00e9rents prennent en charge les diff\u00e9rentes \u00e9tapes du processus de livraison.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> La s\u00e9paration des t\u00e2ches est un contr\u00f4le fondamental exig\u00e9 par pratiquement tous les cadres de conformit\u00e9. Elle pr\u00e9vient la fraude, r\u00e9duit le risque de menace interne et garantit une revue ind\u00e9pendante.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Configurations RBAC, journaux des workflows d’approbation montrant des approbateurs diff\u00e9rents des auteurs du code, r\u00e8gles de protection de branche, matrices d’autorisations de d\u00e9ploiement.<\/p>\n Ce que c’est :<\/strong> Un mod\u00e8le de contr\u00f4le d’acc\u00e8s o\u00f9 les autorisations sont attribu\u00e9es \u00e0 des r\u00f4les (par ex. d\u00e9veloppeur, relecteur, d\u00e9ployeur) plut\u00f4t qu’\u00e0 des utilisateurs individuels. Les utilisateurs h\u00e9ritent des autorisations via l’attribution de leur r\u00f4le.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Le RBAC est le fondement de la s\u00e9paration des t\u00e2ches et du moindre privil\u00e8ge. Il fournit un mod\u00e8le d’acc\u00e8s structur\u00e9 et auditable.<\/p>\n Preuves \u00e0 rechercher :<\/strong> D\u00e9finitions de r\u00f4les et matrices d’autorisations, enregistrements d’attribution utilisateur-r\u00f4le, revues d’acc\u00e8s p\u00e9riodiques, surveillance des r\u00f4les privil\u00e9gi\u00e9s.<\/p>\n Ce glossaire est maintenu comme une r\u00e9f\u00e9rence vivante. Les termes sont d\u00e9finis du point de vue de l’auditeur \u2014 ax\u00e9s sur la v\u00e9rification des contr\u00f4les, non sur les d\u00e9tails de mise en \u0153uvre. Pour des orientations de mise en \u0153uvre technique, visitez secure-pipelines.com<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Glossaire s\u00e9curit\u00e9 et DevSecOps pour auditeurs Ce glossaire explique les principaux termes techniques en langage clair, \u00e0 l’intention des auditeurs, des responsables conformit\u00e9 et des gestionnaires de risques. Pour chaque terme, nous expliquons ce que c’est, pourquoi les auditeurs s’en soucient et quelles preuves rechercher. CI\/CD (Continuous Integration \/ Continuous Delivery) Ce que c’est : … Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-1472","page","type-page","status-publish"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages\/1472","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/comments?post=1472"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages\/1472\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/media?parent=1472"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}CI\/CD (Continuous Integration \/ Continuous Delivery)<\/h3>\n
Pipeline<\/h3>\n
SAST (Static Application Security Testing)<\/h3>\n
DAST (Dynamic Application Security Testing)<\/h3>\n
SCA (Software Composition Analysis)<\/h3>\n
SBOM (Software Bill of Materials)<\/h3>\n
IAST (Interactive Application Security Testing)<\/h3>\n
RASP (Runtime Application Self-Protection)<\/h3>\n
Container \/ Image \/ Registry<\/h3>\n
IaC (Infrastructure as Code)<\/h3>\n
Gestion des secrets<\/h3>\n
Artefact<\/h3>\n
Policy-as-Code<\/h3>\n
Shift-Left<\/h3>\n
DevSecOps<\/h3>\n
S\u00e9paration des t\u00e2ches (SoD)<\/h3>\n
RBAC (Role-Based Access Control)<\/h3>\n