AI pentesting on every pull request
Updated · By Rokkhe team
Rokkhe can test every pull request in two ways. In your own CI job, run the CLI with --diff-base to focus the engagement on what changed, --non-interactive for headless mode and --max-budget-usd to cap model spend; exit code 2 means it reported findings. Or, on a deployment with the GitHub App configured, enroll a repository, and Rokkhe scans each pull request and comments on the changed lines.
What does the CI command look like?
bashrokkhe \
--target . \
--diff-base origin/main \
--non-interactive \
--scan-mode quick \
--max-budget-usd 5Check out with full history (fetch-depth: 0): diff scope needs the merge base. In a CI job building a pull request, the default --scope-mode auto turns diff scope on by itself, and --scope-mode full turns it off.
What does diff scope change?
It tells the agents which files the pull request added or modified. Added files are reviewed whole, modified files around their changes, and other files only for context; findings are reported only when they relate to the change. It focuses the engagement rather than hiding the rest of the repository.
How does the job pass or fail?
| Exit code | Meaning |
|---|---|
| 0 | The run completed and reported no vulnerabilities. |
| 1 | Setup or the engagement failed. |
| 2 | The run reported at least one vulnerability, or the command line was invalid. |
| 3 | Another process already holds this run name. |
How do I keep the cost bounded?
--max-budget-usd is a ceiling on model spend for the whole run, and the scan stops cleanly when it is reached. --scan-mode quick is the mode meant for CI checks; the default is deep.
What does the GitHub App do?
- An Owner or Admin enrolls a repository that their GitHub account can write to, and picks a scan mode (quick by default) and an optional budget.
- When a non-draft pull request is opened, updated, reopened or marked ready, Rokkhe opens a check run and launches a governed scan of the head commit, scoped to the diff against the base.
- When the run finishes, it posts a review with inline comments on lines the pull request added: up to 30, for critical, high and medium findings.
- The check run fails when the diff has a critical or high finding, is neutral for lower severities, and succeeds when there are none.
What about pull requests from forks?
They are not scanned automatically, so outsiders cannot spend the workspace's model budget. Someone with write access can comment @<app> review on the pull request to scan it; the scan is pinned to the head commit that existed when they asked.
Where do findings go next?
Open the fix as a pull request with /docs/remediation, then confirm it with /docs/retests. /docs/cli lists every flag.