Common Audit Findings in CI/CD Pipelines — Top 10 Failures

Introduction: Patterns from the Audit Floor

After reviewing CI/CD implementations across regulated environments — financial services, healthcare, critical infrastructure, and technology firms subject to SOC 2, ISO 27001, DORA, NIS2, and PCI DSS — certain audit findings appear with remarkable consistency. These are not obscure edge cases. They are systemic governance failures that auditors encounter repeatedly, across organisations of all sizes and maturity levels.

This article presents the ten most common audit findings in CI/CD pipelines, written for auditors, compliance officers, and risk managers. For each finding, we describe what it is, why it matters from a regulatory perspective, how it typically surfaces during an audit, and what remediation should look like. Compliance teams should use this as a pre-audit self-assessment checklist to identify and address weaknesses before an external auditor does.

Finding 1: Shared Service Accounts with Admin Privileges

Description

Multiple individuals or teams use shared service accounts with elevated (often administrative) privileges to execute pipeline operations. Individual actions cannot be attributed to specific persons.

Why It Matters

Individual accountability is a foundational principle of access control. When actions cannot be traced to a specific individual, investigation of incidents becomes impossible, and deterrence against misuse is eliminated. Segregation of duties controls are rendered meaningless if multiple people operate under the same identity.

Regulatory References

DORA: Article 9 requires identification and authentication controls for ICT systems
ISO 27001: Annex A.9.2 — User access management, including unique user identification
SOC 2: CC6.1 — Logical access security; individual accountability
PCI DSS: Requirement 8 — Assign unique ID to each person with computer access

Typical Evidence of the Finding

Pipeline logs show the same service account executing builds, deployments, and administrative actions across multiple teams. Access reviews reveal service account credentials shared among multiple personnel. No mapping exists between service account actions and individual operators.

Remediation Expectation

Implement individual user accounts for all pipeline interactions. Where service accounts are technically necessary, implement controls that link service account actions to the individual who initiated them (e.g., through pipeline triggers tied to authenticated users). Conduct a privilege review and apply least-privilege principles.

Severity: High

Finding 2: Approval Gates That Can Be Bypassed or Self-Approved

Description

Pipeline approval gates exist but can be bypassed by users with sufficient privileges, or the same individual who initiates a change can approve their own deployment to production. Segregation of duties is not enforced.

Why It Matters

Approval gates are the primary mechanism for enforcing segregation of duties in CI/CD environments. If they can be bypassed or self-approved, the control is ineffective regardless of whether it exists on paper. This represents a design failure, not merely an operational weakness.

Regulatory References

DORA: Article 9 — ICT change management procedures with appropriate approval
NIS2: Risk management measures must include appropriate authorisation controls
ISO 27001: Annex A.12.1.2 — Change management; Annex A.6.1.2 — Segregation of duties
SOC 2: CC8.1 — Change management controls

Typical Evidence of the Finding

Pipeline configuration shows that users with “admin” or “maintainer” roles can bypass approval requirements. Deployment logs show instances where the same individual committed code and approved deployment. Emergency bypass procedures exist but lack governance controls or post-bypass review.

Remediation Expectation

Enforce approval gates that cannot be bypassed except through a governed emergency change process. Implement segregation of duties rules that prevent self-approval. Log and review all instances where standard approval processes are not followed.

Severity: High

Finding 3: No Pipeline Log Retention or Logs Stored in Mutable Systems

Description

Pipeline execution logs are either not retained beyond a short operational window (e.g., 30 days), or they are stored in systems where they can be modified or deleted by operational personnel.

Why It Matters

Pipeline logs are primary evidence for change management, deployment authorisation, and security testing controls. Without adequate retention, organisations cannot demonstrate to auditors that controls were operating during past periods. Mutable logs undermine evidence integrity — an auditor cannot rely on evidence that could have been altered.

Regulatory References

DORA: Article 12 — Logging requirements for ICT operations; 5-year retention expectation
PCI DSS: Requirement 10 — Track and monitor all access; 1-year retention minimum
ISO 27001: Annex A.12.4 — Logging and monitoring
SOC 2: CC7.2 — System monitoring

Typical Evidence of the Finding

