How to Add Security Scanning to GitHub Actions — Complete Setup Guide

A pull request can pass tests and still ship a vulnerable package, leaked API key, or unsafe code pattern. CI/CD should not only ask, “Does this build work?” It should also ask, “Is this build safe enough to merge?”

That is why security scanning GitHub Actions belongs in every serious development workflow. GitHub Actions already runs your tests, builds, deployments, and release jobs. Adding dependency vulnerability scanning, secret scanning, and code scanning gives developers security feedback before risky changes reach production.

What to Scan in CI/CD and When

CI/CD security scanning means running automated security checks inside your build pipeline. The goal is not to block every pull request with noisy alerts. The goal is to catch serious risks early, give developers useful results, and create a repeatable process for security review.

Most teams should start with three scan types. First, run Software Composition Analysis, or SCA, to detect vulnerable open source dependencies. Second, run secret scanning to catch accidentally committed API keys, tokens, private keys, cloud credentials, database passwords, and webhook secrets. Third, add Static Application Security Testing, or SAST, to detect risky code patterns.

Tip: Start with dependency and secret scanning first. They usually produce clearer results and faster fixes than broad, noisy security gates.

Dependency Vulnerability Scanning

Dependency vulnerability scanning checks whether your application uses packages with known vulnerabilities. In GitHub Actions, this usually means scanning files such as package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, or an SBOM.

The most useful dependency scans identify the vulnerable package, show the affected version, and provide a fixed version. A weak scan only says “critical vulnerability found.” A strong scan tells the developer what to update and why.

Option 1 — Built-In Package Manager Audits

Package manager audits are the fastest starting point. npm, Composer, pip-based tools, Maven plugins, and Go tools can detect known issues in their own ecosystems.

name: npm Security Audit

on:
  pull_request:
  push:
    branches: [main]

jobs:
  npm-audit:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Run npm audit
        run: npm audit --audit-level=critical

This workflow fails the job only when npm finds vulnerabilities at the critical level or above. The limitation is coverage: npm audit only handles npm packages and does not scan Python, Java, PHP, Go, Ruby, Rust, or .NET dependencies.

Option 2 — OWASP Dependency-Check Action

OWASP Dependency-Check is a Software Composition Analysis tool that detects publicly disclosed vulnerabilities in project dependencies. It is useful for teams that want general dependency scanning in GitHub Actions and downloadable reports.

name: OWASP Dependency-Check

on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'

jobs:
  dependency-check:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Run Dependency-Check
        uses: dependency-check/Dependency-Check_Action@main
        with:
          project: 'my-application'
          path: '.'
          format: 'HTML'
          out: 'reports'
          args: >
            --failOnCVSS 8

      - name: Upload Dependency-Check report
        uses: actions/upload-artifact@v4
        with:
          name: dependency-check-report
          path: reports

The --failOnCVSS 8 setting tells the job to fail when findings meet or exceed the chosen CVSS threshold. Many teams start with 9 or 10, then lower the threshold after they clean up the backlog.

Warning: Do not fail every build on every vulnerability at the beginning. Start with critical issues, fix the backlog, then tighten the policy.

Option 3 — Trivy Recommended for Most Teams

Trivy is a practical scanner for repositories because it can scan filesystem content and produce SARIF output for GitHub code scanning. It can detect vulnerabilities across multiple ecosystems and fits well into CI/CD.

name: Trivy Dependency Scan

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read
  security-events: write

jobs:
  trivy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Run Trivy filesystem scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          scan-ref: .
          format: sarif
          output: trivy-results.sarif
          severity: CRITICAL,HIGH

      - name: Upload Trivy SARIF report
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

This setup uploads findings to the GitHub Security tab as code scanning alerts. To fail the build on high or critical findings, add exit-code: '1'.

- name: Run Trivy and fail on critical/high
  uses: aquasecurity/trivy-action@master
  with:
    scan-type: fs
    scan-ref: .
    severity: CRITICAL,HIGH
    exit-code: '1'
    ignore-unfixed: true

Option 4 — Language-Specific Scanners

Language-specific scanners often produce more precise results for their ecosystems. For Go, govulncheck analyzes Go modules and code usage. For Python, pip-audit is a common option. For PHP, composer audit can detect known vulnerable packages.

name: Go Vulnerability Scan

on:
  pull_request:
  push:
    branches: [main]

jobs:
  govulncheck:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.22'

      - name: Install govulncheck
        run: go install golang.org/x/vuln/cmd/govulncheck@latest

      - name: Run govulncheck
        run: govulncheck ./...

name: Python Dependency Scan

on:
  pull_request:

