CI/CD Security Scanning Checklist for GitHub Actions, GitLab CI, and Jenkins

Overview

If you want automated security scanning to work in a delivery pipeline, the goal is not to scan everything at every step. The goal is to run the right pipeline security checks at the right time, with outputs developers can act on and reviewers can trust.

That usually means combining several scan types:

• SAST for code-level issues during development and pull request review
• SCA for open-source dependency risk, license review, and vulnerable packages
• Secret scanning for hard-coded credentials and tokens
• Container image scanning for base image and package vulnerabilities
• Infrastructure as code scanning for Terraform, Kubernetes manifests, Helm charts, and similar configuration
• DAST or API security scanning for running services in preview, staging, or pre-production

If your team needs a broader comparison of scan categories, see SAST vs DAST vs SCA vs IAST: Which Security Scanning Approach Fits Your SDLC?.

A strong CI/CD security scanning checklist should answer five operational questions:

1. What gets scanned on every commit, pull request, merge, build, and deployment?
2. Which findings are informational, which require triage, and which block release?
3. Who can approve exceptions, and how long do they last?
4. Where are results stored for remediation, trend review, and audits?
5. How will you update controls when tools, workflows, or platforms change?

Use the checklist below as a baseline. Then adjust it based on application criticality, internet exposure, data sensitivity, and the maturity of your remediation workflow.

Checklist by scenario

This section gives you a practical CI/CD security scanning checklist by implementation area. You do not need to adopt every item on day one, but you should be able to explain why each item is in scope, deferred, or intentionally excluded.

1. Baseline controls for any CI/CD platform

• Inventory all repositories, pipeline definitions, shared runners or agents, and deployment environments.
• Document which pipelines handle production-bound code, internal tools, infrastructure, APIs, and containers.
• Standardize scanner configuration through reusable templates, shared actions, library steps, or included pipeline files.
• Pin third-party actions, plugins, and build integrations to reviewed versions or immutable references where possible.
• Restrict who can edit pipeline definitions, shared build libraries, secrets, and deployment credentials.
• Separate test credentials from production credentials and rotate them on a schedule.
• Send scan results to a central system for vulnerability triage automation, ticketing, or dashboard review.
• Define severity thresholds by environment. A pull request gate is not always the same as a release gate.
• Record exceptions with owner, business reason, expiry date, and compensating control.
• Verify that logs do not expose secrets, tokens, or sensitive payloads.

2. Commit and pull request checks

This is where developer-friendly security scanning usually has the highest return. The checks should be fast enough to support flow, but strict enough to catch common issues early.

• Run secret scanning on changed files and commit history where practical.
• Run SAST on pull requests for supported languages, ideally with differential analysis to reduce noise.
• Run SCA on dependency manifest changes and lockfile updates.
• Scan infrastructure as code files when configuration changes are part of the branch.
• Comment on pull requests with actionable findings, not only links to external dashboards.
• Fail the check only for findings that are both credible and policy-relevant, such as exposed secrets, known exploitable dependency issues, or critical configuration mistakes.
• Suppress duplicates and low-confidence findings so developers are not forced to review the same false positives repeatedly.
• Map findings to owners based on repository, service, or code path.

3. Build-stage checks

The build stage is the right place to validate the exact artifact that may move forward. This matters for container security scanning, compiled packages, generated assets, and provenance-sensitive workflows.

• Scan built artifacts, not just source code.
• Run container image scanning after the final image is assembled, including the base image and installed packages.
• Verify that software bill of materials generation fits your release process if your team needs stronger supply chain visibility.
• Check for unsigned or untrusted dependencies in package resolution workflows if your build system supports that control.
• Enforce minimal required metadata for release candidates, such as versioning, commit references, and traceable build records.
• Store scan output with the build record so investigators can review what was known at release time.

4. Pre-deployment and staging checks

Some vulnerabilities only appear in a running application. That is why an application security scanner or API security scanning step often belongs in staging, preview environments, or temporary review apps.

