GitHub Action for CI/CD Pentesting

Why CI/CD Security Testing Matters

Traditional penetration testing happens periodically — quarterly, annually, or before a major release. But modern development teams push code to production multiple times per day. A vulnerability introduced on Monday morning could be exploited long before a quarterly pentest discovers it.

CI/CD-integrated pentesting closes this gap. By triggering a pentest on every deployment (or every merge to a protected branch), you ensure that no code reaches production without a security assessment.

The TurboPentest GitHub Action

TurboPentest provides an official GitHub Action (turbopentest/action) that can be added to any GitHub Actions workflow. It authenticates with your TurboPentest account, launches a pentest against the specified target, waits for results, and optionally gates the deployment based on severity thresholds.

Basic Workflow Configuration

A minimal workflow file (.github/workflows/pentest.yml) looks like this:

name: Security Pentest
on:
  push:
    branches: [main]
  deployment_status:

jobs:
  pentest:
    runs-on: ubuntu-latest
    if: github.event.deployment_status.state == 'success' || github.event_name == 'push'
    steps:
      - name: Run TurboPentest
        uses: turbopentest/action@v1
        with:
          api-key: ${{ secrets.TURBOPENTEST_API_KEY }}
          target: "https://staging.example.com"
          tier: "standard"
          wait: true
          fail-on: "high"

Configuration Parameters

The action accepts the following inputs:

api-key (required): Your TurboPentest API key, stored as a GitHub secret
target (required): The URL to pentest. This should point to a staging or preview environment, never production during active user traffic
tier (required): The pentest tier — recon, standard, deep, or blitz
wait (optional, default true): Whether the action should wait for the pentest to complete before continuing
fail-on (optional): The minimum severity that causes the workflow to fail — critical, high, medium, or low
timeout (optional, default 3600): Maximum seconds to wait for the pentest to complete
source-path (optional): Path to source code for static analysis (enables Semgrep, Trivy, and Gitleaks in Phase 1)

Triggering on Deployment

The most effective pattern triggers the pentest after a successful deployment to a staging environment. This way, the pentest runs against the actual deployed application (not just the code), and deployment failures do not waste pentest credits.

on:
  deployment_status:

jobs:
  pentest:
    if: github.event.deployment_status.state == 'success'

For preview environments (Vercel, Netlify, etc.), the deployment URL is available as github.event.deployment_status.target_url:

with:
  target: ${{ github.event.deployment_status.target_url }}

Gating Deployments

The fail-on parameter controls whether the workflow step passes or fails based on findings. Setting fail-on: high means the step fails if any high or critical severity findings are discovered. This can be used to gate promotion from staging to production:

- name: Run TurboPentest
  uses: turbopentest/action@v1
  with:
    api-key: ${{ secrets.TURBOPENTEST_API_KEY }}
    target: ${{ env.STAGING_URL }}
    tier: "standard"
    fail-on: "high"

- name: Promote to Production
  if: success()
  run: ./deploy-production.sh

If any high or critical vulnerabilities are found, the promotion step is skipped and the pipeline fails. The pentest report URL is printed in the action output for immediate review.

Action Outputs

The action provides several outputs for use in subsequent steps:

report-url: Direct link to the pentest report in TurboPentest
findings-count: Total number of findings
critical-count, high-count, medium-count, low-count: Counts by severity
pentest-id: The unique identifier for referencing via API

Best Practices

Use staging environments. Never pentest production during peak traffic. The action works best against staging or preview deployments that mirror production configuration.

Store API keys as secrets. Never hardcode your TurboPentest API key in the workflow file. Use GitHub's encrypted secrets feature.

Choose the right tier. Use recon for every PR for fast feedback. Use standard or deep for merges to main. Reserve blitz for release candidates.

Set appropriate thresholds. Start with fail-on: critical and tighten to fail-on: high as your team remediates existing findings.

Combine with source analysis. Pass source-path: "." to enable static analysis tools alongside the dynamic pentest, giving you both runtime and code-level coverage.

GitHub Action for CI/CD Pentesting

On this page