Auditing CI/CD Pipelines: CI/CD Security Checklist and Compliance Guide

• A CI/CD pipeline audit checks that your pipeline is secure, reliable, fast, traceable, and ready for a compliance review.
• The CICD security checklist below covers access, secrets, pipeline configuration, artifacts, runners, third-party actions, compliance, performance, and incident response.
• CI/CD compliance means your pipeline can prove who changed what, who approved it, what ran, and what reached production, with evidence for SOC 2, PCI DSS, HIPAA, and similar frameworks.
• CI/CD audit tools include Gitleaks, TruffleHog, Checkov, Conftest, Trivy, Vault, Syft and Cosign, and StepSecurity Harden-Runner.
• Every audit should end with findings, risk levels, owners, deadlines, and a remediation plan, followed by a re-check.

CI/CD pipelines are a core part of the software delivery system. They take code through tests, packaging, and release, and connect to secrets, cloud accounts, registries, and production environments. Jobs handle all of it, so a pipeline nobody reviews becomes the least visible part of the SDLC.

Wiz reported in its State of Code Security 2025 that about 35% of enterprises use non-ephemeral self-hosted runners, which raises the risk of lateral movement across repositories and organizations. In March 2025 the popular GitHub Action tj-actions/changed-files was compromised through a stolen token. According to DevOps.com, the action was used by more than 23,000 repositories, and the malicious code printed secrets from runner memory into build logs.

This guide to auditing CI/CD pipelines gives you a nine-block security checklist, a compliance section with control and standards mapping tables, a step-by-step audit process, and the tools that help at each stage.

A CI/CD audit is a systematic review of a pipeline against security benchmarks, performance targets, and compliance requirements. It verifies that the pipeline builds, tests, stores, deploys, and tracks software in a safe and repeatable way.

Depending on scope, a CI/CD pipeline review can be narrow or broad. A narrow review may look only at secrets in GitHub Actions or GitLab CI. A broader audit might verify access control, self-hosted runners, cloud permissions, artifact signing, deployment approvals, logs, test quality, and DORA metrics.

A CI/CD audit differs from a DevOps Health Check in scope and depth. A DevOps Health Check reviews the wider delivery system, including infrastructure, cloud setup, monitoring, costs, CI/CD, and operations. A CI/CD audit goes deeper into the pipeline itself.

Three common audit types are:

• CI/CD security audit: checks access control, secrets, runner isolation, dependency security, code scanning, and artifact integrity.
• Performance audit: checks build time, flaky tests, queue time, and the DORA delivery metrics.
• CI/CD compliance audit: checks logs, approvals, evidence, retention, policy gates, and audit trails for frameworks like SOC 2, PCI DSS, HIPAA, and GDPR, and against baselines such as NIST SSDF and SLSA.

Internal teams can run the first review if they have enough security and DevOps experience. An external DevOps pipeline audit provider helps when the team needs an independent view, compliance preparation, or help with remediation.

A pipeline has more access than many teams realize. It reads code, builds images, pulls secrets, pushes artifacts, deploys to Kubernetes, updates cloud resources, and runs scripts with high privileges. That access makes CI/CD a target for attackers and a common source of compliance gaps.

Security is the first reason. OWASP says CI/CD pipelines support repeatable builds and deployments, but their importance also makes them attractive targets. A single exposed token, overpowered runner, or unreviewed workflow can create a path into cloud systems.

Compliance is the second reason. SOC 2, PCI DSS, HIPAA, GDPR, and ISO-related audits all expect evidence. CI/CD logs, approvals, access changes, deployment records, and change history often become part of that evidence.

Performance is the third reason. Slow pipelines slow down engineering. A CI/CD pipeline security audit should not only block risk. It should also reveal long builds, unstable tests, repeated manual approvals, and weak rollback paths.

Cost is the fourth reason. Unoptimized runners, repeated builds, unused environments, and poor test design can waste compute. A pipeline audit helps with CI/CD cost optimization by showing which jobs run too often, run too long, or use the wrong resources.

A useful audit checks the full path from code commit to production deployment. Do not stop at the YAML file. Review the people, permissions, tools, artifacts, environments, logs, and compliance evidence around the pipeline.

