01
Make security part of the release
Start an assessment for the repository or application you are changing. Keep its scope, findings and follow-up work connected to the release.
For startups
A pentester on the team before you hire one.
Point Rokkhe at a repository. It maps the attack surface, tries exploits from a sandbox and proposes fixes as pull requests with the proof attached.
The engagement
Five steps, from scope to evidence
- 01
Define the target and scope
Name the repository and authorized targets before work begins.
- 02
Map the attack surface
Review routes, parameters, authentication flows, and dependencies within the named scope.
- 03
Test candidate exploits
Run candidate exploits from an isolated sandbox against the named target and keep the request trace as evidence.
- 04
Review remediation work
Review proposed fixes as pull requests with the related finding evidence attached.
- 05
Read the evidence pack
Review findings, proof artifacts, and the items that still need an owner.
Built for the stage you are at
Security work that fits a small team.
02
Lands where you already work
Review findings and proposed fixes alongside the evidence. Route approved work through your configured repository or ticketing integration.
03
Bring your own model key
Use the model provider you already pay for. Model spend stays on your account.
Operating boundaries
A controlled workflow
01
Spend ceiling
Set a budget cap for a run, and the scan stops when it reaches the limit.
02
Scope
Only the targets you name.
03
Execution
Agents and tools run in a container sandbox.
04
Model and audit
Configure your model provider. Review the plans, tool activity and artifacts retained for each assessment.