CI/CD Pipeline Security Template

Overview

CI/CD pipelines are a high-value target for attackers because they have access to source code, build secrets, and production deployment paths. A compromised pipeline can introduce malware, exfiltrate data, or deploy unauthorized changes. This template defines controls to protect code integrity, runner security, secrets, and deployment approvals.

When to Use

• For alternatives, see CI/CD Security: Harden Your Pipelines and Prevent Supply.

• Setting up a new CI/CD platform.

• Reviewing or improving an existing pipeline.

• Preparing for a supply chain security audit.

• After a build system compromise or unauthorized deployment.

• Integrating DevSecOps controls into engineering workflows.

Prerequisites

• A version control system with branch protection and audit logging.
• A CI/CD platform such as GitHub Actions, GitLab CI, Azure DevOps, or Jenkins.
• A secret management solution for pipeline credentials.
• A process for code review and approval before merging.
• Ownership from platform engineering, security, and release management.

Solution

Template

1. Source Control Security

Control	Requirement	Verification
Branch protection	Required reviews before merge to main	Repository settings
Signed commits	Require verified commits for privileged accounts	Git configuration
Access control	Least-privilege access to repositories	RBAC review
Audit logging	All pushes, merges, and permission changes logged	Platform logs
Dependency pinning	Lockfiles and pinned versions for reproducible builds	Repository files
Secret scanning	Automated detection of secrets in commits	Pre-commit hooks + CI

2. Pipeline Configuration

Control	Requirement	Verification
Immutable pipeline definitions	Pipelines stored as code and reviewed	Repository files
No secrets in code	Secrets loaded from vault, CI variables, or OIDC	Secret scanning
Input validation	Pipeline parameters validated and sanitized	Code review
Self-hosted runner isolation	Production runners isolated from dev runners	Runner configuration
Ephemeral runners	Fresh runner per build to reduce persistence	Runner settings
Pipeline provenance	SLSA provenance generated for artifacts	Attestation tool

3. Secrets Management

Secret Type	Storage	Rotation	Scope
Cloud credentials	External vault or OIDC	90 days	Per environment
Container registry tokens	Vault or short-lived CI tokens	90 days	Per pipeline
Signing keys	Hardware-backed or KMS	180 days	Limited service accounts
API keys	Vault or secret manager	90 days	Minimum required permissions
Database passwords	Vault dynamic secrets	24 hours	Per pipeline run

4. Build Security

Control	Requirement	Verification
Dependency scanning	All dependencies scanned for known CVEs	Scanner in CI
Static analysis	SAST run on every pull request	CI job
Container image scanning	Base image and layers scanned before push	Registry scan
Reproducible builds	Same source produces same artifact	Build verification
Artifact signing	All artifacts signed with build identity	Signature verification
SBOM generation	Bill of materials generated per build	CI output

5. Deployment Security

Control	Requirement	Verification
Deployment gates	Manual or automated approval before production	Pipeline rules
Environment separation	Production credentials not available in dev	Secret scoping
Rollback plan	Automated rollback trigger on failure	Pipeline definition
Immutable deployments	Artifacts deployed by reference, not rebuilt	Deployment logs
Drift detection	Unauthorized production changes detected	Monitoring tool
Audit trail	Who deployed what, when, and why	Deployment logs

6. Incident Response

Scenario	Response	Owner
Secret leaked	Rotate secret, revoke tokens, audit usage	Security team
Malicious commit	Revert, investigate, revoke credentials	Platform team
Compromised runner	Terminate runner, rebuild, review logs	Platform team
Unauthorized deployment	Rollback, freeze pipeline, audit	Release manager
Tampered artifact	Block deployment, trace provenance	Security team

Explanation

Pipeline security is a subset of supply chain security. By protecting the source, the build process, and the deployment path, the organization reduces the risk of malicious code reaching production. The template maps each control to a verification method, making it suitable for audits and continuous improvement.

GitHub Actions Security Configuration

