{"id":1474,"date":"2026-03-25T16:51:55","date_gmt":"2026-03-25T15:51:55","guid":{"rendered":"https:\/\/regulated-devsecops.com\/start-here-2\/"},"modified":"2026-03-26T07:05:29","modified_gmt":"2026-03-26T06:05:29","slug":"start-here","status":"publish","type":"page","link":"https:\/\/regulated-devsecops.com\/fr\/start-here\/","title":{"rendered":"Commencez ici \u2014 Guide de l&rsquo;auditeur pour la s\u00e9curit\u00e9 CI\/CD"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Welcome, Auditor<\/h2>\n\n\n\n<p>If you audit, assess, or govern organisations that deliver software, this site is built for you. Modern software delivery uses automated pipelines (CI\/CD) that are increasingly subject to regulatory oversight \u2014 under DORA, NIS2, ISO 27001, SOC 2, and PCI DSS.<\/p>\n\n\n\n<p><strong>You don&rsquo;t need to understand code to audit CI\/CD pipelines. You need to understand controls, evidence, and what good governance looks like. This guide gives you that foundation.<\/strong><\/p>\n\n\n\n<p>This guide helps you navigate the site and build confidence in assessing CI\/CD environments, even without a deep technical background.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Qu&rsquo;est-ce qu&rsquo;un pipeline CI\/CD ?<\/h2>\n\n\n\n<p>A CI\/CD pipeline is an automated system that takes code written by developers and moves it through a series of stages \u2014 build, test, scan, approve, deploy \u2014 before it reaches production. Think of it as a controlled assembly line for software, where each station performs a specific quality or security check.<\/p>\n\n\n\n<p>Here is a simplified view of a typical pipeline:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>CODE \u2192 BUILD \u2192 TEST \u2192 SCAN \u2192 APPROVE \u2192 DEPLOY \u2192 MONITOR<\/code><\/pre>\n\n\n\n<p>Each stage serves a distinct purpose \u2014 and each one matters for audit assurance:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CODE<\/strong> \u2014 Developers write and commit changes to a version-controlled repository. Auditors care because this is where change traceability begins.<\/li>\n<li><strong>BUILD<\/strong> \u2014 Source code is compiled into deployable artifacts. Auditors care because build integrity ensures that what was reviewed is what gets deployed.<\/li>\n<li><strong>TEST<\/strong> \u2014 Les tests automatis\u00e9s valident la fonctionnalit\u00e9 et d\u00e9tectent les r\u00e9gressions. Les auditeurs s&rsquo;en soucient car les preuves de test d\u00e9montrent la diligence raisonnable en assurance qualit\u00e9.<\/li>\n<li><strong>SCAN<\/strong> \u2014 Les scanners de s\u00e9curit\u00e9 v\u00e9rifient les vuln\u00e9rabilit\u00e9s, les erreurs de configuration et les risques de licence. Les auditeurs s&rsquo;en soucient car c&rsquo;est un contr\u00f4le principal pour identifier les faiblesses connues avant le d\u00e9ploiement.<\/li>\n<li><strong>APPROVE<\/strong> \u2014 Des gates d&rsquo;approbation humaines ou automatis\u00e9es d\u00e9cident si le changement se poursuit. Les auditeurs s&rsquo;en soucient car l&rsquo;application de l&rsquo;approbation est la pierre angulaire de la s\u00e9paration des fonctions.<\/li>\n<li><strong>DEPLOY<\/strong> \u2014 L&rsquo;artefact est publi\u00e9 en production via un processus automatis\u00e9 et reproductible. Les auditeurs s&rsquo;en soucient car les contr\u00f4les de d\u00e9ploiement d\u00e9terminent si des changements non autoris\u00e9s peuvent atteindre la production.<\/li>\n<li><strong>MONITOR<\/strong> \u2014 Runtime systems detect anomalies, performance issues, and security events. Auditors care because monitoring closes the feedback loop and enables incident detection.<\/li>\n<\/ul>\n\n\n\n<p><strong>Point cl\u00e9 :<\/strong> Un pipeline bien con\u00e7u rend la s\u00e9curit\u00e9 obligatoire. Un pipeline mal con\u00e7u rend la s\u00e9curit\u00e9 optionnelle.<\/p>\n\n\n\n<p>L&rsquo;architecture du pipeline d\u00e9termine si les contr\u00f4les de s\u00e9curit\u00e9 sont <strong>obligatoires<\/strong> (appliqu\u00e9s par conception) ou <strong>optionnels<\/strong> (d\u00e9pendants de la discipline individuelle). Cette distinction est essentielle pour les auditeurs : un pipeline bien con\u00e7u fait de la conformit\u00e9 une propri\u00e9t\u00e9 du syst\u00e8me, pas un projet p\u00e9riodique.<\/p>\n\n\n\n<p><em>Besoin de d\u00e9finitions ? Consultez notre <a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/\">Glossaire<\/a> pour des explications en langage clair des termes techniques.<\/em><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Pourquoi les auditeurs doivent comprendre la livraison logicielle<\/h2>\n\n\n\n<p>Les r\u00e9glementations exigent d\u00e9sormais explicitement des organisations qu&rsquo;elles gouvernent leurs syst\u00e8mes de livraison logicielle :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>DORA<\/strong> (Digital Operational Resilience Act) \u2014 traite les pipelines CI\/CD comme des syst\u00e8mes ICT soumis \u00e0 la gestion des risques, aux tests et \u00e0 la supervision des tiers<\/li>\n<li><strong>NIS2<\/strong> \u2014 exige la s\u00e9curit\u00e9 de la cha\u00eene d&rsquo;approvisionnement, le signalement des incidents et des mesures de gestion des risques qui impliquent directement la livraison logicielle<\/li>\n<li><strong>ISO 27001<\/strong> \u2014 Les contr\u00f4les de l&rsquo;Annexe A couvrent le d\u00e9veloppement des syst\u00e8mes, la gestion des changements et les relations avec les fournisseurs<\/li>\n<li><strong>SOC 2<\/strong> \u2014 Les crit\u00e8res de services de confiance pour la gestion des changements (CC8), l&rsquo;acc\u00e8s logique (CC6) et les op\u00e9rations syst\u00e8me (CC7) touchent tous le CI\/CD<\/li>\n<li><strong>PCI DSS v4.0<\/strong> \u2014 L&rsquo;exigence 6 impose des pratiques de d\u00e9veloppement s\u00e9curis\u00e9 et la gestion des vuln\u00e9rabilit\u00e9s<\/li>\n<\/ul>\n\n\n\n<p>The following table maps specific regulatory requirements to what they demand for software delivery:<\/p>\n\n\n\n<figure class=\"wp-block-table is-style-stripes\"><table><thead><tr><th>Regulation<\/th><th>Article \/ Requirement<\/th><th>What It Requires for Software Delivery<\/th><\/tr><\/thead><tbody><tr><td>DORA<\/td><td>Art. 9<\/td><td>ICT risk management framework must cover CI\/CD systems, including protection, detection, and response capabilities<\/td><\/tr><tr><td>DORA<\/td><td>Art. 21<\/td><td>ICT change management must be controlled, tested, and approved \u2014 directly applicable to pipeline governance<\/td><\/tr><tr><td>DORA<\/td><td>Art. 28<\/td><td>Third-party ICT risk management extends to cloud providers, SaaS tools, and pipeline service providers<\/td><\/tr><tr><td>NIS2<\/td><td>Art. 21<\/td><td>Risk management measures must address supply chain security, vulnerability handling, and secure development practices<\/td><\/tr><tr><td>ISO 27001<\/td><td>A.8.25<\/td><td>Secure development lifecycle \u2014 security must be designed into the development process<\/td><\/tr><tr><td>ISO 27001<\/td><td>A.8.28<\/td><td>Secure coding practices \u2014 code must be developed, reviewed, and tested according to security standards<\/td><\/tr><tr><td>ISO 27001<\/td><td>A.8.29<\/td><td>Security testing in development and acceptance \u2014 testing must verify that security requirements are met<\/td><\/tr><tr><td>SOC 2<\/td><td>CC6<\/td><td>Logical and physical access controls \u2014 restrict who can modify pipeline configurations and deploy to production<\/td><\/tr><tr><td>SOC 2<\/td><td>CC7<\/td><td>System operations \u2014 monitoring, incident detection, and response for CI\/CD infrastructure<\/td><\/tr><tr><td>SOC 2<\/td><td>CC8<\/td><td>Change management \u2014 changes must be authorised, tested, and approved before implementation<\/td><\/tr><tr><td>PCI DSS<\/td><td>Req. 6<\/td><td>Develop and maintain secure systems \u2014 includes secure coding, vulnerability management, and change controls<\/td><\/tr><tr><td>PCI DSS<\/td><td>Req. 8<\/td><td>Identify users and authenticate access \u2014 MFA and access controls for pipeline and deployment systems<\/td><\/tr><tr><td>PCI DSS<\/td><td>Req. 10<\/td><td>Log and monitor all access \u2014 audit trails for pipeline activity, deployments, and configuration changes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>If software delivery is not in scope for your audit, you may be missing a critical control surface.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">The 5 Things Every Auditor Should Verify<\/h2>\n\n\n\n<p>Regardless of the regulatory framework, these five areas form the foundation of CI\/CD audit assurance:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1. Pipeline Integrity<\/h3>\n\n\n\n<p>Can pipeline configurations be modified without approval? Are stages mandatory or skippable? Is there evidence of tamper-resistant execution?<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Preuves to request:<\/strong> Configuration du pipelineuration files (YAML\/JSON) stored in version control, audit logs of pipeline definition changes, branch protection rules preventing direct edits.<\/li>\n<li><strong>Red flag:<\/strong> Pipeline definitions can be edited directly in the CI\/CD tool&rsquo;s UI without version control or approval \u2014 this means anyone with access can silently remove security stages.<\/li>\n<li><strong>Deep dive:<\/strong> <a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/core-ci-cd-security-controls\/\">Core CI\/CD Security Controls<\/a><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2. Access Controls &amp; Segregation of Duties<\/h3>\n\n\n\n<p>Can the same person write code and deploy it to production? Are privileged roles protected with MFA? Are access reviews performed?<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Preuves to request:<\/strong> Role-based access control (RBAC) matrix for CI\/CD tools, MFA enforcement logs, periodic access review records, evidence that deployment requires a different approver than the code author.<\/li>\n<li><strong>Red flag:<\/strong> A single user account has both \u00ab\u00a0merge to main\u00a0\u00bb and \u00ab\u00a0deploy to production\u00a0\u00bb permissions with no secondary approval required.<\/li>\n<li><strong>Deep dive:<\/strong> <a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/how-auditors-actually-review-ci-cd-pipelines\/\">Comment les auditeurs examinent r\u00e9ellement les pipelines CI\/CD<\/a><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3. Secrets Management<\/h3>\n\n\n\n<p>Are credentials stored in a centralised vault? Are they rotated automatically? Can secrets appear in logs or code?<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Preuves to request:<\/strong> Vault configuration and access policies, secret rotation schedules, log masking configuration, scan results from secret detection tools (e.g., GitLeaks, TruffleHog).<\/li>\n<li><strong>Red flag:<\/strong> Credentials are hardcoded in pipeline configuration files or environment variables that are visible in build logs.<\/li>\n<li><strong>Deep dive:<\/strong> <a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#secrets-management\">Glossary \u2014 Secrets Management<\/a><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4. Artifact Provenance<\/h3>\n\n\n\n<p>Are deployed artifacts signed and traceable to a specific pipeline run? Can unsigned or unscanned artifacts reach production?<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Preuves to request:<\/strong> Artifact signing certificates and verification policies, Software Bill of Materials (SBOM) for recent deployments, container image signatures, policy-as-code rules that block unsigned artifacts.<\/li>\n<li><strong>Red flag:<\/strong> Production containers are pulled from a public registry without signature verification or vulnerability scanning.<\/li>\n<li><strong>Deep dive:<\/strong> <a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#sbom\">Glossary \u2014 SBOM (Software Bill of Materials)<\/a><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5. Change Approval Enforcement<\/h3>\n\n\n\n<p>Are pull request reviews mandatory? Are approvals logged? Can emergency changes bypass controls without documented exceptions?<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Preuves to request:<\/strong> Branch protection rules requiring approvals, merge audit logs showing reviewer identities, emergency change procedure documentation, exception logs with justification and post-incident review.<\/li>\n<li><strong>Red flag:<\/strong> The \u00ab\u00a0admin override\u00a0\u00bb feature is used regularly to bypass required reviews, with no exception documentation or follow-up audit.<\/li>\n<li><strong>Deep dive:<\/strong> <a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/audit-day-playbook-how-to-handle-ci-cd-audits-in-regulated-environments\/\">Audit Day Playbook<\/a><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Reading Paths<\/h2>\n\n\n\n<p>Choose the path that best matches your role and objectives:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">If you are new to CI\/CD auditing:<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/\">Glossary<\/a> \u2014 Learn the terminology first<\/li>\n<li>This guide \u2014 Understand the structure and key concepts<\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/core-ci-cd-security-controls\/\">Core CI\/CD Security Controls<\/a> \u2014 The essential controls every pipeline should have<\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/how-auditors-actually-review-ci-cd-pipelines\/\">Comment les auditeurs examinent r\u00e9ellement les pipelines CI\/CD<\/a> \u2014 Practical review methodology<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">If you audit under DORA:<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Start with <a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora\/\">DORA Hub Page<\/a> \u2014 overview and article index<\/li>\n<li>Read <a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dora-article-21-deep-dive-enforcing-ict-risk-controls-via-ci-cd\/\">DORA Article 21 Deep Dive<\/a> \u2014 ICT risk management controls<\/li>\n<li>Read <a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dora-article-28-explained-managing-ict-third-party-risk-in-ci-cd-and-cloud-environments\/\">DORA Article 28 Explained<\/a> \u2014 third-party ICT risk<\/li>\n<li>Use the <a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dora-article-28-auditor-checklist\/\">DORA Article 28 Auditor Checklist<\/a><\/li>\n<li>Review the <a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dora-article-28-controls-evidence-mapping\/\">Controls &amp; Preuves Mapping<\/a><\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">If you audit under NIS2:<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Start with <a href=\"https:\/\/regulated-devsecops.com\/compliance\/nis2\/\">NIS2 Hub Page<\/a> \u2014 overview and scope<\/li>\n<li>Read <a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/nis2-security-architecture-explained\/\">NIS2 Security Architecture Explained<\/a><\/li>\n<li>Review <a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/nis2-supply-chain-security-deep-dive-what-it-really-means-for-ci-cd-and-vendors\/\">NIS2 Supply Chain Security Deep Dive<\/a><\/li>\n<li>Use the <a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/nis2-supply-chain-auditor-checklist\/\">NIS2 Supply Chain Auditor Checklist<\/a><\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">If you audit under ISO 27001, SOC 2, or PCI DSS:<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Start with <a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/ci-cd-security-audit-compliance-mapping-iso-27001-soc-2-dora\/\">Compliance Mapping (ISO 27001 \/ SOC 2 \/ DORA)<\/a><\/li>\n<li>Read <a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/ci-cd-security-audit-compliance-mapping-nis2-pci-dss\/\">Compliance Mapping (NIS2 \/ PCI DSS)<\/a><\/li>\n<li>Review the <a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dual-compliance-architecture-explained\/\">Dual-Compliance Architecture<\/a><\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">If you assess multiple frameworks:<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dual-compliance-architecture-explained\/\">Dual-Compliance Architecture<\/a> \u2014 How to satisfy overlapping requirements efficiently<\/li>\n<li><a href=\"\/fr\/iso-27001-vs-dora-vs-nis2-overlap-matrix\/\">ISO 27001 vs DORA vs NIS2 Overlap Matrix<\/a> \u2014 Side-by-side comparison of control requirements<\/li>\n<li><a href=\"\/fr\/nis2-vs-dora-overlap-analysis\/\">NIS2 vs DORA Overlap Analysis<\/a> \u2014 Detailed mapping of shared and distinct obligations<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">If you are preparing for an audit:<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/before-the-auditor-arrives-ci-cd-audit-readiness-checklist\/\">Before the Auditor Arrives: Readiness Checklist<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/audit-day-playbook-how-to-handle-ci-cd-audits-in-regulated-environments\/\">Audit Day Playbook<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/audit-day-qa-cheat-sheet\/\">Aide-m\u00e9moire Q&amp;R du jour d&rsquo;audit<\/a><\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">How This Site Is Organised<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/compliance\/\">Regulatory Frameworks<\/a><\/strong> \u2014 DORA, NIS2, and regulation-specific deep dives<\/li>\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/audit-governance\/\">Audit &amp; Governance<\/a><\/strong> \u2014 What auditors assess, governance models, maturity levels<\/li>\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/architecture\/\">Architecture<\/a><\/strong> \u2014 CI\/CD as enforcement systems, maturity models<\/li>\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/application-security\/\">Application Security Governance<\/a><\/strong> \u2014 Secure SDLC, risk frameworks<\/li>\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/devsecops\/\">DevSecOps Operating Models<\/a><\/strong> \u2014 Roles, responsibilities, operating frameworks<\/li>\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/\">Glossary<\/a><\/strong> \u2014 Plain-language definitions of technical terms<\/li>\n<\/ul>\n\n\n\n<p><em>For technical implementation guidance (code, configurations, tool setup), visit our sister site <a href=\"https:\/\/secure-pipelines.com\" target=\"_blank\" rel=\"noopener\">secure-pipelines.com<\/a>.<\/em><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Quick Reference<\/h2>\n\n\n\n<p>Frequently used resources across the site:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/\">Glossary<\/a><\/strong> \u2014 Plain-language definitions of CI\/CD and security terms<\/li>\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/audit-evidence\/common-audit-findings-ci-cd-top-10-failures\/\">Common Audit Findings \u2014 Top 10<\/a><\/strong> \u2014 The most frequent CI\/CD control failures auditors encounter<\/li>\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/executive-audit-briefing-ci-cd-pipelines-in-regulated-environments\/\">Executive Audit Briefing<\/a><\/strong> \u2014 High-level summary for leadership and board reporting<\/li>\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/resources\/\">Full Resource Directory<\/a><\/strong> \u2014 Complete index of all guides, checklists, and reference materials<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p><strong>This site is designed to grow your confidence in assessing CI\/CD environments. Every article is written for your perspective \u2014 controls, evidence, and verification. No code required.<\/strong><\/p>\n\n","protected":false},"excerpt":{"rendered":"<p>Welcome, Auditor If you audit, assess, or govern organisations that deliver software, this site is built for you. Modern software delivery uses automated pipelines (CI\/CD) that are increasingly subject to regulatory oversight \u2014 under DORA, NIS2, ISO 27001, SOC 2, and PCI DSS. You don&rsquo;t need to understand code to audit CI\/CD pipelines. You need &#8230; <a title=\"Commencez ici \u2014 Guide de l&rsquo;auditeur pour la s\u00e9curit\u00e9 CI\/CD\" class=\"read-more\" href=\"https:\/\/regulated-devsecops.com\/fr\/start-here\/\" aria-label=\"En savoir plus sur Commencez ici \u2014 Guide de l&rsquo;auditeur pour la s\u00e9curit\u00e9 CI\/CD\">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-1474","page","type-page","status-publish"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages\/1474","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=1474"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages\/1474\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/media?parent=1474"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}