Scan · deterministic workflow

Repeatable security testing for web apps and APIs.

Scan is ShakerScan’s deterministic security-testing workflow for authorized websites and APIs. You choose a coverage budget and whether active testing is allowed. Scan returns findings with evidence, proof state, coverage, and a report. It does not require an AI model.

Who it is for. Security engineers, penetration testers, and DevSecOps teams who need comparable results between runs.

What problem it solves

Scan reports two things separately: the risk this run’s evidence supports, and how much of the planned work completed.

Budgets (fast, balanced, thorough, opt-in deep) cap duration, requests, endpoints, and tool time. Active testing is a separate permission, off by default.

Findings, evidence, and retest history persist, so you can verify a fix after a change.

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, reviewed passive Nuclei templates, and checks for exposed files such as .env and .git.
  3. 03With authorization, bounded active checks run, such as XSS, SQL injection, and NoSQL injection. Two-user BOLA checks need two distinct credential profiles.
  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 and shows no score.
  • Reported and Suspected findings need review. Only deterministic proof promotes a finding to Verified.
  • Scan does not test SSRF, LFI, RCE, or business logic. The functionality reference lists every check family Scan runs.
  • The repository’s benchmark fixtures list the vulnerability families expected on lab targets such as OWASP Juice Shop and crAPI, for miss analysis. Research publishes dated lab measurements for earlier releases, including misses; they are not a guarantee for the current release.

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.