Security
Pentest
A pentest engagement attacks one of your repositories in an isolated sandbox and reports only what it proved. Every pentest finding arrives with a working proof of concept and the evidence captured while it ran.
Enabling a repository, choosing its attack classes and starting an engagement are admin tasks. Everyone with pentest access can read what an engagement proved.
#What an engagement does
inline clones the repository into a sandbox, looks for the vulnerability classes you enabled, and then tries to exploit what it found. A candidate that cannot be exploited is dropped, so what appears on the Pentest Findings page has already been demonstrated.
Autonomous red team
AI agents attack your repositories' own code in an isolated sandbox, prove exploitability with non-destructive proofs-of-concept, and surface only validated findings.
Enabled repos
4
Open validated
2
Critical / High
1
Recent runs
9
Recent engagements
The Pentest Overview shows engagements newest first, with a live badge while one runs: Enumerating, Attacking, Validating and Reporting, then Complete. An engagement in progress can be opened and watched.
#Reading a pentest finding
The Pentest Findings page is titled Validated findings, which is the distinction that matters: each one comes with a proof of concept that ran and the evidence it produced.
That makes a pentest finding a different kind of thing from a review finding. A review finding is a point inline raises about code it read; a pentest finding is a vulnerability it exploited in a sandbox and captured the result of.
#Setting up a repository
The Pentest Settings tab lists your repositories, each with a switch and its own configuration.
Choose the Depth.
Light leans on static analysis. Tiered works in stages, from reconnaissance through to validation, and is the usual choice. Deep fans out wider and validates everything it finds.Set the Severity floor.
Critical, High, Medium, Low or Info, deciding how much of what is proven is reported.Pick the Attack classes.
Twelve of them, from SQL / NoSQL injection and Command injection through Broken access control, Server-side request forgery and Cross-site scripting to Authentication weaknesses. All are on by default.Choose an Automatic schedule.
Manual only — run on demand, Daily, Weekly or Monthly. Run now starts one whatever the schedule says.Set Max cost / run.
A ceiling on one engagement, so a run that goes long stops rather than continuing. The available settings are on the control.
#Where an engagement runs
Every engagement runs in an ephemeral sandbox, created for that run and destroyed after it. That sandbox is the boundary: a clone of the repository goes into it, and nothing else of yours.
Inside it, each command is screened before it executes. Requests to a host outside the sandbox are refused, as are netcat and raw sockets, disk-destructive commands, anything piped into a shell, and git push. A blocked command comes back as an error, which steers the run toward a proof of concept that demonstrates the vulnerability without reaching anything.
Pentest is included with Enterprise. See Plans and billing.