Skip to main content
In this tutorial you’ll connect a GitHub repository to BattleTest 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’ll need a GitHub account and at least one repository with an open (or easily openable) pull request.
1

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.You’ll land on the BattleTest dashboard with a banner: “No repositories connected yet.”
2

Install the GitHub App

Click Connect GitHub in the banner (or in the left sidebar under Repositories).GitHub opens the App installation page. Choose the account or organisation that owns the repository you want to connect. Under Repository access, select Only select repositories and pick one repository to start with.Click Install & Authorize.You’re returned to the BattleTest dashboard. Your repository now appears with a green Connected badge.
BattleTest reads your code at review time to produce findings. Source code is not persistently stored. See what data is accessed and retained →
3

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 status check appears at the bottom of the PR page: battletest/security-review — In progress.
4

Read the security review

After 2–4 minutes, BattleTest posts a comment from battletest-security[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 will say so — that’s also useful signal. Not every finding requires immediate action; read Understanding findings to know how to triage them.
5

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 will now be reviewed automatically — you don’t need to trigger it manually. 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, secrets in commit history, injection patterns, config gaps. Here’s what a typical finding looks like in the PR comment:
The finding tells you exactly 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 battletest

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.