CI/CD Pipeline Security Checklist

Overview

This article gives you a practical CI/CD pipeline security checklist that maps to the main stages of software delivery: source control, build, artifact handling, deployment, runtime handoff, and incident response. Rather than assume a specific vendor or stack, it focuses on controls that apply across common ci cd tools, platform engineering workflows, and DevSecOps programs.

If you only do one thing, use this checklist as a pre-release review before major changes to your build or deployment system. Security gaps in pipelines often appear during transitions: moving to a new runner model, adding a new cloud account, changing secrets tooling, adopting containers, or introducing third-party actions and plugins.

A useful way to think about a secure CI/CD pipeline is to break it into five trust boundaries:

• Who can change code and pipeline definitions
• What runs during builds and tests
• How artifacts are created, signed, stored, and promoted
• Which identities can deploy to which environments
• How your team detects and responds to suspicious pipeline behavior

The sections below turn those boundaries into a reusable devsecops pipeline checklist.

Checklist by scenario

Use the scenario that best matches your current work. Most teams will need pieces of all four.

1. Baseline checklist for every pipeline

Start here. These are the controls that should exist whether you run a simple web app or a large multi-service platform.

• Protect pipeline configuration like production code. Store workflow files, infrastructure definitions, and deployment manifests in version control. Require review for changes to pipeline logic, environment configuration, and release rules.
• Require branch protections. Use pull requests, status checks, and limited direct pushes to protected branches. If emergency bypasses are allowed, log and review them.
• Separate human and machine identities. Developers should not share service credentials with runners or deployment jobs. Build agents and deploy jobs should use dedicated identities with narrow permissions.
• Use least privilege for automation. Build jobs should not have deployment rights unless there is a clear reason. Deployment jobs should not have broad access to unrelated cloud resources, registries, or secret stores.
• Move secrets out of code and pipeline files. Use a secret manager or native secret store rather than plaintext variables in repositories or job definitions. Rotate credentials on a defined schedule and after suspected exposure. Teams comparing options may find this helpful: Best Secrets Management Tools for DevOps Teams.
• Use short-lived credentials where possible. Prefer federated or temporary credentials over long-lived static keys for cloud deployments and artifact publishing.
• Pin dependencies and actions. Avoid loosely versioned third-party actions, plugins, build images, and packages. Pin to approved versions or immutable references where practical.
• Harden build environments. Use minimal runner images, patch them regularly, and remove tools that are not required for the job.
• Log key events. Capture authentication events, workflow changes, manual approvals, secret access, artifact publication, and production deployment activity.
• Define a promotion path. Artifacts should move from build to test to staging to production through a controlled process rather than being rebuilt in each environment.

2. Checklist for source control and build integrity

This part of the build pipeline hardening process focuses on preventing untrusted changes from entering the system and reducing the blast radius if they do.

• Restrict who can modify repositories, runner settings, and organization-wide workflow templates. Admin access to source control is often effectively admin access to the delivery system.
• Review pipeline file changes with extra scrutiny. Treat edits to workflow YAML, Dockerfiles, package manager settings, and release scripts as higher risk than ordinary application changes.
• Require signed commits or verified authorship if it fits your workflow. The goal is to improve traceability, not create friction for its own sake.
• Scan for hardcoded secrets on commit and in history. A commit-level secret scan is useful, but periodic repository-wide scans can catch older exposures.
• Control fork and external contribution behavior. Pull requests from forks or external repositories should not automatically receive access to production secrets or trusted runners.
• Use isolated build environments for untrusted code. Run less-trusted builds on separate runners, networks, or accounts from privileged internal release pipelines.
• Limit outbound network access from runners when feasible. A runner that can reach everything can also exfiltrate more if compromised.
• Inventory build-time dependencies. Know which package registries, base images, and remote scripts your builds rely on. An inventory discipline similar to cloud asset tracking helps here: How to Build a Cloud Asset Inventory That Stays Accurate.
• Generate provenance where your tooling supports it. Keep a record of what source, dependencies, environment, and identity produced an artifact.

3. Checklist for artifacts, containers, and release promotion

Many software supply chain issues show up after the build step. This software supply chain security checklist section focuses on the artifact path.

• Use a trusted internal registry or controlled repository. Store build outputs in a location with access controls, retention policies, and audit trails.
• Tag artifacts immutably. Human-friendly tags are useful, but each release should also map to an immutable digest, checksum, or build identifier.
• Sign artifacts or container images where practical. Signing is not enough on its own, but it strengthens verification during promotion and deployment.
• Scan images and packages before promotion. Focus on critical exposures first, and define how exceptions are approved and revisited.
• Avoid rebuilding the same release differently per environment. Build once, verify once, and promote the same artifact through environments to preserve integrity.
• Restrict who can overwrite, delete, or promote artifacts. Registry administration and promotion controls are part of deployment security.
• Keep metadata with artifacts. Link artifacts to source commits, test results, security scans, and approval records.
• Set retention policies. Retain enough historic artifacts and logs for rollback, investigation, and audit needs without allowing registry sprawl.

4. Checklist for deployments, infrastructure, and environment access

A pipeline is only as secure as the environment it can reach. If deployment credentials are overpowered or infrastructure changes are ungoverned, build security will not compensate.