This table should become the backbone of your CI/CD audit process. Each area needs an owner, evidence, a risk score, and a remediation task.

Use this CI/CD security checklist as your CI/CD audit checklist for the next review. Each block matches an area from the table above, so you can assign one owner per block and record evidence next to each item.

Access Control

☐ RBAC is set up and documented.

☐ MFA is enabled for all pipeline users.

☐ Audit logs capture access and permission changes.

☐ Old accounts, tokens, and service users are removed.

Secrets Management

☐ No hardcoded secrets exist in config files or repositories.

☐ Secrets live in Vault, AWS Secrets Manager, Azure Key Vault, or a similar system.

☐ Secret rotation is documented and automated where possible.

☐ Secret scanning runs in pre-commit hooks and CI jobs.

Pipeline Configuration

☐ Branch protection rules are enabled.

☐ Required reviews block unapproved merges.

☐ Pipeline config lives in version control.

☐ Changes to pipeline definitions need review from a named owner.

Build and Artifact Integrity

☐ SAST runs on pull requests.

☐ SCA and dependency scanning are enabled.

☐ Artifacts and container images are signed.

☐ Images are scanned before push or deployment.

Runners

☐ Self-hosted runners are ephemeral or cleaned between jobs.

☐ Untrusted pull requests never run on internal runners.

☐ Outbound network access from runners is restricted.

☐ No privileged containers run without approval.

Third-Party Actions and Plugins

☐ Actions and plugins are pinned to a full commit SHA, not a mutable tag.

☐ An allowlist of approved actions and plugins exists.

☐ Updates come through automated pull requests (Dependabot or Renovate) and are reviewed.

Compliance

☐ Policy-as-code checks run in the pipeline.

☐ Compliance scan results are stored.

☐ Audit trails are complete and protected from casual edits.

☐ Deployment approvals are tied to named users or service identities.

Performance

☐ Deployment frequency matches delivery goals.

☐ Change lead time and failed deployment recovery time are tracked.

☐ Change fail rate and deployment rework rate are measured.

☐ Pipeline build time stays within a clear SLA.

Incident Response

☐ There is a documented way to revoke a leaked token quickly.

☐ A runner compromise playbook exists and names who acts.

☐ Rollback was tested in the last quarter.

Run through this CI/CD pipeline security checklist after every change of CI platform, every new self-hosted runner, and every time a job gets new cloud permissions, not only once a year. If you keep this CI/CD audit checklist in your repository as a file, each review leaves a dated record that becomes audit evidence on its own.

CI/CD compliance is the ability of your pipeline to meet the control requirements of the frameworks your company follows and to prove it with evidence. A pipeline that changes code, has access to secrets, or deploys into a regulated environment falls inside the audit scope, whether or not anyone planned it that way.

Most frameworks do not literally tell you to audit the pipeline. They set objectives for systems in scope, such as access control, change management, logging, and testing. The pipeline is one of those systems because it changes software, handles credentials, and reaches production. So the practical question for a CI/CD compliance audit is which pipeline controls support which obligations, and where the evidence lives.

The traditional approach is to collect evidence once a year, just before the auditor arrives. Teams export screenshots, rebuild approval histories from chat, and explain gaps nobody noticed for eleven months. This slows releases at the worst moment and still leaves the rest of the year unchecked.

Continuous compliance moves the controls into the pipeline. Branch protection, scans, and policy checks run on every change. Approvals, scan results, and deployment records are saved automatically with each run, so the evidence exists before anyone asks for it. When a control fails, the pipeline stops or raises an alert, and the team fixes the problem while it is still small.

It also helps to involve auditors early. Show them how evidence is collected and agree on what a good sample looks like. That conversation is much cheaper in the first month of the review period than in the last week.

Policy as code means writing compliance rules as machine-readable policies that the pipeline checks automatically, instead of keeping them in a document that people are expected to remember. The policies live in version control, go through review like any other code, and produce a pass or fail result for every run.

Two common examples:

