Static Code Scanning: The Complete Workflow Guide (2026)

Static code scanning is useless if your team ignores it. That sounds blunt, but it describes the reality in most engineering orgs that have adopted a SAST tool: they ran the scanner, got 2,000 findings on day one, muted the noise, and moved on. The tool still runs in CI — the alerts just accumulate unread. If you are evaluating which scanner to buy, our static code analysis tools comparison covers the field. This article is for the team that already has a tool and needs to make it work operationally: how to configure scans, integrate them into CI/CD, eliminate the alert fatigue that kills adoption, and build a remediation loop developers will actually follow.

The stakes are real. A widely-cited principle from IBM's Systems Sciences Institute suggests defects cost 6× more to fix after deployment than during development — and security vulnerabilities found in production can cost orders of magnitude more in incident response, regulatory penalty, and reputational damage. Static code testing is the earliest practical intervention point: it catches flaws in the code before they ever run. The challenge is not the technology — it is the workflow. This guide fixes that.

What Is Static Code Scanning?

Static code scanning (also called SAST — Static Application Security Testing) analyzes source code, bytecode, or binary code without executing it. The scanner reads your code as text, models it as a data structure (typically an Abstract Syntax Tree or control flow graph), and applies rules to detect patterns associated with bugs, security vulnerabilities, and policy violations.

The key word is static: nothing runs. This is what distinguishes SAST from DAST (Dynamic Application Security Testing), which fires real HTTP requests at a running application and observes its behavior. DAST finds things like authentication bypass under real load, misconfigured HTTP headers in production, and session management flaws — issues that only manifest when the app is alive. SAST finds issues in the code itself: SQL injection patterns, insecure deserialization, hardcoded credentials, off-by-one errors, null pointer dereferences. For a full comparison of both approaches and the tools that implement them, see our SAST and DAST testing tools guide. The complementary nature means you need both — but SAST is the one you run first, earliest in the pipeline, because it costs the least to fix issues at that point.

Beyond security, static analysis catches code quality problems: unused variables, unreachable code, violated style conventions, type mismatches, and complexity thresholds. Linters are a simple form of static analysis. Full SAST tools go further: they trace data flows across function calls to identify taint propagation (untrusted user input reaching a sensitive sink), model control flow to find race conditions, and analyze dependency graphs to surface transitive vulnerabilities in third-party libraries.

The OWASP Top 10 — the industry's most-cited list of critical web application security risks — includes SQL injection, XSS, insecure deserialization, and broken access control, all of which a well-configured SAST scanner can detect at the code level before deployment. Similarly, MITRE CWE (Common Weakness Enumeration) provides the taxonomic framework most SAST tools use to classify findings. When a scanner reports "CWE-89: Improper Neutralization of Special Elements used in an SQL Command," it is referencing a standardized, citable definition — not a tool-vendor opinion.

For language-specific coverage, the tool landscape varies significantly. Python teams tend to combine Bandit, Semgrep, and mypy; Java teams lean on SonarQube and SpotBugs. Our guides to Python static code analysis and Java static analysis tools cover the stack-specific choices in depth.

The Static Code Scanning Workflow Step by Step

The most common failure mode in static code scanning adoption is skipping the baseline phase and running a full scan on an existing codebase. The result: thousands of findings, zero prioritization context, and a team that learns to click "dismiss all." A structured five-phase approach avoids this entirely.

Phase 1: Baseline and initial configuration

Before your first real scan, establish what "normal" looks like in your codebase. Run the scanner in audit mode against the full repo and suppress all current findings into a baseline file. This file records the existing technical debt without blocking your pipeline. From this point forward, the scanner only reports findings introduced after the baseline — new code, new problems. This pattern is how teams with legacy codebases adopt SAST without being paralyzed by historical debt.

During this phase, configure your rule set. Not every rule is relevant to every codebase. A pure frontend JavaScript project does not need server-side deserialization rules. A Python data pipeline does not need Android memory management checks. Scope your rule set to the languages and frameworks you actually use. Most enterprise SAST tools provide language-specific profiles; open-source tools like Semgrep allow custom rule repositories.

Phase 2: First real scan and triage setup

Run your first post-baseline scan on a feature branch — not on main. Review the findings as a team and categorize them into buckets: real security issues, code quality issues, probable false positives, and policy violations. This triage session, done once as a team, calibrates everyone's expectations and creates shared knowledge about what the scanner is and is not catching. Document the decisions: "We suppress rule X because our framework handles this at the ORM layer" is a legitimate baseline annotation — but it needs to be written down, not silently dismissed.