• Separate environments by account, project, subscription, or namespace where possible. Clear boundaries make least privilege easier to enforce.
• Use deployment identities scoped to environment. A staging pipeline should not automatically have production rights. A service deploying one cluster should not manage every cluster.
• Require approvals for high-risk changes. Production deployments, IAM changes, secret rotations, and infrastructure modifications often merit an approval step or policy check.
• Store infrastructure as code in protected repositories. Apply the same review and access controls to Terraform, Kubernetes manifests, and platform modules. For teams managing state securely, see Terraform State Security Best Practices.
• Map IAM permissions to real delivery needs. Review cloud roles used by pipelines regularly, especially across providers. This can get subtle in multi-cloud environments: AWS vs Azure vs Google Cloud IAM: Key Differences That Matter.
• Protect environment variables and runtime secrets. Make sure secrets used during deployment are distinct from secrets used by the application at runtime when that separation improves control and auditability.
• Enforce policy checks before apply or deploy. Common examples include disallowing public storage, privileged containers, broad security groups, or unapproved regions.
• Use rollback-ready deployment patterns. Blue/green, canary, and progressive delivery are not only reliability features; they also limit the impact of faulty or malicious releases.
• Observe post-deployment behavior. Security review should continue after release through logs, traces, Kubernetes signals, and alerting. For cluster-heavy environments, this comparison may help: Best Kubernetes Monitoring Tools Compared.

5. Checklist for self-hosted runners and internal platforms

Self-hosted runners, internal build farms, and platform engineering systems offer flexibility, but they raise the importance of host security and operational discipline.

• Patch runner hosts and base images on a schedule. Unpatched build systems can become a quiet entry point into production tooling.
• Use ephemeral runners for sensitive workloads when practical. Short-lived runners reduce persistence risks between jobs.
• Do not share runners across trust levels without isolation. Public, partner, and internal workloads should not all execute in the same privileged environment.
• Limit access to runner hosts, orchestration layers, and caches. Build caches, package mirrors, and shared workspaces can become contamination paths.
• Protect internal platform APIs. If your delivery system uses internal portals or deployment APIs, apply strong authentication, authorization, and audit logging.
• Measure the right controls. Include pipeline security metrics in your platform reviews, such as privileged workflow count, secret rotation age, runner patch status, and approval bypass incidents. For a broader metric framework, see Platform Engineering KPIs: Metrics That Actually Matter.

What to double-check

Before you call the pipeline hardened, pause on the items that teams most often think are covered when they are only partially covered.

• Secrets exposure paths: Check repository history, logs, artifacts, chat notifications, debug output, and failed job traces. A secret manager alone does not prevent accidental echoing or export.
• Third-party workflow components: Review every reusable action, plugin, orb, extension, or marketplace component. Ask who maintains it, how updates are handled, and what permissions it receives.
• Environment drift: Verify that staging and production use the same core controls, not just similar-looking pipelines. Drift often appears in manual exceptions and copied job definitions.
• Privilege creep: Re-check cloud roles, registry permissions, repository admin rights, and approval exemptions after every reorg or platform migration.
• Logging coverage: Confirm that security-relevant events are actually retained long enough to investigate an incident. Collection without retention is a common blind spot.
• Break-glass procedures: Make sure emergency access exists, is documented, is tightly limited, and is reviewed afterward.
• Ownership: Every pipeline should have a named owner for security decisions, not just a team alias that everyone assumes someone else is watching.

If your environment spans multiple clouds, business units, or clusters, it also helps to maintain a simple control map that shows which pipelines can affect which environments. That visibility pairs well with broader governance checklists such as Cloud Control Center Checklist for Multi-Cloud Teams.

Common mistakes

Most pipeline security gaps come from design shortcuts, not a total lack of security tools. These are the mistakes worth watching for.

• Giving the CI system broad admin access everywhere. It is convenient at first and difficult to unwind later.
• Using long-lived cloud keys in pipeline settings. Static credentials create cleanup and rotation problems and expand the blast radius of a leak.
• Trusting all internal code equally. A compromised developer account or risky dependency can originate from inside the organization, not just from external contributors.
• Running production deploys from the same path as experimental builds. Shared runners, shared secrets, and shared permissions weaken separation.
• Scanning without response rules. A vulnerability or secret scan that produces alerts nobody triages does not meaningfully harden the pipeline.
• Ignoring infrastructure security because application tests pass. A green build does not mean the deployment identity, registry policy, or cluster configuration is safe.
• Failing to review old pipeline jobs. Legacy release jobs, disabled branches, and forgotten scheduled tasks often retain permissions long after the original service changed.

Another recurring mistake is treating pipeline security as separate from IAM, tagging, asset inventory, and cost management. In practice, they interact. Weak identity boundaries complicate incident response. Poor resource visibility makes it harder to know where deployments land. Even governance basics like consistent tagging can help teams trace ownership and policy scope across environments.

When to revisit

This checklist is most useful when it becomes part of a repeatable review cycle. Revisit your pipeline security controls in these moments:

• Before seasonal planning cycles when teams propose new services, environments, or release automation
• When workflows or tools change such as a move to new runners, registries, IaC patterns, or secrets tooling
• After an incident or near miss involving leaked credentials, unusual build behavior, unauthorized deployments, or dependency tampering
• After organizational changes including team reorganizations, admin turnover, or new third-party engineering access
• On a fixed cadence such as quarterly reviews for permissions, secrets age, pipeline ownership, and runner patching

For a simple action plan, schedule a 60-minute pipeline security review with the owners of source control, CI/CD, cloud IAM, and runtime platforms. Walk through one production pipeline from commit to deployment and answer four questions:

1. Who can change it?
2. What secrets and permissions does it use?
3. How is the release verified and promoted?
4. If something went wrong today, what evidence would we have?

Document the answers, create a short remediation list, assign owners, and set a date to review again after the next workflow change. That is usually enough to turn a one-time hardening exercise into an operational habit.

A strong ci cd pipeline security checklist should not feel static. It should evolve with your stack, your threat model, and your delivery process. The goal is not maximum friction. The goal is a pipeline that remains fast, observable, and trustworthy as your team grows.