• Open Policy Agent with Conftest blocks a deployment to production if the change has no recorded approval.
• Checkov stops a Terraform plan that would create a publicly readable S3 bucket.

A short Rego rule for the first case can be as simple as “deny if the target is production and the approvals list is empty.” The point is that the rule is enforced on every run and its result is stored, so the policy and its evidence come from the same place.

Each stage of the pipeline needs its own controls and leaves its own evidence. This table shows what CICD compliance looks like in practice from commit to runtime.

The table below maps common frameworks to pipeline controls. It shows what each one expects, what to check in the pipeline, and which evidence to keep.

This table is a starting point. The interpretation for a specific company should be confirmed by its compliance or legal specialists.

Collect evidence that can reconstruct a change without relying on anyone’s memory. For a sampled production release, an auditor should be able to follow the chain from the approved ticket to the deployment. Stable run IDs, commit identifiers, artifact digests, and synchronized timestamps make that chain much easier to follow.

A typical evidence set includes:

• the ticket, source revision, reviewers, and pipeline definition version for each sampled release;
• build run, test and security results, artifact digest, and signature or provenance where used;
• deployment approval, target environment, and outcome;
• exports of repository protections, CI permissions, runner assignments, secret-store policies, and cloud roles;
• access review results, approved exceptions, and incident tickets.

Keep an evidence register with the control, source, collection method, owner, frequency, retention period, and location. Protect the evidence from edits and make sure logs contain no plaintext secrets. Retention comes from the applicable law, contract, or standard, not from a default of one year, and platform defaults are often shorter than what is required.

In a review on Clutch, a financial services company from South San Francisco describes a CI/CD and SOC 2 audit that AppRecode ran for its pipelines. The audit found 14 gaps, and all of them were closed on schedule. Build time dropped by 68%, and releases moved from about two per week to daily.

The right CI/CD audit tools depend on your stack. A GitHub Actions setup, a Jenkins setup, and a GitLab CI setup will not need the same tool mix. Start with the gaps, then pick tools.

The most useful sources are often the ones already running your delivery system: repository and CI audit logs, protection settings, runner records, identity provider events, cloud access history, registry metadata, and deployment records. A workflow file alone cannot show an inherited organization setting or the permissions behind a cloud role.

Tools help, but they do not replace judgment. A scanner can flag a secret. It cannot decide who owns remediation, whether the token is still active, or how to redesign access.

If you are not sure where your pipeline has gaps, AppRecode’s DevOps Health Check is a structured starting point that covers CI/CD together with infrastructure, monitoring, and access.

A good audit needs a defined path. Otherwise it becomes a pile of screenshots, scanner reports, and Slack opinions.

Step 1. Define audit scope. Choose a security, performance, compliance, or full pipeline audit. Agree which repositories, environments, runners, cloud accounts, and tools are in scope, and which are explicitly excluded.

Step 2. Map the pipeline. Write down every stage, runner, integration, secret source, artifact store, approval gate, and deployment target. Many teams find hidden risk before scanning even starts.

Step 3. Review access controls. Check IAM, RBAC, MFA, service accounts, deployment permissions, and admin access. Look for shared credentials, broad service accounts, and former users who still have access.

Step 4. Run automated scans. Use SAST, SCA, IaC checks, secret scanning, container scanning, and policy-as-code checks. Save scan output as audit evidence.

Step 5. Analyze audit logs. Check whether logs capture pipeline runs, approvals, failed jobs, permission changes to secrets or pipelines, deployments, and suspicious activity. Confirm retention rules.

Step 6. Measure DORA metrics. Track the five DORA metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. They show whether the pipeline helps delivery or slows it down. They describe throughput and instability, and none of them is a security result.

Step 7. Check compliance gates. Review whether policy checks block unsafe changes and whether evidence is stored and easy to export. The compliance section above lists the controls and evidence by pipeline stage.

Step 8. Document and prioritize findings. Group findings by priority: Critical, High, Medium, Low. Each finding needs an owner, risk rating, supporting evidence, proposed fix, and deadline.

A scanner’s “critical” label is only a starting point. Ask what the job or an attacker could reach, whether untrusted input can trigger the path, and which environments share the weakness. One reusable credential exposed to a public pull request job can outrank dozens of package alerts in an isolated test project.

