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.
2026-07-26 14:00:58 +02:00
parent 070727d5cd
commit 01046b01e4
202 changed files with 31290 additions and 0 deletions
--- a/.github/skills/security-specialist/steering/tracking.md
+++ b/.github/skills/security-specialist/steering/tracking.md
@@ -0,0 +1,152 @@
+# Steering: Export Findings to Tracking Systems
+
+Push confirmed findings to external issue trackers (GitHub Issues, GitHub Security Advisories, Jira, Linear) so they're visible to the engineering team and can be assigned/scheduled.
+
+## Step 1: Select Findings to Export
+
+Query the scan database for findings ready to track:
+```bash
+python3 scripts/scan_db.py list --status confirmed --not-tracked
+```
+
+Decide what to export. Typical filters:
+- All confirmed findings above a severity threshold (e.g., high+critical)
+- All findings from a specific scan
+- A hand-picked set by finding ID
+
+Don't export false positives or informational findings to issue trackers — they create noise.
+
+## Step 2: Determine Target System
+
+Identify the project's tracking system:
+- **GitHub Issues** — default for open source and most SaaS teams
+- **GitHub Security Advisories** — for vulnerabilities that need CVEs or coordinated disclosure
+- **Jira** — enterprise, use the project's existing security issue type
+- **Linear** — startup teams, use appropriate team and label
+
+Check the project for existing conventions: issue templates, labels (e.g., `security`, `vulnerability`), custom fields, linked projects.
+
+## Step 3: Format the Issue
+
+### Title Format
+```
+[<SEVERITY>] <Vulnerability Type> in <Location>
+```
+Examples:
+- `[HIGH] SQL Injection in /api/users search endpoint`
+- `[CRITICAL] Authentication bypass via JWT algorithm confusion`
+- `[MEDIUM] Stored XSS in comment rendering`
+
+Keep titles scannable. Someone triaging a backlog should understand the issue from the title alone.
+
+### Body Structure
+
+```markdown
+## Summary
+One paragraph: what's wrong, where, and why it matters.
+
+## Finding Details
+- **ID:** <finding-id from scan database>
+- **Category:** <CWE-XXX / OWASP category>
+- **Severity:** <Critical/High/Medium/Low>
+- **Location:** `<file:line>` or `<endpoint + parameter>`
+- **Detected by:** <tool name or manual review>
+
+## Evidence
+<Code snippet showing the vulnerable pattern, or request/response demonstrating the issue>
+
+## Impact
+What can an attacker do if this is exploited? Be specific:
+- What data is accessible?
+- What actions can be performed?
+- What's the blast radius?
+
+## Recommended Fix
+Brief guidance on the correct remediation approach. Not a full patch — just enough for the developer to understand the direction.
+
+## References
+- CWE link
+- OWASP page
+- Relevant framework documentation for the secure pattern
+```
+
+### For GitHub Security Advisories
+
+Additional fields required:
+- Affected versions / commits
+- CVSS score (calculate from the validated severity + exploitability)
+- Patched version (if fix exists)
+- Credit (if from bug bounty or external reporter)
+
+## Step 4: Show User for Approval
+
+Before creating anything externally, present the formatted payload:
+```
+I'm about to create the following issue in <system>:
+
+Title: [HIGH] SQL Injection in /api/users search endpoint
+Labels: security, priority-high
+Assignee: (none — or suggest based on git blame)
+
+Body:
+<full body text>
+
+Approve? (yes/no/edit)
+```
+
+Never auto-create external issues without explicit user confirmation. These are visible to teams and may trigger notifications.
+
+## Step 5: Create the Issue
+
+Use the appropriate CLI tool:
+
+**GitHub Issues:**
+```bash
+gh issue create --title "<title>" --body "<body>" --label "security,<severity>"
+```
+
+**GitHub Security Advisory:**
+```bash
+gh api repos/{owner}/{repo}/security-advisories --method POST --input payload.json
+```
+
+**Jira:**
+```bash
+# Use project-specific Jira CLI or API
+curl -X POST "https://<instance>.atlassian.net/rest/api/3/issue" \
+  -H "Authorization: Basic <token>" \
+  -H "Content-Type: application/json" \
+  -d @payload.json
+```
+
+**Linear:**
+```bash
+# Use Linear CLI or GraphQL API
+linear issue create --title "<title>" --description "<body>" --team "<team>" --label "Security"
+```
+
+Capture the returned URL/ID of the created issue.
+
+## Step 6: Update Scan Database
+
+Link the finding to the external tracker:
+```bash
+python3 scripts/scan_db.py update-status \
+  --finding-id <id> \
+  --status tracked \
+  --tracking-url <url>
+```
+
+## Step 7: Batch Operations
+
+When exporting multiple findings:
+- Group related findings into a single issue if they share the same root cause (e.g., "Missing CSRF protection on 8 endpoints" = 1 issue with a checklist)
+- Keep unrelated findings as separate issues — don't create mega-issues
+- Apply consistent labels and severity tags across the batch
+
+## Principles
+
+- Issues should be actionable. A developer reading it should know what to fix without needing to re-do the analysis.
+- Don't over-classify. If in doubt about severity, round down — you can escalate later.
+- Include enough evidence that the issue can be verified independently, but don't paste entire exploit chains in public repos.
+- For security advisories: coordinate with maintainers on disclosure timeline before publishing.