Software Supply Chain Security Checklist for CI/CD Pipelines

Overview

A useful software supply chain security checklist should help you answer a simple question: Can we trust what our pipeline built, how it was built, and what eventually reached production? That trust does not come from a single scanner or a single policy. It comes from a chain of controls across source control, CI runners, build steps, dependency resolution, artifact storage, deployment automation, and runtime verification.

For most teams, the goal is not to implement every possible control at once. The more practical approach is to establish a minimum baseline, then deepen controls where the blast radius is highest: shared build systems, privileged release jobs, container image production, infrastructure code, and deployment automation.

Use this checklist in three ways:

• Before introducing a new pipeline or tool: confirm that the workflow has basic trust and auditability built in.
• During quarterly security reviews: check whether earlier assumptions still hold after team, platform, or vendor changes.
• After incidents or near misses: identify where the trust chain is weak rather than only fixing the visible failure.

If your delivery platform includes Kubernetes, this article pairs well with a broader runtime review such as Kubernetes Security Checklist: Baseline Controls to Review Every Quarter. If your team is standardizing developer workflows, it also helps to build these controls into platform defaults and golden paths rather than relying on ticket-by-ticket enforcement; see Golden Paths for Platform Teams: Examples, Guardrails, and Rollout Strategy.

Below is a refreshable checklist organized by scenario, followed by a short list of items worth double-checking, common mistakes, and review triggers.

Checklist by scenario

This section breaks the checklist into practical areas of control so you can review the parts of the pipeline that often fail independently.

1. Source control and change integrity

• Protect critical branches. Require pull requests, approvals, and clear merge rules for branches that feed release pipelines.
• Use strong identity controls. Enforce SSO, MFA, and least-privilege access for repository admins, maintainers, and automation identities.
• Limit who can change pipeline definitions. Treat CI configuration files, reusable workflows, and deployment manifests as high-trust assets.
• Require review for security-sensitive changes. This includes updates to Dockerfiles, build scripts, dependency lockfiles, IaC modules, secrets handling, and release jobs.
• Audit force-push and bypass permissions. Any mechanism that skips normal review should be rare, explicit, and logged.
• Separate human and machine identities. Build bots and deploy bots should not share personal tokens or broad credentials.

2. CI runner and build environment hardening

• Know where builds run. Document whether you use hosted runners, self-hosted runners, ephemeral runners, or shared worker pools.
• Prefer ephemeral build environments. Short-lived runners reduce persistence risk from one job to the next.
• Minimize runner privileges. Build jobs should not default to root, privileged Docker mode, or broad cloud admin access unless clearly required.
• Restrict network egress where possible. Limit outbound access so jobs can only reach required package mirrors, registries, artifact stores, and approved APIs.
• Harden base images and worker AMIs. Keep build environments current and remove unnecessary tools that increase attack surface.
• Isolate untrusted code paths. Builds triggered by forks, external contributors, or experimental branches should not share the same trust zone as release jobs.
• Log runner activity. Preserve audit trails for job execution, environment changes, and administrative actions affecting runners.

3. Secrets and identity in CI/CD

• Replace long-lived static credentials where possible. Prefer short-lived, scoped credentials or workload identity mechanisms over stored cloud keys.
• Scope secrets to the minimum needed. Separate read, build, publish, and deploy permissions rather than using one broad token everywhere.
• Avoid exposing secrets to all pipeline contexts. Pull request validation, especially from less-trusted sources, should not automatically receive production or publish credentials.
• Use a managed secret source of truth. Centralized secrets management reduces sprawl across CI settings, repository variables, and scripts.
• Rotate automation credentials on a schedule and after role changes. Do not assume pipeline secrets remain private forever.
• Mask secrets in logs and artifacts. Review job output and debug settings to avoid accidental leakage.

4. Dependency and package governance

• Pin dependency versions. Use lockfiles or equivalent mechanisms for application and infrastructure dependencies.
• Control where packages come from. Limit builds to approved public registries, internal mirrors, or curated repositories.
• Review high-risk transitive dependencies. A lockfile is helpful, but it does not remove the need for human review on major or sensitive additions.
• Separate dependency update automation from auto-deploy trust. Dependency bots should not bypass release scrutiny simply because updates are frequent.
• Scan dependencies continuously, not only at release time. Build-time scanning is useful, but repos and images should also be re-evaluated as new issues emerge.
• Document exception handling. If a vulnerable package is temporarily accepted, record the reason, owner, and expiry for that decision.

