Get Your First PR Security Review

In this tutorial you’ll set up a BattleTest workspace, connect a GitHub repository, and get a real automated security review posted on a pull request. By the end you’ll have seen what the tool does and be ready to use it on your own work.

You need a GitHub account and at least one repository with an open (or easily openable) pull request.

Sign up

Go to battletest.dev/login and click Continue with GitHub. GitHub will ask you to authorise BattleTest to read your profile and email. Click Authorize.

BattleTest opens a short two-step setup: first you’ll name your workspace, then connect GitHub.

Create your workspace

A workspace is where your repositories, findings, team, and billing live. Enter a name (your own or your company’s is fine) and click Create workspace.

You can rename it later, so don’t overthink it.

Connect the GitHub App

On the next step, click Install GitHub App.

GitHub opens the App installation page. Choose the account or organisation that owns the repository you want to review. Under Repository access, select Only select repositories and pick one repository to start with.

Click Install & Authorize.

You’re returned to BattleTest and land on your dashboard. Your repository now appears with a green Connected badge.

Note

BattleTest processes relevant code to produce review results and stores findings with the evidence needed to explain them. It does not create a general-purpose copy of your repository. See what data is accessed and retained →

Open a pull request

Go to your repository on GitHub and open a pull request: any change, however small. If one is already open, push any new commit to it.

Within 30 seconds, a new check appears at the bottom of the PR page: BattleTest Security Review — In progress.

Read the security review

After 2–4 minutes, BattleTest posts a comment from battletest[bot].

The comment opens with a risk score (0–100). Scores up to 20 are clean: the diff looks clear. Scores above 60 mean findings require attention before merging. How risk scores are calculated →

Below the score, findings are listed by severity: CRITICAL first, then HIGH, MEDIUM, LOW. Each finding shows:

• The file and line number
• What the vulnerability is, in plain English
• The vulnerable code in context
• A drop-in fix with a working code example
• CWE and OWASP category references

If the PR has no findings, the comment says so: that’s also useful signal. Not every finding requires immediate action. Read Understanding findings to know how to triage them.

View the full run in the dashboard

Click View full report → at the bottom of the PR comment. This opens the run detail page where you can see expanded reasoning for each finding and compare this PR against others on the same repository.

Every pull request on this repository is now reviewed automatically. No manual trigger, no YAML to write, no runner minutes, no configuration to maintain. Every PR that opens from this point forward gets a full security pass: dependency CVEs, exposed secrets, injection patterns, config gaps.

Here’s what a typical finding looks like in the PR comment:

Screenshot to addA single finding in the PR comment: severity, type, and file:line, followed by the explanation, the vulnerable code, the fix, and CWE/OWASP references.

The finding tells you what’s wrong, where it is, why it’s a problem, and what to type to fix it, in your language and framework.

What’s next

PR Findings reference

What each field in a finding means, how risk scores are calculated, and the finding lifecycle.

Run a live security test

Test your running infrastructure, not just the code.

Require review before merging

Block PRs with the BattleTest status check.

Add a live target

Add a domain for autonomous security assessment.