SAST and Scanning Tools

A static analyser is a compiler front end with a query language bolted on. It parses your code into a model, lets a rule describe a shape in that model, and reports matches. Everything the tool cannot find follows from that sentence — and so does every tool's licensing, because the expensive part is the model, not the query.

How a SAST engine works

Every engine in this space does the same three things, in the same order. It parses the language into an abstract syntax tree or a control-flow graph. It adds a semantic layer — types, resolved imports, and for taint analysis a model of which functions are sources, which are sinks and which are sanitisers. Then a rule, written in the tool's own language, is evaluated over that model.

The consequences are predictable. If the tool cannot parse a language, it finds nothing — which is why "we run SonarQube" is not coverage. If the taint model does not know a framework's sanitiser, every correctly escaped value is a false positive, which is why framework-specific rule sets matter more than rule count. And if the analysis is intraprocedural, a value that travels through three helper functions is invisible, which is the single largest source of missed findings in a real codebase.

Semgrep: rules you can write

Semgrep's proposition is that a security engineer can express a convention in the language they are reviewing. A rule is a pattern that looks like the code it matches, with metavariables for the parts that vary. That is enough for the majority of real findings — a dangerous function called with an untrusted argument, a framework escape hatch, an unescaped template tag — and it is why the tool became the default first scanner.

rules:
  - id: express-unescaped-ejs
    languages: [javascript, typescript]
    severity: ERROR
    message: >
      Unescaped EJS interpolation (<%-) renders request data as markup.
      Use <%= unless the value is trusted, sanitised HTML.
    metadata:
      cwe: ["CWE-79"]
      owasp: ["A05:2025 - Injection"]
      confidence: HIGH
    patterns:
      - pattern: <%- $X %>
      - pattern-not: <%- include($Y) %>

  - id: go-sql-string-concat
    languages: [go]
    severity: ERROR
    message: Query built by concatenation; bind parameters instead.
    metadata:
      cwe: ["CWE-89"]
    patterns:
      - pattern-either:
          - pattern: $DB.Query("..." + $X + "...")
          - pattern: $DB.Query(fmt.Sprintf(...))
      - pattern-not-inside: |
          func $F(...) {
            ...
            $DB.Query($Q, ...)
            ...
          }

Two limits define the tool. Community Edition analyses one file at a time, so a value passed between files is invisible to a taint rule — the multi-file analysis is a commercial feature. And the rules themselves are not open source: the engine is LGPL-2.1, but the rule syntax and registry rules are covered by the Semgrep Rules License, which restricts redistribution. The Opengrep fork exists because of that split, and it is worth knowing which one a repository's CI is actually running.

# install without a package manager dependency
python3 -m pip install semgrep

# scan the tree with the registry rule sets plus the repository's own rules
semgrep scan --config p/owasp-top-ten --config ./semgrep/ --error

# diff-aware: only report what this branch introduced
semgrep scan --config p/security-audit --baseline-commit origin/main

# SARIF for code scanning, when the scanner is not the GitHub-native one
semgrep scan --config p/security-audit --sarif --output semgrep.sarif

# validate a custom rule against its own test file before merging it
semgrep --test --config ./semgrep/

CodeQL: queries over a database

CodeQL extracts the codebase into a relational database — tables for expressions, calls, types, control flow — and rules are written as queries over it. That model is what makes cross-file data flow possible, and it is also why the tool is slow, why each language needs a purpose-built extractor, and why the language list is shorter than Semgrep's: currently ten languages, and neither PHP nor Scala is among them.

# CodeQL CLI: databases are built per language, then queried
codeql database create ./db   --language=javascript   --source-root=.   --command="npm ci && npm run build"

# the suite must be qualified: a bare suite name does not resolve
codeql database analyze ./db   codeql/javascript-queries:codeql-suites/javascript-security-extended.qls   --format=sarif-latest   --output=codeql.sarif

# upload is a separate, authenticated step
gh api   -X POST   /repos/{owner}/{repo}/code-scanning/sarifs   -f sarif="$(base64 -w0 codeql.sarif)"

SonarQube Community Build

SonarQube was renamed at the community tier: what used to be the Community Edition is now the Community Build, under LGPL-3.0, self-hosted or run locally. It is the broadest single-tool view of a codebase — duplication, complexity, coverage and security rules in one report — which is why organisations adopt it first and then discover the gap.

That gap is branch and pull-request analysis. The Community Build analyses a branch as a standalone project, so there is no "new issues in this pull request" view and no quality gate on a merge. Every commercial edition exists above that line. If the requirement is a gate on a pull request, the free tier of this tool cannot provide it, and planning around that on day one is cheaper than discovering it in month two.

Secrets, dependencies and the gaps

SAST looks at code as written today. Two classes of defect live outside that frame and need their own scanner: credentials committed and later deleted, which remain in git history forever, and vulnerable dependencies, which are not defects in your code at all. The 2025 OWASP Top 10 promoted the second to A03 Software Supply Chain Failures, and it deserves its own gate rather than a line in the SAST report.

Wiring it into CI

A scanner that runs after merge produces a report nobody reads. The workflow below is the minimum that gates a pull request while keeping the existing backlog from blocking every build: scan on the pull request, upload SARIF so the findings appear inline on the diff, and run the slow full-history and dependency scans on a schedule.

name: sast
on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: '0 3 * * 1'

permissions:
  contents: read
  security-events: write

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Semgrep
        run: |
          python3 -m pip install semgrep
          semgrep scan --config p/owasp-top-ten --config ./semgrep/ \
            --sarif --output semgrep.sarif --error || true

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

      - name: Secrets in full history
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Dependencies
        run: |
          npm ci
          npx osv-scanner --lockfile=package-lock.json

Triage workflow

Triage is the step that decides whether the programme survives. Four outcomes, and each one has to be recorded or the same finding is re-investigated in three months:

Evidence Collection

Bedrock Questions Before Filing

Scanning Programme Checklist

Programme Notes