FROM THE BACKLOG TO THE EXPLOIT
This playbook cuts the application security backlog down to the findings an attacker can actually reach.
Your patch version is X and there's a theoretical vulnerability, but it's not exploitable. Worry about this thing over here — particularly where it might be configuration related as opposed to just patching or library versions.
What you get
platform.
Reproducible Exploits
Every proven item ships with the request, the response, and a reproduction an engineer can run.
Ruled-out findings
A candidate that cannot be reproduced is recorded with the reason it did not hold.
Unproven Alerts
An alert with no reachable surface is listed by name as unproven.
Scanner Alerts as Leads
GitHub and GitLab push their alerts into the Cybergraph today.
Where it stops
The edge of this playbook is the alert that never mapped to a surface. Cracken names it and stops there rather than calling it safe, and the decision to close it stays with a person.
It does not try to out-detect your scanner
Cracken is not hunting what Semgrep or Snyk missed here.
It does not work surface the backlog never pointed at
Testing every route on an application, alert or no alert, belongs to the Web Application Penetration Test playbook.
It does not work infrastructure or identity exposure
A finding from a vulnerability scanner, cloud posture tool, EDR, or identity source belongs to the Adversarial Exposure Validation playbook.
It does not fix the code
No patch, no pull request, no dependency bump.
It does not investigate a live secret
Proving a leaked key still authenticates is not an inquiry into whether anyone used it.
Who this is for
Start testingSecurity Engineer / AppSec Lead
Your scanner produces hundreds of findings. You can't remediate everything. You need to know which combinations actually chain to something critical — and which are noise.
Red Team Lead
You want agents to explore attack graphs autonomously between your manual engagements — surfacing chained paths you might not have traced, and re-validating after every environment change.
CISO
Remediation backlog is a board-level issue. You need a defensible answer to "what do we fix first" — based on what's actually exploitable in sequence, not theoretical CVSS severity.
Questions
How is this different from the reachability analysis my SCA tool already does?
Reachability analysis in an SCA tool infers whether a vulnerable function sits on an execution path by reading code and call graphs. This playbook settles the same question by sending the request from outside the application and keeping only the alerts that produce an attacker-meaningful signal.
Does Cracken need my source code?
The imports are findings, not source. Cracken reads the alerts your connected tools produced through Data Integrations and attacks a deployed build you authorise.
Which findings can it not validate?
An alert whose code path has no exposed entry point on the deployed build cannot be settled by attacking it, and this playbook parks it by name instead of clearing it. The same holds for anything outside the authorised scope.
How does this differ from the Web Application Penetration Test playbook?
The Web Application Penetration Test starts from the application and owes a verdict on every surface it discovers. Application vulnerability validation starts from your existing appsec backlog and asks which of those specific alerts hold up. One is coverage, the other is triage.
Bring the backlog. Keep only what reproduces.
Point this playbook at a deployed build you own and the repository organisation that builds it. Coverage of every route, alert or no alert, belongs to the Web Application Penetration Test playbook.