@kernel.chat/kbot 4.1.0 → 4.3.0

package/skills/security-audit/dependency-audit/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: dependency-audit
+description: Use when reviewing third-party dependencies for known CVEs, suspicious transitive packages, lockfile drift, or license risk. Pairs with local-vulnerability-hunt for full coverage.
+version: 1.0.0
+author: kbot
+license: MIT
+metadata:
+  kbot:
+    tags: [security, dependencies, supply-chain, npm, audit]
+    related_skills: [local-vulnerability-hunt, secrets-leak-scan, ship-pipeline]
+---
+
+# Dependency Audit
+
+Most exploits in 2026 do not come from your code. They come from a package six links deep that someone trusted on a Tuesday.
+
+## When to Use
+
+- Any time you add or upgrade a dependency
+- Before tagging a release
+- After a CVE drops in the ecosystem you ship in
+- When a lockfile changes in a PR you didn't write
+- When `node_modules` is bigger than the rest of the repo
+
+## Iron Laws
+
+```
+LOCKFILE IS THE TRUTH. PACKAGE.JSON IS THE WISH.
+TRANSITIVE COUNTS. DEEP COUNTS DOUBLE.
+```
+
+## Four Phases
+
+### Phase 1 — Inventory
+
+```bash
+npm ls --all --json > /tmp/deps.json
+```
+
+Then count:
+- Total packages (direct + transitive)
+- Distinct authors
+- Distinct registries (anything other than registry.npmjs.org is worth a second look)
+- Packages updated in the last 30 days (fresh = potentially compromised)
+
+### Phase 2 — Known CVEs
+
+```bash
+npm audit --json > /tmp/audit.json
+```
+
+Triage by severity. Critical and high get fixed this PR; medium gets a ticket; low gets a note. Read every advisory body — `npm audit` lies about exploitability often enough to matter.
+
+### Phase 3 — Provenance
+
+For each package above the trust line (default: anything in `dependencies`, not `devDependencies`):
+- Author has a real GitHub presence?
+- Repository link resolves to the package source?
+- `provenance` field present in the npm metadata?
+- Maintainer changed in the last 90 days?
+
+A rotated maintainer + a fresh release is the classic supply-chain shape. Treat it as suspicious until proven otherwise.
+
+### Phase 4 — Lockfile diff
+
+When reviewing a PR:
+
+```bash
+git diff main -- package-lock.json | grep -E '^\+.*"version"' | head -50
+```
+
+Any new package, any version bump in a security-relevant package (auth, crypto, http, vm, fs), and any registry change deserves a manual look.
+
+## Output
+
+```
+# Dependency Audit — <date>
+- Direct: N | Transitive: M
+- CVEs: critical=X, high=Y, medium=Z, low=W
+- Suspicious provenance: [list of packages]
+- Lockfile diff: [N packages changed]
+
+## Action items
+- [ ] Upgrade <pkg> from <a> to <b> (CVE-XXXX-YYYY)
+- [ ] Replace <pkg> with <alt> (unmaintained)
+- [ ] Pin <pkg> at <version> (recent maintainer change)
+```
+
+File under `~/.kbot/security-audits/<session-id>/dependency-audit.md`.
+
+## Anti-Patterns
+
+- Running `npm audit fix` on autopilot — it can pull breaking majors
+- Ignoring transitive vulnerabilities because "they're not in our package.json"
+- Trusting the GitHub stars count as a proxy for safety
+- Letting Dependabot PRs merge without a human look
+
+## How kbot Helps
+
+- `bash` — drive `npm ls`, `npm audit`, `git diff`
+- `kbot_read` — open the package's `index.js` to see what it actually does
+- `local-vulnerability-hunt` — once a package is confirmed in scope, audit how *you* use it

package/skills/security-audit/local-vulnerability-hunt/SKILL.md