5. Build integrity and reproducibility

• Define what a trusted build means. For some teams, that means builds only from reviewed commits; for others, it also means isolated runners and verified inputs.
• Make build inputs explicit. Record source revision, dependency versions, base image references, build parameters, and toolchain versions.
• Avoid hidden build logic. Review shell scripts, fetched installers, and remote setup actions that can change behavior outside the main repo.
• Control reusable CI actions and templates. Pin versions and review upstream changes rather than tracking moving tags blindly.
• Limit manual release steps. The more release logic depends on copy-paste operator actions, the harder it is to trust or audit the result.
• Preserve build metadata. Keep records linking source commit, pipeline run, artifact digest, and deployment target.

6. Artifact storage, signing, and provenance

• Publish artifacts to a controlled registry. Container images, packages, and binaries should land in repositories with role-based access and audit logging.
• Use immutable references where possible. Digest-based deployment is more trustworthy than mutable tags alone.
• Sign release artifacts. If artifact signing is part of your model, make sure the signing path is protected and tied to trusted automation.
• Capture provenance data. Teams should be able to trace which source revision and pipeline run produced a given artifact.
• Separate build and promotion stages. Publishing an artifact is not the same as promoting it to staging or production.
• Control deletion and overwrite rights. Registry cleanup is useful, but permissions should not allow quiet tampering with trusted releases.

7. Deployment pipeline controls

• Separate build permissions from deploy permissions. A compromised build job should not automatically be able to change every environment.
• Require environment-specific approvals where justified. Production should usually have stronger controls than preview or test environments.
• Deploy only trusted artifacts. Prevent environments from pulling arbitrary tags or rebuilding from source during deployment.
• Use policy checks before promotion. Validate image source, signature requirements, allowed registries, and manifest rules before rollout.
• Restrict direct production changes. Emergency access may be needed, but routine bypass of deployment automation undermines provenance.
• Log who approved and who deployed. Auditability matters most when a rollback, incident review, or security investigation begins.

If your organization uses GitOps, align these controls with repository permissions and controller trust boundaries. A comparison such as ArgoCD vs Flux: Which GitOps Tool Fits Your Team in 2026? can help clarify where policy enforcement and operational ownership should live.

8. Infrastructure as Code and platform changes

• Treat IaC pipelines as sensitive delivery systems. Terraform, OpenTofu, Pulumi, and similar workflows can alter broad parts of your environment quickly.
• Review module and provider sources. Pin versions, understand upstream trust, and avoid unreviewed dynamic fetches in critical paths.
• Protect state and backend access. State stores, plan outputs, and apply credentials can expose both infrastructure shape and secrets.
• Require plan review for impactful changes. Network, IAM, cluster, and secret-management changes deserve stronger review than cosmetic updates.
• Scope cloud credentials tightly. Separate read-only planning roles from apply roles when possible.

For teams evaluating IaC workflows, Terraform vs Pulumi vs OpenTofu: A Practical IaC Comparison is a useful companion when deciding how much policy and security logic to embed in the delivery process.

9. Container and Kubernetes delivery

• Pin base images and review updates. Avoid vague latest-style references in production build paths.
• Scan images before promotion. Focus on exploitable risk and runtime relevance, not just raw finding counts.
• Keep admission and deployment rules aligned. If the cluster requires signed or approved images, make sure the pipeline already enforces the same assumptions.
• Verify namespace and service account targeting. A secure artifact can still be deployed with overly broad runtime permissions.
• Review release timing with platform version changes. Cluster upgrades and API deprecations can alter enforcement behavior; see Kubernetes Release Calendar and Support Timeline and Kubernetes Version Skew Policy Explained: Upgrade Rules for Clusters, Nodes, and Clients.

10. Monitoring, response, and evidence retention

