DevSecOps Checklist for CI/CD Pipelines: Scanning, Secrets, and Policy Gates

Overview

This guide gives you a reusable DevSecOps checklist for modern pipelines, with emphasis on scanning, secrets, and policy gates. It is not tied to one CI platform, scanner, or cloud provider. Instead, it focuses on controls that remain useful even as tools change.

A strong secure deployment pipeline should answer a few basic questions before code reaches production:

• Can you trust the source, dependencies, and build inputs?
• Can the pipeline access only the secrets and environments it actually needs?
• Do security checks run early enough to catch issues before release pressure builds?
• Are policy decisions explicit, versioned, and reviewable?
• Can you trace what was deployed, by whom, from which commit, with which approvals?

For most teams, the easiest way to apply CI/CD security best practices is to divide the pipeline into control points:

1. Source and pull request stage: stop obvious issues early.
2. Build stage: validate dependencies, artifacts, and build integrity.
3. Pre-deployment stage: evaluate risk before anything is promoted.
4. Deployment stage: enforce least privilege and safe release controls.
5. Post-deployment stage: confirm what happened and feed findings back into engineering work.

If your delivery model includes Kubernetes, infrastructure as code, or multiple environments, policy drift becomes a major concern. In those cases, a policy as code pipeline is usually more maintainable than tribal knowledge, manual reviews, or scattered exception documents.

Before you begin, define a simple severity model for findings. Not every issue should block a release. The point of a checklist is not to create friction everywhere; it is to create predictable controls where risk is highest.

Checklist by scenario

Use this section as the operational core of your pipeline review. Start with the controls that fit your current maturity, then add depth over time.

1. Source control and pull request checks

This is where many high-value, low-cost controls belong.

• Require branch protection for main release branches, including pull request review and status checks.
• Scan commits and pull requests for secrets before merge. This includes API keys, tokens, cloud credentials, private keys, and accidental environment file commits.
• Protect workflow definitions with code review. Pipeline files deserve the same scrutiny as application code because they define trust boundaries.
• Validate changed infrastructure and policy files separately from app code so reviewers can focus on security-sensitive changes.
• Require signed commits or trusted contributor controls if your team has supply chain concerns or broad repository access.
• Restrict who can modify deployment targets, runner settings, or protected environments.

Teams that use scheduled jobs should also review timing and trigger behavior carefully. Misconfigured automation can create surprising attack paths or deployment windows. If your pipeline relies on cron-based workflows, keep a validation reference nearby, such as the Cron Expression Guide: Examples, Edge Cases, and Testing Checklist.

2. Dependency, package, and artifact checks

Many pipeline incidents are not caused by your own code. They are caused by what your code consumes.

• Scan application dependencies for known vulnerabilities as part of the build.
• Review direct dependencies separately from transitive ones so teams know what they intentionally introduced.
• Pin versions where practical for base images, build plugins, and critical packages.
• Use trusted registries and package sources rather than allowing unrestricted external downloads during builds.
• Generate and retain a software bill of materials when your environment requires traceability.
• Sign or attest build artifacts if you need stronger provenance and promotion guarantees.
• Separate build-time and runtime dependencies to reduce attack surface.

Containerized workloads should also scan base images and final images. A clean application layer on top of an outdated image still creates avoidable exposure.

3. Secrets and identity controls

This is one of the most important parts of a devsecops checklist because pipeline secrets often expand quietly over time.

• Do not store long-lived secrets directly in repository variables if a secret manager or workload identity option exists.
• Prefer short-lived credentials issued at runtime over static tokens shared across jobs.
• Scope secrets by environment, repository, branch, and job so one compromise does not expose everything.
• Mask secrets in logs and test whether masking works with transformed values, partial strings, and common encodings.
• Restrict secret access on forked pull requests and untrusted contributors.
• Rotate high-impact secrets on a schedule and after suspicious activity.
• Audit who can read, inject, update, and export secrets.
• Remove unused secrets regularly; stale credentials are easy to forget and hard to defend.

If your team is deciding where secrets should live, this companion comparison may help frame tradeoffs: Secrets Management Comparison: Vault vs AWS Secrets Manager vs Doppler vs 1Password.

Identity tokens also deserve debugging support. When a deployment fails because of a malformed or expired token, a quick verification workflow matters. See JWT Debugging Guide: How to Inspect Claims, Expiry, Signatures, and Common Errors for a practical reference.

4. Infrastructure as code and configuration checks

Infrastructure changes should not bypass the same rigor you apply to app releases.

• Lint and validate infrastructure code before plan or apply stages.
• Scan IaC for risky defaults, such as public exposure, wildcard permissions, missing encryption, or unbounded ingress rules.
• Require plan review for privileged infrastructure changes.
• Store policy rules in version control so exceptions and rule changes are reviewable.
• Detect configuration drift between declared and deployed state.
• Separate duties for high-risk changes, especially network, identity, and production data paths.

For Kubernetes deployments, extend this to manifests, Helm values, admission controls, and ingress settings. If your environment relies on ingress controllers, review the operational and exposure tradeoffs described in Kubernetes Ingress Controller Comparison: NGINX vs Traefik vs HAProxy vs Kong.

5. Policy gates before deployment

A good policy as code pipeline turns decisions into explicit checks instead of informal judgment calls made under release pressure.

• Define blocking criteria by severity and asset criticality. For example, production-facing services may have stricter thresholds than internal tools.
• Make policy outcomes visible in pull requests and release summaries.
• Create documented exception paths with owner, reason, expiration date, and compensating controls.
• Separate advisory checks from blocking checks so the team does not ignore every alert.
• Version your policies and review policy changes with the same discipline as code changes.
• Use environment-specific gates; what is acceptable in development may not be acceptable in production.

