Semgrep for code review
Semgrep's official server is our second pick for code review, and it brings the analysis half of the job: scanning the change for security vulnerabilities and quality issues, then handing back concrete, rule-backed findings rather than guesses. A review built on it surfaces real risks the agent can point to in the diff.
It ranks second because review needs the change in context first, and that is where GitHub leads, the pull request, the diff, the discussion all live there. Semgrep is the layer that makes the review substantive: once the agent can see the change, Semgrep tells it what is actually wrong with it.
How Semgrep fits
semgrep_scan runs against local file paths and semgrep_scan_remote against provided code content, so the agent can analyze exactly the files a PR touches and get findings as JSON. semgrep_scan_with_custom_rule catches violations of your own conventions that default rulesets miss, semgrep_scan_supply_chain flags vulnerable dependencies the change pulls in, and semgrep_findings retrieves existing AppSec Platform results when authenticated. get_abstract_syntax_tree and semgrep_rule_schema support writing precise rules for recurring review issues.
The honest division of labor: Semgrep does not read the pull request, its comments, or its review threads, so it cannot summarize the discussion or post a review on its own. GitHub fits that role and ranks first here for owning the PR surface, GitLab covers the same for GitLab-hosted repos, and SonarQube fits better when you want a quality platform with maintainability tracking and merge gates over time. Pair Semgrep with the review platform: let GitHub or GitLab hold the diff, and let Semgrep find the vulnerabilities in it.
Tools you would use
| Tool | What it does |
|---|---|
| semgrep_scan | Runs a Semgrep scan locally on the provided code files (absolute paths) and returns the findings in JSON format. |
| semgrep_scan_remote | Runs a Semgrep scan on provided code content (rather than local file paths) and returns the findings in JSON format. |
| semgrep_scan_with_custom_rule | Runs a Semgrep scan with a custom rule against provided code content, for vulnerabilities not covered by the default rulesets. |
| semgrep_scan_supply_chain | Runs a Semgrep supply-chain scan on a workspace directory to identify third-party (dependency) security vulnerabilities. |
| semgrep_rule_schema | Returns the schema for a Semgrep rule, showing the fields available when writing or verifying a rule. |
| semgrep_findings | Fetches existing security, code-quality, and supply-chain findings from the Semgrep AppSec Platform Findings API (requires authentication). |
| get_supported_languages | Returns the list of programming languages supported by Semgrep. |
| get_abstract_syntax_tree | Returns the abstract syntax tree (AST) for a provided code file in JSON format, to understand its structure. |
| semgrep_whoami | Returns the identity of the currently authenticated user (works with JWTs, not API tokens). |
FAQ
- Can Semgrep read a pull request or post review comments?
- No. Semgrep scans code through semgrep_scan and semgrep_scan_remote and returns findings, but it does not read PR diffs, discussion, or post comments. GitHub owns that surface and ranks first here, so the strong setup pairs GitHub for the diff with Semgrep for the analysis.
- How does Semgrep make a code review more concrete?
- By returning rule-backed findings the agent can cite in the diff. semgrep_scan flags issues in the changed files, semgrep_scan_with_custom_rule enforces team conventions, and semgrep_scan_supply_chain catches vulnerable dependencies the change introduces, so the review rests on findings rather than impressions.