The CI/CD Security Scanning Checklist for GitHub Actions and Similar Pipelines

Overview

CI/CD security scanning is most useful when it is treated as a set of connected controls rather than a single tool. A pipeline may build an application, package it into a container, deploy infrastructure, and expose APIs—all of which create different security testing requirements.

The goal is not to make every scan block every deployment. The goal is to find meaningful risk early, route findings to the people who can fix them, and preserve enough context to support a consistent decision. A practical DevSecOps security scanning program usually combines several methods:

• Secrets scanning to identify credentials, tokens, private keys, and other sensitive values in repositories or build output.
• Software composition analysis to identify vulnerable or noncompliant open-source dependencies.
• Static application security testing to inspect source code, configuration, and data-flow patterns.
• Container security scanning to examine images, packages, Dockerfiles, and related build configuration.
• Infrastructure and cloud security scanning to review infrastructure-as-code and deployment settings before they reach an environment.
• Dynamic application and API testing to test a running service for weaknesses that static analysis may not reveal.

For a deeper explanation of how these methods fit together, see SAST vs DAST vs SCA: Which Security Scanning Method Does Your Team Need?. The checklist below focuses on implementation: what to scan, where to place each control, and how to make results actionable.

Checklist by scenario

Before code is merged

• Enable secrets scanning on pull requests and repository history where practical.
• Define which findings should block a merge, such as a verified credential or a high-confidence, exploitable issue.
• Run SAST against changed code to provide fast feedback to developers.
• Run SCA against direct and transitive dependencies, and record the manifest or lockfile used for the result.
• Make findings link back to the pull request, commit, file, dependency, or line of code that created them.
• Document an exception path for findings that require investigation rather than immediate remediation.

Fast checks belong close to the developer workflow. They should produce concise explanations, suggested remediation, and enough detail to distinguish a real issue from a likely false positive. Teams comparing developer security scanning tools should test this experience with representative repositories rather than relying only on feature lists.

When building an application or service

• Scan application source code and security-sensitive configuration as part of the build.
• Check dependency versions after installation, not only the top-level manifest.
• Verify that test data, build logs, and generated artifacts do not contain secrets.
• Record the application version, commit identifier, branch, and environment associated with each scan.
• Use a DAST scanner against a deployed test environment when the application is available.
• Provide test credentials or an approved authentication flow when important routes require login.

Dynamic scanning needs a representative target. If authentication, MFA, SSO, or role-based access affects coverage, define the permitted test accounts and routes before adding the scan to the pipeline. The guide to DAST authentication strategies covers the planning questions that commonly determine whether an automated web application scan reaches meaningful functionality.

When building APIs

• Identify every API specification, base URL, version, and authentication method used by the service.
• Scan documented endpoints and compare the specification with routes actually exposed by the application.
• Test authorization boundaries with approved accounts representing relevant roles.
• Include validation for common input, authentication, session, and error-handling weaknesses.
• Keep destructive operations isolated from production data during automated API security scanning.
• Store the specification and scan configuration with the build or release record.

An API scan that tests only unauthenticated health endpoints can appear successful while providing little coverage. Treat endpoint inventory, authentication, role coverage, and safe test data as part of the control—not as optional setup.

When building container images

• Scan the image after it is built and before it is pushed or deployed.
• Scan the Dockerfile and related build files for unsafe defaults and unnecessary privileges.
• Track the base image, operating-system packages, application dependencies, and image digest.
• Set a policy for unpatched or end-of-life components, while allowing documented review for issues that do not affect the runtime.
• Check that secrets are not copied into image layers, build arguments, or artifacts.
• Rescan promoted images when the release process changes their contents or configuration.

Container security scanning should help the team reduce unnecessary attack surface, not merely generate a long package list. Prioritize findings according to the image’s runtime exposure, exploitability, fix availability, and role in the deployed service.

When provisioning cloud infrastructure

