Neue Skills, Referenzen & OpenWiki-Doku integriert

Umfangreiche Erweiterung der Skill-Bibliothek: Neue Skills für Humanisierung (Englisch/PT-BR), Design-Validierung, AI-SEO und Coolify-Deployment inkl. Regelwerke, Presets, Pattern-Referenzen, Testfälle und Automatisierungsskripte. Zusätzliche Skills für Revenue-Centric Design, Pier Cloud, OKF, Lebenslauf- und LinkedIn-Optimierung sowie zahlreiche Referenzdateien, Checklisten und YAML/JSON/Markdown-Templates. Einführung einer vollständigen OpenWiki-Dokumentation mit Architektur-, Domain- und Workflow-Beschreibungen, zentralem Index und automatisierten Updates. Modularer Aufbau, restriktive Lizenzen und umfassende Qualitäts- und Evaluationsmechanismen für alle neuen Inhalte.

.github/skills/security-specialist/steering/attack-paths.md

@@ -0,0 +1,150 @@
+# Attack Path Tracing
+
+## Purpose
+
+Map the exploitation path for a confirmed or suspected vulnerability. Starts from a finding, traces backward to entry point and forward to impact. Produces a realistic severity assessment based on actual exploitability — not theoretical worst-case.
+
+## When to Use
+
+- A finding from `steering/full-scan.md` or `steering/discovery.md` needs severity validation
+- Triaging whether a vulnerability is actually reachable
+- Building proof-of-concept narratives for critical findings
+- Disputing or confirming a severity rating
+
+## Step 1: Start from the Finding
+
+Document the vulnerability anchor:
+
+- **What:** The vulnerable code (file, line, function)
+- **Class:** Injection, auth bypass, IDOR, SSRF, path traversal, etc.
+- **Primitive:** What the attacker gains if this fires (read arbitrary data, execute code, escalate privilege)
+
+## Step 2: Trace Entry Point → Vulnerability
+
+Work backward. How does attacker-controlled input reach the vulnerable code?
+
+Map the chain:
+
+```
+Entry Point (HTTP route, message queue, CLI arg)
+  → Input processing (parsing, deserialization)
+    → Validation (what checks exist between entry and sink)
+      → Intermediate transforms (encoding, type conversion, mapping)
+        → Vulnerable code (the sink)
+```
+
+At each hop, document:
+- What data flows through
+- What transformations or filters apply
+- Whether the attacker retains control over the data
+
+If a hop breaks the chain (e.g., input is cast to integer before reaching SQL query), the path is dead. Document why and downgrade.
+
+## Step 3: Identify Prerequisites
+
+What must be true for the attack to work?
+
+| Factor | Questions |
+|---|---|
+| **Authentication** | Does the attacker need a valid session? What role? |
+| **Network position** | Must they be on the internet, internal network, localhost? |
+| **Application state** | Does a specific condition need to exist (feature flag, data in DB)? |
+| **Race condition** | Is timing critical? How tight is the window? |
+| **User interaction** | Does a victim need to click/visit something? |
+| **Chaining** | Does this require another vulnerability to be exploitable first? |
+
+Each prerequisite reduces exploitability. Stack them honestly.
+
+## Step 4: Map Impact Forward
+
+From the vulnerable code, what happens when it fires?
+
+```
+Vulnerable code triggers
+  → Immediate effect (SQL executes, file reads, command runs)
+    → Data accessed/modified (what exactly)
+      → Lateral movement possible? (pivot to other services, escalate)
+        → Final impact (data breach, RCE, account takeover, DoS)
+```
+
+Be specific about impact scope:
+- Single user's data vs. all users
+- Read-only vs. read-write
+- Contained to one service vs. cross-service pivot
+- Persistent vs. one-shot
+
+## Step 5: Check Existing Mitigations
+
+Before finalizing severity, verify what's already blocking this path:
+
+- **WAF/rate limiting** — does it catch this payload pattern?
+- **Framework protections** — auto-escaping, parameterized queries, CSRF tokens
+- **Network policy** — is the target service isolated?
+- **Monitoring/alerting** — would exploitation trigger alerts?
+- **Input validation upstream** — is there a check we missed?
+
+If mitigations exist, document them and assess residual risk. A mitigated path is still a finding (defense in depth matters), but severity drops.
+
+## Step 6: Assign Severity
+
+Use this matrix — exploitability × impact:
+
+| | Critical Impact | High Impact | Medium Impact | Low Impact |
+|---|---|---|---|---|
+| **Easy to exploit** (unauth, no prereqs) | Critical | High | Medium | Low |
+| **Moderate** (auth required, simple chain) | High | High | Medium | Low |
+| **Difficult** (multi-step chain, race, internal network) | High | Medium | Low | Info |
+| **Very difficult** (requires prior RCE, admin, physical) | Medium | Low | Info | Info |
+
+Impact levels:
+- **Critical** — RCE, full data breach, complete auth bypass
+- **High** — significant data exposure, privilege escalation, account takeover
+- **Medium** — limited data leak, single-user impact, partial bypass
+- **Low** — information disclosure, minor integrity issue
+
+## Step 7: Document the Path
+
+Output format:
+
+```
+## Attack Path: <Title>
+
+**Finding Reference:** <link to finding in scan DB>
+**Final Severity:** <Critical/High/Medium/Low/Info>
+
+### Chain
+
+1. Attacker sends [specific input] to [entry point]
+2. Input passes through [component] where [transform happens]
+3. Reaches [vulnerable code] at [file:line]
+4. Triggers [primitive] resulting in [immediate effect]
+5. Attacker gains [final impact]
+
+### Prerequisites
+- [List each requirement]
+
+### Mitigations Present
+- [List what partially blocks this]
+
+### Mitigations Absent
+- [List what should exist but doesn't]
+
+### Evidence
+[Code snippets, data flow diagram, or PoC outline]
+```
+
+## Step 8: Recommend Action
+
+Based on the path analysis:
+
+- **Critical/High with easy exploit** → Fix immediately, consider if already exploited
+- **Medium** → Fix in next sprint, add detection
+- **Low/Info** → Track, fix opportunistically
+- **Mitigated but structurally present** → Harden, don't ignore. Mitigations fail.
+
+## Notes
+
+- Real severity comes from the PATH, not the pattern. SQLi behind three auth gates and only reaching a public data table is not critical.
+- Conversely, a "low-severity" IDOR that leaks all customer records is critical regardless of what the textbook says about IDORs.
+- If you can't trace a complete path from entry to impact, the finding might be theoretical. Say so explicitly rather than inflating.
+- Attack paths compound. Two medium findings that chain into a critical outcome should be reported as critical.