This glossary explains key technical terms in plain language, tailored for auditors, compliance officers, and risk managers. For each term, we explain what it is<\/strong>, why auditors care<\/strong>, and what evidence to look for<\/strong>.<\/p>\n Ce que c’est :<\/strong> An automated system that builds, tests, and deploys software every time developers make changes. Think of it as a digital assembly line for software \u2014 code goes in one end, tested and packaged software comes out the other.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> CI\/CD pipelines are the control enforcement layer<\/em> for software delivery. If security controls are not embedded in this pipeline, they are likely not enforced at all. Under DORA and NIS2, CI\/CD systems qualify as regulated ICT systems.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Pipeline execution logs with timestamps, mandatory stage completion records, approval workflows before production deployment.<\/p>\n Ce que c’est :<\/strong> A sequence of automated steps (build, test, scan, deploy) that code must pass through before reaching production. Each step can enforce a security gate.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> The pipeline architecture determines whether security controls are mandatory<\/em> or optional<\/em>. A well-designed pipeline prevents unapproved code from reaching production.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Pipeline configuration files showing mandatory stages, gate pass\/fail logs, records of blocked deployments.<\/p>\n Ce que c’est :<\/strong> Automated analysis of source code to find security vulnerabilities before<\/em> the software runs. It reads the code like a reviewer would, looking for known vulnerability patterns.<\/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> IAST provides highly accurate results with fewer false positives than SAST or DAST alone, which means findings are more actionable and auditable.<\/p>\n Preuves \u00e0 rechercher :<\/strong> IAST agent deployment records, test execution reports, vulnerability findings correlated with specific code paths.<\/p>\n Ce que c’est :<\/strong> A runtime security agent embedded inside the application that detects and blocks attacks in real time. Unlike a firewall (which protects the perimeter), RASP protects from within the application.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> RASP demonstrates runtime protection \u2014 a detective and corrective control that operates continuously, not just during testing phases.<\/p>\n Preuves \u00e0 rechercher :<\/strong> RASP deployment configuration, blocked attack logs, alert\/incident integration records, coverage reports.<\/p>\n Ce que c’est :<\/strong> A container<\/strong> is a lightweight, isolated package that bundles an application with everything it needs to run. An image<\/strong> is the template used to create containers. A registry<\/strong> is the repository where images are stored and distributed.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Containers are the standard deployment unit in modern environments. Unsigned or unscanned images represent a supply chain risk. Registry access controls determine who can deploy what.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Image scanning reports, image signing\/verification records, registry access control policies, base image update policies.<\/p>\n Ce que c’est :<\/strong> Managing infrastructure (servers, networks, databases) through code files rather than manual configuration. Changes to infrastructure go through the same pipeline as application code.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> IaC makes infrastructure changes traceable, reviewable, and auditable \u2014 the same governance controls that apply to code can apply to infrastructure.<\/p>\n Preuves \u00e0 rechercher :<\/strong> IaC templates in version control, change approval records, drift detection reports, security scanning of IaC templates.<\/p>\n Ce que c’est :<\/strong> The practice of securely storing, distributing, and rotating sensitive credentials (API keys, passwords, certificates, tokens) used by applications and pipelines.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Exposed secrets are one of the most common and severe security failures. Proper secrets management demonstrates access control maturity and reduces credential compromise risk.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Centralised vault\/secrets manager deployment, automated rotation policies, no hardcoded secrets in code (verified by scanning), access audit logs.<\/p>\n Ce que c’est :<\/strong> Any output produced by the CI\/CD pipeline \u2014 compiled code, container images, packages, documentation. Artifacts are what gets deployed to production.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Artifact integrity ensures that what was tested is exactly what gets deployed. Tampered or unsigned artifacts represent a critical supply chain risk.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Artifact signing records, provenance metadata, checksums\/hashes, immutable artifact storage, deployment traceability back to specific pipeline runs.<\/p>\n Ce que c’est :<\/strong> Encoding security and compliance policies as machine-readable rules that are automatically enforced by the CI\/CD pipeline. Instead of a PDF policy document, the policy becomes executable code.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Policy-as-code transforms policies from aspirational documents into enforced controls. It provides evidence that policies are not just written but actually applied.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Policy definition files in version control, enforcement logs showing policy evaluation results, records of deployments blocked by policy violations.<\/p>\n Ce que c’est :<\/strong> Moving security testing and controls earlier in the software development lifecycle \u2014 from post-deployment (right) to design and coding phases (left). The goal is to catch issues when they are cheaper and easier to fix.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> Shift-left is evidence of a proactive, preventive security posture rather than a reactive one. Regulations increasingly expect security to be embedded throughout the SDLC, not bolted on at the end.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Security requirements in design documents, SAST integrated in developer workflows, threat modelling records, developer security training logs.<\/p>\n Ce que c’est :<\/strong> An operating model that integrates security into every phase of software development and delivery. It defines roles, responsibilities, and automated controls to ensure security is continuous \u2014 not a separate phase or team.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> DevSecOps is the governance framework that makes CI\/CD security sustainable. It determines who is responsible for what, how exceptions are handled, and how controls are enforced.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Defined roles and responsibilities (RACI), security gate configurations, exception\/suppression approval workflows, security metrics and reporting cadence.<\/p>\n Ce que c’est :<\/strong> Ensuring that no single person can both develop code and approve its deployment to production. Different roles handle different stages of the delivery process.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> SoD is a fundamental control required by virtually every compliance framework. It prevents fraud, reduces insider threat risk, and ensures independent review.<\/p>\n Preuves \u00e0 rechercher :<\/strong> RBAC configurations, approval workflow logs showing different approvers than code authors, branch protection rules, deployment permission matrices.<\/p>\n Ce que c’est :<\/strong> An access control model where permissions are assigned to roles (e.g., developer, reviewer, deployer) rather than individual users. Users inherit permissions through their role assignment.<\/p>\n Pourquoi les auditeurs s’en soucient :<\/strong> RBAC is the foundation for segregation of duties and least privilege. It provides a structured, auditable access model.<\/p>\n Preuves \u00e0 rechercher :<\/strong> Role definitions and permission matrices, user-to-role assignment records, periodic access reviews, privileged role monitoring.<\/p>\n This glossary is maintained as a living reference. Terms are defined from the auditor’s perspective \u2014 focused on control verification, not implementation details. For technical implementation guidance, visit secure-pipelines.com<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Security & DevSecOps Glossary for Auditors This glossary explains key technical terms in plain language, tailored for auditors, compliance officers, and risk managers. For each term, we explain what it is, why auditors care, and what evidence to look for. CI\/CD (Continuous Integration \/ Continuous Delivery) Ce que c’est : An automated system that builds, … 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
Secrets Management<\/h3>\n
Artifact<\/h3>\n
Policy-as-Code<\/h3>\n
Shift-Left<\/h3>\n
DevSecOps<\/h3>\n
Segregation of Duties (SoD)<\/h3>\n
RBAC (Role-Based Access Control)<\/h3>\n