• Scan infrastructure-as-code before it is applied.
• Review identity permissions, network exposure, encryption settings, logging, and public access controls.
• Separate checks for reusable modules from checks for environment-specific values.
• Prevent secrets from entering infrastructure files, state, variables, or pipeline logs.
• Use drift or environment checks where the deployed configuration can diverge from reviewed code.
• Record the cloud account, project, subscription, region, and deployment identifier associated with each result.

Cloud security scanning works best when it evaluates both the intended configuration and the deployed state. A clean infrastructure pull request does not necessarily prove that an existing environment matches that code.

Before deployment and after release

• Define release gates for findings that represent unacceptable risk.
• Ensure the gate receives normalized results from the relevant scanners.
• Run final checks on the exact artifact, image, commit, and configuration intended for release.
• Run scheduled scans against deployed applications, APIs, containers, and cloud assets to catch changes outside the pipeline.
• Notify an accountable owner when a new or reopened finding appears.
• Verify that remediation closes the original finding without creating a duplicate record.

What to double-check

Coverage: List repositories, services, APIs, images, environments, and infrastructure projects in scope. Confirm that every production-facing asset has an owner and an expected scan frequency.

Result quality: Review a sample of findings manually. Check whether the tool identifies the affected asset, explains the risk, shows evidence, and offers a realistic fix. Track false positives separately from accepted risk so that suppression does not hide a recurring problem.

Prioritization: Severity alone is rarely enough to determine urgency. Consider exposure, affected data, exploitability, reachability, asset importance, compensating controls, and whether a fix is available. An AI-assisted risk-based vulnerability triage workflow can help organize this context, but teams should retain human review for consequential decisions.

Failure behavior: Decide what happens when a scanner times out, returns incomplete results, or cannot reach a test environment. A pipeline should distinguish a confirmed vulnerability from a tool failure and from a skipped check.

Evidence: Preserve scan time, tool and rule-set version, target identifier, commit or image digest, result status, reviewer, exception reason, and remediation date. This supports compliance-ready vulnerability management and makes later investigation easier. For a fuller recordkeeping model, see How to Build an Audit Trail for Vulnerability Scanning and Remediation.

Common mistakes

• Blocking everything: If every warning fails the pipeline, teams may disable the control or approve exceptions without review. Start with high-confidence policies and expand them as the workflow matures.
• Scanning only the default branch: Findings discovered after merge are more expensive to understand and fix. Put fast checks on pull requests and broader checks on scheduled or release workflows.
• Ignoring authentication: An unauthenticated DAST or API scan may miss the most important application paths.
• Scanning an artifact different from the deployed one: Build, sign, scan, and promote an identifiable artifact so the result remains tied to what runs.
• Suppressing without an expiration: Every exception should have an owner, reason, scope, compensating control where relevant, and review date.
• Sending findings to a queue without ownership: Assign remediation to a team that controls the code, image, API, or cloud resource.
• Treating compliance as a screenshot: Auditable security operations require repeatable records, decisions, and evidence—not only a scan summary.

When to revisit

Revisit this checklist before seasonal planning cycles, major architecture changes, and changes to the build or deployment workflow. It should also be reviewed when the team adopts a new repository, CI provider, cloud account, container base image, API gateway, authentication method, or security scanner.

Set a recurring review to confirm that scan coverage still matches the asset inventory, gates still reflect current risk tolerance, exceptions have not expired unnoticed, and remediation targets remain practical. Review recent incidents, recurring false positives, missed assets, and findings that stayed open beyond their intended window.

For the next implementation pass, choose one representative service and complete the checklist end to end: inventory its code, dependencies, secrets, API routes, image, cloud resources, deployment artifact, owners, gates, and evidence. Then record the gaps, fix the highest-impact workflow problems, and expand the pattern to other services. This approach makes CI/CD security scanning a maintainable part of delivery rather than a collection of disconnected tools.