For an immediate threat, contain first: revoke a leaked token, stop a dangerous trigger, or isolate a questionable runner. Then check where the credential was used, because replacing a token does not tell you whether someone already abused it. When the situation is stable, fix the pattern. If one shared template created the gap in forty repositories, repair the template instead of opening forty separate tickets. An exception needs an approver, a compensating measure, and an expiry date.

Step 9. Re-audit after remediation. Run the relevant checks again after the fixes and compare the results with the original baseline. A finding is closed when the new control is shown to work, not when the ticket is closed.

If you serve ML teams, include model pipelines in scope. For ML pipelines, also check model versioning, drift monitoring, reproducibility, and how models are deployed. AppRecode’s MLOps services cover this kind of work.

Most audit findings fall into familiar groups. The surprise is usually not the type of issue but how long it stayed untouched.

Common findings include:

• Hardcoded secrets in pipeline config files or environment variables.
• Missing RBAC, where too many engineers can deploy to production.
• Self-hosted runners without network egress controls or file monitoring.
• Third-party actions referenced by mutable tags instead of a commit SHA.
• Missing artifact signing, which makes it hard to verify what reached production.
• Incomplete audit logs, which create gaps for SOC 2 and PCI DSS.
• Flaky tests that teams skip instead of fixing.
• Dependency vulnerabilities without automatic blocking rules.
• Overpowered service accounts with broad cloud permissions.
• Manual deployment steps with no reliable record.
• No rollback plan for failed production deployments.

These findings do not always mean the team is careless. CI/CD often grows in pieces. One developer adds a quick workflow, another adds a secret, a third adds a production deploy. Six months later, nobody can explain the full path.

That is why CI/CD audit best practices start with mapping, not fixing.

Not every audit needs the same partner. Some teams need a technical CI/CD pipeline audit with hands-on remediation. Others need a formal compliance audit, a DevOps Health Check, or a wider security review before a SOC 2, ISO, or enterprise customer review.

The companies below cover different needs. AppRecode fits teams that want an engineering review plus implementation. Xebia fits larger transformation work. Linford & Company fits formal compliance audits. Simform and Timspark can help when CI/CD review sits inside a broader software delivery or team extension project. If you are also comparing pipeline implementation partners, see our overview of the top CI/CD companies for cloud deployment.

Clutch ratings and review counts were checked on October 23, 2026.

AppRecode is a DevOps and cloud company that helps teams review, secure, and improve software delivery systems. Its work covers pipeline audits, security reviews, performance assessment, and DevOps pipeline audit work, followed by remediation.

The team works with GitHub Actions, GitLab CI/CD, Jenkins, Argo CD, Kubernetes, Terraform, AWS, Azure, and Google Cloud, along with monitoring, secret scanning, and infrastructure-as-code tools. AppRecode suits teams that need more than a report: the same team can move from audit findings into remediation, pipeline rebuilds, cloud fixes, or MLOps improvements.

A standard pipeline review usually focuses on pipeline files, runners, secrets, testing gates, and deployment flow. AppRecode’s DevOps Health Check has a wider scope and can review CI/CD, infrastructure, monitoring, cloud costs, access control, security gaps, and operational risks together. You can read AppRecode reviews on Clutch before shortlisting the team.

• Structured DevOps Health Check as a clear audit entry point.
• Audit and remediation delivered by one team.
• Coverage across CI/CD, cloud, Kubernetes, Terraform, monitoring, and MLOps.
• Sprint-based delivery that fits startups and scale-ups.
• Clear findings, priorities, and next steps after the audit.

• AppRecode may not fit companies that need a formal Big Four-style enterprise compliance audit.
• MLOps work may not be relevant for teams without ML workloads.
• Large enterprises should confirm procurement, security, and long-term support requirements early.

AppRecode fits startups and scale-ups that do not know the current state of their pipelines. It also fits companies preparing for SOC 2, ISO, or enterprise customer reviews that need to check CI/CD controls before a formal audit. The team also has experience in healthcare: for Synapticure, a care platform for people with ALS, it worked on Terraform infrastructure, Kubernetes, CI/CD with GitHub Actions and Argo CD, and monitoring.

