local-vulnerability-hunt

name	local-vulnerability-hunt
description	Use when the user wants to find security vulnerabilities in a local codebase using their own BYOK frontier model. Mythos-style audit, local-first, audit trail on disk.
version	1.0.0
author	kbot
license	MIT
metadata	{"kbot":{"tags":["security","audit","vulnerability","byok","local-first"],"related_skills":["dependency-audit","secrets-leak-scan","threat-model-quickdraw","systematic-debugging"]}}

Local Vulnerability Hunt

The Project Glasswing posture — but BYOK, local, MIT. Anthropic shipped Claude Mythos to six organizations to hunt zero-days; this skill gives the same workflow to anyone with a frontier model API key, against their own code, with the audit trail on disk where they can read it.

When to Use

• The user asks "scan my repo for vulnerabilities"
• Pre-release security pass before a tag
• After importing a third-party module of unknown provenance
• After a CVE drops and you want to know if your code touches the same surface
• Quarterly hygiene sweep, with the trail filed for later reference

Do not use this skill against systems you don't own. For external targets see pentest and hacker-toolkit — those are scoped for authorized testing.

Iron Laws

NO REMOTE SCAN WITHOUT CONSENT.
NO FINDING WITHOUT EVIDENCE.
NO FIX WITHOUT VERIFICATION.

The model proposes; you verify; the trail records both.

Five Phases

Phase 1 — Scope

Decide what counts as in-scope before reading a line of code. Write it down.

• Source tree root (absolute path).
• Languages and runtimes that matter (node, python, go, rust).
• Excluded paths (node_modules, dist, vendor, generated code).
• Severity floor: report MEDIUM+ by default, LOW+ when asked.
• Time bound: a quick pass is one hour; a thorough pass is a working day.

Phase 2 — Surface map

Walk the tree once and inventory the attack surface. The security_audit_local tool does this in one call:

• HTTP handlers and route registrations
• Auth boundaries and session handling
• Subprocess and shell-out points (exec, spawn, system)
• Eval-shaped sinks (eval, Function, vm.runInContext, dynamic require)
• File-system writes and path-join sites
• Crypto usage (key derivation, randomness, ciphers, JWT signing)
• Third-party network egress
• Secrets-shaped strings (delegate to secrets-leak-scan)

Record findings as signals — not yet vulnerabilities — in ~/.kbot/security-audits/<session-id>/surface.jsonl.

Phase 3 — Hypothesize

For each high-signal site, write down one sentence: "I think this could be exploited because X, by Y, with consequence Z." If you can't finish the sentence, downgrade to LOW or drop.

The frontier model goes here. Hand it the code window plus the signal context and ask for the threat hypothesis. Cap context: never feed more than 4k LOC per turn — accuracy collapses past that.

Phase 4 — Confirm

A hypothesis is not a finding. Confirm by:

1. Writing a failing test that reproduces the exploit (preferred), or
2. Constructing a minimal call sequence that demonstrates it, or
3. Citing a specific equivalent CVE with the same pattern.

Findings without confirmation get filed as UNCONFIRMED and never graduate without phase 4 evidence.

Phase 5 — File

Every confirmed finding lands in ~/.kbot/security-audits/<session-id>/findings.jsonl with this shape:

{
  "id": "AUDIT-2026-05-09-001",
  "severity": "HIGH",
  "category": "command-injection",
  "file": "src/exec.ts",
  "line": 47,
  "evidence": "user-controlled `path` flows into child_process.exec without escaping",
  "reproduction": "POST /api/run {\"path\":\"foo; rm -rf /\"}",
  "remediation": "use execFile with arg array; never compose shell strings from user input",
  "confidence": "high",
  "model": "claude-opus-4-7",
  "cited_cwe": "CWE-78",
  "ts": 1746792000000
}

The whole directory is your evidence pack. Ship it alongside the patch commit.

Output

When finished, produce a short markdown summary:

• Scope: paths walked, files read, LOC scanned
• Counts by severity: CRITICAL / HIGH / MEDIUM / LOW
• Top three with file:line, one-sentence why
• Audit trail: pointer to ~/.kbot/security-audits/<session-id>/
• Model used: which BYOK model produced the hypotheses

Keep the summary under 60 lines. The full trail belongs on disk, not in the chat.

Anti-Patterns

• Letting the model autonomously edit code based on its own findings — confirm first, edit second, separate commits.
• Scanning without writing the scope down — irreproducible audits are worthless.
• Over-trusting one model — for HIGH+ findings, get a second opinion from a second provider before filing.
• Treating LOW findings as noise. They cluster around the next HIGH.

How kbot Helps

• security_audit_local — substrate tool: walks the tree, builds the surface map, persists JSONL trail.
• kbot --thinking — turn on extended thinking when forming threat hypotheses.
• kbot --provider <name> — rotate providers between phases for independent confirmation.
• pentest — the remote-target counterpart; use only with consent.