Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Which CI/CD pipeline artifacts count as audit evidence?
Updated
The pipeline evidences four things well: that required checks ran and passed, that the build produced a traceable artifact, that deployment needed an approval from someone other than the author, and that run history is retained. SLSA levels are best practice, not a requirement.
CI/CD evidence map, last verified 10 September 2026 against the SLSA specification at slsa.dev, NIST SP 800-218 (Secure Software Development Framework), the AICPA Trust Services Criteria change-management criteria, and ISO/IEC 27001:2022 Annex A 8.31 and 8.32, with GitHub Actions and GitLab CI documentation for platform behaviour. SLSA is a community specification, not law: no framework named on this page requires a SLSA build level, and describing a level as an obligation would be wrong. This page is not legal advice, does not determine YOUR obligations, does not start a clock, and does not file with an auditor.
What this page is, and what it is not
Audience: a DevOps or platform lead, engineering leader, or compliance owner who needs the pipeline to answer change-integrity and deployment-approval questions without a manual evidence scramble each quarter.
This page is not legal advice. It does not determine YOUR obligations, does not decide which frameworks apply to your organisation, does not start a clock, and does not file anything with an auditor. Mapping a pipeline stage to a control is a planning step; whether the control operated over the period is the operating-effectiveness question covered by the prove-a-control-works page in this cluster. Last verified 10 September 2026.
It is deliberately tool-agnostic. The stages below exist in GitHub Actions, GitLab CI, Jenkins, CircleCI, Buildkite, and Azure Pipelines, and the evidence is the same shape in each: a run record, a configuration that made the run mandatory, and a retention window that keeps both long enough. Platform-specific paths for the two most common cases are given in the GitHub and GitLab pages in this cluster.
- The strongest pipeline evidence is a configuration that makes the control unavoidable plus a run history that shows it happened. Either one alone is weak: a required-check setting with no runs proves nothing, and green runs with no enforcement prove only that people chose to behave.
- Retention is the quiet failure. Most CI platforms expire run logs and job artifacts on a default schedule that is shorter than an audit period. Check the window before you rely on it.
- Self-hosted runners change the story. Where you run the runner, you own its hardening, its isolation between jobs, and its patching — and you must evidence those.
- Secrets in pipelines are an access control, not a build detail. Who can read a pipeline secret, and who can run a workflow that reads it, belongs in your access evidence.
Pipeline-stage-to-evidence map
Read the first column as the pipeline stage, the second as the artifact that evidences it, the third as the control assertion it supports, and the fourth as the tool-agnostic note with GitHub Actions and GitLab CI examples. Last verified 10 September 2026. Not legal advice.
| Pipeline stage | Evidence artifact | Control assertion it supports | Where it comes from (examples) |
|---|---|---|---|
| Trigger and source integrity | The run record showing the commit SHA, the branch or tag, and the actor that triggered it; the branch-protection or protected-branch configuration that limits what can be built and deployed | Only reviewed code from a controlled branch reaches the build that ships. AICPA TSC CC8.1; ISO/IEC 27001:2022 Annex A 8.32. | GitHub Actions run metadata plus repository rulesets; GitLab CI pipeline metadata plus protected branches. Equivalent metadata exists in Jenkins and Azure Pipelines. |
| Build environment definition | The pipeline definition committed in the repository, its change history, and the runner or executor image reference used for the run | The build process itself is version-controlled and its changes are reviewed. NIST SP 800-218 PO.3 and PS practices; Annex A 8.31 separation of environments. | The workflow file in .github/workflows, or .gitlab-ci.yml, tracked as code. Pinned action or image digests are stronger evidence than floating tags. |
| Static analysis and secret scanning jobs | Job results per run, the finding counts and their disposition, and the configuration making the job required | Code is analysed before release and blocking criteria are enforced. AICPA TSC CC7.1; Annex A 8.28. | Code-scanning or SAST jobs in either platform; a third-party scanner invoked as a job produces equally valid evidence when the report is retained. |
| Dependency and container scanning jobs | Scan results per build, the dependency inventory captured at build time, and the policy that fails or gates the build on stated criteria | Known-vulnerable components are detected before release. AICPA TSC CC7.1; Annex A 8.8. | Dependency scanning jobs, container image scans, or a software-composition-analysis tool run in the pipeline. See the dependency page in this cluster. |
| Test execution | Test job results per run, coverage or result summaries where you report them, and the requirement that tests pass before merge or deploy | Changes are tested before implementation. AICPA TSC CC8.1; Annex A 8.29 security testing in development and acceptance. | Required status checks in GitHub, merge checks in GitLab, or an equivalent gate elsewhere. Retain the run record, not only the badge. |
| Build and artifact production | The build log, the produced artifact digest, the artifact registry entry, and the mapping from artifact digest back to the source commit | A released artifact can be traced to the reviewed source that produced it. NIST SP 800-218 PS.1–PS.3. | Container image digests in a registry, package versions in a package registry, or release assets. Record the digest, not just the tag, because tags move. |
| Provenance and attestation | A signed provenance statement naming the builder, the source, the build parameters, and the resulting artifact digest, stored alongside the artifact | Supply-chain integrity: a consumer can verify what built the artifact. SLSA build levels — best practice, not a requirement (see the section below). | GitHub artifact attestations, GitLab CI job-generated attestations, or an in-toto or Sigstore-based step. Provenance you never verify is documentation, not a control. |
| Artifact signing and verification | Signature material, the verification step in the deploy pipeline, and the failure record when verification fails | Only artifacts you produced are deployed. NIST SP 800-218 PS.2; Annex A 8.32. | Sigstore or platform-native signing, plus an admission or deploy-time verification step. The verification step is the control; the signature alone is not. |
| Deployment approval | The approval record naming the approver and the time, the environment protection configuration requiring it, and the deployment record | Deployment to production is authorised by someone other than the change author. AICPA TSC CC8.1; segregation-of-duties expectations under PCAOB AS 2201 where SOX applies. | GitHub environment protection rules with required reviewers; GitLab protected environments with deployment approvals. This is usually the cheapest segregation-of-duties artifact available to a small team. |
| Environment separation | Separate credentials and configuration per environment, the deploy target mapping, and evidence that non-production credentials cannot reach production | Development, test, and production are separated. Annex A 8.31; AICPA TSC CC8.1. | Environment-scoped secrets in either platform, distinct cloud accounts or projects per environment. See the AWS, Azure, and GCP pages in this cluster. |
| Emergency and out-of-band change | The record of the bypass or manual deploy, who authorised it, the reason, and the retrospective review or follow-up change | Emergency change is an exception with an owner, not an unmonitored path. AICPA TSC CC8.1; Annex A 8.32. | Ruleset bypass events, protected-environment overrides, or a documented manual runbook execution. See the change-management page in this cluster. |
| Pipeline audit trail and retention | Run history for the period, job logs, artifact retention settings, and the record of who changed pipeline configuration or secrets | The pipeline's own activity is recorded and retained. AICPA TSC CC7.2; Annex A 8.15. | Actions run history and repository or organisation audit log; GitLab pipeline history and audit events. Check the platform's default expiry against your required retention. |
| Runner and executor integrity | Runner inventory, whether runners are hosted by the platform or by you, isolation configuration between jobs, and patching evidence for self-hosted runners | The build platform is not a soft path into production. NIST SP 800-218 PO.5; Annex A 8.31. | Platform-hosted runners shift much of this to the provider; self-hosted runners keep it with you and must be evidenced like any other host. |
SLSA levels: best practice, not a requirement
SLSA is a specification maintained by the OpenSSF community at slsa.dev. Its build track describes increasing levels of assurance about how an artifact was produced. It is genuinely useful, and it is not a legal obligation. No statute, no attestation criterion, and no certification requirement named on this page requires a SLSA level, and a page that implies otherwise is misleading you. Last verified 10 September 2026 against the SLSA specification. Not legal advice.
| SLSA build level | What the specification describes | Status |
|---|---|---|
| Build L1 — provenance exists | The build runs on a build platform and produces provenance describing how the artifact was built, so a consumer can see the source and the build process. Provenance may be unsigned at this level. | Industry best practice. Not a legal requirement, and not required by AICPA TSC, ISO/IEC 27001, or PCI DSS. |
| Build L2 — hosted build platform with signed provenance | The build runs on a hosted build platform that generates and signs the provenance, so tampering by the package producer after the build is detectable. | Industry best practice. Achievable with platform-native attestation features in common CI systems. |
| Build L3 — hardened builds | The build platform provides strong assurances that provenance is unforgeable, including isolation between builds and protection of the signing material from the build itself. | Industry best practice. A meaningful engineering commitment, still not a legal requirement. |
| Verification of provenance at deploy or install time | The specification's value depends on a consumer verifying the provenance against a policy. Producing provenance nobody checks does not deliver the assurance. | Industry best practice, and the step most often skipped. Where you claim provenance as a control, the verification step is the evidence. |
| NIST SP 800-218 PS.1–PS.3 on protecting and archiving release integrity. | Regulatory and standards guidance. Binding on some US federal software suppliers through separate acquisition authority — notably attestation regimes for software sold to US federal agencies. | Guidance for a commercial company unless a contract or acquisition rule pulls it in. Check your contracts. |
| Generate provenance, verify it at deploy time, and retain the provenance with the artifact for as long as the release is supported. | ShipReady Metrics recommendation, aligned to SLSA but stated as our advice. | Not required by any framework named here. Adopt it because it makes an incident investigation faster, not because a regulator asked. |
Legal requirement, guidance, best practice, or our recommendation
Supply-chain security has more vocabulary than obligation. Label the reason each pipeline control exists. Last verified 10 September 2026. Not legal advice.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| PCI DSS v4.0.1 Requirement 6.5 on managing changes to system components, and 6.2 on secure development. | Legal requirement in the contractual sense, for entities in scope through card-brand and acquirer agreements. | Does not name a CI platform, provenance format, or SLSA level, and does not apply outside cardholder-data scope. |
| AICPA TSC CC8.1 on authorised, designed, tested, approved, and documented change. | Attestation criteria, applying because you sought a SOC 2 report or a contract requires one. | Does not require automation. A well-documented manual gate satisfies the criterion; automation just makes the evidence cheaper. |
| ISO/IEC 27001:2022 Annex A 8.28 secure coding, 8.29 security testing, 8.31 separation of environments, 8.32 change management. | Certification requirement where you seek or hold certification. | Does not require signing, attestation, or a particular gate configuration. |
| NIST SP 800-218 (SSDF) and the SLSA specification. | Regulatory and standards guidance, and community best practice respectively. | Neither is binding on a commercial company by default. Federal software attestation regimes can pull SSDF in by contract; SLSA is not a legal instrument at all. |
| Require status checks on the protected branch, require an approver other than the author for production deployment, and pin action or image references by digest. | Industry best practice, widely expected by auditors as a matter of practice. | Not written as a numbered requirement in the criteria above. |
| Export the pipeline run population and the deployment approval records for the period before the platform's retention window expires. | ShipReady Metrics recommendation. | Does not make the control effective by itself, and is not required by any framework named here. |
Checklist
A question list for the pipeline side of your evidence set. Not a determination that any framework applies to you. Last verified 10 September 2026. Not legal advice.
- Can we produce every production deployment in the period as one population, with the commit, the artifact digest, the approver, and the time?
- Is each check we describe as required actually enforced by configuration, or is it merely usually present?
- Does the platform's default retention for run logs and job artifacts cover our audit period, and if not, where are exports stored?
- Can a person deploy to production without an approval from someone other than the change author, anywhere in scope?
- Are pipeline definitions themselves under review, or can a single contributor change the gate that guards them?
- Are actions, images, and third-party pipeline components pinned by digest, or can an upstream tag change what runs?
- Who can read production secrets, and who can trigger a workflow that reads them? Is that list reviewed?
- For self-hosted runners: are they isolated between jobs, patched, and inventoried, and can we evidence that?
- If we claim provenance or signing as a control, is there a verification step that fails the deploy, and has it ever failed?
- Are emergency and manual deployments recorded with an authoriser and a reason, and reviewed afterwards?
What to do now
Ordered so the artifacts auditors ask for first become producible first. None of these steps is a legal determination, and none files anything with an auditor.
- Produce the deployment population for the current period today, from the platform, and store it. That single export answers more audit questions than any configuration screenshot.
- Add a production deployment approval requiring someone other than the change author. It is the cheapest segregation-of-duties evidence available and closes the most common finding.
- Check retention windows for run logs, job artifacts, and audit events, and set up scheduled exports where the window is shorter than your audit period.
- Make required checks actually required in configuration rather than conventional in practice, then verify by attempting a merge that should fail.
- Pin actions, images, and pipeline components by digest, and record the policy. Floating tags make the build record unreproducible.
- If you want provenance, add generation and a deploy-time verification step in the same change. Provenance without verification is not a control.
- Treat emergency deployment as a recorded exception path with a named authoriser, not as an unmonitored capability.
- Re-verify slsa.dev and your CI platform documentation annually, and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not configure your pipelines, does not sign or verify your artifacts, does not gate your deployments, and does not file anything with an auditor.
Delivery Health computes DORA posture — deployment frequency, lead time for changes, change failure rate, and time to restore — from connected sources including GitHub Actions runs. That is delivery posture: useful for spotting a pipeline that has stopped deploying or a change failure rate that moved, and not a change-management control opinion, not an attestation, and not an incident-response runbook.
The GitHub App is read-only and reads Actions runs among other scopes; it does not trigger workflows, change protection, or configure environments. GitLab ingest covers security findings with the same read-only posture.
If you already have a session: signed-in app → Compliance holds evidence collection for control-mapped artifacts across starter control subsets, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. That is a timestamped compliance artifact — not a forensic chain of custody, not a downloadable evidence binder, and not an auditor's opinion.
Primary sources (last verified 10 September 2026)
Each source below is labelled by the kind of authority it carries. Platform documentation is the authority for platform behaviour.
The SLSA specification at slsa.dev is a community specification and industry best practice — not law. NIST SP 800-218 (Secure Software Development Framework) is guidance, which acquisition rules can make contractual for suppliers to US federal agencies. AICPA Trust Services Criteria CC7 and CC8 are professional attestation criteria. ISO/IEC 27001:2022 Annex A 8.28, 8.29, 8.31 and 8.32 are certification requirements. PCI DSS v4.0.1 Requirements 6.2 and 6.5 bind entities in scope through contract. GitHub Actions and GitLab CI documentation are the authority for those platforms' behaviour and retention defaults. Not a complete list, and not legal advice.
The GitHub and GitLab pages in this cluster give platform-specific paths. The change-management page covers the approval and emergency-change side, and the SBOM and dependency pages cover what the build should record about its inputs.
Frequently asked questions
Is this legal advice?
No. It is an operational mapping of pipeline stages to evidence, with every source labelled by the kind of authority it carries. Whether SOC 2, ISO/IEC 27001, PCI DSS, or any statute applies to your organisation is a legal and commercial question for counsel and your contracts. This page does not determine YOUR obligations and does not file anything with an auditor.
Do we need to reach a SLSA level to pass an audit?
No. SLSA is a community specification and industry best practice maintained at slsa.dev. No statute, no AICPA criterion, no ISO/IEC 27001 Annex A control, and no PCI DSS requirement named on this page requires a SLSA build level. It is worth adopting because provenance shortens incident investigation and supply-chain questions from customers — not because a regulator asked for it.
Is a green pipeline enough evidence of change control?
Not by itself. A green run shows that checks passed on that run. An auditor also wants the configuration that made those checks unavoidable, the complete population of runs and deployments in the period, and evidence that bypass was either impossible or recorded. Green runs with no enforcement show only that people behaved when nobody made them.
How long do CI platforms keep run logs and artifacts?
Less time than most audit periods, by default, and the specifics differ by platform and plan. Read your platform's current documentation for log and artifact retention, then either extend the retention setting or export on a schedule into your evidence repository. Discovering the window after an auditor asks for a nine-month-old run is a common and avoidable failure.
Does ShipReady Metrics evidence our pipeline controls?
Partly, and only as posture. Delivery Health computes DORA metrics — deployment frequency, lead time, change failure rate, time to restore — from connected sources including GitHub Actions runs. That is delivery posture, not a change-management control opinion. Pipeline configuration and approval artifacts are handled as manual evidence rows, where a named human accepting a row renders it met and rejecting it renders it a gap, with a timestamp.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.