Secure Deployment Checklist: A Repeatable DevSecOps Workflow for CI/CD Releases

Overview

Deployment security is not one scan or one approval. It is a chain of controls that begins with the change being proposed and continues through production validation. The goal is to make unsafe changes harder to release while keeping legitimate delivery work predictable.

This DevSecOps checklist is designed to be adapted to your repository, pipeline platform, cloud environment, and risk model. Some teams may automate nearly every item; others may require a human review for high-impact changes. The important part is to define the expected evidence and the person or system responsible for each step.

For each release, record the commit or artifact version, the target environment, the checks that ran, exceptions that were accepted, and the person or role that approved the change. That record makes the release easier to troubleshoot and gives the team a clear starting point for later reviews.

Checklist by scenario

For every code change

• Confirm the change scope: Identify the services, configurations, infrastructure resources, data paths, and user permissions affected by the release.
• Review the source: Require peer review for production-bound changes and check that the proposed code matches the stated purpose.
• Run automated tests: Include unit, integration, and relevant end-to-end tests. Treat unexplained failures as release blockers until they are investigated.
• Scan dependencies: Check direct and transitive dependencies for known issues, outdated components, license requirements, and unexpected additions. Define how exceptions are documented and when they expire.
• Check for secrets: Scan commits, generated files, configuration, and build logs for credentials, tokens, private keys, and connection strings. Keep secrets in an approved secret store rather than in source control or images.
• Verify build provenance: Record the source revision and build inputs used to create the deployable artifact. Prevent the pipeline from silently replacing a reviewed artifact with one built from different inputs.

For container and Kubernetes releases

• Inspect the image: Use a trusted base image, remove unnecessary packages, scan the final image, and investigate high-impact findings rather than relying only on the result label.
• Pin important inputs: Use controlled image tags or digests where practical, and review changes to base images, Helm charts, operators, and admission policies.
• Review runtime permissions: Check service accounts, container privileges, writable paths, host access, network policies, and namespace boundaries.
• Validate resource settings: Confirm requests, limits, probes, disruption settings, and replica behavior are appropriate for the workload and environment.
• Prepare for startup failure: Know which logs, events, probes, and rollout commands will be used if a workload enters a restart loop. The Kubernetes CrashLoopBackOff troubleshooting runbook can serve as a companion operational reference.

For infrastructure and configuration changes

• Review the planned change: Inspect the infrastructure plan for unexpected resources, replacements, permission changes, public exposure, data destruction, and changes to network routes.
• Separate environments: Confirm that credentials, state, variables, and approval paths for development, staging, and production are not unintentionally interchangeable.
• Validate configuration: Check required values, secure defaults, encryption settings, allowed origins, logging destinations, retention settings, and resource ownership metadata.
• Protect state and records: Ensure infrastructure state, deployment logs, and audit evidence have controlled access and suitable backup or recovery arrangements.
• Use deliberate scheduling: For recurring jobs, verify timezone, overlap behavior, failure handling, and the intended schedule. A cron expression generator guide can help validate expressions before they enter production configuration.

For high-risk or emergency releases

• Define the risk: State why the release is urgent, what normal control is being shortened, and which compensating checks will still run.
• Limit the blast radius: Prefer a feature flag, canary, maintenance window, restricted audience, or narrowly scoped configuration change when available.
• Assign decision owners: Name the release owner, technical approver, incident contact, and person responsible for monitoring the result.
• Preserve evidence: Capture the change reference, commands or pipeline run, approval, test results, and follow-up actions even when the normal workflow is bypassed.

What to double-check

Before approving the release, check the boundaries between tools and teams. A pipeline may report success while the deployed configuration points to the wrong environment, uses an unintended secret, or sends traffic to a component that was not included in testing.

• Artifact identity: Confirm the artifact promoted to production is the one that passed review and security checks. Avoid rebuilding between environments unless the process records and verifies the resulting differences.
• Secret usage: Verify that secret names, scopes, rotation behavior, and permissions match the target environment. Never print secret values during debugging.
• Access controls: Check who can change pipeline definitions, approve production deployments, alter environment variables, publish packages, and override failed checks.
• Rollback path: Identify the previous known-good version, confirm it is still available, and document how to restore it. For database changes, define whether the change is reversible, forward-fixable, or dependent on a backup restore.
• Observability: Confirm dashboards, logs, alerts, traces, and deployment markers are available before traffic moves. If instrumentation is changing, review the relevant OpenTelemetry implementation guidance.
• Post-deployment tests: Run smoke tests that check the user journey, health endpoints, authentication, critical integrations, and expected background jobs rather than checking only that a process is running.

Use a clear exception record when a check cannot run or a finding is accepted. Include the reason, scope, owner, compensating control, and expiration or review date. An exception without an owner tends to become permanent configuration.

Common mistakes

• Treating scanners as decisions: A scan produces findings; the team still needs to determine exploitability, exposure, remediation, and acceptable risk.
• Scanning only source code: Dependencies, container layers, generated files, infrastructure plans, pipeline actions, and deployment configuration can introduce risk outside the main application code.
• Using mutable labels as release evidence: A tag such as latest does not clearly identify what was tested. Use an immutable version, digest, or recorded build identifier.
• Allowing broad pipeline credentials: Give jobs only the permissions they need for the stage and environment. Review inherited permissions when workflows or reusable actions change.
• Skipping rollback rehearsal: A rollback plan that has never been tested may fail because of schema changes, unavailable artifacts, incompatible configuration, or forgotten dependencies.
• Confusing deployment success with service health: A green pipeline does not prove that users can complete critical actions. Validate the running system after deployment.
• Ignoring failed checks to meet a deadline: If an override is necessary, document it explicitly and create a follow-up task with a responsible owner.

When to revisit

Review this secure deployment checklist before seasonal planning cycles, after a security incident, and whenever the delivery workflow or hosting architecture changes. Revisit it when the team adopts a new CI/CD platform, package registry, cloud account, container base image process, infrastructure tool, secret manager, or deployment strategy.

Also update the checklist after repeated pipeline failures, an unexpected production change, a missed alert, a rollback that exposed a gap, or a new class of dependency and configuration finding. These events show where the written process does not match operational reality.

To keep the checklist useful, assign an owner for each control, link each automated check to its pipeline step, and remove items that no longer apply. At the next release review, ask three practical questions: Which check prevented or detected a real problem? Which check produced noise? Which important decision still depends on memory or manual investigation?

Start with a small, enforceable workflow: verify the artifact, scan dependencies and secrets, inspect infrastructure and permissions, confirm approvals, prepare rollback, and validate the service after deployment. Expand it as your systems and risks change. For troubleshooting pipeline failures during that process, use the CI/CD pipeline debugging guide as a companion reference.