Code review is your last line of defence before a vulnerability ships to production. But most teams rely on human reviewers who are optimising for logic correctness, readability, and architectural fit — not for a comprehensive security check on every change.
What human reviewers miss
A senior engineer reviewing a PR is thinking about whether the feature works, whether the tests are comprehensive, and whether the code fits the team's patterns. They're almost never running through:
- Is this new dependency on the OSV database with a known CVE?
- Did this change introduce a raw SQL query where there wasn't one before?
- Does this new API endpoint do proper input validation?
- Did someone accidentally commit a secret in this branch?
- Does this new config file disable a security header?
These aren't failures of the reviewer. They're a checklist that humans reliably skip because they're not the focus of code review.
What automated security review adds
An AI security review agent that runs on every PR does the checklist that humans skip:
Dependency CVE scanning
Every added or updated dependency gets checked against the OSV and NVD databases at the exact version pinned in the PR. If [email protected] has a known prototype pollution vulnerability, you know before it merges — not when someone runs a quarterly audit.
Secret detection
Git history scanning with an extensive detection ruleset (API keys, database passwords, JWT secrets, cloud credentials) runs against every commit in the PR diff. If a developer committed a secret to a feature branch and then "deleted" it in the next commit, it's still in history and still leakable — the agent catches it.
Semantic vulnerability analysis
This is where AI beats grep-based SAST. The agent understands the data flow: a parameter coming in from a request, being passed through a service layer, and eventually landing in a database query without parameterization. That chain spans multiple files and functions — static pattern matching doesn't catch it, but semantic analysis does.
Config hardening checks
Does your repo have a SECURITY.md? A Dependabot config? A CODEOWNERS file? Are lockfiles committed? Did a PR change a Dockerfile to add --no-check-certificate to a wget call? These hygiene checks run automatically.
How to set it up
- Install the BattleTest GitHub App on your repository
- The app requests read access to your code and PR metadata
- Every new PR triggers a security review within 2–3 minutes
- Findings are posted as a PR comment with severity, code location, and remediation steps
There's no YAML configuration file. No security policy to write. The agent understands your codebase from context.
The review output
Each PR review produces:
- A risk score (0–100) for the overall change
- Individual findings sorted by severity (CRITICAL → HIGH → MEDIUM → LOW)
- For each finding: the specific line(s), the vulnerability type, why it's a problem, and how to fix it
- A summary paragraph explaining the security posture of this PR in plain English
What it doesn't replace
Automated security review is not a replacement for a human security engineer reviewing high-risk changes. It's a filter that ensures every PR has been checked for the obvious and automatable issues, so your security-aware engineers can spend time on the nuanced architectural questions.