Security Scanning

The eight scan families

Map each family to a pipeline stage. Running everything on every commit creates 45-minute PR feedback loops; running nothing until release ships CVEs. Elite teams use tiered execution: PR = fast + blocking, main = comprehensive + attestations.

flowchart LR
  PR["Pull request"] --> SAST["SAST
Semgrep"]
  PR --> SCA["SCA
lockfile"]
  PR --> SEC["Secret scan
Gitleaks"]
  PR --> IAC["IaC scan
Checkov"]
  MERGE["Merge to main"] --> BUILD["Build image"]
  BUILD --> CS["Container scan
Trivy"]
  CS --> SBOM["SBOM + SARIF"]
  DEPLOY["Deploy staging"] --> DAST["DAST
ZAP baseline"]
  SBOM --> GATE["Policy gate
CRITICAL block"]

name: Security matrix
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
  security-events: write
jobs:
  changes:
    runs-on: ubuntu-latest
    outputs:
      app: ${{ steps.filter.outputs.app }}
    steps:
      - uses: actions/checkout@v4
      - uses: dorny/paths-filter@v3
        id: filter
        with:
          filters: |
            app:
              - 'src/**'
              - 'package*.json'
              - 'Dockerfile'
  sast:
    needs: changes
    if: needs.changes.outputs.app == 'true'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install semgrep
      - run: semgrep scan --config=auto --sarif -o semgrep.sarif
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

stages: [detect, scan, report]

changes:
  stage: detect
  script:
    - apk add --no-cache git
    - |
      if git diff --name-only $CI_MERGE_REQUEST_DIFF_BASE_SHA...$CI_COMMIT_SHA | grep -qE '^(src/|package|Dockerfile)'; then
        echo "APP_CHANGED=true" >> scan.env
      fi
  artifacts:
    reports:
      dotenv: scan.env

sast:
  stage: scan
  needs: [changes]
  rules:
    - if: $APP_CHANGED == "true"
  script:
    - semgrep scan --config=auto --sarif -o gl-sast-report.sarif
  artifacts:
    reports:
      sast: gl-sast-report.sarif

Tooling landscape

What to block vs warn

Pipeline integration

name: SAST
on: [pull_request]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: p/ci
      - run: semgrep scan --config=auto --sarif -o semgrep.sarif
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif
  codeql:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript, python
      - uses: github/codeql-action/analyze@v3

sast-semgrep:
  stage: test
  image: returntocorp/semgrep
  script:
    - semgrep scan --config=auto --sarif -o gl-sast-report.sarif
  artifacts:
    reports:
      sast: gl-sast-report.sarif
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

codeql:
  stage: test
  image: registry.gitlab.com/gitlab-org/security-products/analyzers/codeql:latest
  script:
    - /analyzer run
  artifacts:
    reports:
      sast: gl-sast-report.sarif

Operational checklist

1. Define severity policy document—what CRITICAL means for your org.
2. Run tool in advisory mode for one sprint; export baseline finding count.
3. Enable SARIF upload; wire Slack/PagerDuty on new CRITICAL in main.
4. Review false positive rate monthly; tune rulesets or suppressions with expiry dates.
5. Measure mean time to remediate per category—SAST vs SCA vs container often differ by 10×.

Common failure modes

• Scanning only default branch—feature branches ship vulns via cherry-pick.
• No lockfile—SCA reports stale or empty.
• Ignoring unfixed upstream CVEs without compensating WAF/network controls.
• Developers disable checks locally because PR feedback exceeds 30 minutes.

Tooling landscape

What to block vs warn

Pipeline integration

name: SCA
on: [pull_request]
jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high
  trivy-fs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          scan-ref: .
          format: sarif
          output: trivy-fs.sarif
          severity: CRITICAL,HIGH
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-fs.sarif

dependency-scan:
  stage: test
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy fs --format template --template @/contrib/sarif.tpl
        --output gl-dependency-scanning-report.sarif .
        --severity HIGH,CRITICAL
  artifacts:
    reports:
      dependency_scanning: gl-dependency-scanning-report.sarif
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

renovate:
  stage: maintenance
  script:
    - echo "Renovate bot opens update MRs on schedule — see renovate.json"

Operational checklist

1. Define severity policy document—what CRITICAL means for your org.
2. Run tool in advisory mode for one sprint; export baseline finding count.
3. Enable SARIF upload; wire Slack/PagerDuty on new CRITICAL in main.
4. Review false positive rate monthly; tune rulesets or suppressions with expiry dates.
5. Measure mean time to remediate per category—SAST vs SCA vs container often differ by 10×.

Common failure modes

• Scanning only default branch—feature branches ship vulns via cherry-pick.
• No lockfile—SCA reports stale or empty.
• Ignoring unfixed upstream CVEs without compensating WAF/network controls.
• Developers disable checks locally because PR feedback exceeds 30 minutes.

Tooling landscape

What to block vs warn

Pipeline integration

name: Secret scan
on: [pull_request, push]
jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: TruffleHog verified
        run: |
          docker run --rm -v $PWD:/pwd trufflesecurity/trufflehog:latest \
            git file:///pwd --only-verified --fail

secret-detection:
  stage: test
  image:
    name: zricethezav/gitleaks:latest
    entrypoint: [""]
  script:
    - gitleaks detect --source . --verbose --redact
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

trufflehog:
  stage: test
  image: trufflesecurity/trufflehog:latest
  script:
    - trufflehog git file://. --only-verified --fail
  allow_failure: false

Operational checklist

1. Define severity policy document—what CRITICAL means for your org.
2. Run tool in advisory mode for one sprint; export baseline finding count.
3. Enable SARIF upload; wire Slack/PagerDuty on new CRITICAL in main.
4. Review false positive rate monthly; tune rulesets or suppressions with expiry dates.
5. Measure mean time to remediate per category—SAST vs SCA vs container often differ by 10×.

Common failure modes

• Scanning only default branch—feature branches ship vulns via cherry-pick.
• No lockfile—SCA reports stale or empty.
• Ignoring unfixed upstream CVEs without compensating WAF/network controls.
• Developers disable checks locally because PR feedback exceeds 30 minutes.

Tooling landscape

What to block vs warn

Pipeline integration

name: Container scan
on:
  push:
    branches: [main]
jobs:
  build-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: docker build -t app:${{ github.sha }} .
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: app:${{ github.sha }}
          format: sarif
          output: trivy-image.sarif
          severity: CRITICAL,HIGH
          exit-code: 1
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-image.sarif

container-scan:
  stage: scan
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - trivy image --exit-code 1 --severity CRITICAL,HIGH
        --format template --template @/contrib/sarif.tpl
        --output gl-container-scanning-report.sarif
        $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    reports:
      container_scanning: gl-container-scanning-report.sarif

Operational checklist

1. Define severity policy document—what CRITICAL means for your org.
2. Run tool in advisory mode for one sprint; export baseline finding count.
3. Enable SARIF upload; wire Slack/PagerDuty on new CRITICAL in main.
4. Review false positive rate monthly; tune rulesets or suppressions with expiry dates.
5. Measure mean time to remediate per category—SAST vs SCA vs container often differ by 10×.

Common failure modes

• Scanning only default branch—feature branches ship vulns via cherry-pick.
• No lockfile—SCA reports stale or empty.
• Ignoring unfixed upstream CVEs without compensating WAF/network controls.
• Developers disable checks locally because PR feedback exceeds 30 minutes.

Tooling landscape

What to block vs warn

Pipeline integration

name: DAST
on:
  workflow_dispatch:
  schedule:
    - cron: '0 3 * * 1'
jobs:
  zap-baseline:
    runs-on: ubuntu-latest
    steps:
      - uses: zaproxy/[email protected]
        with:
          target: https://staging.example.com
          rules_file_name: .zap/rules.tsv
          cmd_options: -a
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: report_json.sarif

dast-zap:
  stage: dast
  image: owasp/zap2docker-stable
  variables:
    STAGING_URL: https://staging.example.com
  script:
    - zap-baseline.py -t $STAGING_URL -J gl-dast-report.json
        -c .zap/rules.tsv -a
  artifacts:
    reports:
      dast: gl-dast-report.json
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

nuclei:
  stage: dast
  image: projectdiscovery/nuclei:latest
  script:
    - nuclei -u $STAGING_URL -severity critical,high -json-export nuclei.json
  artifacts:
    paths: [nuclei.json]

Operational checklist

1. Define severity policy document—what CRITICAL means for your org.
2. Run tool in advisory mode for one sprint; export baseline finding count.
3. Enable SARIF upload; wire Slack/PagerDuty on new CRITICAL in main.
4. Review false positive rate monthly; tune rulesets or suppressions with expiry dates.
5. Measure mean time to remediate per category—SAST vs SCA vs container often differ by 10×.

Common failure modes

• Scanning only default branch—feature branches ship vulns via cherry-pick.
• No lockfile—SCA reports stale or empty.
• Ignoring unfixed upstream CVEs without compensating WAF/network controls.
• Developers disable checks locally because PR feedback exceeds 30 minutes.

Tooling landscape

What to block vs warn

Pipeline integration

name: IaC scan
on:
  pull_request:
    paths: ['terraform/**', 'k8s/**', 'helm/**']
jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          framework: terraform
          output_format: sarif
          output_file_path: checkov.sarif
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: checkov.sarif
  kubeconform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          curl -sL https://github.com/yannh/kubeconform/releases/latest/download/kubeconform-linux-amd64.tar.gz | tar xz
          ./kubeconform -summary k8s/

iac-sast:
  stage: test
  image:
    name: bridgecrew/checkov:latest
    entrypoint: [""]
  script:
    - checkov -d terraform/ --framework terraform
        --output sarif --output-file-path checkov.sarif
  artifacts:
    reports:
      sast: checkov.sarif
  rules:
    - changes:
        - terraform/**/*
        - k8s/**/*

kics:
  stage: test
  image: checkmarx/kics:latest
  script:
    - kics scan -p . -o results --report-formats sarif
  artifacts:
    paths: [results/results.sarif]

Operational checklist

1. Define severity policy document—what CRITICAL means for your org.
2. Run tool in advisory mode for one sprint; export baseline finding count.
3. Enable SARIF upload; wire Slack/PagerDuty on new CRITICAL in main.
4. Review false positive rate monthly; tune rulesets or suppressions with expiry dates.
5. Measure mean time to remediate per category—SAST vs SCA vs container often differ by 10×.

Common failure modes

• Scanning only default branch—feature branches ship vulns via cherry-pick.
• No lockfile—SCA reports stale or empty.
• Ignoring unfixed upstream CVEs without compensating WAF/network controls.
• Developers disable checks locally because PR feedback exceeds 30 minutes.

Tooling landscape

What to block vs warn

Pipeline integration

name: License scan
on:
  pull_request:
  push:
    tags: ['v*']
jobs:
  license-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npx license-checker --production --summary --failOn GPL
      - uses: fossas/fossa-action@v1
        with:
          api-key: ${{ secrets.FOSSA_API_KEY }}

license-scan:
  stage: compliance
  image: node:20
  script:
    - npm ci
    - npx license-checker --production --summary --failOn GPL
  rules:
    - if: $CI_COMMIT_TAG

fossa:
  stage: compliance
  image: fossa/fossa-cli:latest
  script:
    - fossa analyze
    - fossa test
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  allow_failure: false

Operational checklist

1. Define severity policy document—what CRITICAL means for your org.
2. Run tool in advisory mode for one sprint; export baseline finding count.
3. Enable SARIF upload; wire Slack/PagerDuty on new CRITICAL in main.
4. Review false positive rate monthly; tune rulesets or suppressions with expiry dates.
5. Measure mean time to remediate per category—SAST vs SCA vs container often differ by 10×.

Common failure modes

• Scanning only default branch—feature branches ship vulns via cherry-pick.
• No lockfile—SCA reports stale or empty.
• Ignoring unfixed upstream CVEs without compensating WAF/network controls.
• Developers disable checks locally because PR feedback exceeds 30 minutes.

Tooling landscape

What to block vs warn

Pipeline integration

name: SARIF upload
on:
  workflow_run:
    workflows: [SAST, SCA, Container scan, IaC scan]
    types: [completed]
jobs:
  aggregate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
      - run: |
          for f in *.sarif; do
            echo "Uploading $f"
            gh api repos/${{ github.repository }}/code-scanning/sarifs \
              -f sarif=@$f -f ref=refs/heads/main
          done
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

# GitLab auto-ingests when artifacts.reports.sast/container_scanning/dependency_scanning are set
include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Security/Container-Scanning.gitlab-ci.yml

variables:
  SECURE_ANALYZERS_PREFIX: "registry.gitlab.com/gitlab-org/security-products/analyzers"
  SAST_EXCLUDED_PATHS: "spec, test, tmp"

security-dashboard:
  stage: report
  script:
    - echo "Findings visible in Security & Compliance > Vulnerability Report"
  needs:
    - sast
    - dependency_scanning
    - container_scanning

Operational checklist

1. Define severity policy document—what CRITICAL means for your org.
2. Run tool in advisory mode for one sprint; export baseline finding count.
3. Enable SARIF upload; wire Slack/PagerDuty on new CRITICAL in main.
4. Review false positive rate monthly; tune rulesets or suppressions with expiry dates.
5. Measure mean time to remediate per category—SAST vs SCA vs container often differ by 10×.

Common failure modes

• Scanning only default branch—feature branches ship vulns via cherry-pick.
• No lockfile—SCA reports stale or empty.
• Ignoring unfixed upstream CVEs without compensating WAF/network controls.
• Developers disable checks locally because PR feedback exceeds 30 minutes.