AI penetration testing vs DAST vs vulnerability scanning
Updated · By Rokkhe team
A vulnerability scanner or DAST tool flags patterns that look exploitable; a penetration test tries to exploit them. Rokkhe's agents map a target's routes, parameters, auth flows and dependencies, then attempt a proof-of-concept from an isolated container sandbox. A Rokkhe finding must carry that proof-of-concept, its evidence and a CVSS 3.1 score, and in governed runs a separate validator agent must reproduce it before it is accepted.
What does a pattern match tell you?
That something resembles a known weakness. A scanner flags what looks exploitable, and someone still has to establish whether it is. The difference with a penetration test is the attempt: a pentest tries to exploit what it finds.
What does Rokkhe do with a target?
Rokkhe's agents map routes, parameters, auth flows and dependencies, then attempt a proof-of-concept. The agents' tools run inside a Kali Linux container sandbox, and an intercepting proxy in that sandbox records the HTTP exchanges they make.
Rokkhe tests only the targets you name. The hosted workspace tests Git repositories; self-hosted deployments and the CLI can also test live web applications, local source and IP addresses you are authorized to test.
What must a Rokkhe finding contain?
The reporting tool refuses a finding that is missing any of these:
- The proof-of-concept itself, as code or payload, plus the steps to run it.
- Concrete evidence, the assumptions the exploit depends on, and the strongest evidence against the finding.
- A confidence level, with a rationale whenever it is not high.
- The eight CVSS 3.1 base metrics, from which Rokkhe calculates the score and severity.
- The condition that would raise or lower the severity, and a remediation.
When a finding cites proxy exchanges as proof, their IDs are checked against the proxy's record: unknown IDs are rejected, and IDs that cannot be checked are dropped rather than recorded as evidence. A finding that describes the same root cause on the same asset as an existing one is rejected as a duplicate.
How is a finding confirmed before it is accepted?
In a governed run, which is how a Rokkhe deployment in database mode launches scans, the agent that suspects a vulnerability cannot file it. It submits a hypothesis, and a separate validator agent has to reproduce it independently. /learn/how-rokkhe-validates-a-finding walks through that step.
A model's claim that is not backed by evidence is never shown as a confirmed finding. Rejected and inconclusive hypotheses stay in the run's validation ledger and never enter accepted findings.
Where do I go from a finding?
- /docs/remediation — open the fix as a pull request your team reviews.
- /learn/how-a-retest-verifies-a-fix — confirm the fix with fresh evidence.
- /docs/quickstart — run a first engagement against a target you own.