Start Here — Auditor’s Guide to CI/CD Security

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.

---

What Is a CI/CD Pipeline?

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 → MONITOR

Each 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 — Automated tests validate functionality and catch regressions. Auditors care because testing evidence demonstrates due diligence in quality assurance.
• SCAN — Security scanners check for vulnerabilities, misconfigurations, and licence risks. Auditors care because this is a primary control for identifying known weaknesses before deployment.
• APPROVE — Human or automated approval gates decide whether the change proceeds. Auditors care because approval enforcement is the cornerstone of segregation of duties.
• DEPLOY — The artifact is released to production through an automated, repeatable process. Auditors care because deployment controls determine whether unauthorised changes can reach production.
• MONITOR — Runtime systems detect anomalies, performance issues, and security events. Auditors care because monitoring closes the feedback loop and enables incident detection.

Key insight: A well-designed pipeline makes security mandatory. A poorly designed one makes security optional.

The pipeline’s architecture determines whether security controls are mandatory (enforced by design) or optional (dependent on individual discipline). This distinction is critical for auditors: a well-designed pipeline makes compliance a property of the system, not a periodic project.

Need definitions? See our Glossary for plain-language explanations of technical terms.

---

Why Auditors Need to Understand Software Delivery

Regulations now explicitly require organisations to govern their software delivery systems:

• DORA (Digital Operational Resilience Act) — treats CI/CD pipelines as ICT systems subject to risk management, testing, and third-party oversight
• NIS2 — requires supply chain security, incident reporting, and risk management measures that directly involve software delivery
• ISO 27001 — Annex A controls cover system development, change management, and supplier relationships
• SOC 2 — Trust Service Criteria for change management (CC8), logical access (CC6), and system operations (CC7) all touch CI/CD
• PCI DSS v4.0 — Requirement 6 mandates secure development practices and vulnerability management

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?

• Evidence to request: Pipeline configuration 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?

• Evidence 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: How Auditors Actually Review CI/CD Pipelines

3. Secrets Management

Are credentials stored in a centralised vault? Are they rotated automatically? Can secrets appear in logs or code?

• Evidence 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?

• Evidence 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?

• Evidence 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:

1. Glossary — Learn the terminology first
2. This guide — Understand the structure and key concepts
3. Core CI/CD Security Controls — The essential controls every pipeline should have
4. How Auditors Actually Review CI/CD Pipelines — Practical review methodology

If you audit under DORA:

1. Start with DORA Hub Page — overview and article index
2. Read DORA Article 21 Deep Dive — ICT risk management controls
3. Read DORA Article 28 Explained — third-party ICT risk
4. Use the DORA Article 28 Auditor Checklist
5. Review the Controls & Evidence Mapping

If you audit under NIS2:

1. Start with NIS2 Hub Page — overview and scope
2. Read NIS2 Security Architecture Explained
3. Review NIS2 Supply Chain Security Deep Dive
4. Use the NIS2 Supply Chain Auditor Checklist

If you audit under ISO 27001, SOC 2, or PCI DSS:

1. Start with Compliance Mapping (ISO 27001 / SOC 2 / DORA)
2. Read Compliance Mapping (NIS2 / PCI DSS)
3. Review the Dual-Compliance Architecture

If you assess multiple frameworks:

1. Dual-Compliance Architecture — How to satisfy overlapping requirements efficiently
2. ISO 27001 vs DORA vs NIS2 Overlap Matrix — Side-by-side comparison of control requirements
3. NIS2 vs DORA Overlap Analysis — Detailed mapping of shared and distinct obligations

If you are preparing for an audit:

1. Before the Auditor Arrives: Readiness Checklist
2. Audit Day Playbook
3. Audit Day Q&A Cheat Sheet

---

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.