security-orchestrator

name	security-orchestrator
description	Route a security task to the right skill among six specialists — defensive code review, offensive/bounty vulnerability hunting, agent-config (.claude) auditing, source-asset & embedded-dependency scanning, a pre-action fact-forcing gate, and destructive-operation safety locks. USE WHEN a user wants to secure, audit, harden, or attack a codebase or an agent setup but hasn't named the specific concern.
cluster	security
version	1.0.0

Security Orchestrator

The single entry skill for security work. It locates the task on the posture × surface map — defend vs attack against code, agent-config, or live runtime — and delegates to one of six specialist spokes. The cross-cutting idea every spoke shares — the trust boundary: where untrusted, attacker-controlled input or action reaches a privileged sink, and the default-deny posture that contains it — lives in security-core; read it before triaging a finding or deciding whether something is exploitable.

Cluster map (spoke → role)

• security-review — Defensive code review. The build-time checklist: secrets management, authn/authz, input handling, API endpoints, payments, transport, plus a cloud-infrastructure-security companion. Use when writing or reviewing code that touches a sensitive surface.
• security-bounty-hunter — Offensive discovery. Hunts remotely reachable, user-controlled, exploitable vulnerabilities (SSRF, auth bypass, RCE, SQLi, path traversal) and discards noisy local-only findings. Use when the question is "does this actually pay / is this reportable?".
• security-scan — Agent-config audit. Scans a .claude/ setup (CLAUDE.md, settings.json, MCP servers, hooks, agent defs) for injection, over-permissive allowlists, and supply-chain risk via the ecc-agentshield tool. Use when securing the agent harness itself.
• repo-scan — Source-asset audit. Classifies every file as project / third-party / artifact, detects embedded (vendored) libraries and their versions, and emits four-level verdicts. Use to find outdated bundled OpenSSL/FFmpeg/etc. and unowned attack surface across a polyglot repo.
• gateguard — Pre-action fact-forcing gate. A PreToolUse hook that blocks the first Edit/Write/Bash and demands concrete investigation (importers, data schema, the user's instruction) before allowing it. Use to stop blind, guessed changes in an autonomous loop.
• safety-guard — Destructive-operation lock. Intercepts rm -rf, force-push, DROP TABLE, etc., and freezes writes to a chosen directory. Use to contain blast radius when an agent runs full-auto or on production.

Folded spokes (offensive recon, AppSec testing, threat intel)

These spokes extend the cluster beyond the original six — they cover the offensive recon → web/LLM testing pipeline and the threat-intelligence feeds that inform it. Route to them the same way (load on demand; see "Loading spokes on demand"):

• recon — Infrastructure & network reconnaissance. Passive-by-default WHOIS/DNS/cert-transparency/ASN mapping plus authorization-gated active port/service scanning. Use to map a target's attack surface (domains, IPs, netblocks, subdomains) before testing.
• osint — Open-source intelligence on people, companies, and entities/domains. Public-sources-only, authorization-first. Use for due diligence, background checks, or entity/threat-actor research; commonly hands off to recon for the technical infrastructure.
• webassessment — Web application security assessment. Builds an app narrative, threat-models it, then runs a 6-phase pentest (recon → mapping → vuln analysis → exploitation → reporting) with ffuf fuzzing. Use for "pentest / security-test this web app".
• promptinjection — LLM/AI application security testing. Direct, indirect (RAG/document), and multi-stage injection + jailbreak testing with an attack taxonomy and defense/remediation guidance. Use to test a chatbot or LLM feature for prompt injection. Authorized use only.
• secret-scanner — Leaked-secret detection. Scans files, .env, and git history for hardcoded API keys/credentials (AWS, Stripe, GitHub tokens, etc.). Use as a fast pre-push / CI credential-exposure check (complements security-review's secrets section).
• secupdates — Security news aggregation. Pulls and ranks the latest breaches, CVEs/research, and industry analysis from tl;dr sec, Krebs, THN, Schneier, etc. Use for "what's new in security / sec updates".
• annualreports — Annual security-report aggregation & analysis. Indexes 570+ industry threat/AppSec/cloud/ransomware reports and synthesizes cross-vendor trends. Use to pull or analyze the threat landscape from vendor annual reports.

Routing the additions:

• Recon / attack-surface mapping / OSINT / due diligence → recon, osint
• Web app or LLM/chatbot penetration testing → webassessment, promptinjection
• Credential-leak / secrets scan of a repo → secret-scanner
• Threat-intel & industry trends (news, CVEs, annual reports) → secupdates, annualreports

Routing rules by intent

Defend — code (build time)

• "Review this for security" / adding auth, input handling, secrets, payments → security-review
• Cloud/IaC posture (IAM, buckets, network) → security-review (cloud-infrastructure-security companion)

Attack — code (find real bugs)

• "Find exploitable vulns" / prep a Huntr/HackerOne report / triage exploitability → security-bounty-hunter

Audit — what's already there

• Audit the agent/Claude Code config → security-scan
• Audit the source tree (ownership, vendored deps, dead weight) → repo-scan

Contain — live agent runtime

• Force investigation before edits (quality + safety) → gateguard
• Block destructive commands / freeze the writable area → safety-guard

If the ask is broad ("make this secure"), default to security-review for the code path and offer security-scan for the agent config — they cover the two most common surfaces.

Sibling clusters (framework-native security)

This cluster owns cross-cutting security — review, scan, bounty — across any stack. When the concern is bound to a specific framework or domain, hand off to that cluster's own security spoke:

• Python/Django → django-security (cluster python-backend)
• PHP/Laravel → laravel-security (cluster php-laravel)
• JVM (Spring Boot / Quarkus) → springboot-security / quarkus-security (cluster jvm)
• On-chain / smart contracts → cluster blockchain-web3 (e.g. defi-amm-security)
• Desktop (Electron) → electron-security (cluster electron)

Use those for in-framework hardening; route back here for stack-agnostic code review, config/asset scanning, or exploitability triage.

Standard flow

1. Place the task on posture × surface: are we defending or attacking, and is the surface code, agent-config, or runtime?
2. If it involves judging a finding (reachable? user-controlled? meaningful sink?), pull the trust-boundary model from security-core first — exploitability is a property of the path, not the pattern.
3. Delegate to the spoke(s). Multi-surface asks fan out: e.g. "harden this agent project" → security-scan (config) + security-review (code) + safety-guard (runtime lock).
4. Return: chosen spoke(s), the surface/posture, the severity or verdict implied, and the next action.

Guardrails

See security-core. In short: default-deny — grant the narrowest permission/scope that works and treat any widening as a security change. Exploitability over theory — rank by "can attacker-controlled input reach a meaningful sink?", not by lint pattern count; drop local-only and out-of-scope noise. Contain before you trust — in autonomous runs keep safety-guard/gateguard on. Never weaken a control silently — disabling a gate, widening an allowlist, or adding a host is a stated decision, never a quiet one.

Loading spokes on demand

To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:

~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).