Phase 3: Triage and false positive filtering

Ongoing triage is where most implementations fail. Without a clear ownership model — who reviews which findings, by when — alerts accumulate and rot. Assign ownership by component or team boundary, not by individual. Set a SLA: critical findings require acknowledgment within 24 hours; high within one sprint; medium within the quarter. Tools with IDE plugins (SonarLint, Semgrep VS Code extension) move this triage into the developer's natural workflow, reducing the context-switch cost.

Phase 4: Remediation and verification

Once a finding is accepted as real, remediation follows the same development workflow as any other fix: branch, implement, test, PR, merge. The key addition is verification: re-run the scan after the fix and confirm the finding is gone. Do not rely on "I fixed it" — re-run the scanner. Some vulnerability patterns can be patched in one place but still exist in a similar code path elsewhere; the re-scan catches those siblings.

Phase 5: Continuous monitoring

Once baselines are set and triage workflows are established, the scanner becomes ambient infrastructure. Every PR triggers a scan; findings gate the merge (or notify without blocking, depending on your policy). Dashboards track vulnerability trends over time: is the finding count going up or down? Is time-to-remediation improving? The goal is not zero findings — it is a manageable, downward trend with clear ownership of what remains open.

Types of Scans and What They Catch

Not all SAST tooling uses the same underlying technique. Understanding the four main scan types helps you configure the right combination for your risk profile and avoid over-relying on one method that misses an entire class of vulnerability.

Scan Type	What It Catches	Example Tools	Typical False Positive Rate
Rule-Based (Pattern Matching)	Hardcoded credentials, deprecated crypto functions (MD5/SHA1), dangerous API calls, style violations, obvious injection patterns	Semgrep (OSS rules), ESLint security plugins, Bandit (Python), gitleaks	Moderate–High (20–50%) — scanner lacks data-flow context
Data-Flow Analysis (Taint Tracking)	SQL injection, XSS, command injection, path traversal, insecure deserialization — source-to-sink taint flows	CodeQL, Checkmarx, Snyk Code, Semgrep Pro, Fortify	Low (5–15%) — context-aware, understands sanitization
Dependency Scanning (SCA)	Known CVEs in third-party packages, license violations, outdated transitive dependencies, malicious packages	Dependabot, Snyk Open Source, OWASP Dependency-Check, Socket	Very Low (<5%) — CVE matching against advisory databases
Configuration Scanning (IaC)	Overpermissive IAM roles, exposed ports, missing TLS, secrets in env vars, misconfigured Kubernetes RBAC	Checkov, tfsec, Trivy (IaC mode), Terrascan, KICS	Low–Moderate (10–25%) — depends on rule specificity

Rule-based scanning (pattern matching)

The simplest form: the scanner applies regex-like patterns to source code, looking for known-dangerous constructs. Examples: dynamic code execution calls with untrusted input, hardcoded strings matching password or API key patterns, deprecated cryptographic functions like MD5 or SHA1 used for password storage, file path concatenation without sanitization. Rule-based scanning is fast, predictable, and easy to extend with custom rules — but it has limited context. It sees the pattern, not the data flow. A call to execute(query) looks dangerous whether query is a hardcoded string or user input; the scanner flags both.

Data-flow analysis (taint tracking)

More sophisticated: the scanner models how data moves through the program. It identifies "sources" (user-controlled inputs: HTTP parameters, headers, form fields, file uploads) and "sinks" (sensitive operations: SQL queries, shell commands, HTML rendering, file writes). It then traces every path from source to sink. If user input can reach a SQL sink without passing through sanitization or parameterization, that is a confirmed injection vulnerability — not a guess. Data-flow analysis produces fewer false positives than rule-based scanning for injection classes because it understands context. It is also slower and more memory-intensive, which matters for large codebases.

Dependency scanning (SCA within the pipeline)

Software Composition Analysis examines your dependency manifest (package.json, requirements.txt, pom.xml, go.mod) and compares it against vulnerability databases — NVD, OSV, GitHub Advisory Database. It catches known CVEs in third-party libraries. Strictly speaking, SCA is distinct from SAST (it does not analyze your code), but most modern SAST platforms include it as a scan type because the remediation workflow is similar: triage, prioritize, update. For SAST tool comparisons that include SCA coverage, see our SAST tools overview.

Configuration scanning

Infrastructure-as-code files — Terraform, Kubernetes YAML, Dockerfile, Ansible playbooks, GitHub Actions workflows — contain their own class of security issues: overly permissive IAM roles, exposed ports, missing network policies, secrets in environment variables. Configuration scanning applies static analysis to these files using tools like Checkov, Trivy (IaC mode), or tfsec. This is increasingly important as the attack surface shifts to the supply chain and deployment layer rather than the application code itself.