jobs:
  pip-audit:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install pip-audit
        run: python -m pip install pip-audit

      - name: Run pip-audit
        run: pip-audit -r requirements.txt

Failing Builds Intelligently — Severity Thresholds

Severity thresholds decide when a scan should fail the build. This is one of the most important parts of security scanning GitHub Actions. If the threshold is too strict on day one, developers may see the scanner as noise. If the threshold is too weak, serious vulnerabilities pass through CI.

Secrets Scanning With gitleaks

Secret scanning detects credentials committed to the repository. This includes cloud keys, API tokens, GitHub tokens, database passwords, private keys, Slack webhooks, and other sensitive values.

name: Secret Scan

on:
  pull_request:
  push:
    branches: [main]

jobs:
  gitleaks:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

If the scanner finds a real secret, rotate the secret immediately. Deleting it from the latest commit is not enough because it may still exist in Git history.

Uploading Results to GitHub Security Tab SARIF

SARIF, the Static Analysis Results Interchange Format, is a standard format for security scan results. GitHub can display SARIF results in the Security tab as code scanning alerts.

permissions:
  contents: read
  security-events: write

steps:
  - name: Upload SARIF
    uses: github/codeql-action/upload-sarif@v3
    with:
      sarif_file: results.sarif

The security-events: write permission is required so the workflow can upload code scanning results.

Scheduling Nightly Security Scans

Pull request scans catch new changes, but they do not catch every newly disclosed CVE. A package that was safe yesterday can become vulnerable tomorrow when a new advisory is published.

on:
  schedule:
    - cron: '0 2 * * *'
  workflow_dispatch:

The workflow_dispatch trigger lets your team run the scan manually from GitHub when a major CVE is disclosed.

A Complete Production-Ready Security Workflow

The following workflow combines dependency scanning, SARIF upload, secret scanning, severity enforcement, nightly scheduling, and manual runs.

name: Security Scanning

on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'
  workflow_dispatch:

permissions:
  contents: read
  security-events: write

jobs:
  dependency-scan:
    name: Dependency Vulnerability Scan
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Run Trivy filesystem scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          scan-ref: .
          format: sarif
          output: trivy-results.sarif
          severity: CRITICAL,HIGH
          ignore-unfixed: true

      - name: Upload Trivy SARIF
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: trivy-results.sarif

      - name: Enforce critical/high vulnerability policy
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          scan-ref: .
          severity: CRITICAL,HIGH
          exit-code: '1'
          ignore-unfixed: true

  secret-scan:
    name: Secret Scan
    runs-on: ubuntu-latest

    steps:
      - name: Checkout full history
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  npm-audit:
    name: npm Audit
    runs-on: ubuntu-latest
    if: hashFiles('package-lock.json') != ''

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Run npm audit
        run: npm audit --audit-level=critical

Where Vulert Fits Beyond CI/CD

CI scans run when workflows run. But new CVEs are disclosed between commits, between pull requests, and outside release windows. That is why continuous monitoring still matters after you add security scanning GitHub Actions.

Vulert monitors open source dependencies by analyzing manifest files and SBOMs against a database of 458,000+ known CVEs. It supports files such as package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SPDX/CycloneDX SBOMs.

When Vulert detects a CVE affecting your packages, it alerts your team within hours of disclosure and provides fix guidance, exact fixed versions, and exact CLI commands where available. That complements CI/CD because your team can detect dependency risk even when no one has pushed code.

Key Takeaways

• GitHub Actions is a practical place to run dependency scanning, secret scanning, and SAST checks.
• Start with dependency vulnerability scanning because vulnerable packages are common and usually fixable with version upgrades.
• Use severity thresholds so critical issues fail builds while lower-risk findings become tickets.
• Upload SARIF results to GitHub Security tab to make findings easier to review and track.
• Run scheduled nightly scans because new CVEs can affect existing dependencies even when code does not change.
• Security scanning GitHub Actions works best when paired with continuous monitoring between CI runs.

Frequently Asked Questions

1. Should security scans block pull request merges?

Yes, but only for high-confidence and high-impact findings. Start by blocking critical vulnerabilities and verified secrets. Use warnings or tickets for lower-severity findings until your backlog is under control.

2. What severity level should fail a GitHub Actions build?

A practical starting point is critical severity for dependency scans and verified secrets for secret scans. Mature teams often fail builds for high and critical vulnerabilities in production dependencies, especially when the affected component is internet-facing.

3. Is Trivy enough for all dependency scanning?

Trivy is a strong general-purpose option, but many teams still combine it with package-manager audits, language-specific scanners, and continuous monitoring. The best setup depends on your languages, risk tolerance, and reporting needs.