What is a code scan: what a scanner reads in an AI-built app, which one to run on your stack, and how to prove it runs

A clean scan report can sit in the repo while any logged-in user still reads another customer’s invoices, because no scanner knows who is supposed to see what. That gap is part of the honest answer to what is a code scan: a program that reads source code for known bad patterns without running it. ESLint, the TypeScript compiler, CodeQL and npm audit are one of each kind.

What is a code scan: a program reading your source for known bad patterns

A code scan is a program reading your source code for known bad patterns without running it. It parses each file, matches rules, and the better tools follow data from an input to a dangerous call. The four kinds are linters, type checkers, security scanners and dependency scanners, and each reads something different.

Scanning is one of the engineering standards for AI-assisted teams. A code scan, code scanning and static analysis are the same idea at three sizes: one run, the run wired into every pull request, and the technique underneath both. GitHub uses code scanning as the name of its own feature, which GitHub’s code scanning documentation describes as “a feature that you use to analyze the code in a GitHub repository to find security vulnerabilities and coding errors.”

A static analysis tool is any program that does this job. When a buyer shops for code scan software, they usually mean the security kind. Testing textbooks stretch static testing tools further, to reviews and walkthroughs that a person does with no program at all.

The “what it reads” column below is my reading of each tool’s input. The “what it reports” column is what each project’s documentation says it produces.

The last row has its own page, on the npm audit command. Probing a running app from the outside is a different test again, explained in SAST vs DAST.

A code checker is four different tools: linter, type checker, scanner, online checker

A code checker is one of four things: a linter for patterns, a type checker for mismatched data, a security scanner for risky calls, or a web page that checks a pasted snippet. Only the first three see the whole app, and they help only when they run on every pull request.

The online kind checks syntax or style in one snippet and knows nothing about the rest of the app, so it cannot notice that a route is missing its permission check. Never paste code that holds API keys, tokens or customer data into one. The phrase also covers plagiarism checkers, diff checkers and CodeChecker, a Clang-based analysis product, none of which is what a founder with a live app needs.

The free code checker worth having is the one wired into your repository, where it runs on every change without anyone remembering to open it. Setting up linters properly is a topic of its own. Detectors that claim to spot machine-written code are a different product again, covered under an AI code check.

What is GHAS? GitHub Advanced Security and its code scanning

GHAS is GitHub Advanced Security, sold as two products: GitHub Code Security, which includes code scanning with CodeQL or a third-party tool and dependency review, and GitHub Secret Protection, which includes secret scanning. Some features, such as code scanning and secret scanning, are enabled for public repositories by default; private ones need the product on a Team or Enterprise plan.

GitHub’s page on GitHub Advanced Security puts the plan rule plainly: “You must be on a GitHub Team or GitHub Enterprise plan in order to purchase GitHub Code Security or GitHub Secret Protection.” To run code scanning on a private or internal repository, you buy the product; a personal private repository on the Free plan does not get it.

The engine underneath is CodeQL, and CodeQL’s supported languages run from C, C++ and C# through Go, Java, Kotlin, Python, Ruby, Rust and Swift to JavaScript and TypeScript, plus GitHub Actions workflow files. You switch it on from the repository’s settings with no workflow file to write; the exact clicks are in the first-scan steps further down.

Why it matters for an AI-built app: a floor, not a verdict

A code scan matters for an AI-built app as a floor, not a verdict. One rule finds a risky pattern everywhere an assistant repeated it, but no scan sees a missing rule about who may see what, and a finding changes nothing unless something makes a person read it.

This section stays short on purpose, because the category-by-category view lives on other pages linked below. In the apps I audited in June and July 2026, at least 17 of the 21 third-party apps had no deploy gate, and so did all 5 founder apps: every push ships straight to production with nothing checking it first. Those apps are a selected set, not a random sample and not a rate for AI-built apps in general, and the counts are human-verified findings. A scanner nobody wired into the merge is a report nobody is made to read.