• Run DAST against reachable web routes and authenticated flows that are safe to test.
• Run API security scanning against documented and discovered endpoints.
• Verify that test accounts and seeded data are isolated from production.
• Scope scans to avoid destructive actions such as deleting records, sending external notifications, or triggering billing logic.
• Test for common misconfigurations: exposed admin paths, weak headers, insecure cookies, verbose error responses, and accidental debug endpoints.
• Review whether rate limits, WAF rules, or bot defenses are masking meaningful results.
• Confirm that authenticated DAST sessions are still valid after login flow changes.

5. Release gates and exception handling

Release gates should protect the business, not create a backlog of ignored alerts. This is where risk-based vulnerability management matters.

• Define release-blocking rules by exploitable risk, not by scanner severity alone.
• Consider exposure, asset criticality, reachable attack path, and whether the vulnerable code is actually deployed.
• Use AI vulnerability prioritization or other triage support carefully to sort findings, but keep final release policy explicit and reviewable.
• Require approval for exceptions from a named role such as engineering manager, product security lead, or service owner.
• Set automatic expiry dates for waivers so accepted risk is revisited.
• Attach evidence to exceptions: ticket link, mitigation, planned fix version, and residual risk note.
• Do not allow blanket permanent suppressions for entire rulesets without periodic review.

6. GitHub Actions checklist

For GitHub Actions vulnerability scanning, the main challenge is consistency across many repositories.

• Use reusable workflows for SAST, SCA, secret scanning, IaC scanning, and container checks.
• Restrict who can modify workflow files in .github/workflows.
• Review permissions for the default GITHUB_TOKEN and reduce them to the minimum needed.
• Prefer pinned third-party actions over floating tags when practical.
• Separate validation workflows for pull requests from deployment workflows that access protected environments.
• Use environment protections and required reviewers for production deployment jobs.
• Publish findings back into pull requests, status checks, or a central vulnerability management system.
• Review self-hosted runner access, network reachability, and secret exposure risks.

7. GitLab CI checklist

For GitLab CI security scanning, the focus is often on template reuse, variable hygiene, and clear stage placement.

• Use included templates or centralized pipeline definitions for standard security jobs.
• Separate build, test, scan, and deploy stages so failure reasons are visible.
• Protect CI variables and scope them by environment or branch where possible.
• Require merge request approvals when scan jobs fail under defined policy.
• Ensure dependency, container, and IaC scan jobs run against the same branch or image version being promoted.
• Review runner trust boundaries, especially if shared runners process sensitive projects.
• Archive scan artifacts for later audit and remediation reference.

8. Jenkins checklist

Jenkins security scanning often requires extra discipline because plugins, agents, and shared libraries can drift over time.

• Inventory all installed plugins and remove anything unused.
• Review plugin update and approval practices on a defined schedule.
• Restrict who can modify shared libraries, credentials, and pipeline jobs.
• Run security scans from centrally maintained pipeline steps where possible.
• Segment build agents by trust level and workload sensitivity.
• Rotate credentials stored in Jenkins and audit who can retrieve them.
• Verify that archived artifacts, logs, and workspaces do not retain sensitive data longer than intended.
• Audit scanner integrations after plugin or controller changes. For a related risk pattern, see Checkmarx Jenkins AST Plugin Compromise: How to Audit Your CI/CD Security Scanner and Prevent Supply Chain Drift.

9. Compliance-ready workflow checklist

If your pipeline supports SOC 2 vulnerability management or similar audit needs, the process around scanning matters almost as much as the scanner itself.

• Keep evidence of scans, findings, approvals, and remediation status.
• Document the policy for severity thresholds, exception handling, and review cadence.
• Show that critical systems are scanned consistently, not only after incidents.
• Link findings to tickets or remediation work items with timestamps.
• Retain proof of closure or accepted risk decisions.
• Review whether pipeline evidence is operationally provable, not just described on paper. A useful related read is When Compliance Looks Legal on Paper but Isn’t Operationally Proved.

What to double-check

