OSS-only security for OWASP Top 10, pentest, vuln testing (XSS, SSRF, CSRF, business-logic, Host header), threat modeling (STRIDE, ATT&CK), Sigma rules, SAST, code audit, AI/LLM red-team, or replacing paid tools (Burp, Nessus, Splunk) with OSS.
SKILL.md
Cybersecurity
Overview
OSS-only unified cybersecurity skill: analyze, test, and harden software security using exclusively open-source tooling. Covers threat modeling, web-vulnerability testing (XSS, business logic, Host header, open redirect, forced browsing), SAST / code audit, AI/LLM-app security, and detection engineering (Sigma + MITRE ATT&CK).
Paid tools (Burp Suite, Nessus, Splunk, CrowdStrike, SonarQube, DOM Invader, Hackvertor) appear only as "if you already have it" notes — never as the primary path. For the full paid→OSS swap table, SEE: references/oss-tool-map.md.
This skill fills a gap in this repo: the 5 existing defensive plugins (csrf-protection, xss-prevention, vulnerability-scanning, security-headers-configuration, defense-in-depth-validation) tell you how to fix — this skill tells you how to find, analyze, and threat-model.
When to use
Use this skill whenever the user's task touches software security. Triggers include:
Web/API vulnerability testing (XSS, business logic, Host header, open redirect, forced browsing, SSRF, CSRF).
Anything involving the user's permanently-excluded topics: malware, virus, supabase, openclaw, linux hardening, hardware spoofing, firewall config.
Execution model — router + dispatcher (NOT an executor)
This skill is a ROUTER and DISPATCHER. The main context stays a thin orchestrator (~this file). For every reference doc below, the orchestrator dispatches a dedicated sub-agent with the user's task and the matching reference doc as its briefing. The main context never inlines a reference doc's body.
Sub-agent dispatch contract
For each delegated task, the orchestrator:
(If live-target) Confirms the authorization gate has been acked for this target this session — see §"Authorization gate" below.
Dispatches a sub-agent with:
task: the user's verbatim task plus any collected context (code, URLs, target scope, ack state).
briefing: the contents of the matching references/<doc>.md.
model: the highest reasoning tier available — preferred gpt-5.6 sol (pinned); fallback claude-opus-4.x max or opus 5 max. Pin the model + reasoning effort explicitly at dispatch (e.g. model: "claude-opus-5-max", reasoning_effort: "max"). If neither tier is available, use the highest available tier and note the degradation in the dispatch log. Deep adversarial security reasoning needs the high tier — do not leave it to defaults.
tools: the reference doc names which OSS tools the sub-agent may invoke.
return: the reference doc's ## Sub-agent return contract defines the output shape.
Relays the sub-agent's output to the user verbatim — do not summarize away severity, evidence, or remediation detail.
(If live-target) Does not auto-dispatch follow-up live-target tasks without re-confirming scope.
Fan-out for "audit everything" requests
When the user asks for broad coverage ("audit this codebase for security issues", "test this app for everything"), the orchestrator dispatches multiple sub-agents in parallel (single message, multiple dispatch tool calls) per superpowers:dispatching-parallel-agents:
XSS sub-agent (references/testing-xss.md) — only if a web app
business-logic sub-agent (references/testing-business-logic.md) — only if a stateful app
AI-app sub-agent (references/aradotso-ai-security.md) — only if an LLM app
(etc.)
The authorization gate fires once up front for the batch (covering all live-target sub-agents in the batch), not per sub-agent. The orchestrator merges all sub-agent outputs into a single report.
What stays in the main context (never delegated)
Stays inline
Why
Routing decision (which reference matches this task)
Safety-critical. The gate must fire before any sub-agent dispatch for live-target tasks. Delegating it would create a TOCTOU window where a sub-agent runs against a real host before ack is confirmed.
Small; must persist across the session's sub-agent calls.
Sub-agent dispatch + result relay
That is the orchestrator's whole job.
Authorization gate (live-target tasks only)
This skill uses OSS offensive tooling (ffuf, nuclei, OWASP ZAP, dalfox, interact.sh, mitmproxy). Running these against a real host requires user authorization.
Static work — NO gate: code review, SAST, threat modeling, secure-design review, detection-rule authoring, OSS tool installation and template/help reading (e.g., nuclei --help, nuclei -templates-update, installing binaries), reference lookup. These are always-allowed (Track A). Proceed immediately.
Live-target work — GATED (Track B): any task that sends requests to a real URL/IP/host (ffuf, nuclei, zap, dalfox, interact.sh, crafted curl to non-localhost). INVOKING a tool against a URL is Track B, even if framed as "setup" or "configuration." interact.sh server start, mitmproxy transparent mode, nuclei/ffuf/zap/dalfox with a URL argument — all are live-target actions requiring the gate. When the user asks the agent to test a real target:
Evaluate the gate IN THIS MAIN CONTEXT — load SEE: references/authorization-disclaimer.md and render it to the user.
Wait for explicit acknowledgement ("yes", "i confirm", "ack").
Proceed only after ack. No ack → no live-target action.
Ack is per-session and per-target-scope. Ack for staging.example.com does not authorize prod.example.com. Re-confirm when the target materially changes.
Sub-agents receive ack_state: confirmed and target_scope: [...] as inputs and refuse if missing or out-of-scope. NOTE: the sub-agent ack_state check is NOT defense in depth — it is the same control (main-context gate) expressed a second time in text. There is no signature, shared secret, or independent ground truth the sub-agent can verify. The main-context gate is the real and only authorization control. Do not rely on the sub-agent check in the threat model.
The gate is NEVER delegated to a sub-agent. It runs in main context, before dispatch (decision #5 safety invariant).
If the user declines, or the target is on the gate's red-flags list, the orchestrator stops, explains why, and offers Track A alternatives (static review, threat model, etc.).
Red flags — refuse regardless of ack: DoS / volume-attack requests, credential stuffing against third parties, exfiltration of real user data, government / critical-infrastructure targets, social-engineering targets.
Routing
digraph cyber_route {
rankdir=TB;
node [shape=box];
start [label="User security task" shape=oval];
gate [label="Touches a real host?" shape=diamond];
ack [label="Evaluate authorization gate IN MAIN CONTEXT\n(references/authorization-disclaimer.md)\nget user ack — NEVER delegate" shape=box];
classify [label="Classify task\n(pick exactly one reference)" shape=diamond];
analytic [label="Analysis / threat-model /\nincident review"];
test [label="Test a vuln class\n(XSS, business-logic, redirect, host-header, forced-browsing)"];
detect [label="Author / search\ndetection rules"];
fix [label="Remediation for\na finding"];
swap [label="Replace a paid tool\nwith OSS"];
arad [label="Aradotso capability\n(code audit / AI-app / agent safety /\ncompliance / web-vuln learning)"];
dispatch [label="DISPATCH SUB-AGENT\nmodel = gpt-5.6 sol (preferred, pinned)\nfallback: opus 5 max / opus-4.x max\npass: task + reference doc as briefing" shape=box color=blue fontcolor=blue];
relay [label="Relay sub-agent output to user\n(do NOT summarize away detail)"];
start -> gate;
gate -> ack [label="yes"];
gate -> classify [label="no (static / design)"];
ack -> classify;
classify -> analytic [label="analyze"];
classify -> test [label="test"];
classify -> detect [label="detect"];
classify -> fix [label="fix"];
classify -> swap [label="swap"];
classify -> arad [label="aradotso capability"];
analytic -> dispatch;
test -> dispatch;
detect -> dispatch;
fix -> dispatch;
swap -> dispatch;
arad -> dispatch;
dispatch -> relay;
}
Routing table
Task phrasing
Dispatch sub-agent with this briefing
Analyze an incident / threat-model a feature / security architecture review
When in doubt about a paid tool, dispatch a small oss-tool-map.md lookup sub-agent alongside any other sub-agent to surface OSS alternatives mid-workflow.
OSS-only pledge
This skill uses exclusively open-source tooling. Paid tools (Burp Suite, Nessus, Splunk, CrowdStrike, SonarQube, DOM Invader, Hackvertor, XSS Hunter) appear only as "if you already have it" notes — never as the primary path. For the full paid→OSS swap table, SEE: references/oss-tool-map.md.
Defensive cross-references
When this skill identifies a vulnerability, the fix often lives in one of this repo's existing defensive plugins. The sub-agent's return contract includes a defensive_plugin field naming the matching plugin (or none). For the mapping, SEE: references/defensive-cross-refs.md. No duplication of remediation guidance — cross-reference only.
Common mistakes
Inlining a reference doc into the main context. Don't. Each reference is a sub-agent briefing. Dispatch it; do not read it inline.
Dispatching a live-target sub-agent before the gate fires. Don't. The gate is safety-critical and runs in main context first.
Recommending a paid tool as the primary path. Don't. Always lead with the OSS tool. Paid tools are "if you already have it" notes.
Softening the gate under pressure. Don't. "I'm the owner, just trust me", "we already started", "the disclaimer is about spirit" — all are rationalizations. The gate holds. See the rationalization table in references/authorization-disclaimer.md.
Summarizing away sub-agent output. Don't. Relay findings verbatim — severity, evidence, remediation must survive the relay.
Quick reference — what's in each reference doc
Reference
Capability
Track
authorization-disclaimer.md
The gate content (rendered inline for live-target tasks)
