DevSecOps Pipeline Checklist: Security Controls for Every CI/CD Stage

Overview

DevSecOps means treating security as part of software delivery, not as a separate activity that begins after code is ready to ship. The goal is not to make every developer investigate every possible threat. It is to automate proportionate checks, make ownership clear, and create useful feedback before a defect or exposure reaches production.

A CI/CD security checklist should cover four questions at each stage:

• What can go wrong here? Identify threats such as leaked credentials, vulnerable dependencies, tampered artifacts, unsafe infrastructure changes, or unauthorized deployments.
• What can be checked automatically? Use CI/CD tools to validate code, configuration, dependencies, identities, artifacts, and deployment conditions.
• What requires human judgment? Reserve manual review for high-risk changes, exceptions, architectural decisions, and unusual production behavior.
• What evidence is retained? Record the result, owner, timestamp, commit or artifact reference, and decision for controls that matter to operations or compliance.

Controls should be matched to the application's data, exposure, change rate, and operational impact. A small internal service and a public system handling sensitive information may need different gates. Start with controls that address the highest consequences and the most likely failure modes, then expand as the pipeline matures.

For a broader view of workflow design, see the CI/CD Pipeline Design Guide. It provides useful context for separating build, test, release, and deployment responsibilities.

Checklist by scenario

1. Source control and pull requests

The repository is the first security boundary. Apply these checks before code enters the default branch:

• Require authenticated access and use the minimum repository permissions needed for each person, bot, and integration.
• Protect important branches with pull-request review, status checks, and restrictions on direct pushes.
• Require reviews from appropriate code owners for security-sensitive paths such as authentication, authorization, payment logic, deployment files, and identity configuration.
• Scan commits and pull requests for secrets, private keys, tokens, connection strings, and other credentials.
• Confirm that generated files, build scripts, workflow definitions, and dependency manifests receive the same review attention as application code.
• Record exceptions to branch protection and review rules, including who approved them and when they expire.

A secret scan is not a substitute for revocation. If a credential is exposed, treat it as compromised, rotate it through the appropriate process, and investigate where it may have been copied.

2. Dependencies and build inputs

Modern builds depend on packages, container images, plugins, compilers, actions, and external services. Make those inputs visible and controllable:

• Maintain lockfiles or equivalent version controls where the ecosystem supports them.
• Scan direct and transitive dependencies for known vulnerabilities and review whether a finding affects the code's actual use.
• Track abandoned, unmaintained, or unexpected packages as separate review concerns rather than relying only on severity scores.
• Pin critical build actions, plugins, and reusable workflow components to reviewed versions or immutable references where practical.
• Use isolated, reproducible build environments and restrict network access when a build does not need it.
• Keep a software bill of materials or another dependency inventory when it supports incident response and release decisions.

Automated findings need an owner and a response path. Define when a build fails, when a finding creates a review task, and how a documented exception is approved.

3. Static analysis, tests, and application security

Static application security testing, secure coding checks, unit tests, integration tests, and specialized analysis should be combined rather than treated as interchangeable. Check that:

• Static analysis runs on changed code and produces results that developers can locate and understand.
• Tests cover authentication, authorization, input validation, error handling, and security-critical business rules.
• High-impact findings are blocked or routed to an explicit approval process before release.
• False positives and accepted risks include a rationale, owner, scope, and review date.
• Test data does not contain production secrets or unnecessary personal and sensitive information.

4. Containers and infrastructure as code

Container and infrastructure definitions can introduce risk even when application code passes its tests. Before packaging or applying changes:

• Use minimal base images and remove unnecessary tools, packages, users, and files from runtime images.
• Scan images for vulnerable operating-system packages, application dependencies, exposed secrets, unsafe permissions, and configuration problems.
• Run services as non-root where possible and define explicit user, network, filesystem, and capability settings.
• Validate Kubernetes manifests, admission policies, and deployment configuration before rollout. The Kubernetes Deployment Checklist can be used alongside this stage.
• Scan infrastructure as code for public exposure, excessive permissions, insecure defaults, and drift from approved patterns.
• Require review for changes involving networks, identity, encryption, storage, firewall rules, or production accounts.

Teams using Terraform should connect security checks to the plan-and-apply workflow, not only to the application repository. See Terraform Best Practices for Scalable Cloud Infrastructure for related planning and review guidance.

5. Artifacts, release integrity, and deployment approvals

A successful build is not enough. The release process should establish that the artifact being deployed is the artifact that was reviewed:

