Scan · deterministic workflow

Repeatable security testing for web apps and APIs.

Scan is ShakerScan’s deterministic security-testing workflow. Every submission runs the same DAST pipeline against an authorized website or API. You choose a coverage budget and whether active testing is authorized; ShakerScan returns findings with evidence, proof state, coverage information, and a report. Scan does not require an AI model.

Who it is for. Security engineers, penetration testers, and DevSecOps teams who need comparable results from one run to the next, with or without an AI agent in the loop.

What problem it solves

Most scanners blur two different questions: how much work ran, and how much risk was observed. Scan keeps them separate. A risk score and grade describe only the material risk supported by this run’s evidence, while an assurance score describes how much of the planned work actually completed.

Scanners also tend to blur depth and permission. In Scan, fast, balanced, thorough, and opt-in deep are resource ceilings for duration, requests, endpoints, and tool time. Active testing is a separate, explicit permission that is off by default.

Finally, findings should not be lost between runs. Scan persists findings, evidence, and retest history so a fix can be verified after a change instead of re-triaged from scratch.

How it works

  1. 01Enter or select an authorized target, pick a coverage budget (fast, balanced, thorough, or opt-in deep), and state whether active testing is authorized.
  2. 02Passive work runs first: DNS, TLS, email and HTTP-header posture, crawling and API discovery, and reviewed passive Nuclei templates.
  3. 03With authorization, bounded active checks run: XSS, SQL injection, and two-principal BOLA verification when two distinct credential profiles are configured.
  4. 04Findings are persisted with a severity and a proof state (Verified, Suspected, Unverified, Inconclusive, or Refuted). Deterministic verification promotes a finding to Verified; a label or an HTTP 200 alone never does.
  5. 05The report separates observed risk from assurance, lists coverage gaps, and reports incomplete coverage separately from failure. You can retest any finding after a fix.

What you get

  • Findings with severity, proof state, source, lifecycle, and supporting evidence.
  • A risk score and grade plus an independent assurance score and band, so incomplete coverage is never read as a clean result.
  • Coverage information: which check families ran, which did not finish, and why.
  • Authenticated scanning through encrypted, target-bound credential profiles: bearer tokens, cookies, custom headers, form login, and two-user BOLA/IDOR testing.
  • Redacted HTTP-transaction export as JSON and raw replay evidence as HAR 1.2, plus JSON and PDF reports.
  • Retests, attack-chain correlation, and an OWASP coverage matrix.
  • For CI: the engine-less client submits scans with shakerscan scan --json, GET /scans/{id}/deployment-decision returns a gate decision, and the scanner CLI can write SARIF 2.1.

Example workflow

Submit, review, retestshell
# Passive deterministic Scan with a balanced budgetshakerscan scan https://app.example.test --budget-profile balanced # Same pipeline, broader ceilings, explicitly authorized active testingshakerscan scan https://app.example.test --budget-profile thorough \  --active-testing --confirm-active # Review and retest through the local APIcurl "http://localhost:8080/findings?status=active&severity=high"curl -X POST http://localhost:8080/findings/{finding_id}/retest \  -H "Content-Type: application/json" -d '{"requested_by":"api"}'

Security and authorization

  • Only scan systems you own or are explicitly authorized to test. Active testing can change application state, trigger alerts, and create significant traffic.
  • Active testing is off by default and requires an explicit confirmation flag or UI acknowledgement on every submission.
  • Credentials are stored as encrypted profiles bound to one exact target; the API accepts profile IDs only, so secrets never enter a scan request, queue payload, or shell history.
  • ShakerScan is a trusted-operator system. Keep its UI and API on localhost or behind your VPN, firewall, or authenticated reverse proxy.

Limitations

  • ShakerScan does not claim to find every vulnerability. Absence of a finding in a check family that did not finish is not evidence of safety; the report says which families completed.
  • If the target could not be examined (for example, only an authentication challenge was reachable), the report marks the run as not examined. Do not read the compatibility 100/100 projection as a clean bill of health in that state.
  • Reported and Suspected findings need review. Only deterministic proof promotes a finding to Verified.
  • The runnable active families are XSS, SQL injection, and BOLA. SSRF, LFI, RCE, NoSQL injection, business-logic, and sensitive-exposure families are registered as planned and are not Scan coverage today.
  • The repository’s benchmark fixtures list the vulnerability families expected on lab targets such as OWASP Juice Shop and crAPI, for miss analysis. ShakerScan publishes no recall or precision figures.

Get started

  1. 01Install ShakerScan and open the web UI at http://localhost:3000.
  2. 02Choose New Scan, enter an authorized target, select a budget, and decide whether active testing is authorized.
  3. 03Follow live progress, then review findings, proof state, and coverage on the scan detail page.
  4. 04Fix an issue and use Retest on the finding to verify the change.