Integrating Static Scanning Into CI/CD

Static code testing only delivers value when it runs automatically, on every change, without requiring a developer to remember to trigger it. The right integration model runs scans at multiple points: pre-commit (locally), on every PR (in CI), and on a schedule against the main branch (for dependency drift and new rule releases).

Pre-commit hooks

The fastest feedback loop: run lightweight rules locally before code even reaches the remote repository. Tools like pre-commit (Python), lefthook (Go, polyglot), or Husky (Node.js) run configured scanners as Git hooks. Keep this stage fast — under 30 seconds — by running only the highest-signal rules (secrets detection, obvious injection patterns, linting). Slow pre-commit hooks get disabled. The goal is a quick sanity check, not a full scan.

GitHub Actions integration

The PR-level scan is the main enforcement gate. Here is a complete GitHub Actions workflow for a Semgrep SAST scan on every pull request:

name: Static Code Scanning

on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [main]

jobs:
  semgrep-sast:
    name: Semgrep SAST Scan
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write

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

      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/secrets
            p/javascript
          generateSarif: "1"
        env:
          SEMGREP_APP_TOKEN: {{ secrets.SEMGREP_APP_TOKEN }}

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

Key points about this workflow: it runs on every PR targeting main or develop, uploads results in SARIF format (the standard for security tooling integration with GitHub Advanced Security), and uses three rule packs — OWASP Top 10, secrets detection, and JavaScript-specific rules. Adjust the config block to match your stack and risk priorities.

Scan placement in the pipeline

Place the SAST scan after dependency installation (so the scanner can resolve imports) but before build and test steps. This placement ensures the scan has full dependency context while failing fast — if the scan blocks a merge, the developer gets the feedback without waiting for a full build cycle. Dependency scanning (SCA) can run in parallel with the SAST scan since it only reads the manifest, not the code.

Blocking versus non-blocking policies

Not every finding should block a merge. A pragmatic policy: critical and high severity findings block the PR; medium and low findings create non-blocking annotations. This prevents scan-induced paralysis while ensuring the most dangerous issues cannot silently ship. Implement this using the exit-zero flag or severity thresholds in your scanner's CLI — most tools support returning non-zero exit codes only above a configurable severity level.

For broader automated review patterns that complement SAST — including AI-assisted code review and quality gates — our guide to automated code review tools covers the full landscape.

The False Positive Problem (and How to Handle It)

False positives are not a minor inconvenience in static code scanning — they are the primary reason implementations fail. When developers learn that 60% of scan findings are irrelevant to their codebase, they stop reading findings altogether. Alert fatigue is a real and documented phenomenon: a team trained to expect noise will ignore signal. Research on developer security behavior consistently shows that trust in the tool is more predictive of adoption than any feature set.

Why false positives happen

Static analysis is inherently approximate. To be sound (never miss a real bug), a scanner must over-approximate — it reports some things that are not actually bugs because the alternative (under-approximating) would miss real issues. The scanner does not know your business logic: it sees a function that takes string input and passes it to a query executor, and it cannot know whether your framework already parameterizes that query upstream. Rule-based scanners are especially prone to this; data-flow scanners are better but still produce false positives when sanitization happens in a custom wrapper the scanner does not recognize.

Strategies that work

Rule customization: Disable rules that consistently fire on legitimate patterns in your codebase. If your ORM handles all SQL parameterization and a rule is flagging safe ORM calls, disable that rule rather than suppressing individual findings. Suppressing 500 instances of the same false positive is not a solution; fixing the root cause in the rule configuration is.

Baselines: As discussed in the workflow section, baselines suppress pre-existing findings so new findings are always net-new. This is the single most effective tactic for reducing initial noise and making the scanner actionable.

AI-assisted filtering: Several modern SAST platforms (Snyk, Semgrep Code, GitHub Advanced Security with Copilot Autofix) now use LLMs to evaluate whether a finding is likely a true positive before surfacing it to the developer. Early benchmarks show 20–40% reduction in false positives with this layer. It is not a replacement for rule tuning, but it meaningfully reduces noise in dynamic, modern codebases with complex framework interactions.

Suppression with rationale: When a finding is a confirmed false positive that cannot be addressed through rule configuration, suppress it inline with a comment explaining why. A comment like nosemgrep: rule-id paired with "ORM parameterizes this query" is a legitimate suppression. A bare suppression annotation with no rationale is technical debt that will confuse the next developer reviewing it. Require rationale in your suppression policy; enforce it in PR review.