• Store build outputs in a controlled registry with appropriate access permissions and retention rules.
• Generate checksums or signatures for release artifacts where verification is supported by the platform and operational model.
• Record the source commit, build definition, dependencies, test results, and producing pipeline for each release.
• Prevent deployment jobs from silently rebuilding code after approval.
• Use environment-specific permissions and separate credentials for development, staging, and production.
• Require an explicit approval or policy decision for high-risk production changes, including emergency releases.

Deployment approval should be meaningful. If the approver cannot see the change, test results, security findings, and rollback plan, the approval is likely to become a routine click.

6. Runtime verification and response

Security controls continue after deployment. Add checks that confirm the running service matches its intended state:

• Verify that the deployed image, configuration, and infrastructure version match the approved release.
• Monitor authentication failures, privilege changes, unusual administrative activity, exposed endpoints, and unexpected network behavior.
• Check health signals after deployment and define rollback or pause conditions before the release begins.
• Ensure logs are protected from unauthorized access and do not disclose credentials or unnecessary sensitive data.
• Test that alerts reach an accountable team and include enough context to support investigation.
• Maintain a documented process for credential rotation, vulnerable dependency response, compromised artifacts, and unauthorized changes.

Runtime controls should connect to incident response. The SRE Alert Fatigue Checklist offers a useful reminder to review alert quality as well as alert coverage.

What to double-check

Before calling a DevSecOps pipeline complete, review the boundaries between tools and teams. Security gaps often appear where one stage assumes another stage has performed a check.

• Secrets: Are secrets excluded from source, build logs, container layers, artifacts, and chat-based troubleshooting? Are they injected only where needed?
• Identity: Does each pipeline job have a narrowly scoped identity, or can one compromised job access unrelated environments?
• Permissions: Can a pull request modify the workflow that validates it? If so, is that change subject to a trusted review path?
• Exceptions: Are waivers time-limited and visible, or do they become permanent bypasses?
• Traceability: Can an operator connect a production deployment to a commit, reviewer, test result, artifact, and deployment identity?
• Failure behavior: Does a failed security check stop the release, create a ticket, or merely produce a warning? Is that behavior intentional?
• Recovery: Can the team revoke credentials, block a compromised artifact, roll back safely, and preserve investigation evidence?

Use a simple control register to capture the check, purpose, owner, tool or system, blocking behavior, evidence location, and review date. This makes the checklist maintainable when the pipeline changes.

Common mistakes

• Adding every scanner without an operating model: More findings do not automatically create more security. Assign ownership, severity guidance, and response targets before expanding coverage.
• Blocking on unreviewed severity alone: A severity score is an input to triage, not a complete risk decision. Consider exploitability, exposure, reachability, compensating controls, and business impact.
• Scanning only application code: Workflow files, infrastructure code, images, dependencies, deployment permissions, and build services can all affect the final system.
• Trusting the pipeline's default permissions: Review token scopes, cloud roles, runner access, registry permissions, and environment protections explicitly.
• Treating compliance evidence as an afterthought: If evidence is collected manually at the end of a release cycle, it may be incomplete or difficult to verify. Capture it as part of normal pipeline execution.
• Making exceptions permanent: Every bypass should have a reason, owner, compensating control, and expiry or reapproval date.
• Ignoring developer experience: Slow, noisy, or unclear controls encourage workarounds. Place fast feedback early and reserve slower, deeper checks for appropriate stages.

When to revisit

Review this checklist before seasonal planning cycles, major architecture changes, and any migration to a new CI/CD platform, cloud account, registry, runner model, or deployment strategy. Revisit it immediately after a security incident, a significant supply-chain alert, a credential exposure, or a production change that bypassed the normal path.

Also schedule a periodic review of findings and exceptions. Ask which checks are producing actionable results, which controls are routinely bypassed, whether permissions still match responsibilities, and whether the evidence would explain a release to someone who was not involved in creating it.

To make the review practical, create a short control inventory and complete these actions:

1. Map each pipeline stage from commit to runtime.
2. Assign one owner for every security control and one backup owner.
3. Mark controls as blocking, advisory, or manual, and document why.
4. Test one failure path, such as a leaked secret, vulnerable dependency, unsigned artifact, or unauthorized deployment.
5. Record the result, fix gaps with the highest risk first, and set the next review date.

Tools will change, but the underlying questions remain stable: what is being changed, who is allowed to change it, how is it checked, what reaches production, and how can the team prove and reverse the decision? Keeping those questions visible is the durable foundation of a secure CI/CD pipeline.