# Deadeye Vapt > Whole-service VAPT / pen-test pass -- complete OWASP Top 10:2025, API Security Top 10 2023, and LLM Top 10:2025 coverage, ranked worst-first. - Skill: `deepaksinghcs14/deadeye-vapt` (Agent Skill) - Install (CLI): `npx skillmds@latest add deepaksinghcs14/deadeye-vapt` - Raw SKILL.md: https://api.skillmd.com/api/skills/deepaksinghcs14/deadeye-vapt/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - License: MIT - Author: deepaksinghcs14 (https://skillmd.com/u/deepaksinghcs14) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/deepaksinghcs14/deadeye-vapt --- # Deadeye VAPT A whole-service vulnerability assessment and penetration test, static and whitebox: find this service's real attack surface, then find what an attacker reaches through it. This is not a diff review. `/deadeye-guard` and `/deadeye-review` catch what changed; this catches what's already there — the endpoint nobody touched this session, the auth check that was never written, the route still live from an API version everyone thinks is retired. **What this is not.** No traffic is sent, no exploit is run, nothing outside this repository's source is touched — no network probing, no host/container/cloud-IAM layer, no runtime fuzzing. This is the source half of a VAPT: a whitebox read that reasons like an attacker with the code in hand, not the network half. Say this plainly in the output, not just here. **How this runs.** Phase 0 (the five surface tracks below) and the ambiguous-scope gate run first, sequentially, as normal interactive turns — Phase 0 is a handful of greps, no fan-out needed, and the ambiguity gate needs a live turn to actually ask from (a Workflow runs to completion in the background with no pause point to ask mid-script). Once scope is settled, on Claude Code, load the `workflow-authoring` skill and run the rest as a Workflow: Phase 1 (attack-surface inventory) fans out across whichever surface tracks Phase 0 confirmed, then Phase 3/4 (triage + verify) fan out one agent per tag-family. A fanned-out agent doesn't inherit this conversation's context the way a sequential turn does — **interpolate Phase 2's full trust-boundary map text directly into every Phase 3/4 `agent()` call's prompt**, not just a reference to it; "grounded in the map" means the map's actual text travels into the call, not that it's assumed to already be in scope. Then one integration pass over every returned finding before the report (Phase 5) is generated. This is the default, not an opt-in — a whole-service pass is already the heaviest, least-frequent command here, and it spends meaningfully more tokens than a single-agent pass to get meaningfully more coverage; say so if asked why. Every other host has no Workflow tool — run every phase below as one agent there, same as always. **Set each agent's tier explicitly in the script** — a Workflow's `agent()` calls run outside deadeye's own routing advisory (that only watches the interactive `Agent` tool, not a script's internal calls), so an untiered script silently inherits the session's own model for every agent, tiering nothing. Phase 1 inventory is grep-driven pattern matching: the cheapest tier that fits. Phase 3/4 verification needs real judgment: floor each tag-family agent at tier 1 (sonnet), reserving the top tier for a family touching a risky surface (authn/authz/crypto/inject/llm). Run the closing integration pass at the strongest tier available — it's the one place seeing every finding at once. ## Scope `git ls-files` (or `find -maxdepth` outside a git repo) — never read whole directories. Grep-first; open full file bodies only for candidates that make the attack-surface table. **Phase 0 — confirm there's a real attack surface.** Five independent tracks; any one alone is enough to proceed, a target may have any combination: - **Network-facing.** Grep for route/handler/controller shapes (`@app.route`, `router.`, `http.HandleFunc`, `@RequestMapping`, `#[get(`, Express `app.get/post`, gRPC/GraphQL defs). - **LLM/agent context-injection.** Grep for an LLM SDK call (`anthropic`, `openai`, `.messages.create(`, `.chat.completions.`, `generateContent(`, a langchain/llamaindex import), a prompt/system-message template built from variables, or an agent/hook framework injecting content into a model's context (`additionalContext`, a `SessionStart`-shaped hook, a RAG/tool-output pass-through). A CLI with no HTTP surface can still be exactly this — its whole job is feeding external content to an LLM. - **Message/event-driven.** Grep for a queue/topic consumer or subscriber registration (`kafka.NewConsumer`/`consumer.Subscribe(`/ `@KafkaListener`, `channel.Consume(`/`@RabbitListener`, SQS `ReceiveMessage(`/`@SqsListener`, `redis...Subscribe(`, NATS `nc.Subscribe(`) or a scheduled/cron handler that processes external data on a trigger instead of a request. No inbound HTTP request and no LLM call doesn't mean no attacker-controlled input — the message body is exactly that. - **Client-side/UI.** Grep for a frontend framework (React/Vue/Angular/ Svelte components, a client-side router — `createBrowserRouter`, `` — the findings under this category, by number - `clean` — checked, nothing survived verification - `n/a — ` — e.g. `n/a — no LLM surface`, `n/a — no third-party API consumed` A category may never be silently absent from the matrix. If the pass could not actually reach a category (too large to triage fully, a sub-surface never opened), say `not reached — ` — that is a coverage gap to disclose, never a clean result to imply. End with the tally (` critical, high, medium, nits`), the coverage matrix, and the scope disclaimer from above (no traffic sent, source-only). Nothing survives verification anywhere → skip individual findings and print exactly: `Clean line of fire — no service-level exposure survived verification.` — still followed by the full coverage matrix; "clean" is a per-category verdict, not a reason to omit the matrix. ## Report generation Once the findings and coverage matrix above are final, generate a shareable report: build the JSON shape `deadeye vapt` expects (one object per finding — severity, tag, title, endpoint, owasp ids, link, attack, proof, fix — plus the coverage rows, the tally, and the Phase 1/2 text printed above) and run: `"repo"` is the repo's own name (its directory name, or `git remote`'s `owner/repo` if one exists). `"scope"` names whatever the pass actually covered — if the ambiguous-scope gate fired and narrowed to one service, put that service's name here (e.g. `"billing service"`), never the whole repo's name; leave it empty only when no gate fired and the entire repo was genuinely in scope. This is what stops the report from reading as full coverage when it wasn't. ```bash deadeye vapt --in=- <<'JSON' {...} JSON ``` This writes `vapt-reports/vapt-.html` in the scanned repo — a print-optimized report; open it and use the browser's Print → Save as PDF for a shareable copy, no separate tool needed. If `vapt-reports/` isn't already in `.gitignore`, suggest adding it — a findings report is sensitive, like any other security artifact. This step is purely additive. `deadeye vapt` missing or failing (not on PATH, bad JSON) never blocks or invalidates anything above — the findings printed to chat are the deliverable regardless; note the report generation failed and move on, same fail-open discipline the dependency auditor step already follows. ## Honesty boundaries (load-bearing) - Never invent a CVE, advisory id, or CVSS score you did not see from a tool or an OSV/advisory database lookup. - If a dependency manifest exists, run its native auditor when installed (`govulncheck ./...`, `npm audit`, `pip-audit`, `cargo audit`, or `osv-scanner -L ` as a fallback) — no auditor installed → say so, do not fabricate a result. No manifest anywhere in the repo (a script or app with no lockfile/dependency file at all) → `dep:` is `n/a — no dependency manifest`, not `not reached`; `not reached` is reserved for a manifest that exists but the pass genuinely couldn't examine (too large, auditor timed out). - State plainly, every report, that no traffic was sent and no exploit was run — this is a source read, not a live pen-test. - Findings above the cap (~25) get ranked, not padded — say how many lower-severity ones were omitted; never present a ranked sample as exhaustive coverage. - A `deadeye: . ceiling: . upgrade: .` comment over a hunk is a recorded decision, not a finding — count it separately as accepted. ## Learning loop Before finalizing, run `deadeye lessons priority` (best-effort — retry once with `~/.deadeye/bin/deadeye` if `deadeye` isn't on PATH; if that also fails, run the pass normally). Recent coder misses or disputed findings on the `security:` lens raise the bar for the matching tag here too — this rubric shares the learning signal with `/deadeye-guard` and `/deadeye-review`'s security lens, not a separate ledger. For each finding that survives verification and makes the final report: ```bash deadeye lessons record coder-miss security: ``` using the tag without its trailing colon — e.g. an `authz:` finding → `deadeye lessons record coder-miss security:authz`. No-op when coder mode wasn't active this session. When the user disputes a finding ("that's not reachable", "already gated upstream", "won't fix"): ```bash deadeye lessons record review-false-positive security: ``` ## Boundaries - Findings are a LIST. Do not apply or push any fix unless asked. - This is a static, source-only, whitebox pass — never imply live traffic was sent or an exploit was run. - Not a diff review: `/deadeye-review`/`/deadeye-pr` (four lenses, diff-scoped) and `/deadeye-guard` (security-only, diff-scoped) are the right tool for "did this change introduce a problem." This is "what can an attacker already reach in this service," scoped to the whole repo by design. - None of Phase 0's five tracks found → say so and stop. Do not invent a route, an LLM call, a consumer, a rendered page, or a deployment resource for a plain library that genuinely has none of the five.