Configuring Scans for Your Stack

Generic rule sets produce generic results. The biggest accuracy improvement available to most teams is spending four hours tuning the scanner for their specific language, framework, and risk profile.

Language tool matrix

Different stacks have different mature tooling. Here is the current (2026) landscape by language for static code testing:

Language	Primary SAST Tools	Notable Strength
JavaScript / TypeScript	Semgrep, ESLint (security plugins), SonarQube	Broad rule coverage; npm ecosystem SCA
Python	Bandit, Semgrep, Pylint, mypy	Bandit for security; mypy for type-safety
Java	SonarQube, SpotBugs, PMD, Error Prone	Deep bytecode analysis; Maven/Gradle SCA
Go	Gosec, Semgrep, Staticcheck	Gosec covers Go-specific crypto and race patterns
C / C++	Clang Static Analyzer, Coverity, CodeQL	Memory safety, buffer overflow detection
Ruby	Brakeman, Semgrep	Brakeman specializes in Rails-specific vulnerabilities
PHP	RIPS, Psalm, PHPStan	Taint analysis for legacy web app patterns

For deep dives into language-specific configuration, our articles on Python static analysis and Java static analysis tools cover rule selection, configuration files, and CI integration for those ecosystems.

Sensitivity tuning

Most SAST tools expose sensitivity as a dial: high sensitivity catches more real bugs but produces more false positives; low sensitivity produces cleaner results but misses more. The right setting depends on your risk profile. Security-critical applications (payment processing, identity, healthcare data) warrant higher sensitivity with a staffed triage process. Internal tooling with low attack surface can afford lower sensitivity and lighter triage overhead.

Tune sensitivity per scan type, not globally. Run data-flow analysis at higher sensitivity (worth the triage cost for injection classes); run style and complexity rules at lower sensitivity (catching every cyclomatic complexity violation is not the goal).

Custom rules for proprietary patterns

Your codebase has internal abstractions that generic rule sets do not understand. If your team uses a custom logging framework that inadvertently captures PII, the scanner will not know to flag it unless you write a rule. Most enterprise SAST tools support custom rule authoring in their rule DSL; Semgrep's YAML rule format is particularly accessible and well-documented. Writing 10–20 custom rules targeting your most common internal anti-patterns often produces a higher signal-to-noise ratio than enabling 500 generic rules.

Remediation Patterns That Actually Stick

Finding vulnerabilities is the easy part. The hard part is building a remediation workflow that developers follow consistently without treating it as a compliance checkbox. These patterns are drawn from teams that have sustained low vulnerability counts over time — not teams that had a clean scan on launch day and let it drift.

Prioritize by severity and exploitability, not just CVSS

CVSS scores measure theoretical severity in isolation. In practice, a critical CVSS score on an internal admin endpoint with network access controls is less urgent than a medium CVSS SQL injection in a public-facing search handler. Apply context: is the vulnerable code path reachable from the internet? Is there a mitigating control (WAF, authentication) upstream? Most mature security programs apply "reachability analysis" — using the dependency and call graph to determine whether a vulnerable code path is actually invocable in your deployment context.

Build the developer feedback loop

Findings that reach developers through a security team's issue tracker two weeks after the code was written feel disconnected from the code. Findings that appear inline in the PR diff, explaining exactly which line is vulnerable and why, are findings developers actually engage with. Invest in IDE plugins and PR-level annotations. Tools like SonarLint (for SonarQube), Semgrep's VS Code extension, and GitHub Advanced Security's inline PR comments all support this pattern. The closer the feedback is to the moment of writing, the lower the remediation cost and the higher the learning value for the developer.

Automated fixes for the mechanical cases

Many vulnerability classes have deterministic fixes that can be automated. Dependency updates with known CVE fixes: npm audit fix, Dependabot, Renovate. Insecure hash function replacement: a codemod script can replace MD5 with SHA-256 across the repo. String formatting to parameterized queries: some SAST tools offer autofix suggestions. Reserve developer review time for the judgment calls — novel vulnerability patterns, architectural issues, business logic flaws — and automate the mechanical ones.

Track metrics that reflect real progress

Vanity metrics: "number of scans run this month." Signal metrics: mean time to remediation (MTTR) for critical findings, percentage of critical findings remediated within SLA, false positive rate over time, and coverage (percentage of repos with active scanning enabled). Track these in a dashboard visible to engineering leadership. When MTTR trends down, the process is working. When it trends up, something is broken — triage is backed up, ownership is unclear, or the rule set has drifted into noise.

