The pull request is your last automated checkpoint before code ships. A SQL injection caught at PR time takes 10 minutes to fix. The same bug caught in production takes weeks, a public disclosure, and significant user trust. Adding automated security scanning to your GitHub Actions pipeline is free, takes less than five minutes to set up, and catches the vulnerabilities that code review routinely misses.
This guide covers how to set up end-to-end security scanning in GitHub Actions, with PR comments, SARIF upload to GitHub's Security tab, and a configurable fail threshold using entirely free tools, including the SecurePilot GitHub Action, which we built specifically to catch the vulnerabilities AI coding assistants introduce.
🛡️ The SecurePilot GitHub Action does exactly this, free
The SecurePilot GitHub Action runs all 165+ security rules on every pull request, posts a score and top findings directly in the PR comment, and uploads results to GitHub's Security tab via SARIF. SQL injection, hardcoded secrets, SSRF, and missing auth are all caught automatically before merge. 5 lines of YAML. No account. No cost.
Why Security Scanning in CI/CD Matters
Most security bugs are caught by the person who wrote them. That only happens, however, if they are given immediate feedback. A GitHub analysis of code review patterns shows that developers fix issues far more reliably when the feedback appears directly on their pull request, visible before merge, rather than in a separate security dashboard reviewed later by a different team.
With AI-generated code now making up a significant portion of what developers ship, automated scanning has become more critical. AI assistants generate functional code quickly but consistently miss security concerns. They have no awareness of your deployment context, user trust levels, or data sensitivity.
A scanner running on every PR bridges this gap: it reviews code the way a security engineer would, without the bottleneck of manual review.
What to Scan For
According to the Aikido top SAST tools roundup, effective CI/CD security coverage requires three layers:
- SAST (Static Application Security Testing): scans source code for vulnerability patterns: SQL injection, hardcoded secrets, missing auth checks, SSRF, XSS, and LLM-specific risks like prompt injection
- Secret scanning: detects API keys, tokens, and credentials committed to the repository
- Dependency scanning (SCA): flags known CVEs in third-party packages before they are merged
For AI-generated code specifically, SAST is the highest-value layer. It catches the structural vulnerabilities (injection, access control gaps, insecure configurations) that LLMs introduce at generation time. SecurePilot covers this layer with 165+ rules, including 21 AI/LLM-specific checks that generic scanners don't have: prompt injection vectors, unsafe eval() on LLM output, and insecure model configurations.
The 5-Minute Setup with SecurePilot
The SecurePilot GitHub Action runs a 165+ rule security scan on every pull request, posts a score and top findings directly in the PR comment, and uploads results to GitHub's native Security tab via SARIF. No sign-up, no API key, no configuration required.
Create .github/workflows/security.yml in your repository:
name: Security Scan
on:
push:
branches: [main]
pull_request:
jobs:
scan:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write # post PR comments
security-events: write # upload SARIF to Security tab
steps:
- uses: actions/checkout@v4
- name: SecurePilot Security Scan
uses: Securepilot/securepilot-action@v1
with:
fail-on-severity: 'high' # block merges with high/critical findings
- name: Upload to GitHub Code Scanning
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: securepilot-results.sarifThat is the full setup. Push this file to your repository and every future pull request will automatically receive a security review.
What the Output Looks Like
After each PR scan, the action posts a comment directly on the pull request, visible to the author and every reviewer:
🛡️ SecurePilot Security Scan Score: 64/100 🟠 Needs Work, 12 files scanned | Severity | Count | |----------|-------| | 🔴 Critical | 2 | | 🟠 High | 4 | | 🟡 Medium | 3 | Top findings: 1. 🔴 Hardcoded AWS Access Key, src/config.ts (line 12) · CWE-798 2. 🔴 SQL Injection via string concat, src/db/users.ts (line 89) · CWE-89 3. 🟠 JWT signed with weak secret, src/auth.ts (line 103) · CWE-327
The SARIF upload shows findings inline in the “Files Changed” tab with line-level annotations, and all results appear in the repository's Security tab for tracking over time.
Adding GitHub Native Secret Scanning
GitHub's built-in secret scanning is free for public repositories and catches over 200 token types including AWS keys, GitHub tokens, Stripe keys, and Slack tokens. Enable it in your repository settings:
# Enable via GitHub CLI: gh secret scanning enable --repo OWNER/REPO # Or: Settings → Code security and analysis → Secret scanning → Enable # Push protection blocks commits containing detected secrets before they reach the repo
Rolling Out fail-on-severity Gradually
If your codebase has existing security debt, failing every PR immediately will create friction. The recommended approach (used by security-forward engineering teams ) is a three-stage rollout:
# Stage 1: Informational only. Never block PRs.
# Add this first; let the team see findings without friction
- uses: Securepilot/securepilot-action@v1
with:
fail-on-severity: 'none'
# Stage 2: Block on critical only. Address the worst issues.
- uses: Securepilot/securepilot-action@v1
with:
fail-on-severity: 'critical'
# Stage 3: Block on high or worse. Maintain a secure baseline.
- uses: Securepilot/securepilot-action@v1
with:
fail-on-severity: 'high'Start at stage 1 for two weeks. Review the findings, fix the critical ones, then move to stage 2. Most teams reach stage 3 within a month. The findings are visible in all three stages. Only the blocking behaviour changes.
Adding Dependency Scanning
For dependency CVEs, enable GitHub Dependabot in your repository settings. Dependabot automatically opens pull requests to update vulnerable dependencies and can be configured to auto-merge patch-level updates:
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: 'npm'
directory: '/'
schedule:
interval: 'weekly'
open-pull-requests-limit: 10The Complete Security Workflow
Combining SAST, secret scanning, and dependency scanning gives you defence-in-depth on every pull request:
- SecurePilot Action: 165+ SAST rules including AI/LLM-specific checks
- SARIF upload: findings visible inline in Files Changed and in the Security tab
- GitHub secret scanning: blocks commits containing API keys and tokens
- Dependabot: weekly PR to update vulnerable dependencies
Each layer costs nothing to add and runs automatically. The DEV Community roundup of AI code review tools for 2026 covers additional options if you want to extend coverage further.