Skip to content

/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.

From plugin
deadeye
511 skills3 commands7 hooks
Install
$ npx -y skills add deepaksinghcs14/deadeye-cc --skill deadeye-vapt --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/deadeye-vapt

Context preview

The summary Claude sees to decide when to auto-load this skill.

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.md

deadeye-vapt.SKILL.md
name: deadeye-vapt
description: 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.
license: MIT

<!-- deadeye-vapt: canonical rubric; edit internal/vapt/ruleset.md, the skill and every host rendering are generated from it -->

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.

<!-- claude-only --> **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.

<!-- /claude-only -->

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`, `<Route path=`, `useNavigate`) or a browser-extension manifest. A UI-only repo with no backend at all still renders untrusted content, stores tokens, and embeds third-party scripts — it's a real target on its own, not a "nothing to review here."

  • **Infrastructure-as-code / CI-CD.** Grep for deployment config:

Terraform/CloudFormation (`*.tf`), Kubernetes manifests (`kind: Deployment/Role/ClusterRoleBinding`), Dockerfiles (`FROM`, `USER`), pipeline defs (`.github/workflows/*.yml`, `.gitlab-ci.yml`, `Jenkinsfile`). A repo with no app code at all can still be exactly this — provisioning infra or running builds with real credentials.

None found → say so and stop. Whichever track(s) DO apply set Phase 1's inventory shape (below); tags with no matching surface end up `n/a` in the coverage matrix, not skipped from it.

**Scope is ambiguous → ask, don't guess.** Phase 0 turning up multiple independently-deployed services (a monorepo — separate top-level dirs, each with its own entrypoint/manifest), vendored/generated code mixed with fi

Read more
Ships withdeadeye

Claude Code plugin that fits the model, effort, and context to each task — fewer tokens, same quality. Deterministic policy kernel in the hooks; every number it reports is measured, not estimated.

Get the whole plugin, auto-invoked
Stats
5
Stars
1
Forks
Active
Maintenance
Go
Language
MIT
License
2d ago
Last commit
1mo ago
Created

Repo: deepaksinghcs14/deadeye-cc

Other skills on deadeye.