Requests for pipeline logs from six months ago yield no results. Log storage is in the same system where operators have write access. No log integrity verification mechanism exists (no checksums, no immutable storage).

Remediation Expectation

Implement log retention policies aligned with regulatory requirements. Store logs in immutable or write-once storage. Implement log integrity verification mechanisms. Ensure log retention covers the full audit period plus regulatory retention requirements.

Severity: High

Finding 4: Secrets Hardcoded in Code or Pipeline Configurations

Description

Credentials, API keys, certificates, or other secrets are embedded directly in source code repositories or pipeline configuration files, rather than managed through a dedicated secrets management capability.

Why It Matters

Hardcoded secrets are accessible to anyone with repository access, cannot be rotated without code changes, and persist in version control history even after removal. This creates uncontrolled credential exposure and makes credential management — rotation, revocation, access logging — effectively impossible.

Regulatory References

DORA: Article 9 — Protection of ICT assets and data
ISO 27001: Annex A.9.4.3 — Password management; Annex A.10 — Cryptographic controls
PCI DSS: Requirement 2 — Do not use vendor-supplied defaults; Requirement 8 — Credential management
SOC 2: CC6.1 — Logical access controls

Typical Evidence of the Finding

Repository scans reveal secrets in code or configuration files. Version control history contains credentials even if they have been removed from current versions. No secrets management solution is in use, or it is in use but not universally adopted.

Remediation Expectation

Remove all hardcoded secrets from repositories and pipeline configurations. Implement a centralised secrets management capability. Rotate all exposed credentials. Implement automated secret detection in pipelines to prevent future occurrences.

Severity: Critical

Finding 5: Security Scan Results Ignored — No Policy Gates Blocking Deployment

Description

Security scanning tools (SAST, DAST, SCA, container scanning) are integrated into pipelines, but their results do not gate deployments. High or critical vulnerabilities are identified but code proceeds to production regardless.

Why It Matters

Running security scans without acting on results is security theatre. It creates the appearance of security testing without providing the substance. From a governance perspective, the organisation has awareness of vulnerabilities but is choosing not to address them — which may be worse than not scanning at all, as it demonstrates conscious acceptance of unmanaged risk.

Regulatory References

DORA: Article 8 — ICT risk identification, protection, and prevention
NIS2: Article 21 — Vulnerability handling and disclosure
ISO 27001: Annex A.12.6 — Technical vulnerability management
PCI DSS: Requirement 6 — Develop and maintain secure systems

Typical Evidence of the Finding

Scan reports show critical findings over extended periods without remediation. Pipeline configurations show scans execute but results do not affect pipeline progression. No defined thresholds exist for what scan results should block deployment.

Remediation Expectation

Define clear security thresholds that gate pipeline progression. Implement policy gates that block deployment when findings exceed defined severity thresholds. Establish a governed exception process for findings that are accepted — with documented risk acceptance from appropriate authority.

Severity: High

Finding 6: No SBOM Generation or Third-Party Component Inventory

Description

The organisation does not generate Software Bills of Materials (SBOMs) or maintain a comprehensive inventory of third-party and open-source components used in its applications.

Why It Matters

Without an SBOM, the organisation cannot identify which applications are affected when a vulnerability is disclosed in a third-party component (as occurred with Log4Shell, Spring4Shell, and similar supply chain incidents). Incident response becomes guesswork, and regulatory requirements for supply chain risk management cannot be met.

Regulatory References

DORA: Article 28 — ICT third-party risk management
NIS2: Article 21 — Supply chain security
ISO 27001: Annex A.15 — Supplier relationships
SOC 2: CC9.2 — Risk management of third-party providers

Typical Evidence of the Finding

No SBOM files exist for deployed applications. When asked “which of your applications use component X?”, the organisation cannot answer promptly. No automated dependency scanning is integrated into pipelines.

Remediation Expectation

Implement automated SBOM generation as part of the CI/CD pipeline. Use standard formats (CycloneDX or SPDX). Maintain a central repository of SBOMs for all deployed applications. Implement processes to cross-reference new vulnerability disclosures against the SBOM inventory.

Severity: Medium-High

Finding 7: Direct Production Access Without Change Management

Description

