Code Security Reviews in 2026

Code is being written faster than ever, much of it with AI assistance, and security review has had to keep pace. In 2026 a good code security review combines fast, deterministic tools with AI reviewers that can reason about how code actually behaves, and a human who makes the final call.

This article is for developers, team leads and IT managers who have been asked to "make sure the code is secure". It covers the layers of a modern review, the tools for each, how to get real value from AI reviewers such as Claude, and where those tools still fall short.

The six layers of a modern review

No single tool finds everything. Each layer below catches a different kind of problem, and together they cover far more than any one of them alone.

Layer	What it catches	Speed and cost	When it runs
Linting	Risky patterns, unsafe functions, sloppy code that hides bugs	Seconds, free	In the editor and on every commit
Static analysis (SAST)	Injection, unsafe data flows, known weakness patterns	Minutes, free to moderate	Every pull request
Secret scanning	API keys, passwords and tokens committed to the repository	Seconds, free	Every commit and push
Dependency and supply chain	Vulnerable or malicious third-party packages	Seconds to minutes, free	Every pull request, plus daily
AI-assisted review	Logic flaws, broken access control, issues spread across several files	Minutes, paid per use	Every pull request, plus periodic deep scans
Human review	Business logic, design decisions, whether a finding actually matters	Hours, your team's time	Every pull request, and before major releases

The first four layers are deterministic: the same code gives the same result every time, which makes them ideal as automatic gates. AI and human review are where judgement comes in.

Linting and static analysis

Linters and static analysis (SAST) tools read your source code without running it, looking for patterns known to cause trouble. They're fast, cheap and consistent, so they belong at the very start of the process.

Start with a security-aware linter for your language

Language	Tool	Notes
JavaScript and TypeScript	ESLint with eslint-plugin-security	Flags eval, unsafe regular expressions and risky file access.
Python	Bandit	Finds hard-coded passwords, unsafe deserialisation and shell injection.
PHP	PHPStan or Psalm	Psalm's taint analysis traces user input to dangerous functions.
C# and .NET	Built-in Roslyn analysers	Turn on the security rules and treat warnings as errors in CI.
Go	gosec	Covers SQL injection, weak crypto and file permission issues.
Ruby on Rails	Brakeman	Rails-aware, so it understands controllers and views.

Add a cross-language SAST tool

• Semgrep: fast, with readable rules you can write yourself. The open-source Community Edition is a good default for small teams.
• CodeQL: GitHub's deep semantic analysis, which treats code as data you can query. Free for public repositories; private repositories need a paid GitHub security licence.
• SonarQube: combines code quality and security in one dashboard. The free Community Build covers the main languages.

Two tips save a lot of frustration. First, introduce tools in warning-only mode and fix the backlog before making them block merges. Second, tune out noisy rules rather than letting developers learn to ignore the tool.

Secrets, dependencies and the supply chain

Most modern applications are largely third-party code, and some of the most damaging breaches start with a leaked key rather than a coding bug.

Secret scanning

• Run Gitleaks or TruffleHog as a pre-commit hook and in CI, so keys are caught before they reach the shared repository.
• Turn on your platform's push protection (GitHub, GitLab and Bitbucket all offer it).
• Scan the full git history once. Deleting a secret in a later commit doesn't remove it from history.
• If a secret leaks, rotate it immediately. Removing it from the code is not enough.

Dependency scanning

• Use Dependabot, Renovate or your language's audit command (npm audit, pip-audit, dotnet list package --vulnerable) to flag packages with known vulnerabilities.
• Commit lock files, so every build installs exactly the versions you reviewed.
• Generate a software bill of materials (SBOM) with a tool such as Syft, so you can answer "are we affected?" in minutes when the next major vulnerability is announced.

Supply chain attacks

Attackers now target package registries directly. In 2025 the self-replicating Shai-Hulud worm compromised hundreds of npm packages, stealing developer credentials and publishing malicious versions under trusted names (Check Point Research). Known-vulnerability scanners can't catch a package that is malicious from the moment it's published, so add a few habits:

• Delay adopting brand-new package versions by a few days where your tooling allows it.
• Disable or restrict install scripts for packages that don't need them.
• Use short-lived, narrowly scoped tokens for publishing and CI.
• Check OpenSSF Scorecard results before adopting an unfamiliar package.

AI-assisted security review

