Compliance and Audit

First PublishedFeb 17, 2026ByAtif Alam

Organizations subject to SOC 2, HIPAA, PCI DSS, ISO 27001, or internal governance policies need CI/CD pipelines that produce evidence — who changed what, who approved it, and what was deployed. This page covers the practices that make CI/CD auditable and compliant.

Why Compliance in CI/CD?

Auditors ask questions like:

Question	What They Want to See
Who can deploy to production?	RBAC, branch protection, approval gates
Was this change reviewed before deployment?	PR reviews, merge policies
What exactly was deployed?	Artifact provenance, image digests, SBOM
Can a single person push code to production?	Separation of duties
Is there an audit trail?	Git history, deployment logs, approval records
How do you handle vulnerabilities?	Security scanning, patching SLAs

CI/CD, when configured correctly, automates most of these controls — generating audit evidence as a byproduct of the normal workflow.

Audit Trail

Git as the Source of Truth

Every change flows through Git, creating an immutable audit trail:

Commit:     a1b2c3d
Author:     alice@example.com
Date:       2026-02-17T10:30:00Z
Message:    feat: add payment processing (#142)
Signed:     GPG signature verified
PR:         #142 (reviewed by bob@example.com, approved by carol@example.com)
Merged by:  carol@example.com
Pipeline:   Build #847 (passed all stages)
Deployed:   staging at 10:35 UTC, production at 11:00 UTC (approved by dave@example.com)

This chain answers: who made the change, who reviewed it, who approved deployment, and when it reached production.

Deployment Logs

CI/CD platforms maintain deployment history:

Platform	Where to Find It
GitHub Actions	Actions tab → workflow runs → job logs
GitLab CI	CI/CD → Pipelines → job logs, Environments → deployment history
Jenkins	Build history per job, audit log plugin
ArgoCD	Application history, sync events

Centralized Audit Logging

For compliance, forward CI/CD logs to a centralized system:

CI/CD events ──► Event stream ──► SIEM / Log Analytics
  - Pipeline runs                   - Splunk
  - Deployments                     - Elastic
  - Approvals                       - Azure Sentinel
  - Secret access                   - AWS CloudTrail
  - Permission changes

Separation of Duties

Separation of duties means no single person can write code AND deploy it to production without oversight:

Developer:     Writes code, opens PR
Reviewer:      Reviews and approves the PR (different person)
Pipeline:      Builds, tests, scans automatically
Approver:      Approves production deployment (can be the reviewer or a release manager)
Pipeline:      Deploys to production

Implementing Separation of Duties

Control	How to Implement
Code review required	Branch protection: require 1+ approving review before merge
Author cannot approve own PR	Branch protection: dismiss stale reviews, require different person
Production deploy approval	Environment protection rules: require named approvers
No direct push to main	Branch protection: require PR, no force push
Limited deploy permissions	RBAC: only specific teams can trigger production deploy

GitHub Branch Protection

Branch: main
  ✓ Require pull request before merging
  ✓ Require 1 approving review
  ✓ Dismiss stale reviews when new commits are pushed
  ✓ Require review from code owners
  ✓ Require status checks to pass (CI pipeline)
  ✓ Require signed commits (optional, for high-security)
  ✓ Do not allow bypassing the above settings

GitLab Merge Request Approvals

Project Settings → Merge Requests
  ✓ Approvals required: 2
  ✓ Prevent approval by author
  ✓ Prevent approval by committers
  ✓ Require code owner approval
  ✓ Prevent pushing to protected branches

Signed Commits

GPG-signed commits prove that a commit was made by the claimed author — not forged:

# Configure GPG signing
git config --global commit.gpgsign true
git config --global user.signingkey <GPG-KEY-ID>

# Signed commits show as "Verified" in GitHub/GitLab
git log --show-signature

Requiring Signed Commits

Platform	How
GitHub	Branch protection → “Require signed commits”
GitLab	Push rules → “Reject unsigned commits”

SSH Signing (Simpler Alternative)

Git 2.34+ supports SSH keys for signing — no GPG setup needed:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

Change Management

Formal change management processes require evidence that changes were planned, reviewed, tested, and approved.

Change Record

A typical change record includes:

Field	Source
Change description	PR title and body
Risk assessment	PR labels (e.g. risk:high, risk:low)
Testing evidence	CI pipeline status (all green)
Security scan results	SAST/SCA/container scan reports
Reviewer(s)	PR review approvals
Approval	Environment protection approval in CI/CD
Deployment time	CI/CD deployment logs
Rollback plan	Documented in PR or deployment runbook

Automating Change Records

# GitHub Actions — create a deployment record
- name: Record deployment
  run: |
    echo "## Deployment Record" > deployment-record.md
    echo "**Version:** ${{ github.sha }}" >> deployment-record.md
    echo "**Deployed by:** ${{ github.actor }}" >> deployment-record.md
    echo "**Time:** $(date -u)" >> deployment-record.md
    echo "**Environment:** production" >> deployment-record.md
    echo "**PR:** #${{ github.event.pull_request.number }}" >> deployment-record.md
    echo "**Pipeline:** ${{ github.run_id }}" >> deployment-record.md

- name: Upload record
  uses: actions/upload-artifact@v4
  with:
    name: deployment-record
    path: deployment-record.md
    retention-days: 365

Artifact Provenance

Provenance proves where an artifact came from and how it was built:

SLSA (Supply-chain Levels for Software Artifacts)

SLSA is a framework for supply chain security with increasing levels:

Level	Requirement
SLSA 1	Build process is documented
SLSA 2	Build runs on a hosted service, generates provenance
SLSA 3	Build environment is hardened, provenance is non-forgeable
SLSA 4	Two-person review, hermetic build, provenance is signed

GitHub Actions — SLSA Provenance

- uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2.0.0
  with:
    image: ghcr.io/myorg/myapp
    digest: ${{ steps.build.outputs.digest }}

Image Signing with Cosign

# Sign an image (Sigstore keyless signing)
cosign sign ghcr.io/myorg/myapp@sha256:abc123...

# Verify signature before deployment
cosign verify ghcr.io/myorg/myapp@sha256:abc123... \
  --certificate-identity=https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

SBOM (Software Bill of Materials)

An SBOM lists every component in your software:

# Generate SBOM
syft ghcr.io/myorg/myapp:1.4.0 -o spdx-json > sbom.json

# Attach SBOM to the image
cosign attach sbom --sbom sbom.json ghcr.io/myorg/myapp:1.4.0

See Security Scanning for more on SBOM.

Compliance Framework Mapping

SOC 2

SOC 2 Criteria	CI/CD Control
CC6.1 — Logical access controls	Branch protection, RBAC, environment protection
CC6.2 — Access provisioning	Team-based permissions, code owners
CC8.1 — Change management	PR reviews, approval gates, pipeline status checks
CC7.1 — Monitoring	Pipeline logs, deployment alerts, security scanning
CC7.2 — Incident response	Rollback procedures, deployment history

PCI DSS

PCI Requirement	CI/CD Control
6.3 — Secure development	SAST, SCA, code review
6.4 — Change control	PR approval, separation of duties
6.5 — Vulnerability management	Dependency scanning, container scanning
10.1 — Audit trails	Git history, pipeline logs, deployment records

HIPAA

HIPAA Requirement	CI/CD Control
Access control	RBAC, MFA, environment protection
Audit controls	Pipeline logs, deployment history, access logs
Integrity	Signed commits, image signing, immutable tags
Transmission security	TLS for registry access, encrypted secrets

Environment Controls

Control	Implementation
Development	Any developer can deploy; no approval needed
Staging	Auto-deploy from main; team can trigger manually
Production	Require approval from 1+ named reviewers; branch restriction (main only)
Hotfix	Expedited review (1 reviewer minimum); post-incident review within 24 hours

GitHub Environment Protection

jobs:
  deploy-production:
    environment:
      name: production
      url: https://myapp.com
    # GitHub checks:
    # - Required reviewers (configured in Settings → Environments)
    # - Wait timer (optional)
    # - Deployment branches (only main)
    steps:
      - run: ./deploy.sh production

Compliance Checklist

A checklist for CI/CD compliance readiness:

Access Control

• Branch protection enabled on main (require PR, reviews, status checks).
• No direct push to production branches.
• Environment protection rules for staging and production.
• RBAC configured — least-privilege for CI/CD permissions.
• MFA required for all accounts with deploy access.

Change Management

• All changes go through PR with at least 1 reviewer.
• Author cannot approve their own PR.
• CI pipeline must pass before merge is allowed.
• Production deployment requires manual approval from named approvers.

Audit Trail

• Git history preserved (no force push to protected branches).
• CI/CD logs retained for required period (e.g. 1 year).
• Deployment history tracked with timestamps, actors, and versions.
• Signed commits enabled (recommended for high-security).

Security

• SAST, SCA, and container scanning in the pipeline.
• Secret detection (gitleaks, pre-commit hooks).
• Secrets stored in platform secret store (not in code).
• OIDC for cloud authentication (no long-lived credentials).
• Image scanning on push.

Artifact Integrity

• Image tag immutability enabled.
• Container images signed (cosign).
• SBOM generated and stored for each release.
• Lifecycle policies for artifact retention.

Key Takeaways

• Git is your audit trail — commits, PRs, reviews, and merges provide evidence of who changed what and who approved it.
• Separation of duties — require PR reviews, prevent self-approval, and use environment protection for production.
• Branch protection is the foundation — no direct pushes, require reviews and passing CI.
• Signed commits and images prove provenance and prevent tampering.
• SBOM and SLSA provide supply chain transparency for compliance frameworks.
• Automate evidence generation — let the pipeline produce deployment records, scan reports, and approval logs.
• Map CI/CD controls to your compliance framework (SOC 2, PCI, HIPAA) and let auditors review the automated evidence.