• Log key CI/CD events. Capture changes to pipeline definitions, secret access, approval actions, release promotions, and administrative configuration changes.
• Alert on unusual release behavior. Examples include off-hours production deployments, artifact publishing from unfamiliar runners, or repeated failed signing steps.
• Retain enough evidence for investigation. Build logs, provenance metadata, registry events, and deploy history should survive long enough to support post-incident review.
• Map pipeline incidents into your response process. Supply chain failures should fit cleanly into incident severity definitions and escalation paths; see Incident Severity Matrix: How to Define Sev Levels That Actually Work.
• Define recovery steps. Know how to revoke credentials, quarantine registries, pause promotions, and rebuild artifacts from a known-good point.

What to double-check

Even teams with mature pipelines tend to overlook a few high-impact details. Before you call your ci cd security checklist complete, pause on these items:

• Who can modify reusable workflows and shared templates? Many organizations lock down application repos but leave central CI logic with broad write access.
• Can pull request jobs access secrets or publish artifacts? This is one of the most common trust-boundary mistakes.
• Are deployments tied to immutable artifacts? If production pulls floating tags, your provenance story is weaker than it appears.
• Do you know which credentials are long-lived? Temporary identity is often discussed more than it is actually implemented.
• Can someone bypass the normal promotion path? Break-glass access may be necessary, but it should be explicit, auditable, and uncommon.
• Are your scanners producing action or only noise? A backlog of ignored findings is not a control. Tuning and ownership matter more than raw scan count.
• Does platform enforcement match pipeline assumptions? If the cluster, registry, or cloud policy rejects artifacts the pipeline happily builds, developers end up working around security rather than using it.

A helpful rule is to test your controls from the perspective of an attacker and from the perspective of a tired engineer in a hurry. If either can accidentally break the trust chain with a routine action, the control probably needs to move earlier in the workflow or become a paved-road default.

Common mistakes

The goal of a devsecops supply chain program is not to collect controls for their own sake. These are the mistakes that usually reduce effectiveness:

• Relying on a single scanner. Vulnerability scanning is valuable, but it does not replace identity controls, provenance, or artifact trust.
• Securing production but ignoring build systems. If the build path is weak, runtime hardening starts too late.
• Using one privileged token for everything. Shared automation credentials increase blast radius and complicate attribution.
• Trusting tags instead of digests or verifiable metadata. Human-friendly labels are useful, but they should not be the only basis for deployment trust.
• Letting exceptions become permanent. Temporary policy bypasses need owners and review dates.
• Adding controls without improving developer flow. Security that requires constant manual workarounds will be bypassed. Platform-level defaults are more durable.
• Ignoring incident readiness. If you cannot quickly answer what was built, from which commit, on which runner, with which credentials, your response time will suffer.

This is also where internal developer platforms can help. Instead of asking every team to assemble its own secure pipeline, central teams can package approved build templates, registry policies, and deployment guardrails into reusable workflows. If you are heading in that direction, Backstage Adoption Guide: When an Internal Developer Platform Actually Needs It may help frame where self-service should begin.

When to revisit

This checklist is most useful when treated as a living review, not a one-time compliance artifact. Revisit it before seasonal planning cycles and any time your workflows or tools change. In practice, that usually means creating a short review cadence with clear owners.

Review the checklist again when any of the following happen:

• You adopt a new CI platform, runner model, package registry, or artifact signing approach.
• You move from direct deployments to GitOps, or the reverse.
• You centralize platform engineering standards and introduce new golden paths.
• You change cloud identity patterns, secret stores, or registry architecture.
• You add new build targets such as container images, Terraform modules, internal packages, or signed binaries.
• You onboard external contributors, contractors, or a new business unit into shared CI infrastructure.
• You experience a release incident, credential exposure, or suspicious artifact behavior.
• You upgrade Kubernetes or change admission, policy, or runtime enforcement patterns.

To keep the review lightweight, assign one owner from platform engineering, one from security, and one from a delivery team that uses the pipeline daily. Ask them to answer four practical questions:

1. What changed in the toolchain?
2. Which trust assumptions are no longer true?
3. Which controls are still manual and should become defaults?
4. What evidence would we need if a release were under investigation tomorrow?

Finish each review with a short action list: one quick fix, one medium-term hardening task, and one platform improvement that reduces future exceptions. That keeps this software supply chain security checklist useful as an operational document instead of a shelf document.

If you want one practical next step today, start by tracing a single production artifact backward: deployment record, artifact digest, registry event, build run, source commit, approver, and credentials used. Any missing link in that chain is your next priority.