Developers or operators can access production environments directly and make changes outside of the CI/CD pipeline, bypassing all pipeline controls including approval gates, security scans, and audit logging.

Why It Matters

If production changes can be made outside the governed pipeline, the entire control framework is undermined. Every control embedded in the pipeline — approvals, scans, logging, segregation of duties — can be circumvented simply by making changes directly. The pipeline becomes optional, not mandatory.

Regulatory References

DORA: Article 9 — ICT change management and deployment controls
ISO 27001: Annex A.12.1.2 — Change management; Annex A.14.2.2 — System change control
SOC 2: CC8.1 — Change management
PCI DSS: Requirement 6.5 — Change control procedures

Typical Evidence of the Finding

Production access logs show direct logins by development or operations personnel. Changes in production do not correspond to pipeline deployment records. Production environment configurations differ from what the pipeline last deployed.

Remediation Expectation

Restrict production access to authorised service accounts controlled by the pipeline. Implement just-in-time access for emergency scenarios with full logging and post-access review. Monitor for and alert on any direct production changes outside the pipeline.

Severity: Critical

Finding 8: Vulnerability Suppressions Without Documented Risk Acceptance

Description

Security scan findings are suppressed, waived, or marked as “accepted” without formal risk acceptance documentation. No record exists of who accepted the risk, what the justification was, or when the acceptance expires.

Why It Matters

Risk acceptance is a legitimate risk treatment option — but only when it is a conscious, documented, and authorised decision. Ungoverned suppressions are not risk acceptance; they are risk ignorance. They create hidden pockets of unmanaged risk that auditors will identify and flag.

Regulatory References

DORA: Article 8 — ICT risk identification and treatment
ISO 27001: Clause 6.1.3 — Risk treatment; documented risk acceptance by risk owners
SOC 2: CC3.2 — Risk assessment and management
NIS2: Article 21 — Risk management measures

Typical Evidence of the Finding

Security scan configurations contain suppression lists with no associated documentation. Suppressed findings include critical or high-severity vulnerabilities. No approval workflow exists for adding findings to suppression lists. Suppressions have no expiry date or review cycle.

Remediation Expectation

Implement a formal risk acceptance process requiring documented justification, appropriate authority approval, defined expiry dates, and periodic review. Retrospectively review all existing suppressions and either document risk acceptance or remove the suppression.

Severity: High

Finding 9: No Segregation Between Development, Staging, and Production Environments

Description

Development, staging (or testing), and production environments are not adequately segregated. They may share infrastructure, credentials, data, or network segments, or development personnel may have equivalent access across all environments.

Why It Matters

Environment segregation is a fundamental control that protects production systems from unauthorised changes, prevents development activities from impacting live services, and ensures that testing is conducted in conditions that approximate — but do not compromise — production. Without it, the risk of uncontrolled changes, data leakage, and environment contamination increases substantially.

Regulatory References

DORA: Article 9 — Separation of ICT environments
ISO 27001: Annex A.12.1.4 — Separation of development, testing, and operational environments
PCI DSS: Requirement 6.5 — Separation of development/test and production environments
SOC 2: CC6.1 — Logical access controls between environments

Typical Evidence of the Finding

Infrastructure review reveals shared resources between environments. The same credentials work across development and production. Development personnel have administrative access to production environments. Production data is used in development or testing without anonymisation.

Remediation Expectation

Implement clear environment boundaries with separate infrastructure, credentials, and access controls. Restrict production access to authorised operational personnel and pipeline service accounts. Implement data anonymisation or synthetic data for non-production environments.

Severity: High

Finding 10: Inconsistent Control Application Across Teams or Pipelines

Description

Controls are applied inconsistently across the organisation. Some teams have well-governed pipelines with approval gates, security scanning, and evidence retention, while other teams operate with minimal or no pipeline controls.

Why It Matters

Compliance is an organisational obligation, not a team-level option. Inconsistent control application means that the organisation’s compliance posture is only as strong as its weakest pipeline. It also suggests a governance gap: the absence of an enterprise-wide standard for pipeline controls and the lack of a mechanism to enforce that standard.

Regulatory References

DORA: ICT risk management framework must cover the entire organisation
NIS2: Risk management measures must be comprehensive and proportionate
ISO 27001: ISMS scope must be defined and controls applied consistently within scope
SOC 2: Controls must be applied across all in-scope systems and processes

