SOURCE REVIEW / AI security · Review tools
Code and security
review tools
A dated comparison of OpenAI and Anthropic code review and security scanning tools, their scope and access, and where different checks fit in the software development lifecycle.
- Article date
- Base notes dated
- Latest source check
THE SHORT VERSION
Key points.
- Scope comes first: a code review, a security review of changes and a repository scan answer different questions.
- Repeat checks by trigger: establish a baseline, review changes and deepen assessment when security assumptions change.
- Findings need evidence: source analysis, executed validation and release approval remain distinct.
01SOURCE REVIEW
What is being reviewed?
Choose a review by the question it needs to answer. Code review looks for consequential defects and regressions. Security review focuses on vulnerabilities and threats. Either can examine a change set or a broader codebase; the product name alone does not establish the scope.
A diff review concentrates on changed code and relevant supporting paths. A repository scan can investigate vulnerabilities already present elsewhere. OpenAI and Anthropic offer separate workflows for these scopes, as well as checks integrated into coding or pull requests. [03] [10] [12]
Source review and runtime testing provide different evidence. Claude’s managed Code Review reads source without building or running it. Codex Security distinguishes source evidence from an executed reproducer. A scan result therefore needs its scope, validation method and coverage alongside it. [07] [06]
02SOURCE REVIEW
Code review and security scanning products
The table compares documented scope, access and review triggers. Similar names can refer to separate managed services, local commands or plugins; their setup and available evidence differ.
| Product | Scope, function and access | Checked / sources |
|---|---|---|
| Codex Code ReviewOpenAI | Reviews GitHub pull-request changes for consequential bugs, including security issues, with repository guidance from AGENTS.md. Connect GitHub, then configure automatic reviews or request @codex review. | [01] |
| Codex Security ReviewOpenAI | Investigates security issues in a PR diff and supporting code, using threat-model context and reporting thresholds. Automatic triggers or @codex security review. Pro, Business, Enterprise and Edu; not Plus. | [02] |
| Codex Security: plugin, CLI and SDKOpenAI | Scans a local repository, folder or change set; records findings, evidence and coverage. CLI and SDK support automation. Plugin in Codex; standalone @openai/codex-security package for CLI/SDK. OpenAI inference requires Security access; full CLI scans may also require Trusted Access. | [03] [04] |
| Codex Security CloudOpenAI | Runs one-time GitHub repository scans or monitors new commits, with findings and remediation workflows. Separate Cloud plugin, workspace access, GitHub connection and a Codex cloud environment. | [05] |
| Claude Code ReviewAnthropic | Managed multi-agent review of GitHub PRs for logic errors, security issues and regressions. Reads source without building or running it. Team and Enterprise. Enable the service, then use automatic triggers or @claude review; merge gates remain separate. | [07] |
| Claude Code /code-reviewAnthropic | Reviews branch changes in the coding session; can target a PR, commit range, file or directory. Local command on any plan, using session usage or API billing. Separate from the managed PR service. | [08] |
| /security-review and GitHub ActionAnthropic | The command makes one security pass over current-branch changes. The separately configured Action reviews PR changes. Claude Code, including Pro/Max and API users. Invoke the command or install and configure the Action. | [09] [12] |
| Claude Security pluginAnthropic | Scans an entire repository or a diff with architecture mapping, threat modelling and multi-agent finding review; can propose patches. Install the plugin and run /claude-security. Uses paid-plan, API or supported provider access; local checkouts can come from GitLab or Bitbucket too. | [10] |
| Claude Security on the webAnthropic | Scans connected codebases for vulnerabilities, validates findings and suggests patches for review. Enterprise public beta; organization enablement and GitHub connection. Distinct from the Claude Code plugin. | [11] |
| Security guidance pluginAnthropic | Checks code as Claude writes it, combining edit-time patterns with separate reviews of turn and commit changes. Runs automatically after installation. Does not block writes or commits; complements later scans and review. | [12] |
| OSS ScannerAnthropic | Provides periodic vulnerability scans for accepted open-source projects. Reports arrive without human triage. Free, opt-in service for qualifying established projects; acceptance is assessed individually. | [13] |
03SOURCE REVIEW
Review timing across the lifecycle
The following graphic brings together lifecycle guidance and risk-based scoping. It is an editorial synthesis, not a prescribed sequence of vendor products. Checks can overlap, and findings can send work back to design, implementation or tests. [14] [18]
For an existing application without a documented baseline, first establish its architecture, security assumptions and assessment scope. Subsequent changes can be assessed against that baseline. Review depth follows changes to the attack surface; a new feature is not automatically equivalent to a new full audit. [15] [16]
EXPLAINED VISUALLY
When to review — and how deeply
WHERE IN THE SOFTWARE DEVELOPMENT LIFECYCLE
- 01Design
Requirements, architecture & threat model
- 02Build
Tests, static analysis, dependencies & secrets
- 03Change review
Review the diff and affected code paths
- 04Release
Verify runtime behaviour & deployment settings
- 05Operate
Track vulnerabilities, changes & new evidence
Activities overlap. Findings feed back into design, fixes and tests.
When to repeat the checks
- Initial baselineNew application
- Assess architecture, the repository and relevant runtime risks before first release. Revisit after major changes.
- Every changeDevelopment & integration
- Run automated baseline checks and review affected behaviour. This does not mean a full repository audit on every pull request.
- Risk-triggeredSecurity assumptions change
- Revisit affected threats and deepen review for new interfaces, permissions, sensitive data, dependencies or infrastructure.
- RecurringMaintenance & operations
- Reassess on a risk-based schedule and when new vulnerabilities or incidents emerge, even without a code change.
Scope follows the change
Presentation checks + baseline
Check the diff, appearance and contrast. A purely cosmetic change normally needs no new full audit.
Targeted tests + review
Test affected behaviour and confirm that existing security assumptions still hold. Escalate if they change.
Deeper security review
Update affected threats; test access boundaries and misuse cases, including relevant runtime paths.
These examples are an editorial application of the guidance. “Cosmetic” assumes no change to behaviour, data flows, dependencies or security configuration. Code scans do not replace tests of the running application.
Required controls still apply. AISVS Appendix C, AC.4.2 (Level 2), specifies automated security testing on every pull request containing AI-generated code. Risk-based scoping does not waive an applicable requirement. [19]
An editorial synthesis of OWASP and ENISA guidance, consistent with NIST SSDF’s risk-based approach. The phases overlap and repeat; they are not the exact phase names of any one framework or a record of checks run on this website. OWASP and ENISA sources checked 18 October 2026; individual source dates are listed below.
04SOURCE REVIEW
What these tools can establish
A finding is a claim to investigate. Check affected code, exploit conditions, validation evidence and the proposed fix. An empty report does not prove the absence of vulnerabilities; coverage limitations and failed analysis still matter. [06] [04]
AI review complements static analysis, dependency scanning and tests of the running application. These checks cover different failure modes. A repository scan cannot by itself establish that deployed access controls, infrastructure or operational settings behave correctly. [12] [14]
Findings and merge authority are separate. Claude’s managed review does not approve or block a pull request, and its security guidance plugin does not block writes or commits. Required checks and approval gates need their own configuration. [07] [12]
The companion article on testing develops test objectives, coverage and security-testing methods. The article on review and approval compares who examines changes, who can accept them and where human judgment remains involved.
Choose the review scope and repetition trigger before choosing a product. Interpret its findings alongside conventional checks, runtime evidence and a clear approval policy.
REFERENCES / 19
Sources.
This overview summarises provider documentation and institutional guidance. Product capabilities and access were checked on 18 October 2026; individual source records retain their check dates. It is not a hands-on comparison or a record of tools run on this website.
- OpenAI — Review GitHub pull requests with Codex (opens in a new tab)
PR scope, GitHub setup, automatic review, @codex review and repository rules in AGENTS.md.
- OpenAI — Codex Security Review (opens in a new tab)
Eligible plans, PR diffs and supporting code, threat-model context, reporting thresholds and @codex security review.
- OpenAI — Codex Security (opens in a new tab)
Separate Cloud, plugin, CLI and SDK workflows; repository scans, change reviews and report handling.
- OpenAI — Codex Security CLI quickstart (opens in a new tab)
Public package, Security access, possible Trusted Access requirement and the distinction between scan completion and coverage.
- OpenAI — Codex Security Cloud setup (opens in a new tab)
Separate Cloud plugin, workspace access, GitHub connection, environment, one-time scans and continuous commit monitoring.
- OpenAI — Codex Security Cloud FAQ (opens in a new tab)
Findings and validation: source evidence versus execution evidence; coverage limits; proposed patches and verification of fixes.
- Anthropic — Claude Code Review (opens in a new tab)
Availability, managed review, source-only analysis, review triggers and the separation of findings from PR approval or blocking.
- Anthropic — Review locally with /code-review (opens in a new tab)
Local command, supported targets, plan usage and separation from the managed service and cloud ultrareview.
- Anthropic — Automated Security Reviews in Claude Code (opens in a new tab)
Displayed page date: 16 March 2026. Availability, on-demand command and separately configured GitHub Action. The security-guidance documentation specifies that /security-review covers current-branch changes.
- Anthropic — Scan your codebase for vulnerabilities (opens in a new tab)
Claude Security plugin: repository and diff scans, multi-agent finding review, patching, prerequisites and model/provider access.
- Anthropic — Use Claude Security (opens in a new tab)
Enterprise public beta, organization enablement, GitHub access, finding validation and remediation. Separate from the Claude Code plugin.
- Anthropic — Catch security issues as Claude writes code (opens in a new tab)
Automatic in-session checks after plugin installation; no write or commit blocking. How this fits with other security tools specifies the branch-change scope of /security-review.
- Anthropic — OSS Scanner (opens in a new tab)
Opt-in periodic scanning at no cost; eligibility for established security-relevant open-source projects; reports without human review or triage.
- OWASP WSTG 4.2 — The Web Security Testing Framework (opens in a new tab)
Flexible framework across design, development, deployment and operation. The graphic uses an editorial grouping, not the exact WSTG phase names.
- OWASP — Attack Surface Analysis Cheat Sheet (opens in a new tab)
Managing the Attack Surface: baseline assessment, incremental changes, new APIs/uploads, authentication, authorisation and architecture.
- OWASP SAMM — Threat Modeling (opens in a new tab)
Iterative scope, triggers for updates and regular review of existing threat models. Activities are organised by maturity level.
- ENISA — Secure coding and verification practices (opens in a new tab)
Mutable official playbook: peer review for sensitive changes; SAST and dependency checks on each PR; negative tests, secrets checks and release evidence.
- NIST — Secure Software Development Framework (SSDF), Version 1.1 (opens in a new tab)
Final publication; PW.7.1 and PW.7.2, printed p. 14 (PDF p. 23). Content retained from the 11 October check.
- OWASP AISVS — Appendix C: AI-Assisted Secure Coding (opens in a new tab)
Mutable main branch, 1.01 directory. AC.4.2 specifies automated security testing on every PR containing AI-generated code at Level 2; AC.4.4 adds review requirements for critical files.