For ML and AI teams, AppRecode offers MLOps services such as model versioning, deployment audit trails, reproducibility checks, and production monitoring.

AppRecode works with SaaS, fintech, AI/ML, e-commerce, healthcare tech, telecom/IoT, and cloud-native products. Teams in regulated industries usually ask about access controls, audit logs, deployment approvals, artifact tracking, secrets management, and policy gates.

Client: A financial services company based in South San Francisco, California. The project ran from September to December 2025, with a budget of 49,999.

Challenge: The company needed an audit of its CI/CD pipelines together with SOC 2 audit work.

Solution: AppRecode audited the CI/CD pipelines, identified 14 gaps, and closed all of them within the agreed timeline.

Result: Build time dropped by 68%, and the company moved from about two releases per week to daily releases. The details come from the client’s review on Clutch, published on June 1, 2026.

Client: Kubeshop, the company behind the open-source Kubernetes tools Testkube, Monokle, and Kusk.

Challenge: The client needed stronger CI/CD processes, faster test execution, better Kubernetes workflows, less troubleshooting effort, and more stable infrastructure.

Solution: AppRecode worked with GitLab CI/CD, Amazon EKS, Terraform, Docker with non-root multi-stage builds, and Datadog monitoring. The team added branch protection, required reviews, image-scan gates, and versioned artifacts with changelogs.

Result: Testing time dropped by 90%, troubleshooting time dropped by 20%, and there were fewer misconfigurations.

Client: An AI-driven media intelligence and AdTech company from New York with about 150 employees. The cooperation has lasted three years.

Challenge: The platform helps advertisers and agencies verify their ad spend, and the client needed a scalable, secure AWS foundation and automated delivery for it.

Solution: AppRecode built the infrastructure with Terraform and set up delivery with Jenkins, GitLab CI/CD, Docker, and Kubernetes/ECS. Monitoring runs on CloudWatch and New Relic, and Transit Gateway connects the networks.

Result: Deployment time was cut by 70%, uptime reached 99.995%, and MTTR dropped below one day.

Xebia is a global consulting company with DevOps, platform engineering, cloud-native development, and engineering enablement services. It fits larger teams that need CI/CD auditing as part of a wider delivery transformation, not only a short pipeline security review. Xebia can help review delivery practices, platform engineering setup, CI/CD patterns, cloud workflows, and developer productivity. The company suits mid-market and enterprise buyers with bigger programs and more stakeholders. Smaller teams may find Xebia too broad if they only need a short CI/CD security audit.

Linford & Company is an independent audit firm focused on SOC 1, SOC 2, HIPAA, HITRUST, PCI, ISO 27001, and information security audits. It is different from engineering-first CI/CD audit providers because it can deliver formal assurance reports. Linford & Company fits companies preparing for SOC 2 or similar audits where pipeline controls, access logs, change management, and evidence quality matter. It is a strong option when a company needs a compliance auditor, not a DevOps remediation team. For hands-on pipeline fixes, teams may still need a DevOps partner after the audit.

Simform is a software engineering and cloud consulting company with DevOps managed services, application support, cloud work, testing, and platform engineering capabilities. It fits teams that need compliance audit support as part of a larger engineering or cloud modernization program. Simform can help review delivery flows, testing setup, cloud deployment, and DevOps practices, then bring engineering capacity for implementation. It works best when the audit is one part of a broader product or platform project. For a narrow pipeline-only audit, a smaller specialist may move faster.

Timspark is a software development and team extension company with DevOps and cloud management among its service areas. It fits startups and mid-market teams that need extra engineering capacity for delivery systems, testing, application development, and cloud work. Timspark can help when an audit leads into broader delivery support or extra development capacity. Its model is practical for teams that need people added to the delivery process. For formal compliance work, companies should still involve a licensed audit firm where required.

Pipelines now carry business risk, not only engineering work. These numbers and sources show why.

Key numbers and signals:

