Launch post

Why We Built ScanRook

Most scanners force a cloud-first workflow or overload teams with findings they cannot trust quickly. We built ScanRook to start local, stay fast, and add cloud enrichment only when you need it.

The Problem

  1. Too many findings with unclear applicability.
  2. Slow, opaque scan workflows.
  3. Friction to adopt in developer pipelines.

Our Approach: Local-First + Cloud Enrichment

  • Local scan engine runs without mandatory cloud auth.
  • Cloud enrichment adds context, org workflows, and scaling controls.
curl -fsSL https://scanrook.sh/install | bash
scanrook scan --file ./image.tar --mode deep --format json --out report.json

The split matters more than either half. Everything needed to produce a report lives on your machine; the cloud side is something you opt into when a team needs shared workflows.

Local-first boundary: what runs on your machine versus what the optional cloud side adds.On your machineno mandatory cloud authInstall the CLIScan a file or image tarInstalled-state-first detectionConfidence tiering: confirmed vs heuristicReport written to disk (JSON or text)opt insign in or add an API keyCloud enrichment (optional)added when a team needs itEnrichment context on findingsOrg and team workflowsQueue-to-completion visibilityAPI and org controlsScaling controls
Where the local-first boundary sits. Every capability shown is one described in this post — the diagram shows which side of the line each one lives on, not how long anything takes or how much it finds.

What Makes ScanRook Different

  1. Installed-state-first model.
  2. Confidence tiering for findings (confirmed vs heuristic).
  3. Workflow visibility from queue to completion.
  4. API and org controls for managed team operations.

What's Next

  • Reproducible benchmark reports vs common tools.
  • CI integrations (GitHub Actions first).
  • Expanded distribution (Homebrew, crates.io, Docker).

Try It

curl -fsSL https://scanrook.sh/install | bash