This is the biggest change in recent years. Traditional SAST tools match patterns. AI reviewers can read code more like a security researcher: following data from a web request through several files, understanding what a function is meant to do, and noticing when an access check is missing rather than wrong. That makes them good at exactly the issues pattern-matchers miss, such as broken access control and flawed business logic.

The Claude options

Anthropic currently offers several ways to run security reviews with Claude, each suited to a different moment:

Tool	Best for	How it works
/security-review in Claude Code	A quick check before you commit	Run it in your project; it explains each finding and can implement fixes on request.
Claude Code Security Review GitHub Action	Every pull request	Reviews only the changed files and posts inline comments, filtering out common low-value findings.
Claude Security plugin (beta)	Periodic deep scans of a whole codebase	Multiple agents model threats, research and then vote on each finding; it writes a report and patch files you apply yourself.
Claude Code Security (Team and Enterprise)	Organisation-wide scanning	Launched in February 2026 as a research preview: findings are verified, rated for severity and confidence, and patches wait for human approval.

Other platforms offer similar features, including GitHub Copilot code review and Copilot Autofix. Whichever you choose, the techniques below make the results far more useful.

How to get good results

• Give it context. Describe the architecture, the authentication model and what counts as sensitive data, for example in a CLAUDE.md file. A reviewer that knows "only admins may export reports" will spot a missing check.
• Ask for evidence. Require the file and line, the path the data takes, and a realistic attack scenario for every finding. Vague warnings are hard to act on.
• Focus the review. "Check every API endpoint for missing authorisation checks" beats "find security issues".
• Prove it with a test. Ask for a failing test that demonstrates each finding before accepting a fix. This weeds out false positives quickly.
• Combine it with your scanners. Feed SAST and dependency results to the AI and ask it to triage which are genuinely exploitable in your code.

A focused prompt might look like this:

Review the changes on this branch for security issues. Focus on authorisation:
for every new or changed API endpoint, confirm the user can only access their
own organisation's records. For each finding, give the file and line, how an
attacker would exploit it, the severity, and a failing test that proves it.
Ignore style issues.

Limits, risks and the human in the loop

AI reviewers are powerful, but they need to be used with your eyes open.

• Results vary between runs. The same code can produce slightly different findings each time. Use AI review alongside deterministic scanners, never instead of them.
• False positives and misses both happen. Vendors filter and verify findings, but Anthropic's own documentation is clear that these tools supplement manual review and existing security practices rather than replace them.
• Prompt injection is real. Code, comments and documentation can contain text written to manipulate an AI reviewer. Anthropic's GitHub Action notes it is not hardened against prompt injection and should only review trusted pull requests (README). For public repositories, require maintainer approval before workflows run on outside contributions.
• Scan untrusted code in a sandbox. If you're reviewing code you didn't write, such as an inherited project or a third-party plugin, run the AI tools in an isolated environment.
• Mind your data. Check what your plan's terms say about how code is handled, and confirm that sending source code to an AI service is acceptable under your client contracts.
• Never auto-apply fixes. Every patch should go through a normal pull request with tests and a human reviewer. A fix that closes one hole can quietly open another.

Human reviewers remain essential for the questions no tool can answer: should this feature exist, is this the right way to store this data, and does this finding actually matter to the business?

A practical workflow

Here's how the layers fit together in a typical team's day. Fast, deterministic checks block merges; slower AI and human reviews add judgement on top.

1. In the editor. Security linters flag problems as code is written. Developers can run /security-review before committing a significant change.
2. On commit. A pre-commit hook runs the secret scanner and linters. Leaked keys never leave the developer's machine.
3. On every pull request. CI runs SAST, dependency scanning and secret scanning, and blocks the merge on high-severity findings. The AI reviewer comments on the changed code, and a human reviewer weighs both before approving.
4. Daily. Dependency alerts check for newly published vulnerabilities in packages you already use.
5. Quarterly, and before major releases. Run a deep AI scan of the whole codebase, triage the findings as a team, and pair it with a dynamic test of the running application (see our guide to hardening and penetration testing a web server).

Track every confirmed finding to closure in your issue tracker, with an owner and a due date based on severity. The tools find problems; only the process makes sure they get fixed.

Need a hand?

Setting up these layers, tuning out the noise and deciding which findings really matter takes experience. At James Anthony Consulting, code security reviews and security audits are part of our everyday work, on systems we've built and on codebases we've inherited from others.

If you'd like an independent review of your code, help setting up security checks in your pipeline, or advice on using AI review tools safely, we'd love to hear from you. Reach out to the JAC team to find out more.