Typical Evidence of the Finding

Comparison of pipeline configurations across teams reveals significant variations in control implementation. Some pipelines lack approval gates, security scans, or evidence retention that others have. No organisation-wide pipeline governance standard exists, or it exists but is not enforced.

Remediation Expectation

Define an organisation-wide pipeline governance standard specifying minimum required controls. Implement mechanisms to enforce the standard (pipeline templates, policy-as-code, compliance scanning of pipeline configurations). Conduct a gap assessment across all pipelines and remediate non-conformances.

Severity: Medium-High

Summary: Findings, Regulatory Impact, and Remediation Priority

Finding	DORA	NIS2	ISO 27001	SOC 2	PCI DSS	Severity	Remediation Priority
1. Shared service accounts	Yes	Yes	Yes	Yes	Yes	High	Immediate
2. Bypassable approval gates	Yes	Yes	Yes	Yes	Yes	High	Immediate
3. No log retention / mutable logs	Yes	Yes	Yes	Yes	Yes	High	Immediate
4. Hardcoded secrets	Yes	Yes	Yes	Yes	Yes	Critical	Immediate
5. Security scans without gates	Yes	Yes	Yes	Yes	Yes	High	High
6. No SBOM / component inventory	Yes	Yes	Yes	Yes	Partial	Medium-High	High
7. Direct production access	Yes	Yes	Yes	Yes	Yes	Critical	Immediate
8. Ungoverned vulnerability suppression	Yes	Yes	Yes	Yes	Yes	High	High
9. No environment segregation	Yes	Yes	Yes	Yes	Yes	High	High
10. Inconsistent controls across teams	Yes	Yes	Yes	Yes	Yes	Medium-High	Medium

How These Findings Typically Surface During Audits

Understanding how auditors discover these findings helps compliance teams prepare more effectively:

Interview questions: “Walk me through how a code change reaches production.” “Who can approve a deployment?” “How are secrets managed?” These open-ended questions often reveal control weaknesses through the answers given — or the inability to answer consistently.
Evidence requests: “Show me pipeline logs from three months ago.” “Provide the approval record for this specific deployment.” “Show me your SBOM for this application.” The inability to produce evidence promptly is itself a finding.
Configuration reviews: Auditors increasingly request access to pipeline configurations, access control settings, and security tool configurations. These reviews reveal whether controls exist in practice, not just in policy.
Cross-referencing: Comparing deployment records with approval records, comparing production configurations with pipeline outputs, and comparing security scan results with deployment decisions. Inconsistencies between these sources reveal control failures.

Pattern Recognition: What Combinations of Findings Reveal

Individual findings are concerning, but combinations of findings reveal deeper governance issues. When Finding 1 (shared service accounts) and Finding 2 (bypassable approval gates) appear together, they indicate a fundamental absence of access governance — not just isolated control gaps. Similarly, if Finding 5 (scans without gates) and Finding 8 (ungoverned suppressions) coexist, the organisation’s security testing programme is effectively decorative.

Auditors should look for these patterns, as they indicate whether findings are isolated weaknesses that can be remediated individually or symptoms of a broader governance maturity gap that requires a more comprehensive response.

Recommendations for Compliance Teams

Use this list as a pre-audit self-assessment checklist. For each finding:

Determine whether the finding exists in your environment.
If it does, assess its scope: is it isolated to specific teams or pipelines, or is it widespread?
Document the current state honestly — attempting to conceal known issues from auditors invariably makes things worse.
Develop a remediation plan with realistic timelines and clear ownership.
If remediation cannot be completed before the audit, prepare a documented remediation plan to present to auditors, demonstrating awareness and commitment to addressing the issue.

Proactive identification and remediation of these common findings demonstrates governance maturity and significantly reduces the risk of adverse audit outcomes.

Related Resources

For further guidance on CI/CD audit preparation and red flag identification, see:

Related for Auditors

Glossary — Plain-language definitions of technical terms
How Auditors Review CI/CD
Audit Day Playbook
Audit Readiness Checklist

New to CI/CD auditing? Start with our Auditor’s Guide.