The other direction matters more for a live app. In the same audits, 7 of the 21 third-party apps had confirmed cross-user or cross-tenant authorization failures, where a logged-in user could read or write another customer’s data. That is again a chosen group, so read it as what turned up there, not as a measure of every AI-built app. A pattern rule has nothing to match when the rule that should exist was never written.

Picture a founder’s Next.js app on Supabase that runs a code scan on every pull request, and the report comes back clean. One table’s row level security policy was created in the Supabase dashboard with using (true), so no file in the repository holds it and the scanner never read it; every signed-in user can read every row of that table. Supabase’s row level security guide describes a policy as attached to a table and run every time the table is accessed, and it offers two places to run the SQL: the SQL Editor for a one-off change, or a migration “to keep the change reproducible across environments”. Only the migration leaves a file in the repository for a scanner to read. CodeQL’s language list has no SQL in it either. A scan reads the files and languages it is given, nothing else.

The full table of what these tools catch and miss, and how to read a SAST report, is in what static code analysis tools find and miss. What a scanner report proves next to a verified audit is set out under what a scanner proves, and what it cannot. Scanner, audit and pen test side by side, with five tools named, sit in vibe coding security scanners compared. If you want checks that need no code at all, start with ten checks you can run without reading code. The review that reads intent, which no rule can, follows the secure code review checklist.

How it works: from source text to a finding, stack by stack

The mechanism is the same in every tool. The scanner parses each file into a syntax tree, matches its rules against the tree, and, in the security kind, follows data from an input such as a request parameter to a dangerous call such as a database query; each match becomes a finding with a severity. How data flow and taint analysis work in depth is on the static code analysis tools page linked above.

False positives happen because a rule cannot always see the sanitizer two files away, so it flags a value that was already cleaned. False negatives happen because no rule exists for your business logic: nothing in a generic rule set knows that invoices belong to one account. Tool behavior in the tables below comes from each project’s own documentation, not from a benchmark run for this page.

The last column is my own order of work, not a vendor default.

JavaScript code analysis and TypeScript static code analysis

JavaScript code analysis has three layers: ESLint for patterns, the TypeScript compiler in strict mode for types, and a data-flow scanner such as CodeQL or Semgrep for security. TypeScript static code analysis starts with strict mode, because the compiler is already installed and costs nothing extra.

This stack goes first here because it is what most AI builders produce, even though the tool lists that rank for these searches are mostly about Java. ESLint’s core concepts define a rule as something that “validates if your code meets a certain expectation, and what to do if it does not meet that expectation.” typescript-eslint “enables ESLint, Prettier, and more to support TypeScript code”, and adds rules that use TypeScript’s type information. The compiler step is a single setting, a separate topic: how to enable TypeScript strict mode.

On a Next.js or Express app, each layer catches something the others miss. ESLint with typescript-eslint’s type-checked rules flags a promise that is never handled, since no-floating-promises requires “Promise-like statements to be handled appropriately.” The compiler, with strictNullChecks on, gives a type error when null or undefined is used “where a concrete value is expected.” CodeQL flags a request parameter that flows into an SQL string, the exact case used as the test further down.

Put together, those three layers are what JS static code analysis means on a real project, and CodeQL reads the .js, .jsx, .mjs, .vue, .ts and .tsx files where most of that code lives. None of them reads a row level security policy created in the Supabase dashboard, the case described in the section above.

Code analysis for Python: the code quality tools and the security ones

Code analysis for Python splits in two: quality tools such as Ruff, Pylint and mypy find bugs, style problems and type mismatches, and security tools such as Bandit look for risky calls. A data-flow scanner adds what crosses files.

On the quality side, the Python code quality tools I would start with are Ruff, “An extremely fast Python linter and code formatter, written in Rust”, and Pylint, which “checks for errors, enforces a coding standard, looks for code smells, and can make suggestions about how the code could be refactored.” mypy is a different kind of Python static analysis tool: you add type hints, and “mypy will warn you when you use those types incorrectly.”

For security, Bandit’s documentation calls it “a tool designed to find common security issues in Python code”, and it works on the same syntax-tree principle as the rest. The deeper security scanners are covered on the static code analysis tools page. One gap is easy to miss with Python code analysis: scanners read files in the repository, so code pasted into a hosted notebook or run as a one-off script outside it is never scanned.