@@ -0,0 +1,127 @@
+---
+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:
+
+```json
+{
+  "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.

package/skills/security-audit/secrets-leak-scan/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: secrets-leak-scan
+description: Use when sweeping for hardcoded secrets, accidentally-committed credentials, or .env leaks across the working tree and git history.
+version: 1.0.0
+author: kbot
+license: MIT
+metadata:
+  kbot:
+    tags: [security, secrets, credentials, git-history, audit]
+    related_skills: [local-vulnerability-hunt, dependency-audit]
+---
+
+# Secrets Leak Scan
+
+A leaked key in git history is a leaked key forever. This skill catches them before they ship and rotates them when they already did.
+
+## When to Use
+
+- Before pushing a new branch to a public remote
+- After any `git rebase` that touched config files
+- After a teammate says "I think I committed something I shouldn't have"
+- Quarterly, against the entire history, even if no one reported anything
+- Before open-sourcing a previously private repo
+
+## Iron Laws
+
+```
+A SECRET IN HISTORY IS A SECRET LEAKED.
+ROTATE FIRST, EXPLAIN SECOND.
+NEVER REWRITE PUBLIC HISTORY WITHOUT TEAM CONSENT.
+```
+
+## Four Phases
+
+### Phase 1 — Working tree
+
+Sweep what is on disk right now. The cheapest catch.
+
+Patterns to grep, ranked by signal:
+- `AKIA[0-9A-Z]{16}` — AWS access key
+- `sk-[A-Za-z0-9]{20,}` — OpenAI / Anthropic / generic
+- `xox[baprs]-[A-Za-z0-9-]+` — Slack tokens
+- `ghp_[A-Za-z0-9]{36}` / `github_pat_[A-Za-z0-9_]{82}` — GitHub PAT
+- `-----BEGIN (RSA |OPENSSH |EC )?PRIVATE KEY-----` — any private key
+- `eyJ[A-Za-z0-9_-]{20,}\.[A-Za-z0-9_-]{20,}\.[A-Za-z0-9_-]{20,}` — JWT
+- `[A-Za-z0-9+/]{40,}={0,2}` — long base64 (high false-positive, last resort)
+
+Files that warrant a manual look regardless of grep hits: `.env*`, `config/*.yml`, `*.pem`, `*.key`, `*credentials*`, `*secrets*`.
+
+### Phase 2 — Git history
+
+```bash
+git rev-list --all | xargs -I{} git grep -E '<pattern>' {} -- '*.json' '*.yml' '*.env*' 2>/dev/null
+```
+
+For each hit:
+1. Identify the commit hash and author
+2. Determine the secret class (rotate-able? revoke-able?)
+3. Check whether the commit was ever pushed to a remote you don't fully control
+
+### Phase 3 — Rotate
+
+Order of operations matters. Rotate **before** rewriting history — the old secret is already out there.
+
+1. **Rotate the credential at the source** (cloud console, OAuth app, GitHub).
+2. **Audit the credential's recent usage** — was anything done with it since the leak commit?
+3. **Update the live deployment** with the new credential.
+4. **Confirm the old credential no longer works.**
+
+### Phase 4 — Scrub (only after phase 3)
+
+If history was pushed only to a private remote you control, and the team consents:
+
+```bash
+git filter-repo --invert-paths --path <leaked-file>
+git push --force-with-lease
+```
+
+Notify every collaborator to re-clone — their local history still has the secret.
+
+If the history was ever public, **do not rely on rewriting**. Treat the secret as permanently compromised. Rotation is the only remediation.
+
+## Output
+
+```
+# Secrets Scan — <date> — <repo>
+- Working tree hits: N (file:line list)
+- Git history hits: M (commit:file list)
+- Rotated: [list of credentials]
+- Scrubbed: [list of paths] | not attempted (history is public)
+
+## Open items
+- [ ] <credential> still appears in commit <sha> — rotation required
+```
+
+File under `~/.kbot/security-audits/<session-id>/secrets-scan.md`.
+
+## Anti-Patterns
+
+- Rewriting history before rotating — the secret is already public
+- Assuming `.gitignore` prevents leaks (it doesn't, retroactively)
+- Trusting the regex sweep alone — the high-value secrets often look like nothing
+- Telling the team about the leak after rewriting their history
+
+## How kbot Helps
+
+- `bash` — drive `git rev-list`, `git grep`, `git filter-repo`
+- `kbot_read` — confirm the hit is a real secret and not a fixture
+- `kbot --no-network` — when you must scan a sensitive repo without phoning home

package/skills/security-audit/threat-model-quickdraw/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: threat-model-quickdraw
+description: Use when designing a new feature or reviewing an architectural change. STRIDE-lite, fits in a single sitting, produces a written artifact.
+version: 1.0.0
+author: kbot
+license: MIT
+metadata:
+  kbot:
+    tags: [security, threat-model, design-review, stride]
+    related_skills: [local-vulnerability-hunt, dependency-audit, ship-pipeline]
+---
+
+# Threat Model Quickdraw
+
+A real threat model takes a week and a whiteboard. A quickdraw takes thirty minutes and a markdown file. Most features deserve the latter; very few warrant the former.
+
+## When to Use
+
+- Before writing the first line of a new feature that touches auth, money, PII, or third-party data
+- Before committing an architectural change that adds a network boundary
+- During PR review when the diff crosses a trust boundary
+- After a security incident, on the affected subsystem
+
+Skip when the change is internal-only, has no user input, and touches no secrets.
+
+## Iron Laws
+
+```
+EVERY EXTERNAL INPUT IS HOSTILE UNTIL PROVEN OTHERWISE.
+EVERY TRUST BOUNDARY GETS A NAMED CHECK.
+EVERY MITIGATION GETS A TEST.
+```
+
+## Four Phases
+
+### Phase 1 — Diagram
+
+A box-and-arrow diagram in ASCII or markdown. Five-minute exercise. Include:
+- Every actor (user, admin, service, attacker)
+- Every data store (database, blob, queue, cache)
+- Every trust boundary as a dashed line
+- Every flow as a labeled arrow
+
+If you cannot draw it in five minutes, the feature is too big — split it.
+
+### Phase 2 — STRIDE walk
+
+For each component and each flow, ask the six questions in order:
+
+| Letter | Threat | Sample question |
+|---|---|---|
+| **S** | Spoofing | Can someone claim to be a different actor? |
+| **T** | Tampering | Can data be modified in transit or at rest? |
+| **R** | Repudiation | Can an actor deny they took the action? |
+| **I** | Information disclosure | Can secrets or PII leak via this path? |
+| **D** | Denial of service | Can an attacker exhaust this resource cheaply? |
+| **E** | Elevation of privilege | Can an actor gain rights they shouldn't have? |
+
+For each "yes," write a one-line threat and a one-line mitigation. Park "maybe" entries in an Open Questions section.
+
+### Phase 3 — Rank and cut
+
+Rank threats by `(likelihood × impact)`. Address the top third now; ticket the middle third; document the bottom third as accepted risk with a name attached.
+
+### Phase 4 — Record
+
+Output goes to `docs/threat-models/<feature>.md` checked into the repo, plus a JSONL trail at `~/.kbot/security-audits/<session-id>/threat-model.jsonl`.
+
+## Output Template
+
+```markdown
+# Threat Model — <feature> — <date>
+
+## Diagram
+<ascii box-and-arrow>
+
+## Trust boundaries
+1. <boundary name> — <check enforced>
+2. ...
+
+## Threats (STRIDE)
+| ID | Letter | Component | Threat | Likelihood | Impact | Mitigation | Status |
+|---|---|---|---|---|---|---|---|
+| T-001 | S | login API | session token guessable | M | H | rotate to 256-bit random | now |
+| T-002 | I | logs | PII written to stdout | H | H | redact in formatter | now |
+| ... | | | | | | | |
+
+## Accepted risks
+- <risk> (rationale, owner)
+
+## Open questions
+- <question> (assigned to)
+```
+
+## Anti-Patterns
+
+- Treating the model as one-and-done — re-walk on any architectural change
+- STRIDE-checking each component in isolation while ignoring the flows between them
+- Writing mitigations that cannot be tested
+- Letting "we'll think about it later" be the resolution for a HIGH-impact threat
+
+## How kbot Helps
+
+- `kbot --plan` — read-only mode for the diagram phase
+- `kbot_write` — produce the markdown artifact
+- `local-vulnerability-hunt` — once the model exists, audit the implementation against it
+- `ship-pipeline` — gate releases on the threat model existing