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 — under DORA, NIS2, ISO 27001, SOC 2, and PCI DSS.
You don’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.
This guide helps you navigate the site and build confidence in assessing CI/CD environments, even without a deep technical background.
Qu’est-ce qu’un pipeline CI/CD ?
A CI/CD pipeline is an automated system that takes code written by developers and moves it through a series of stages — build, test, scan, approve, deploy — before it reaches production. Think of it as a controlled assembly line for software, where each station performs a specific quality or security check.
Here is a simplified view of a typical pipeline:
CODE → BUILD → TEST → SCAN → APPROVE → DEPLOY → MONITOREach stage serves a distinct purpose — and each one matters for audit assurance:
- CODE — Developers write and commit changes to a version-controlled repository. Auditors care because this is where change traceability begins.
- BUILD — Source code is compiled into deployable artifacts. Auditors care because build integrity ensures that what was reviewed is what gets deployed.
- TEST — Les tests automatisés valident la fonctionnalité et détectent les régressions. Les auditeurs s’en soucient car les preuves de test démontrent la diligence raisonnable en assurance qualité.
- SCAN — Les scanners de sécurité vérifient les vulnérabilités, les erreurs de configuration et les risques de licence. Les auditeurs s’en soucient car c’est un contrôle principal pour identifier les faiblesses connues avant le déploiement.
- APPROVE — Des gates d’approbation humaines ou automatisées décident si le changement se poursuit. Les auditeurs s’en soucient car l’application de l’approbation est la pierre angulaire de la séparation des fonctions.
- DEPLOY — L’artefact est publié en production via un processus automatisé et reproductible. Les auditeurs s’en soucient car les contrôles de déploiement déterminent si des changements non autorisés peuvent atteindre la production.
- MONITOR — Runtime systems detect anomalies, performance issues, and security events. Auditors care because monitoring closes the feedback loop and enables incident detection.
Point clé : Un pipeline bien conçu rend la sécurité obligatoire. Un pipeline mal conçu rend la sécurité optionnelle.
L’architecture du pipeline détermine si les contrôles de sécurité sont obligatoires (appliqués par conception) ou optionnels (dépendants de la discipline individuelle). Cette distinction est essentielle pour les auditeurs : un pipeline bien conçu fait de la conformité une propriété du système, pas un projet périodique.
Besoin de définitions ? Consultez notre Glossaire pour des explications en langage clair des termes techniques.
Pourquoi les auditeurs doivent comprendre la livraison logicielle
Les réglementations exigent désormais explicitement des organisations qu’elles gouvernent leurs systèmes de livraison logicielle :
- DORA (Digital Operational Resilience Act) — traite les pipelines CI/CD comme des systèmes ICT soumis à la gestion des risques, aux tests et à la supervision des tiers
- NIS2 — exige la sécurité de la chaîne d’approvisionnement, le signalement des incidents et des mesures de gestion des risques qui impliquent directement la livraison logicielle
- ISO 27001 — Les contrôles de l’Annexe A couvrent le développement des systèmes, la gestion des changements et les relations avec les fournisseurs
- SOC 2 — Les critères de services de confiance pour la gestion des changements (CC8), l’accès logique (CC6) et les opérations système (CC7) touchent tous le CI/CD
- PCI DSS v4.0 — L’exigence 6 impose des pratiques de développement sécurisé et la gestion des vulnérabilités
The following table maps specific regulatory requirements to what they demand for software delivery:
| Regulation | Article / Requirement | What It Requires for Software Delivery |
|---|---|---|
| DORA | Art. 9 | ICT risk management framework must cover CI/CD systems, including protection, detection, and response capabilities |
| DORA | Art. 21 | ICT change management must be controlled, tested, and approved — directly applicable to pipeline governance |
| DORA | Art. 28 | Third-party ICT risk management extends to cloud providers, SaaS tools, and pipeline service providers |
| NIS2 | Art. 21 | Risk management measures must address supply chain security, vulnerability handling, and secure development practices |
| ISO 27001 | A.8.25 | Secure development lifecycle — security must be designed into the development process |
| ISO 27001 | A.8.28 | Secure coding practices — code must be developed, reviewed, and tested according to security standards |
| ISO 27001 | A.8.29 | Security testing in development and acceptance — testing must verify that security requirements are met |
| SOC 2 | CC6 | Logical and physical access controls — restrict who can modify pipeline configurations and deploy to production |
| SOC 2 | CC7 | System operations — monitoring, incident detection, and response for CI/CD infrastructure |
| SOC 2 | CC8 | Change management — changes must be authorised, tested, and approved before implementation |
| PCI DSS | Req. 6 | Develop and maintain secure systems — includes secure coding, vulnerability management, and change controls |
| PCI DSS | Req. 8 | Identify users and authenticate access — MFA and access controls for pipeline and deployment systems |
| PCI DSS | Req. 10 | Log and monitor all access — audit trails for pipeline activity, deployments, and configuration changes |
If software delivery is not in scope for your audit, you may be missing a critical control surface.
The 5 Things Every Auditor Should Verify
Regardless of the regulatory framework, these five areas form the foundation of CI/CD audit assurance:
1. Pipeline Integrity
Can pipeline configurations be modified without approval? Are stages mandatory or skippable? Is there evidence of tamper-resistant execution?
- Preuves to request: Configuration du pipelineuration files (YAML/JSON) stored in version control, audit logs of pipeline definition changes, branch protection rules preventing direct edits.
- Red flag: Pipeline definitions can be edited directly in the CI/CD tool’s UI without version control or approval — this means anyone with access can silently remove security stages.
- Deep dive: Core CI/CD Security Controls
2. Access Controls & Segregation of Duties
Can the same person write code and deploy it to production? Are privileged roles protected with MFA? Are access reviews performed?
- Preuves to request: 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.
- Red flag: A single user account has both « merge to main » and « deploy to production » permissions with no secondary approval required.
- Deep dive: Comment les auditeurs examinent réellement les pipelines CI/CD
3. Secrets Management
Are credentials stored in a centralised vault? Are they rotated automatically? Can secrets appear in logs or code?
- Preuves to request: Vault configuration and access policies, secret rotation schedules, log masking configuration, scan results from secret detection tools (e.g., GitLeaks, TruffleHog).
- Red flag: Credentials are hardcoded in pipeline configuration files or environment variables that are visible in build logs.
- Deep dive: Glossary — Secrets Management
4. Artifact Provenance
Are deployed artifacts signed and traceable to a specific pipeline run? Can unsigned or unscanned artifacts reach production?
- Preuves to request: 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.
- Red flag: Production containers are pulled from a public registry without signature verification or vulnerability scanning.
- Deep dive: Glossary — SBOM (Software Bill of Materials)
5. Change Approval Enforcement
Are pull request reviews mandatory? Are approvals logged? Can emergency changes bypass controls without documented exceptions?
- Preuves to request: Branch protection rules requiring approvals, merge audit logs showing reviewer identities, emergency change procedure documentation, exception logs with justification and post-incident review.
- Red flag: The « admin override » feature is used regularly to bypass required reviews, with no exception documentation or follow-up audit.
- Deep dive: Audit Day Playbook
Reading Paths
Choose the path that best matches your role and objectives:
If you are new to CI/CD auditing:
- Glossary — Learn the terminology first
- This guide — Understand the structure and key concepts
- Core CI/CD Security Controls — The essential controls every pipeline should have
- Comment les auditeurs examinent réellement les pipelines CI/CD — Practical review methodology
If you audit under DORA:
- Start with DORA Hub Page — overview and article index
- Read DORA Article 21 Deep Dive — ICT risk management controls
- Read DORA Article 28 Explained — third-party ICT risk
- Use the DORA Article 28 Auditor Checklist
- Review the Controls & Preuves Mapping
If you audit under NIS2:
- Start with NIS2 Hub Page — overview and scope
- Read NIS2 Security Architecture Explained
- Review NIS2 Supply Chain Security Deep Dive
- Use the NIS2 Supply Chain Auditor Checklist
If you audit under ISO 27001, SOC 2, or PCI DSS:
- Start with Compliance Mapping (ISO 27001 / SOC 2 / DORA)
- Read Compliance Mapping (NIS2 / PCI DSS)
- Review the Dual-Compliance Architecture
If you assess multiple frameworks:
- Dual-Compliance Architecture — How to satisfy overlapping requirements efficiently
- ISO 27001 vs DORA vs NIS2 Overlap Matrix — Side-by-side comparison of control requirements
- NIS2 vs DORA Overlap Analysis — Detailed mapping of shared and distinct obligations
If you are preparing for an audit:
How This Site Is Organised
- Regulatory Frameworks — DORA, NIS2, and regulation-specific deep dives
- Audit & Governance — What auditors assess, governance models, maturity levels
- Architecture — CI/CD as enforcement systems, maturity models
- Application Security Governance — Secure SDLC, risk frameworks
- DevSecOps Operating Models — Roles, responsibilities, operating frameworks
- Glossary — Plain-language definitions of technical terms
For technical implementation guidance (code, configurations, tool setup), visit our sister site secure-pipelines.com.
Quick Reference
Frequently used resources across the site:
- Glossary — Plain-language definitions of CI/CD and security terms
- Common Audit Findings — Top 10 — The most frequent CI/CD control failures auditors encounter
- Executive Audit Briefing — High-level summary for leadership and board reporting
- Full Resource Directory — Complete index of all guides, checklists, and reference materials
This site is designed to grow your confidence in assessing CI/CD environments. Every article is written for your perspective — controls, evidence, and verification. No code required.