Java static analysis: the code analysis tools for Java, from FindBugs to FindSecBugs

Java static analysis is well served, with five tools that each read something different: PMD and Checkstyle read source, SpotBugs reads compiled bytecode, Error Prone extends the compiler’s checks, and Find Security Bugs adds security patterns to SpotBugs. FindBugs, the original, is now an abandoned project.

The table lists the static code analysis tools for Java I would look at first, one row each, plus the tool that started the line.

FindBugs is the original tool behind the phrase find bugs, and the work now goes on in SpotBugs, FindBugs’ successor, which its own manual calls “a program to find bugs in Java programs.” SpotBugs’ site is blunt about the history: it is “a fork of FindBugs (which is now an abandoned project), carrying on from the point where it left off with support of its community.” FindSecBugs is the short name of Find Security Bugs, “The SpotBugs plugin for security audits of Java web applications.” PMD calls itself “an extensible multilanguage static code analyzer”, so it also reaches beyond Java.

Java source code analysis (PMD, Checkstyle, Error Prone) reads the .java files as written; bytecode analysis (SpotBugs and its plugin) reads what the compiler produced, which is why the two find different things. IDE inspections run the same kind of checks earlier, while you type. Vendor products such as Parasoft and Coverity sell into this space too; Coverity comes up again in the SonarQube section below.

Ruby static analysis, and PHPMD for PHP

Ruby static analysis starts with RuboCop for style and lint, with Brakeman added on Rails apps for security patterns. For PHP, PHPMD flags unused code and overcomplicated expressions, and PHPStan or Psalm add a second pass that looks for bugs. PHPMD is a quality tool, not a security scanner.

RuboCop describes itself as “a Ruby static code analyzer (a.k.a. linter) and code formatter” that, out of the box, enforces many guidelines of the community Ruby Style Guide. Brakeman’s documentation calls it “a security scanner for Ruby on Rails applications”, so static code analysis for Ruby usually means both tools on a Rails app; its detail belongs with the other security scanners on the static code analysis tools page.

PHPMD, the PHP Mess Detector, is “a PHP equivalent of the well known Java tool PMD”, and it looks for possible bugs, suboptimal code, overcomplicated expressions and unused parameters, methods and properties. Its rules come in six sets: Clean Code, Code Size, Controversial, Design, Naming and Unused Code. PHPStan’s own line is that it “finds bugs in your code without writing tests”, and Psalm calls itself “a free & open-source static analysis tool that helps you identify problems in your code”. PHPMD is not a security scanner, and CodeQL’s language list has no PHP, so the security kind needs its own look on a PHP app.

SonarQube vs the rest: the open source edition, the alternatives and the matchups

Most “SonarQube vs” searches compare products from different categories, so the useful answer is which category each one is in, not which one wins. The table under the alternatives heading below puts each vendor’s own description of itself side by side. No vendor here is linked, and none is ranked. The Semgrep and Fortify matchups are covered on the static code analysis tools page.

SonarQube open source, and SonarCloud vs SonarQube

SonarQube open source means the Community Build, the free self-managed edition, which leaves branch and pull-request analysis to the paid editions. SonarCloud vs SonarQube is hosted against self-hosted: SonarQube Cloud runs the analysis for you instead of on your own server and database.

SonarSource renamed its products in October 2024: SonarQube became SonarQube Server, SonarCloud became SonarQube Cloud, SonarLint became SonarQube for IDE, and the Community Edition became the Community Build. The downloads page lists what the paid Developer Edition adds over the free build, including “Analysis of feature branches, maintenance branches, and pull requests” and “Display quality gate status in DevOps pull requests for GitHub, GitLab, Bitbucket, and Azure DevOps.” That makes open source SonarQube a main-branch tool: it will not comment on a pull request by itself.

