AI code security review: check every pull request and track CVEs in your dependencies

An AI code security review checks each change for the flaws that turn into incidents: injection, broken access checks, leaked secrets and vulnerable dependencies. Run it on every pull request. Then run a second check every day that compares your dependencies against newly published CVEs, because a library you installed months ago can become the risk overnight.

Why does AI-written code need a security review?

Because it ships flaws at a measurable rate. Veracode's 2025 GenAI Code Security Report tested over 100 large language models on coding tasks in Java, Python, C# and JavaScript. 45% of the code samples failed security tests and introduced an OWASP Top 10 vulnerability. Against cross-site scripting, the models failed to defend in 86% of the relevant samples.

The code compiles, the tests pass and the feature works, so nothing looks wrong. A security flaw only shows when someone checks for it.

What should a security review of a pull request check?

Check	What to look for
Injection	User input reaching a SQL query, a shell command or a file path without being escaped or parameterised
Cross-site scripting	User input rendered into a page without escaping
Access control	A new route or API that skips the login check, or lets one user read another user's data
Secrets	Keys, tokens or passwords written into code, config or logs
Data handling	Personal data logged, sent to a third party, or stored without a reason
Dependencies	A new package, or a version change, with a known vulnerability

Keep the review to the diff. A reviewer that reads the whole repository on every change produces long reports nobody reads. One that reads what changed produces a short list somebody fixes.

How do you run a security review on every pull request?

Three common ways, from lightest to most complete:

1. By hand before you commit. Claude Code's /security-review command runs a security analysis from your terminal, explains what it finds and can apply the fix. It looks for SQL injection, cross-site scripting, authentication and authorization flaws, insecure data handling and dependency vulnerabilities.
2. In CI on every pull request. Anthropic's GitHub Action for the same review runs when a pull request opens and posts inline comments with each concern and a recommended fix.
3. As a workflow with a checklist. The review runs on every pull request, a second check holds the report to a fixed bar, and the result lands where your team already looks.

The first two review the code. The third also checks the review: whether every changed file was covered, whether each finding names a file and line, and whether the report reached the people who act on it.

Why track CVEs in your dependencies?

48,185 CVEs were published in 2025, up 20.6% from 2024. Most will never touch your app. The few that do arrive without warning, in a package you installed months ago and have not looked at since.

The window to act is short. VulnCheck's State of Exploitation 2026 found that 28.96% of the vulnerabilities known to be exploited in 2025 were exploited on or before the day their CVE was published. A monthly dependency check finds those weeks late.

How do you track CVEs before they affect you?

1. Know what you run. Your lockfiles, such as package-lock.json, poetry.lock or go.sum, list every package and version, including the ones your packages pulled in.
2. Check every day. Compare those versions against an advisory database. npm audit does this for a JavaScript project, and the public OSV database covers most package ecosystems through one API.
3. Report only what changed. Yesterday's findings are already known. A daily report that repeats them gets ignored by the third day.
4. Name the fix. Each finding carries the package, the installed version, the version that fixes it and where the package is used.
5. Open the upgrade as a pull request. The fix goes through the same review as any other change, and a person merges it.

How do you set up both as workflows?

	Pull request review	Dependency CVE watch
Trigger	A pull request opens on your repository	Every weekday at 8:00
Brief	Review the diff for injection, cross-site scripting, access control, secrets, data handling and new dependencies	Check every lockfile in the repository against known advisories and report what is new since yesterday
Output	A findings report, each finding with file, line, severity and a suggested fix	A list of new findings, each with package, installed version and fixed version
Checklist	Every changed file is listed; every finding names a file and line; no finding points outside the diff	Every lockfile was checked; every finding names a fixed version; nothing reported yesterday is repeated as new
Where it goes	A comment on the pull request	Your team's Slack channel

Write a workflow in the Kavela docs walks through each part.

How does Kavela run security reviews?

In Kavela you describe both jobs in plain words, and Kav, the lead agent, sets them up as workflows.

• Connect GitHub once. The connection belongs to the workspace, so every agent can clone your repositories, read a diff, and comment on or open a pull request with git and gh in its own cloud computer.
• Runs on every pull request. Kav places the workflow's address on your repository through GitHub's API, for the events you name, such as a pull request opening.
• Runs on a schedule. The dependency watch runs at the times you set, such as every weekday at 8:00. The agent can run npm audit or query the OSV database from its computer.
• Every run is checked. A second agent checks each report against your checklist, line by line. A report that skipped a file or left a finding without a line number goes back with the gap.
• Results reach your team. Each report is saved to your workspace files and can be sent to a Slack, Discord, Telegram or Lark chat you name.
• Fixes come back as pull requests. Ask the agent to open the upgrade as a pull request, and you review and merge it.

Each agent works in its own cloud computer, on your own Claude or Codex plan.

Kavela starts with a 14-day free trial, no card. Start your free trial