• Wiz reported that about 35% of enterprises use non-ephemeral self-hosted runners, which raises the risk of lateral movement across repositories and organizations.
• In the same report, 61% of organizations have public repositories that contain cloud secrets, and VMs with runners have on average three times more software packages installed.
• The tj-actions/changed-files compromise (CVE-2025-30066) on March 14–15, 2025 affected an action used by more than 23,000 repositories. The injected code wrote AWS keys, GitHub tokens, npm tokens, and RSA keys from runner memory into build logs, and public repositories were most exposed because their logs are open.
• OWASP Top 10 CI/CD Security Risks and the OWASP CI/CD Security Cheat Sheet treat pipelines as important SDLC components and a target for attackers.
• NIST SP 800-204D gives strategies for adding software supply chain security into DevSecOps CI/CD pipelines.
• The JetBrains TeamCity guide to CI/CD security from April 2025 recommends layered protection, least privilege, secrets management, branch protection, signed commits, and regular permission reviews.

Trends to watch:

• Runner security is moving up the priority list. The tj-actions incident showed how one compromised dependency can expose secrets from every runner that uses it, which is why pinning actions to a commit SHA and controlling log output are becoming standard checks.
• Compliance teams ask better pipeline questions. Auditors want evidence for access, changes, approvals, logs, and deployments.
• Secrets management moves earlier. Hardcoded tokens and long-lived credentials are becoming harder to defend, and short-lived OIDC identities are replacing stored cloud keys.
• Artifact integrity matters more. SLSA, signing, provenance, and software composition analysis are moving into normal audit scope.
• AI and MLOps increase audit scope. Model pipelines add new questions about training data, model versions, reproducibility, and model rollout.

Auditing CI/CD pipelines is no longer optional for teams that ship serious software. The pipeline has access to code, secrets, cloud resources, artifacts, and production systems, which makes it part of your security model and your CI/CD compliance scope.

A good audit should end with a ranked plan that engineering teams can act on. Start by running the checklist above against one production pipeline. Record the evidence for each item, rank the gaps by what they could reach, and assign an owner and a date to each one. If you already know which parts need work, AppRecode’s CI/CD consulting team can review and rebuild them.

A CI/CD audit goes deep into the pipeline, while a DevOps Health Check looks across the whole delivery system. The audit examines source control rules, runners, secrets, pipeline definitions, artifacts, approvals, and deployment logs, and tests whether each control actually worked during the review period. A DevOps Health Check covers CI/CD at a higher level together with infrastructure, cloud setup, monitoring, costs, and operations. Many teams start with a Health Check to see where the biggest risks are, then order a focused CI/CD audit for the pipelines that need it.

Because a deployment job often holds more access than most employees. In a few minutes it can touch private source code, signing keys, a package registry, cloud APIs, Kubernetes, and sometimes customer data. An audit shows where that trust has piled up: pull request code from outsiders running on internal machines, test jobs that receive production secrets, or former contractors who can still edit a release workflow. It also exposes slow queues, flaky tests, and manual steps only one person knows. Finally, it checks that approvals, access changes, and deployment records exist when a customer, auditor, or incident responder asks for them.

A CI/CD security audit covers four areas: source control, execution, inputs and outputs, and visibility. In source control, the reviewer checks write access, MFA, branch protection, required reviews, and who can edit pipeline definitions. In execution, they inventory runners, check isolation, and review the identity and permissions of each job, preferring short-lived OIDC tokens over stored cloud keys. For inputs and outputs, they check how dependencies and actions are pinned, which scans run, and whether artifacts are signed and traceable to source. For visibility, they test logging, alerting, token revocation, and rollback. The depth depends on the threat model: a documentation site and a payment platform need different levels of review.

CI/CD compliance means your pipeline meets the control requirements of the frameworks your company follows, such as SOC 2, PCI DSS, or HIPAA, and can prove it with evidence. In practice, that means controlled access, reviewed and approved changes, logged activity, tested security, and records that link every production release to its source, approvals, and build. Most frameworks do not mention CI/CD directly. They set goals for systems in scope, and a pipeline that changes code or deploys to a regulated environment is one of those systems. Continuous compliance builds these controls into the pipeline, so evidence is collected on every run instead of once a year.

