| FMRS | 42 / 100 · D | 79 / 100 · B |
|---|
| Reliability | 6 / 20 | 12 / 20 |
|---|
| Security and permissions | 4 / 20 | 18 / 20 |
|---|
| Maintenance | 9 / 20 | 16 / 20 |
|---|
| Documentation | 13 / 20 | 18 / 20 |
|---|
| Setup experience | 10 / 20 | 15 / 20 |
|---|
| Best for | - Authorized security researchers and red/blue team engineers who want verify-before-report workflows
- Agent users who want a full penetration-testing flow driven by one call inside an MCP client
- Developers and security reviewers needing code audit (taint analysis, source-to-sink, variant analysis)
- Teams that want a structured methodology plus knowledge base (manuals, playbooks, escalation chains) instead of scattered scripts
| - Engineering teams scaling AI coding agents while controlling spend
- Platform teams that need auditable, rollback-aware agent execution records
- Organizations using multiple agents (Claude, Codex, Gemini) under one governed flow
|
|---|
| Not for | - Anyone wanting to test external systems without explicit owner authorization
- Anyone treating a scan hit as a confirmed vulnerability and skipping STRIKE validation
- Users expecting everything to work offline out of the box — payloads and templates need `blitzstrike sync-data`, and fofa_search needs FOFA_EMAIL/FOFA_KEY
- Users looking for an official or vendor-endorsed product; this is a community project
| - Developers who just want a simple code-completion helper without run governance
- Teams unwilling to accept local JSONL run records with HMAC signing
- Environments without a supported adapter (Claude/Codex/Gemini CLIs, direct provider, or verifier-only)
|
|---|
| Required permissions | - Read the source directory or files being audited
- Run a local process over stdio (command `blitzstrike`, args `serve --mcp`)
- Make outbound HTTP requests to the audited target for live validation and recon
- Write to client MCP config files (install merges into existing config, never overwrites)
- Read/write memory and data cache under ~/.blitzstrike (overridable via BLITZSTRIKE_HOME / BLITZSTRIKE_DATA)
- Optional: FOFA_EMAIL / FOFA_KEY for FOFA access, and H1_USERNAME to add the X-HackerOne-Research header
- ensure_tool may auto-install missing security tools on the local machine
| - Read/write access to the configured repo root (writable scope restrictable via --allow-path/--deny-path)
- Ability to invoke the chosen agent CLI (Claude/Codex/Gemini, etc.) and its underlying model account
- Local disk writes for run records, receipts, and share outputs (share/run-receipt., etc.)
- Execution of user-configured verifier commands (e.g. npm test)
|
|---|
| Risks and side effects | - Live validation and live_recon send real requests to targets; misconfigured scope or missing authorization can cause harm or legal exposure
- ensure_tool auto-installation modifies the local environment and introduces supply/version risk
- Payloads, nuclei templates, and exploitation manuals are offensive material that can be misused
- Memory is stored append-only as JSONL at ~/.blitzstrike/memory.jsonl and may accumulate sensitive target data
- FOFA and HackerOne credentials are supplied via environment variables and can leak
- Automated scan results can still be false positives — the README insists every finding stays a hypothesis until strike_verify confirms it
| - Verifier commands are executed; poorly chosen verifier commands carry security risk despite preflight policy checks
- Cost and token figures may be estimates (labeled with provenance) and should not be treated as settled accounting
- Receipt integrity must be verified before use as trustworthy evidence; missing rollback evidence is flagged as EVIDENCE_BOUNDARY
- Policy defaults come from martin.config.yaml and can be overridden by CLI flags; misconfiguration can loosen safety boundaries
|
|---|
| Supported clients | Claude Desktop, Claude Code, Cursor, OpenCode, Hermes, Gemini, Windsurf, GitHub Copilot, Cline | Claude Code, Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, Continue |
|---|
| Tools | 52 | 0 |
|---|