The hosted side has a free way in: SonarSource’s pricing page offers the “SonarQube Team Plan, free for your private projects up to 50k LOC” with no card needed. Self-hosting the free build is not free of work: its install guide has you set up a database, with PostgreSQL, Microsoft SQL Server and Oracle supported and an embedded H2 database used by default. A server and a database to patch are the real price of the free edition.

SonarQube alternatives and competitors, one row each

SonarQube alternatives depend on the job. Of the five named rivals, Snyk splits dependency and code scanning, Veracode sells a platform, Coverity targets large, complex software, Sonatype scans dependencies rather than your code, and Qodana runs JetBrains inspections in CI. My working rule for a small team: usually a linter, a type checker and one free scanner in CI.

Snyk vs SonarQube is mostly a category question. In Snyk’s docs, Snyk Open Source is “a developer-first software composition analysis (SCA) solution” and Snyk Code is “a developer-first static application security testing (SAST) solution”, while SonarQube Server calls itself an automated code review and static analysis tool. What people call Snyk code review is Snyk Code’s pull request check, which its docs say “can be applied to every pull request you create in your Git repository before you merge it into the target branch.”

Veracode vs SonarQube compares a platform that sells static, dynamic and dependency testing under one roof with a tool built around code quality and static analysis. Coverity vs SonarQube is closer, since Black Duck, Coverity’s owner, says it “scans source code without executing it” and pitches it at “large-scale, complex software”. Sonatype vs SonarQube is the real mix-up in the list: Sonatype’s products manage and check open source packages and binaries, so it looks at what you depend on, not the code you wrote. Qodana vs SonarQube comes down to where the rules come from, since Qodana runs the same inspections JetBrains IDEs run.

The open alternative to SonarQube is often already in reach: CodeQL costs nothing on public repositories, and the per-language tools above cover the rest. When people ask for SonarQube competitors, the honest shortlist for a two-person team is rarely another platform.

SonarQube AI code review and automated code review: what the scanner adds to a pull request

SonarQube automated code review is a quality gate on the pull request: the change passes or fails on conditions about new code, such as new issues and coverage. Its AI features sit beside the same rules. A rule match and a model’s opinion are different evidence, and a reviewer should know which one they are reading.

SonarSource’s docs define a quality gate as “a set of conditions against which the code is measured during analysis.” The built-in “Sonar way” gate has four conditions: “No new issues are introduced”, “All new Security Hotspots are reviewed”, “New code test coverage is greater than or equal to 80.0%” and “Duplication in the new code is less than or equal to 3.0%.” On self-managed SonarQube, the gate shows on a pull request only from the Developer Edition up, as the section above explains.

The AI side has two named features in the Server docs. AI CodeFix “uses a large language model (LLM) to suggest fixes for issues found during analysis”, and the SonarQube MCP Server is a “Model Context Protocol (MCP) server that connects your AI coding agent to SonarQube Server”; on the commercial editions it “can run directly on SonarQube Server”, and SonarSource’s pricing page calls it “Open source and free.” So SonarQube’s own review is still the rule engine; the model proposes a fix for a finding the rules already made. For AI-powered pull request review, the same docs point to Gitar, “a separate Sonar product.” A scanner comment says a rule matched; an AI reviewer’s comment says a model read the diff and had an opinion. Who publishes the rankings of review bots, and how they compare, is covered in who says which AI code reviewer is best.

ast-grep and Semgrep beside an AI coding agent: structural search, MCP servers and AI triage

Both tools come up when people wire analysis into Claude Code or Cursor, so they get their own section. What MCP and an MCP server are, and how you add one, is explained in how MCP servers work in Claude Code; this section assumes you know.

ast-grep: searching code by structure, and the ast-grep MCP server for Claude Code

ast-grep is a command-line tool that searches and rewrites code by syntax-tree pattern instead of by text. One pattern finds every call of a function whatever the spacing, which suits a coding agent doing a refactor. It finds what you ask for, not vulnerabilities.

ast-grep still sums itself up as “like syntax-aware grep/sed!”, and its guide calls it “an hybrid of grep, eslint and codemod.” The point for an agent is precision. A text search for a function name misses calls split across lines and hits comments; an ast grep pattern matches the call itself, so a refactor touches every real call and nothing else.