Release strategy matters here too. Policy gates should align with how you actually ship. If your team uses staged rollouts, compare the operational implications in Blue-Green vs Canary vs Rolling Deployments: Which Release Strategy Fits Your Risk Profile.

6. Deployment execution controls

The safest pre-deployment checks lose value if the deploy step itself is too permissive.

• Use dedicated deployment identities rather than broad administrator credentials.
• Limit production deployments to protected environments with scoped approvals where appropriate.
• Ensure runners or agents are isolated, especially if they handle secrets or production credentials.
• Prevent unreviewed manual command execution on deployment infrastructure.
• Record deployment metadata: commit SHA, artifact digest, approver, environment, and time.
• Require verified artifacts for promotion rather than rebuilding from source at each stage.

If you are evaluating platform choices, maintenance overhead matters as much as features. See GitHub Actions vs GitLab CI vs Jenkins: Feature Comparison and Maintenance Tradeoffs for a practical comparison lens.

7. Post-deployment verification and feedback

Security in CI/CD does not end when the job turns green.

• Verify deployment health with objective checks, not just pipeline completion status.
• Monitor for unusual auth failures, traffic changes, crash loops, or policy denials immediately after release.
• Link security findings back to owners so issues become planned work rather than forgotten artifacts.
• Review incident learnings and turn them into new checks.
• Track exceptions and overdue remediations as part of operational reviews.

To keep deployment risk tied to service reliability, it helps to align security gates with service objectives. A useful companion resource is SRE Service Level Objectives Guide: How to Define SLIs, SLOs, and Error Budgets.

What to double-check

This section helps you catch the subtle gaps that often remain after a pipeline appears “secured.”

• False confidence from one scanner: Dependency scanning, image scanning, secret scanning, and policy validation each cover different risks. One passing result does not mean the pipeline is safe.
• Secret exposure through logs: Test build output, debug mode, failed commands, and third-party actions. Secrets often leak through indirect output rather than explicit echo statements.
• Overbroad CI permissions: Review default tokens, repository write access, cloud roles, and artifact permissions. Least privilege is rarely the default.
• Policy gate bypasses: Make sure administrators, maintainers, or emergency workflows cannot silently skip controls without a traceable exception path.
• Untrusted code execution: Fork-based contributions, external actions, custom scripts, and dynamic downloads all deserve extra scrutiny.
• Artifact integrity between stages: Confirm that the artifact tested is the same artifact promoted.
• Environment drift: If staging and production differ too much, passing checks in one environment may not reflect risk in the other.
• Data sensitivity: Pipelines that touch regulated or customer-sensitive data need stronger separation than general internal tooling.

It also helps to keep small validation tools close to the workflow. Teams often waste time debugging malformed JSON policy files, invalid regex patterns, or broken payload formatting during security automation. These references can speed up that work:

• JSON Formatter and Validator Guide: Fixing Common Parse Errors Fast
• Regex Tester Guide: Common Patterns Developers Reuse and How to Validate Them

Common mistakes

The most common pipeline security problems are usually process problems wearing a tooling disguise.

• Blocking everything from day one: If every check fails constantly, teams learn to ignore the system. Start with high-signal controls and tighten over time.
• Treating secrets scanning as a one-time setup: New repositories, new runners, and new workflow patterns can reopen old risks.
• Using shared admin credentials for convenience: This makes incidents harder to contain and audit.
• Storing exceptions outside version control: If waivers live in tickets, chat messages, or memory, they become invisible operational debt.
• Ignoring pipeline code ownership: CI definitions, reusable workflows, and deployment scripts should have clear maintainers.
• Separating security from delivery reality: Controls that do not match the release model often get bypassed during urgent changes.
• Confusing alert volume with coverage: More findings do not automatically mean better protection.
• Failing to retire old tooling: Legacy scanners, duplicate gates, and abandoned runners create blind spots as often as they prevent them.

If your team operates Kubernetes in production, avoid treating cluster security and pipeline security as separate topics. They are linked through manifests, secrets, ingress, and rollout design. Cost and security also interact more than teams expect, especially when sprawl leads to unmanaged environments. For a broader operational review, see Kubernetes Cost Optimization Checklist for Teams Running Production Clusters.

When to revisit

Return to this checklist whenever your delivery context changes. A pipeline that was acceptable six months ago may now have different trust boundaries, dependencies, or deployment risks.

Revisit your controls when:

• You add a new CI/CD platform, runner type, or reusable workflow system.
• You introduce a new cloud account, cluster, region, or production environment.
• You move from manual to automated deployments, or from simple releases to canary or blue-green strategies.
• You change how secrets are issued, stored, or rotated.
• You adopt new package ecosystems, base images, or artifact repositories.
• You onboard external contributors, contractors, or new internal teams to shared pipelines.
• You respond to an incident, audit finding, or near miss.
• You enter a planning cycle and need to prioritize platform hardening work.

For a practical quarterly review, use this short action list:

1. Pick one critical service and map its full path from commit to production.
2. List every secret, token, role, approval, scanner, and policy gate involved.
3. Identify one place where trust is broader than necessary.
4. Identify one control that is noisy and one control that is missing.
5. Document one exception that should expire or be replaced with automation.
6. Test one rollback or failed-deployment scenario.
7. Assign owners and due dates for the top three improvements.

The best ci cd security best practices are the ones your team can maintain under normal delivery pressure. Keep the checklist visible, update it when workflows change, and treat the pipeline itself as a product that deserves versioned controls, regular review, and clear ownership.