Skip to main content
Home/Tools/Assessment/CI/CD Security Checklist

CI/CD Security Checklist

Assess your CI/CD pipeline security across secrets management, SAST and DAST, artifact signing, the SLSA framework, and deployment controls.

100% Private - Runs Entirely in Your Browser
No data is sent to any server. All processing happens locally on your device.

Hardening Your CI/CD Pipeline

A CI/CD pipeline is one of the most privileged systems in a software organization: it holds production credentials, signs releases, and pushes code directly to customers. A single compromised build step can poison every downstream artifact. This checklist walks through the controls that close the most common gaps, organized so you can score where you stand today and prioritize what to fix next.

What the Checklist Covers

The assessment spans the full pipeline lifecycle:

  • Secrets management — no plaintext credentials in code or config; use a vault or native secret store, short-lived tokens, and OIDC instead of long-lived keys.
  • SAST/DAST — static analysis on every pull request, dynamic and dependency (SCA) scanning before release, with builds failing on critical findings.
  • Artifact signing — sign build outputs and verify signatures at deploy time so only trusted artifacts reach production.
  • Deployment controls — protected branches, required reviews, least-privilege runners, and segregated environments.

The SLSA Framework

SLSA (Supply-chain Levels for Software Artifacts) gives you a graduated target. Level 1 asks for a documented, automated build with provenance. Higher levels add a hardened, isolated build platform, non-falsifiable provenance, and two-person review of the pipeline definition itself. Treating SLSA as a ladder lets you improve incrementally rather than trying to fix everything at once.

Why This Matters

Supply-chain attacks increasingly target the build process rather than the running app, because trust flows downhill from the pipeline. Securing it protects every release without per-application work.

Using the Results

Work the gaps in rough priority order: eliminate hardcoded secrets first, then add signing and provenance, then tighten runner and deployment permissions. Re-run the assessment after each sprint to track progress. The checklist runs entirely in your browser — nothing about your pipeline is uploaded — so you can answer candidly. To weigh the cost of fixing gaps against the risk they carry, the cybersecurity ROI calculator can help frame the business case.

## Hardening Your CI/CD Pipeline A CI/CD pipeline is one of the most privileged systems in a software organization: it holds production credentials, signs releases, and pushes code directly to customers. A single compromised build step can poison every downstream artifact. This checklist walks through the controls that close the most common gaps, organized so you can score where you stand today and prioritize what to fix next. ## What the Checklist Covers The assessment spans the full pipeline lifecycle: - **Secrets management** — no plaintext credentials in code or config; use a vault or native secret store, short-lived tokens, and OIDC instead of long-lived keys. - **SAST/DAST** — static analysis on every pull request, dynamic and dependency (SCA) scanning before release, with builds failing on critical findings. - **Artifact signing** — sign build outputs and verify signatures at deploy time so only trusted artifacts reach production. - **Deployment controls** — protected branches, required reviews, least-privilege runners, and segregated environments. ## The SLSA Framework SLSA (Supply-chain Levels for Software Artifacts) gives you a graduated target. Level 1 asks for a documented, automated build with provenance. Higher levels add a hardened, isolated build platform, non-falsifiable provenance, and two-person review of the pipeline definition itself. Treating SLSA as a ladder lets you improve incrementally rather than trying to fix everything at once. ### Why This Matters Supply-chain attacks increasingly target the build process rather than the running app, because trust flows downhill from the pipeline. Securing it protects every release without per-application work. ## Using the Results Work the gaps in rough priority order: eliminate hardcoded secrets first, then add signing and provenance, then tighten runner and deployment permissions. Re-run the assessment after each sprint to track progress. The checklist runs entirely in your browser — nothing about your pipeline is uploaded — so you can answer candidly. To weigh the cost of fixing gaps against the risk they carry, the [cybersecurity ROI calculator](/tools/planning/cybersecurity-roi-calculator) can help frame the business case.
Loading interactive tool...

CI/CD Pipeline Security Gaps?

Our DevSecOps team audits pipelines, implements security gates, and hardens your software delivery.

Learn About DevSecOps ServicesExplore DevOps Consulting

Frequently Asked Questions

Common questions about the CI/CD Security Checklist

SLSA (Supply-chain Levels for Software Artifacts) is a security framework for protecting software supply chains. It defines four levels of increasing security guarantees, from basic build provenance (L1) to hermetic, reproducible builds (L4).

Never hardcode secrets in code or config files. Use your CI/CD platform's secret management (GitHub Secrets, GitLab CI Variables). Better yet, use OIDC for cloud authentication to eliminate stored credentials.

SAST (Static Application Security Testing) analyzes source code without running it. DAST (Dynamic Application Security Testing) tests running applications. Use both for comprehensive coverage.

Pinning actions to commit SHAs prevents supply chain attacks. Tags can be moved to point to malicious code, but SHAs are immutable. Use actions/checkout@b4ffde65f46... instead of @v4.

Build provenance is cryptographic evidence of where an artifact came from. It enables verification that artifacts weren't tampered with. Generate provenance using SLSA GitHub generator or sigstore/cosign.

Set permissions: {} at the workflow level to disable all permissions, then grant only what's needed per job. Use environment-specific credentials and avoid admin tokens in pipelines.

ℹ️ Disclaimer

This tool is provided for informational and educational purposes only. All processing happens entirely in your browser - no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results. Use at your own discretion.