The ast-grep MCP server is, in the project’s words, “an experimental server that connects AI assistants, such as Cursor and Claude Code, with the powerful structural search capabilities of ast-grep.” For ast-grep with Claude Code, its docs also describe a skill that “teaches Claude how to write and use ast-grep rules to perform advanced code searches.” Neither turns it into a security scanner: its rules find what you tell them to find. Telling an agent when to reach for such a tool is part of guardrails for AI coding agents.

Semgrep MCP, Semgrep Assistant and the AI features

Semgrep MCP lets a coding agent run Semgrep on the code it just wrote and read the findings before a person does. Semgrep Assistant, now documented as Semgrep Multimodal, is the vendor’s AI layer for triaging and fixing findings. Both inherit the limit of every scan: no rule checks an access rule nobody wrote down.

The packaging has moved. The standalone Semgrep MCP server repository is deprecated, and “further updates to the Semgrep MCP server will be made via the official semgrep binary.” The agent product is now Semgrep Guardian, which “bundles the Semgrep MCP server, Hooks, and Skills into a single install, and scans every file an agent generates using Semgrep Code, Supply Chain, and Secrets.” It runs either on Semgrep’s hosted remote server or through a locally installed CLI. So the Semgrep MCP server now ships inside Guardian and the main semgrep binary rather than as a project of its own.

On the Semgrep AI side, the pages still filed under Semgrep Assistant are titled Semgrep Multimodal, which “adds AI-driven capabilities to Semgrep, including AI-powered detection, triage, and remediation of your findings” and “Requires the Semgrep AppSec Platform.” Semgrep itself, its rules and what is free are covered on the static code analysis tools page.

How to check your own app: run a first scan and prove it runs

A first code scan is proven by a plant, not by a clean report. Turn scanning on for pull requests, add the scanner’s own documented example of a flaw on a throwaway branch, and confirm the pull request shows the alert. Only then make new high-severity findings block the merge.

These steps hold for GitHub code scanning with CodeQL default setup on a JavaScript or TypeScript repository; the planted example uses Express and the pg library. The repository has to qualify first, as the GHAS section above sets out: public, or private with GitHub Code Security. If your repository is a personal private one on the Free plan, take the Semgrep path instead: run Semgrep Community Edition, which Semgrep calls “an open source static analysis tool”, in CI with the Express rule tainted-sql-string from its registry, which treats req.params as untrusted input and flags it when it is added to a string containing SELECT, and read steps 2 and 5 against that tool’s own docs.

The first rung needs only a browser. In the repository, open Settings, then Advanced Security under “Security and quality”, then choose Set up next to “CodeQL analysis” and click Default.

1. 01 Turn on default setup. It scans on each push to the default branch, on pull requests against the default branch, and weekly. Evidence: the tool status page shows the first scan with its timestamp and the share of files scanned.
2. 02 Plant the flaw. On a throwaway branch, add the vulnerable example from the CodeQL help page for "Database query built from user-controlled sources" (js/sql-injection, in the default javascript-code-scanning suite), shown below, and open a pull request against the default branch. Expect that alert as an annotation on the pull request. Evidence: the alert link. No alert means the scan is not running on that path or that language, which is exactly what the plant is for. Never merge or deploy the branch, and delete it afterwards.
3. 03 Read the real findings on the default branch. Dismiss nothing in bulk: each dismissal carries a written reason someone else can check.
4. 04 Fix what triage marks as reachable, then let the scan run again. Evidence: the open-alert count before and after, each with its date.
5. 05 Turn the scan into a gate. In Settings, open Rulesets, create a new branch ruleset, add a target under Target branches that includes the default branch, change its enforcement status from Disabled, select "Require code scanning results", add CodeQL, and set Security alerts to "High or higher". This covers public repositories and organization-owned repositories on Team or Enterprise with GitHub Code Security, not a personal private repository. Evidence: a test pull request that adds the plant again shows the merge blocked.
6. 06 Re-run after every dependency or framework upgrade, and read the weekly scan results rather than waiting for a pull request to touch the affected file.

