Skip to main content
BattleTest runs two distinct analysis pipelines depending on whether it’s examining code or live infrastructure. Both feed into the same finding record, which is what makes cross-product regression detection possible.

​
Two pipelines

PR review runs four analysis passes in parallel when a pull request event arrives: secret detection across full branch history, dependency CVE analysis, configuration hardening checks, and AI code analysis. For what each pass catches and why the AI pass runs last, see How PR review works. Live battletest runs three sequential phases against a running target: passive discovery, permission-gated targeted testing, and reporting. Each phase depends on the output of the previous one. For the phases and the permission tier model, see How Live BattleTest works. The two pipelines differ in structure for a reason: code review passes are independent, so they parallelise; live phases build on each other, so they’re sequential.

​
How scans are coordinated

Each scan is managed by a set of coordinating components: The orchestrator is the persistent coordinator. The repository and site coordinators are each scoped to a single repository or domain and maintain their own state across scans of the same target — that’s how regression detection works without re-reading the full history on every scan.

​
How the two products share data

PR review and live battletest write to the same finding record per organisation. Each finding is stored with a vector embedding of its description, used for semantic similarity matching. When a live scan produces a finding, BattleTest checks whether a semantically similar finding has been seen in PR review for the same organisation. If the same vulnerability pattern appears in code and in the running application, the live scan finding is flagged as having a code-level counterpart. This is what lets you trace a vulnerability from the commit that introduced it through to confirmation that it’s exploitable in production. The reverse also applies: if a vulnerability was confirmed in a live scan and then disappears from a subsequent scan (because you deployed a fix), but the corresponding PR review finding is still open, BattleTest notes the discrepancy. The fix is in production but the code finding is still open — that’s worth knowing.

​
Timing

Scans run on dedicated cloud infrastructure, not shared queues, so timing is fairly consistent. A PR review takes 2–4 minutes; live scans range from minutes to an hour depending on the phase and target size. See Limits & Quotas for the full table. A scan that runs significantly longer than expected either encountered a very large target or hit an infrastructure issue — see Troubleshooting.