The audit posture for CI/CD pipelines tightened meaningfully through 2025, and the trend is continuing into 2026 with FedRAMP Rev 5 enforcement and the updated SOC 2 trust services criteria. This checklist is what I take into an audit cycle and what I recommend internal security teams use as a self-assessment before the auditors arrive.
The scope is the build and deploy pipeline itself, not the application code traveling through it. Both matter, but they audit differently and conflating them creates pain.
Is your build provenance audit-ready?
Provenance is the dimension that has moved furthest in the last two years. SLSA level 3 is now the de facto target for organizations under federal contract or selling into regulated industries, and auditors increasingly ask for the attestation record rather than just the policy that says provenance is generated. The practical implication is that you need a queryable store of build attestations, retained for at least the period required by your control frameworks, with attestations cryptographically linked to the artifacts they describe.
The common gap I find is that organizations generate attestations but cannot retrieve them efficiently when an auditor asks. The fix is straightforward: an attestation lookup service that takes an artifact digest and returns the SLSA provenance, the SBOM, and the signing certificate. Build this once at the platform layer and every team benefits. Without it, audit prep becomes a scavenger hunt across CI logs that may have aged out.
How tight is your secret management posture?
Secret management in CI/CD is no longer a passing-grade item; it is one of the dimensions auditors probe hardest. The bar in 2026 is short-lived credentials issued via OIDC federation for cloud and registry access, with static long-lived tokens reserved for the small set of systems that genuinely cannot consume federated identity. If your build runners are still authenticating to AWS or GCP with static access keys, expect that to be a finding.
Inventory all the secrets the pipeline holds and document the rotation cadence for each. The standard is rotation at least every 90 days for any unavoidable static secret, with audit logging that proves the rotation actually happened. Push protection at the source repository level is now expected, and the auditor will ask for the dashboard showing how many push-protection events fired in the audit period.
Are your runners properly isolated?
Runner isolation is where many self-hosted CI deployments fail audit. Shared runners that execute untrusted code from pull requests against the same instance that builds production releases are a finding. The remediation is to separate runner pools by trust level: one pool for untrusted PR builds, one for trusted main branch builds, and a third for release builds. Each pool runs on isolated infrastructure with its own service account and network policy.
Ephemerality is the other half of runner hygiene. Runners should be single-use, destroyed after each job, and never accumulate state across builds. GitHub Actions self-hosted runners, GitLab Runners, and Jenkins agents all support ephemeral modes; the audit risk is the team that configured persistent runners for performance reasons and forgot to revisit the choice. Auditors will ask for the configuration evidence, and "we use ephemeral runners" is not enough on its own.
What does end-to-end pipeline auditability require?
Auditability requires a tamper-evident log of every action that affected an artifact between source commit and production deploy. The chain runs commit, build, test, scan, sign, promote, deploy, and each link must be attributable to an identity, timestamped, and retained. The retention period depends on the framework; SOC 2 typically requires 12 months minimum, FedRAMP requires 3 years for security-relevant events.
The structural test is whether you can answer the question: "show me everything that happened to this production artifact from commit to deploy, including who approved each step." If the answer requires correlating logs from four systems with mismatched timestamps, the auditor will note it. If the answer is a single query returning a complete event chain, you are ahead of most of the industry.
How do you handle policy gate evidence?
Policy gates need their own evidence trail. Auditors want to see that the gate exists, that it fires on the conditions you claim, and that overrides are exceptional and approved. The records I produce for audit show the policy as it was at each evaluation point, the input artifact, the verdict, and the override record if any. This is straightforward if your policy engine is purpose-built and painful if your gates are scattered across YAML files in different repositories.
A common finding is that policy gates exist but the override path is undocumented, so the auditor cannot confirm whether overrides are governed. Document the override workflow as part of the policy itself: who can override, what evidence is required, where the override is logged, and how the override is reviewed retrospectively.
How Safeguard Helps
Safeguard's policy and audit module is built around the evidence-collection workflow that audits actually demand. Every policy gate evaluation produces a tamper-evident record linking the artifact, SBOM, attestation, and verdict, queryable by artifact digest or build identifier across the full retention window. Griffin AI surfaces audit-relevant findings before the auditor does, and the TPRM module produces the supplier evidence increasingly required under SOC 2 and FedRAMP. Zero-CVE base images come with provenance attestations included, removing one common audit gap entirely. The platform turns the question "show me the evidence for this control" into a single query rather than a multi-week scramble.