Le CI/CD comme système réglementé
Dans les environnements réglementés, les pipelines CI/CD ne sont pas de simples outils d’automatisation.
Ce sont des systèmes d’application.
L’architecture détermine si :
- Les contrôles de sécurité sont obligatoires ou optionnels
- Les politiques sont documentées ou appliquées
- Evidence is manual or system-generated
- Compliance is reactive or continuous
This is the foundational insight for auditors: architecture is where compliance becomes technical reality. A well-designed pipeline makes non-compliance structurally difficult. A poorly designed one makes it structurally inevitable.
New to these concepts? See our Glossary for plain-language definitions of CI/CD terms.
Why Architecture Comes First
Before discussing tools, frameworks, or audits, one principle must be clear:
If your architecture does not enforce controls, no checklist will save you.
A secure CI/CD architecture:
- Empêche les changements non approuvés en production — via le RBAC obligatoire et les gates d’approbation
- Bloque automatiquement les violations de politique — via l’application du policy-as-code
- Génère des journaux traçables — pour chaque exécution de pipeline, approbation et déploiement
- Préserve les preuves pour les régulateurs — avec des enregistrements immuables et horodatés
- Soutient les exigences de sortie et de résilience — essentielles pour DORA et NIS2
Les contrôles doivent être intégrés dans le système — pas superposés.
Ce que les auditeurs doivent évaluer dans l’architecture CI/CD
Lors de l’examen de l’architecture CI/CD, les auditeurs doivent évaluer cinq questions clés :
| Question | Ce à quoi ressemble une bonne pratique | Signal d’alerte |
|---|---|---|
| Les étapes de sécurité peuvent-elles être ignorées ? | Toutes les étapes obligatoires ; aucun contournement sans exception gouvernée | Les étapes peuvent être commentées ou désactivées par les développeurs |
| Qui peut déployer en production ? | Déploiement restreint à des rôles spécifiques ; différent des auteurs du code | Toute personne ayant accès au dépôt peut déclencher un déploiement en production |
| Les configurations de pipeline sont-elles protégées ? | Définitions de pipeline dans le contrôle de version avec approbation des changements | Configurations de pipeline modifiables sans revue ni piste d’audit |
| Les preuves sont-elles générées par le système ? | Journaux, résultats de scan, enregistrements d’approbation produits automatiquement | Preuves compilées manuellement avant les audits |
| Les exceptions sont-elles traçables ? | Chaque contournement a une approbation documentée, une raison et une expiration | Aucun processus de gestion des exceptions ; suppressions non gouvernées |
Pour une approche d’évaluation complète, consultez Comment les auditeurs examinent réellement les pipelines CI/CD.
Core Architectural Domains
Modern regulated CI/CD architectures rely on four foundational domains. Each domain addresses a distinct control objective that auditors verify independently.
1. Enforcement Layer
The enforcement layer is the control engine of the pipeline. It determines whether security is advisory or mandatory.
It ensures:
- Mandatory approval workflows — no deployment without authorised review
- Blocking policy gates — critical SAST/DAST/SCA findings prevent release
- Secure build and artifact validation — signed, verified, traceable
- Role-based deployment permissions — segregation of duties enforced by design
- Exception governance with audit trails — every override documented and time-limited
Without enforcement, CI/CD becomes advisory. With enforcement, CI/CD becomes regulated.
Auditor insight: Ask to see a recent deployment that was blocked by a policy gate. If the organisation cannot produce one, enforcement may not be real.
Deep dives:
2. Secure SDLC Integration
Architecture must integrate security from plan to runtime — the shift-left principle embedded in pipeline design.
| SDLC Phase | Security Control | Evidence Produced |
|---|---|---|
| Plan | Threat modelling, security requirements | Threat model documents, security stories |
| Code | SAST, secrets scanning, code review | Scan logs, review approval records |
| Build | SCA, SBOM generation, artifact signing | Dependency reports, SBOM files, signatures |
| Test | DAST, penetration testing | DAST reports, test evidence |
| Release | Policy gate evaluation, approval workflows | Gate pass/fail logs, approval records |
| Deploy | Configuration validation, environment parity | Deployment logs, config checksums |
| Monitor | Runtime protection, incident detection | Alert logs, incident records |
Secure SDLC is not a compliance slogan — it is an architectural pattern.
Deep dives:
- Secure SDLC Fundamentals
- Secure SDLC from the Auditor’s Perspective
- How Auditors Assess Application Security Controls
3. Continuous Compliance Model
Regulated environments require compliance that is continuous, not periodic. The architecture must produce evidence automatically on every pipeline execution.
- Repeatable control execution — same controls, every time, every pipeline
- Evidence-by-design — logs, reports, and approval records generated as a byproduct of normal operations
- Automated traceability — every deployment traceable to a specific commit, review, scan, and approval
- Framework mapping — controls mapped to DORA, NIS2, ISO 27001, SOC 2, PCI DSS
A mature architecture produces compliance continuously — not quarterly.
Deep dives:
- Continuous Compliance via CI/CD
- Continuous Auditing vs Point-in-Time Audits
- Dual-Compliance Architecture — Explained
- Building an Evidence Repository for Continuous Compliance
4. Security Domain Separation
Confusion often arises between overlapping security domains. Clear architecture prevents duplication and control gaps.
| Domain | Focus | Key Concern for Auditors | Hub Page |
|---|---|---|---|
| CI/CD Governance | Pipeline controls, enforcement, access | Are controls mandatory and non-bypassable? | Explore |
| Application Security | Code-level controls (SAST, DAST, SCA) | Is security testing integrated and enforced? | Explore |
| DevSecOps | Operating models, roles, governance | Who owns security? How are decisions escalated? | Explore |
| Regulatory Frameworks | Compliance mapping and assurance | Do controls satisfy regulatory requirements? | Explore |
| Audit & Evidence | Evidence validation, assessment | Is evidence trustworthy, complete, and retained? | Explore |
Understanding these domains prevents duplication and control gaps. Architecture ensures each domain has clear boundaries and responsibilities.
Deep dive: Security Domains Explained
Architectural Maturity Model
Regulated CI/CD systems typically evolve across four stages. Auditors can use this model to quickly assess an organisation’s maturity level.
| Level | Name | Characteristics | Regulatory Readiness |
|---|---|---|---|
| 1 | Automation | Pipelines automate builds and deployments. Controls are optional. No evidence generation. | Not audit-ready. Significant gaps across all frameworks. |
| 2 | Security Integration | Security tools integrated (SAST/DAST/SCA). Results advisory, not blocking. Some logging. | Partially compliant. Evidence exists but enforcement is inconsistent. |
| 3 | Enforced Controls | Critical controls block non-compliant releases. Segregation of duties. Systematic evidence. | Audit-ready for most frameworks. Meets DORA/NIS2/ISO 27001 minimums. |
| 4 | Regulated System | Full traceability. Policy-as-code. Continuous compliance. Exit readiness. Predictive risk. | Exceeds requirements. Continuous assurance model. |
Regulated environments must operate at Level 3 or higher. Most regulatory frameworks (DORA, NIS2, ISO 27001) effectively require Level 3 as a minimum for certification or compliance.
For a structured self-assessment tool, see the DevSecOps Maturity Assessment Framework.
Architecture vs Tooling
Tools do not create architecture. Architecture defines how tools are governed.
| Architecture Decides | Tools Implement |
|---|---|
| Which controls are mandatory | How scans are executed |
| Where enforcement occurs in the pipeline | Which vulnerabilities are detected |
| Which failures block releases | How results are reported |
| How evidence is retained and protected | Where logs are stored |
| Who can override policies | How exceptions are technically processed |
A strong architecture can change tools without losing control. A weak architecture depends entirely on vendor defaults.
For auditor guidance on tool governance, see CI/CD Security Tooling — Auditor’s Guide to Tool Categories and Controls.
Architecture & Regulatory Alignment
A well-designed CI/CD architecture supports multiple regulatory frameworks simultaneously. Rather than adapting architecture per regulation, design architecture once — map controls many times.
| Framework | Architectural Requirement | Key Articles/Controls | Deep Dive |
|---|---|---|---|
| DORA | ICT risk management, third-party control, resilience testing | Art. 9, 21, 28 | Art. 21 Deep Dive |
| NIS2 | Supply chain security, incident readiness, risk management | Art. 21 | Art. 21 Controls Mapping |
| ISO 27001 | Change management, access control, secure development | A.8.25, A.8.28, A.8.29 | Annex A Mapping |
| SOC 2 | Logical access, system operations, change management | CC6, CC7, CC8 | TSC Mapping |
| PCI DSS | Secure development, access control, logging, testing | Req. 6, 7, 8, 10, 11 | Req. 6 Deep Dive |
For cross-framework analysis, see the ISO 27001 vs DORA vs NIS2 Controls Overlap Matrix.
Related Architecture Deep Dives
- CI/CD Only Architecture — Pipeline, Evidence & Approvals
- CI/CD Enforcement Layer
- CI/CD-Based Enforcement Models
- Continuous Compliance via CI/CD
- Secure SDLC Fundamentals
- Core CI/CD Security Controls
- DORA Compliance Architecture — CI/CD as a Regulated ICT System
- NIS2 Security Architecture Explained
Final Principle
In regulated environments, delivery speed and control are not opposites. The right architecture makes them compatible.
If your pipeline is not designed as a control system, compliance will always be reactive. If your architecture enforces policy by design, compliance becomes continuous.
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- How Auditors Actually Review CI/CD Pipelines
- Common Audit Findings — Top 10 CI/CD Failures
- DevSecOps Maturity Assessment Framework
New to CI/CD auditing? Start with our Auditor’s Guide.