A good security checklist should cover every part of the pipeline that an attacker or auditor might look at. At a minimum, include access control and MFA, secrets management and scanning, pipeline configuration and branch protection, build and artifact integrity, runner isolation, third-party actions pinned to commit SHAs, compliance gates and stored evidence, delivery performance, and incident response. Each item should be specific enough to answer yes or no, and each answer should point to evidence. The checklist in this article has nine blocks with these items. Review it after every major platform change, not only once a year.

For a stable, lower-risk service, a full review once a year is a reasonable baseline, but it is not enough on its own. Access, tokens, dependencies, and runners change too quickly, so those controls need automated monitoring or shorter review cycles. Add event-based reviews when you move to another CI platform, add a self-hosted runner, change the secrets service, give a job new cloud permissions, or add a production target. Review after any credential leak or security incident too. Some laws, standards, and contracts set their own review periods, so ask your compliance owner which ones apply.

Most frameworks do not literally require a CI/CD pipeline audit. They set objectives for systems in scope, and a pipeline can fall in scope because it changes software, handles credentials, or reaches a regulated environment. PCI DSS v4.0.1 covers secure development, access, change control, logging, and testing. The HIPAA Security Rule requires safeguards for ePHI, including audit controls under 45 CFR 164.312(b). GDPR requires accountability, data protection by design and by default, and security appropriate to risk, but it does not prescribe a pipeline audit. SOC 2 and ISO/IEC 27001 work through selected criteria and applicable controls. NIST SSDF, SP 800-204D, and SLSA are baselines, not laws or certificates.

Start with the tools that already run your delivery system: repository and CI audit logs, protection settings, runner records, identity provider events, cloud access history, and deployment records. Then add scanners for specific questions. Gitleaks and TruffleHog find secrets, Trivy and OWASP Dependency-Check find vulnerable components, Checkov checks infrastructure as code, and Open Policy Agent with Conftest enforces configuration rules. Syft creates SBOMs, and Cosign signs artifacts. Before adopting a tool, test it on a known example, check the permissions it requests, and decide who reviews its exceptions. No tool decides a finding by itself.

A review of one repository with a simple deployment path may take several working days. A small product usually takes one to two weeks, and a multi-team environment with shared runners, several cloud accounts, or regulated workloads can take four to eight weeks or more. These are planning ranges, not guarantees. The estimate depends on the number of repositories, pipeline systems, runners, environments, and compliance mappings, as well as how quickly access is granted. Remediation is separate work and should not be hidden inside the audit estimate. A credible provider starts with a short scoping phase and then gives a revised estimate.

Collect evidence that can reconstruct a production change without anyone’s memory. For each sampled release, connect the ticket, source revision, reviewers, pipeline definition version, build run, test and security results, artifact digest, signature or provenance, deployment approval, and outcome. Add configuration exports for repository protections, CI permissions, runners, secret-store policies, and cloud roles, plus access reviews and approved exceptions. Machine-readable exports with a capture date are stronger than screenshots. Protect the evidence from edits, keep secrets out of logs, and set retention from the applicable law, contract, or standard, since platform defaults are often shorter.

Prioritize by real impact, not by the scanner’s label. Ask what the weakness could reach, whether untrusted input can trigger it, and how many environments share it. For an immediate threat, contain first by revoking the token, disabling the trigger, or isolating the runner, then check whether the weakness was already abused. After that, fix the underlying pattern, for example by repairing a shared template rather than each repository separately. Every finding needs an owner, a due date, a planned control, and a validation test. A finding is closed only when the new control is shown to work.

Start with a read-only discovery phase. Name one audit coordinator and owners for source control, CI, identity, runners, cloud, and security, and give auditors time-limited read-only access instead of shared admin accounts. Prepare an evidence pack with diagrams, access lists, configuration exports, recent run and deployment records, and the exception register. Run scanners on ordinary CI paths first and schedule any active tests outside release windows, with a named owner and a rollback plan. Do not hide known weaknesses. List them with their owner and planned fix, because auditors can tell managed risk from a surprise.