The plant for step 2, copied from CodeQL’s help page for this query. Use it only as a test in your own repository, on a branch that is never deployed.

const app = require("express")(),
      pg = require("pg"),
      pool = new pg.Pool(config);

app.get("search", function handler(req, res) {
  // BAD: the category might have SQL special characters in it
  var query1 =
    "SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='" +
    req.params.category +
    "' ORDER BY PRICE";
  pool.query(query1, [], function(err, results) {
    // process results
  });
});

CodeQL rates this query’s security severity at 8.8, which falls in the CVSS “High 7.0 - 8.9” band that GitHub uses to label alerts, so the “High or higher” threshold in step 5 catches it. GitHub shows an alert on a pull request only when every line the alert points to is in the pull request’s diff, which a new file always satisfies. The rule set is explained on GitHub’s merge protection for code scanning page, and turning the rule on does not turn scanning on by itself. How to triage what the scan turns up is on the static code analysis tools page. Dead-code findings are a separate job: how to find unused code in a repo, and the duplication and complexity numbers a scan also reports belong to code quality checks.

The Production Hardening Sprint proves its pull-request checks in the same spirit, with changes that should fail and changes that should pass: under deliverable 7.3 we run linting, type checks, builds and tests on every pull request, and we verify it by submitting failing and passing changes and retaining the CI results.

Where the sprint fits

Each deliverable named here is one row on the published scope. Deliverable 3.5 audits dependencies, upgrades or removes known-vulnerable packages, and removes unused packages. Under 3.7, we review the application against the OWASP Top 10 and record findings, fixes, and evidence by category. For types, deliverable 10.6 enables TypeScript strict mode and resolves errors in TypeScript applications, with an equivalent strict-checking approach for other supported stacks. So that later AI-assisted changes are checked too, deliverable 10.8 provides CLAUDE.md, AGENTS.md, Cursor rules, or equivalents describing conventions and protected patterns, and adds CI checks for enforceable rules. And 3.10 tests the five highest-risk externally reachable attack surfaces, because implementation review alone may miss behavior exposed through real attack paths. Formal third-party certifications and independent audit opinions are separate from the sprint deliverables. Third-party hosting, service subscriptions and API consumption remain in your own accounts.

Common questions about code scanning tools

Is SonarQube still used?

Yes. SonarSource still sells SonarQube Server in Developer, Enterprise and Data Center editions, runs SonarQube Cloud with a free plan, and ships the free Community Build and the SonarQube for IDE extension. What changed in October 2024 is the naming, not the product: SonarCloud and SonarLint are the old names for the cloud and IDE products.

Can SonarQube detect dead code?

Partly. SonarQube has rules such as ‘Unused “private” methods should be removed’, ‘Unused “private” fields should be removed’, ‘Unused local variables should be removed’ and ‘Unnecessary imports should be removed’. Those catch unused pieces inside a file or class, not a whole feature that no route reaches any more; that needs the approach on the unused-code page named in the first-scan section.

How do I install AST-grep?

Install it with a package manager: brew install ast-grep through Homebrew, npm i @ast-grep/cli -g through npm, pip install ast-grep-cli through pip, or cargo install ast-grep --locked through Cargo; MacPorts and Nix work too. The command is then ast-grep, or sg for short, but on Linux sg is already the setgroups command, so use the full name there.

What is the difference between AST-grep and grep?

grep matches lines of text; ast-grep matches nodes of the code’s syntax tree. ast-grep’s own docs put it this way: “Using text-based tool for searching code is fast but imprecise”, and “Unlike traditional text-based search (grep, ripgrep), ast-grep understands the structure of your code”. In practice, grep finds a function’s name in comments and strings too, while ast-grep finds only the calls.

Can I use SonarQube in VS Code?

Yes, through the free SonarQube for VS Code extension, which analyzes a supported project on its own as soon as it is installed. Connecting it to SonarQube Server, SonarQube Cloud or the Community Build is optional; connected mode “joins SonarQube for IDE with SonarQube to deliver the full Sonar solution”, and it “does not push issues to the server.”