These are the areas where teams often believe they have CI/CD security scanning in place, but the actual coverage is weaker than expected.

Are scans attached to the real delivery path?

If engineers can merge, build, or deploy around the scan job, the control is advisory, not enforced. Confirm that required checks are actually required on the repositories and branches that matter.

Are findings deduplicated and prioritized?

Many teams have automated security scanning but weak vulnerability triage automation. If the same dependency issue appears in twenty services, developers should not receive twenty independent, noisy alerts without ownership or grouping.

Do gates reflect exploitability?

A flat “block all high findings” policy often causes friction without improving outcomes. Review whether your gates consider runtime reachability, public exposure, privileged execution paths, and compensating controls.

Are credentials and tokens overexposed in the pipeline?

Your scanner can be strong while the pipeline itself is weak. Recheck secret scope, job permissions, runner isolation, and log retention.

Are dynamic scans still valid after application changes?

Login flows, MFA prompts, feature flags, and route changes can silently break DAST and API security scanning. Revalidate authentication, scan scope, and safe test coverage after each major release.

Are exceptions visible and time-bound?

An exception process is useful. Hidden permanent waivers are not. Make sure every suppression has an owner, reason, and review date.

Common mistakes

The most common CI/CD security scanning failures are process problems, not scanner problems.

• Running every scan on every event. This slows delivery and trains teams to ignore results. Match each scan to the stage where it creates the most value.
• Blocking on noisy rules. False positive reduction in security scanning is not optional if you want developers to trust the pipeline.
• Using severity without context. A critical finding in an unreachable component may deserve triage, while a medium finding in an exposed authentication flow may deserve urgent action.
• Ignoring pipeline infrastructure. CI servers, runners, plugins, build agents, and workflow actions are part of the attack surface.
• Treating compliance evidence as an afterthought. If evidence is scattered across logs, chat threads, and local exports, audit readiness becomes expensive.
• Forgetting APIs and infrastructure changes. Teams often focus on application code while missing Terraform drift, Kubernetes exposure, or undocumented API routes.
• No remediation owner. A finding without a destination team is usually a finding that stays open.

If your environment depends on adjacent systems and shared services, it can also help to think beyond the app itself. Related operational resilience topics are covered in Building a Cloud Outage Readiness Checklist for Identity, Endpoints, and Admin Access and Trust, But Verify: Continuous Validation for AI-Driven Autonomous Networks.

When to revisit

This checklist is most useful when treated as a living control review, not a one-time setup task. Revisit your CI/CD security scanning checklist:

• before seasonal planning cycles and major release trains
• when you add a new language, framework, or package ecosystem
• when your team adopts GitHub Actions, GitLab CI, Jenkins, or a new runner model
• when deployment patterns change, such as moving from VMs to containers or from monolith to microservices
• when login flows, APIs, or staging environments change in ways that may affect DAST or API scan coverage
• when compliance scope expands or new evidence requirements appear
• after a false positive spike, broken gate, missed vulnerability, or major incident review
• after plugin, integration, or shared template changes in the build platform

For a practical next step, schedule a 60-minute quarterly review with engineering, platform, and security leads. Bring one representative repository from each major application type and walk through the same questions every time:

1. What scans run at commit, pull request, build, staging, and release?
2. Which findings blocked delivery in the last quarter, and were those blocks justified?
3. Which alerts were noisy, duplicated, or unactionable?
4. Which exceptions are about to expire?
5. What changed in tooling, architecture, or compliance scope that should change the checklist?

That simple review loop turns a static checklist into an operational control. It also makes your developer security scanning tools more useful because they stay aligned with how software is actually built and shipped.

If you maintain this as a shared standard across GitHub Actions, GitLab CI, and Jenkins, you will usually get better results from fewer, better-placed controls than from adding more scanners without clear policy. The real maturity signal is not how many checks you run. It is whether your pipeline helps teams find exploitable issues early, prioritize fixes intelligently, and keep a reviewable record of what was accepted, remediated, and released.