Reviewing Scan Findings Alongside Code Diffs

When a SAST tool flags a vulnerability, the next step is always the same: look at the diff that introduced it. A finding without the diff context is an alert. A finding read alongside the exact code change that created it is an actionable, reviewable security issue. These are operationally different.

This is where code diff review becomes a security practice, not just a merge-approval workflow. Consider the sequence: a scanner flags a potential SQL injection in a query builder function. The SARIF output points to line 147 of user-search.ts. The developer looks at the current file — but the vulnerability was introduced three commits ago, across a refactor that touched six files. Reading the finding in isolation does not tell you whether the issue was pre-existing (already in the baseline, so suppressed), newly introduced (by the current PR), or a side effect of another change that broke a sanitization guard.

Pulling the diff for the PR or commit that introduced the flagged line immediately answers those questions. You can see whether the vulnerable pattern was added, modified to become vulnerable, or was always there and newly flagged due to a rule update. That distinction determines the remediation priority and the owner. For source code review workflows that integrate diff analysis alongside findings, our source code review tools guide covers the tooling landscape.

In practice, teams that integrate diff review into their security triage workflow catch an additional class of issue that scanners miss: contextual vulnerabilities. A function that is individually safe can become vulnerable when combined with another change elsewhere — a new route that calls it with unvalidated input, for example. The scanner sees the function and passes; the diff reviewer sees the new caller and catches the combination. This is why static code testing and code diff review are complements, not substitutes.

Diff Checker makes this workflow fast: paste the before and after versions of any flagged code section for an instant side-by-side view of exactly what changed, with syntax highlighting for 20+ languages. No upload, no server-side processing — the comparison runs locally in your browser, which matters when the code contains unreleased security fixes or sensitive business logic. When a scan flags a finding, open the diff right alongside it.

Frequently Asked Questions

What is the difference between static code analysis and dynamic code analysis?

Static code analysis (SAST) inspects source code, bytecode, or binaries without executing them — it models the code as a syntax tree or control flow graph and applies rules to detect bugs and vulnerabilities. Dynamic code analysis (DAST) runs the application and observes its real behaviour under traffic, finding runtime issues like authentication bypass, misconfigured headers, and session flaws. SAST catches issues earliest and cheapest, so it gates the pipeline. DAST catches issues SAST cannot see, so it runs in staging. They are complements, not substitutes — mature programs use both.

How do you reduce false positives in static code scanning?

Four tactics, in order of impact. First, establish a baseline so pre-existing findings are suppressed and only new code is reported. Second, tune rules: disable any rule that consistently fires on safe patterns in your codebase (for example, ORM calls flagged as SQL injection). Third, prefer data-flow scanners over pure rule-based ones for injection classes — they understand sanitization context and produce 5–15% false positive rates instead of 20–50%. Fourth, use AI-assisted filtering layers (Snyk, Semgrep, GitHub Advanced Security) which can cut noise by an additional 20–40% on top of rule tuning.

How often should you run static code scans?

Run scans at three cadences. On every pull request — this is the primary enforcement gate and blocks critical or high severity findings before merge. On every commit to main, as a safety net for anything that slipped through. And on a nightly or weekly schedule against the main branch, which catches new findings from updated rule packs and new CVEs in dependencies even when no code changed. Pre-commit hooks add a fourth, lightweight tier that catches obvious issues (secrets, dangerous calls) locally before code reaches the remote repository.

What is the difference between SAST and SCA?

SAST (Static Application Security Testing) analyses your first-party source code — the code your team writes — for vulnerabilities, insecure patterns, and bugs. SCA (Software Composition Analysis) analyses your third-party dependency manifest (package.json, requirements.txt, pom.xml) and compares it against vulnerability databases like NVD, OSV, and GitHub Advisory Database to flag known CVEs in libraries you imported. They cover different attack surfaces: most real-world breaches involve both classes, so modern SAST platforms bundle SCA as a parallel scan type in the same CI pipeline.

Can static code scanning find all security vulnerabilities?

No — static code scanning is bounded by what is visible in the code. It catches injection patterns, hardcoded secrets, insecure crypto, known CVEs in dependencies, and many logic bugs. It cannot find issues that depend on runtime state: authentication bypass under real load, race conditions only triggered by specific traffic patterns, misconfigured production infrastructure, or business logic flaws that are syntactically valid. That is why static code testing is necessary but not sufficient — pair it with DAST, dependency monitoring, and manual code review to cover the gaps.