name: Secure CI Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read
  packages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/ci-role
          aws-region: us-east-1
          # No static keys - OIDC only

      - name: Build and sign
        uses: sigstore/cosign-installer@v3
      - run: |
          cosign sign-blob --yes artifact.tar.gz

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Scan dependencies
        uses: github/codeql-action/init@v3
      - run: npm audit --audit-level=high
      - uses: github/codeql-action/analyze@v3

SLSA Provenance Example

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "artifact.tar.gz",
      "digest": { "sha256": "abc123..." }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "builder": { "id": "github-actions" },
    "buildType": "https://github.com/actions/runner",
    "invocation": {
      "configSource": {
        "uri": "git+https://github.com/org/repo",
        "digest": { "sha1": "commit-hash" }
      }
    },
    "materials": [
      { "uri": "git+https://github.com/org/repo", "digest": { "sha1": "commit-hash" } }
    ]
  }
}

Pipeline Security Audit Checklist

Control	Verified	Notes
No long-lived secrets in CI
OIDC for cloud auth
Actions pinned to SHA
Minimal permissions per job
Branch protection on main
Signed artifacts verified
SBOM generated per build
Dependency scan in pipeline
Runners isolated per env
Audit log retention > 90 days

Variants

• GitHub Actions security checklist: Focuses on actions pinning, workflow permissions, and reusable workflows.
• GitLab CI security template: Includes CI/CD job token scopes, protected runners, and compliance pipelines.
• Jenkins hardening template: Covers plugin management, agent isolation, and Groovy sandboxing.
• Container-native pipeline: Emphasizes image signing, registry scanning, and Kubernetes admission.
• High-compliance pipeline: Adds SLSA Level 3, dual approval, and signed SBOMs for regulated environments.

What works

• Store pipeline definitions as code and review them like application code.
• Use short-lived credentials and OIDC instead of long-lived secrets.
• Scan dependencies before merging and before deploying.
• Sign artifacts and verify signatures before deployment.
• Separate build and production environments physically or logically.
• Require human approval for production deployments.
• Generate and retain SBOMs for every release.
• Monitor pipeline activity for unusual behavior.

Common Mistakes

• Storing secrets in environment variables or pipeline files.
• Using third-party actions without pinning or reviewing them.
• Allowing any branch to deploy to production.
• Running production and dev workloads on the same runner.
• Skipping security scans for hotfix deployments.
• Not rotating pipeline credentials after a compromise.
• Trusting artifacts without signature verification.

Troubleshooting

• Authentication bypass in tests: ensure test users cannot reach production endpoints.
• False positives in scanning tools: tune rules against the risk profile. Distinguish between reachable vulnerabilities and theoretical issues.
• Secrets appear in logs: configure log filters to redact tokens, passwords, and keys. Audit log sinks for sensitive patterns.
• CSP breaks legitimate functionality: use report-only mode first, then enforce. Iterate on allowed sources based on real violations.
• Incident response stalls: run tabletop exercises.

Further Reading

• Official documentation: check the current reference for the framework or tool used.
• Related guides: explore the security and supply-chain guides for deeper coverage.
• Complementary patterns: review design patterns applicable to your technology stack.
• Public postmortems: study real incidents from teams that faced similar production issues.

Production Notes

• Deploy gradually using canary or blue-green to catch regressions early.
• Configure alerts for error rate, p99 latency, and failure rate before enabling in production.
• Document the rollback in the runbook; test the procedure in staging at least once per quarter.
• Review structured logs with correlation IDs to trace requests end-to-end during incidents.

Key Takeaways

• Apply ci/cd pipeline security template when you need a practical solution for your use case.
• Monitor performance after implementation; measure latency, errors, and resource usage before and after.
• Check the Troubleshooting section for common failures; most have documented root causes with fixes.
• Keep dependencies updated and run tests in CI to prevent production regressions.

Common Production Pitfalls

• Leaving required fields blank or using vague one-word answers.
• Filling the document once and never updating it after scope or decisions change.
• Storing the document where the team does not look during incidents or reviews.
• Not assigning an owner, due date, or review cadence.
• Copying boilerplate without removing sections that do not apply.
• Skipping version control, which makes rollback and accountability impossible.
• Failing to link the document to related decisions or follow-up actions.
• Avoiding quarterly reviews that would retire stale or unused sections.