A Governance-Focused Guide to CI/CD Security Control Categories for Auditors, Compliance Officers, and Regulators
CI/CD pipelines are the backbone of modern software delivery. For auditors and compliance officers, understanding the security controls embedded within these pipelines is essential for evaluating whether an organization adequately manages software delivery risk.
This guide explains the main CI/CD security control categories — not as product recommendations, but as governance domains that auditors should understand, verify, and assess during compliance reviews.
Why Auditors Need to Understand CI/CD Security Controls
Modern CI/CD pipelines handle:
- access to source code repositories
- automated build and packaging processes
- integration with third-party services and dependencies
- deployment to production systems
Each of these stages introduces risk. Auditors must be able to verify that appropriate security controls are in place at every stage, that those controls are enforced consistently (not merely available), and that they produce reliable, retained evidence.
In regulated environments, the question is not which tools are installed, but whether the right controls are active, enforced, and auditable.
Control Category 1: Source Code and Repository Security
What it controls: Access to source code, authorization of code changes, prevention of unauthorized modifications, and detection of secrets committed to repositories.
What evidence it produces: Access control logs, branch protection configurations, pull request approval records, and secrets detection scan results.
What auditors should verify:
- Branch protection rules are enforced (not merely documented)
- All code changes require peer review and approval before merging
- Secrets scanning runs automatically on every commit or pull request
- Access to repositories follows least-privilege principles
- Audit logs for code changes are retained for the required period
Red flags:
- Direct commits to main branches without review
- Branch protection rules that can be overridden by administrators
- No secrets scanning in place, or scanning that runs only on demand
- Overly broad repository access permissions
Control Category 2: Static Application Security Testing (SAST)
SAST (Static Application Security Testing) is a control that analyzes source code to identify security vulnerabilities before applications are built or deployed. It operates during the development and build stages.
What it controls: Code-level security flaws, insecure coding patterns, and policy compliance of custom-written code.
What evidence it produces: Scan reports showing identified vulnerabilities, severity classifications, policy pass/fail decisions, and trend data over time.
What auditors should verify:
- SAST runs automatically on every build or pull request — not on demand only
- Defined severity thresholds exist that can block builds or deployments
- Suppressed or accepted findings have documented justifications and expiration dates
- Scan results are retained and linked to specific builds and releases
- The scope of SAST scanning covers all production codebases
Red flags:
- SAST is configured but not enforced — builds proceed regardless of findings
- Large numbers of suppressed findings without documented rationale
- Scan results are not retained or cannot be traced to specific releases
- SAST coverage does not include all production applications
Control Category 3: Software Composition Analysis (SCA)
SCA (Software Composition Analysis) identifies risks in third-party libraries, open-source components, and their transitive dependencies. This control is central to supply chain risk management.
What it controls: Known vulnerabilities in dependencies, license compliance, and visibility into the software supply chain.
What evidence it produces: Dependency inventories, Software Bills of Materials (SBOMs), vulnerability reports for third-party components, and license compliance records.
What auditors should verify:
- SCA runs automatically during builds and produces current dependency inventories
- Known vulnerable dependencies trigger defined responses (blocking, alerting, or documented acceptance)
- SBOMs are generated and retained for each release
- License compliance is actively monitored
- Dependency policies define what is acceptable and what requires approval
Red flags:
- No dependency inventory or SBOM exists for production applications
- Known critical vulnerabilities in dependencies are not addressed or documented
- SCA scanning is not integrated into CI/CD — it runs manually or not at all
- No governance over which third-party components may be used
Control Category 4: Secrets Management and Detection
Secrets — such as API keys, credentials, tokens, and certificates — are high-value targets in CI/CD environments. This control category encompasses both the detection of exposed secrets and the governance of how secrets are stored, accessed, and rotated.
What it controls: Prevention of credential exposure in code and pipelines, controlled access to secrets, and rotation and revocation procedures.
What evidence it produces: Secrets scan results, access logs for secrets storage systems, rotation records, and incident response records for any detected exposures.
What auditors should verify:
- Secrets scanning is automated and runs on every code change
- A centralized secrets management system is used — secrets are never hardcoded
- Access to secrets is role-based and logged
- Rotation policies exist and are enforced
- Detected secret exposures trigger documented incident response
Red flags:
- Secrets found in source code, configuration files, or pipeline logs
- No centralized secrets management — teams manage credentials independently
- No rotation policy or evidence of rotation
- Secrets scanning is not enforced or can be bypassed
Control Category 5: Build Integrity and Artifact Security
Build integrity controls ensure that what is deployed matches what was tested and approved. This includes artifact signing, integrity verification, immutable storage, and provenance tracking.
What it controls: Tamper prevention for build outputs, traceability from source code to deployed artifact, and assurance that artifacts have not been modified after testing.
What evidence it produces: Signed artifacts, provenance attestations, integrity checksums, and immutable artifact repository logs.
What auditors should verify:
- Artifacts are signed and signatures are verified before deployment
- Artifact storage is immutable — previously published artifacts cannot be overwritten
- Provenance records exist linking each artifact to its source code, build, and test results
- Integrity checks are enforced at deployment time, not just at build time
Red flags:
- Artifacts are not signed or signatures are not verified
- No provenance or traceability from artifact to source
- Artifact repositories allow overwriting of existing versions
- Manual artifact handling outside of the pipeline
Control Category 6: Dynamic Application Security Testing (DAST)
DAST (Dynamic Application Security Testing) tests running applications by interacting with them externally, simulating real-world attack scenarios. It validates runtime security posture, including authentication flows, session handling, and configuration weaknesses.
What it controls: Runtime vulnerabilities, security misconfigurations, and access control issues in deployed or staged applications.
What evidence it produces: Scan results documenting runtime findings, gating decisions (pass/fail), and records of any exceptions granted.
What auditors should verify:
- DAST is executed before production releases — not only on demand
- Defined thresholds exist that can block or delay releases based on findings
- Exceptions to DAST gating are documented with approvals
- DAST results are retained and traceable to specific releases
Red flags:
- DAST runs only occasionally or not at all for critical applications
- No gating logic — all releases proceed regardless of DAST findings
- DAST results are not retained or cannot be linked to specific deployments
- DAST scope does not cover externally facing applications
Control Category 7: Logging, Monitoring, and Evidence Retention
Every control in the CI/CD pipeline must produce evidence, and that evidence must be collected, stored, and made accessible for audit. This category covers centralized log aggregation, monitoring, alerting, and evidence retention.
What it controls: Visibility into pipeline activities, incident detection, and the availability of audit evidence.
What evidence it produces: Centralized logs, monitoring dashboards, alert histories, and retained records of all pipeline executions and their outcomes.
What auditors should verify:
- Pipeline logs are collected centrally and cannot be tampered with
- Retention periods meet regulatory requirements
- Monitoring covers both security events and pipeline health
- Evidence from all security controls (SAST, SCA, DAST, secrets, artifact integrity) is aggregated and accessible
Red flags:
- Logs are stored only locally on build agents and not centralized
- Retention periods are shorter than regulatory requirements
- No alerting on pipeline failures or security control bypasses
- Evidence from security controls cannot be retrieved for a given release
Summary: Control Category to Audit Verification Mapping
| Control Category | Control Objective | Key Evidence | Audit Verification |
|---|---|---|---|
| Source Code Security | Prevent unauthorized code changes | Access logs, PR approvals, branch protection configs | Verify enforcement of review and approval workflows |
| SAST | Detect code-level vulnerabilities before deployment | Scan reports, gating decisions, suppression records | Confirm automated execution and threshold enforcement |
| SCA | Manage third-party and supply chain risk | Dependency inventories, SBOMs, vulnerability reports | Verify current inventory, SBOM generation, and response to known vulnerabilities |
| Secrets Management | Prevent credential exposure and unauthorized access | Scan results, access logs, rotation records | Confirm no hardcoded secrets, verify rotation and access governance |
| Build Integrity | Ensure artifacts are trustworthy and traceable | Signed artifacts, provenance attestations, checksums | Verify signing, immutability, and source-to-artifact traceability |
| DAST | Validate runtime security of deployed applications | Scan results, gating decisions, exception records | Confirm pre-release execution and documented exception handling |
| Logging and Evidence | Provide audit trail and incident visibility | Centralized logs, monitoring records, retained evidence | Verify retention periods, centralization, and tamper resistance |
Conclusion
CI/CD security controls are not about which products an organization deploys. They are about whether the right control categories are in place, whether those controls are enforced consistently within the pipeline, and whether they produce reliable evidence that auditors can verify.
When reviewing CI/CD security, auditors should focus on enforcement, evidence quality, traceability, and governance — not on product names or feature lists.
Related for Auditors
- Glossary of CI/CD Security and Compliance Terms
- Core CI/CD Security Controls
- How Auditors Actually Review CI/CD Pipelines
- Continuous Compliance via CI/CD
