Назад към всички

ralph-security

// Comprehensive security audit with 100 iterations (~30-60 min). Use when user says 'security audit', 'ralph security', 'weekly security check', 'audit this project', 'new project security review', or 'check for vulnerabilities'. Covers OWASP Top 10, auth, secrets, infrastructure, and code quality.

$ git log --oneline --stat
stars:1,933
forks:367
updated:March 4, 2026
SKILL.mdreadonly
SKILL.md Frontmatter
nameralph-security
descriptionComprehensive security audit with 100 iterations (~30-60 min). Use when user says 'security audit', 'ralph security', 'weekly security check', 'audit this project', 'new project security review', or 'check for vulnerabilities'. Covers OWASP Top 10, auth, secrets, infrastructure, and code quality.
metadata[object Object]

Ralph Security — 100 Iterations (~30-60 min)

Comprehensive security audit with balanced depth and duration.

References

Instructions

Execution Engine

YOU MUST follow this loop for EVERY iteration:

  1. STATE: Read current iteration (start: 1)
  2. PHASE: Determine phase from iteration number
  3. ACTION: Perform ONE check from current phase
  4. VERIFY: Before reporting FAIL — read actual code, check if a library handles it (jose, bcrypt, passport, Auth0, etc.), check DB constraints, check environment gating. If inconclusive: NEEDS_REVIEW, not FAIL.
  5. REPORT: Output iteration result
  6. SAVE: Every 10 iterations, update .ralph-report.md
  7. INCREMENT: iteration = iteration + 1
  8. CONTINUE: IF iteration <= 100 GOTO Step 1
  9. FINAL: Generate comprehensive report

Critical rules:

  • ONE check per iteration — deep, not wide
  • ALWAYS show [SEC-X/100]
  • NEVER skip iterations
  • CRITICAL findings: flag for immediate attention

Per-Iteration Output

══════════════════════════════════════════════════════════
[SEC-{N}/100] Phase {P}: {phase_name}
Check: {specific_check}
══════════════════════════════════════════════════════════
Target: {file/endpoint/system}
Result: {PASS|FAIL|WARN|N/A}
Confidence: {VERIFIED|LIKELY|PATTERN_MATCH|NEEDS_REVIEW}
Severity: {CRITICAL|HIGH|MEDIUM|LOW|INFO}
Finding: {description}
Fix: {recommendation or "N/A"}
──────────────────────────────────────────────────────────
Progress: [██████████░░░░░░░░░░] {N}%
──────────────────────────────────────────────────────────

Persona

Senior security engineer. Evidence-based mindset, defense in depth, fail secure, least privilege.

Phase Structure (100 Iterations)

PhaseIterationsFocus Area
11-15Reconnaissance & Sync
216-45OWASP Top 10 Analysis
346-65Authentication & Secrets
466-85Infrastructure Security
586-100Code Quality & Report

Phase 1: Reconnaissance (1-15)

IterCheck
1Auto-detect stack and infra
2Git sync: local vs remote
3Uncommitted sensitive files
4.env in .gitignore
5Public endpoints enumeration
6Authentication requirements mapping
7Rate limiting coverage
8Exposed ports (host/container)
9Hidden services discovery
10Cron jobs and scheduled tasks
11Environment variable audit
12Docker environment check
13Documentation vs reality
14Attack surface score
15Phase 1 summary

Phase 2: OWASP Top 10 (16-45)

IterOWASPCheck
16-18A01Broken Access Control (IDOR, CORS, path traversal)
19-21A02Cryptographic Failures (weak algos, key mgmt, TLS)
22-27A03Injection (SQL, Command, XSS, Template, Log)
28-30A04Insecure Design (missing controls, business logic)
31-33A05Security Misconfiguration (debug, errors, headers)
34-36A06Vulnerable Components (dependency audit)
37-39A07Auth Failures (credential stuffing, session mgmt)
40-42A08Integrity Failures (deserialization, CI/CD)
43-44A09Logging Failures (coverage, security)
45A10SSRF (URL validation, metadata protection)

Phase 3: Authentication & Secrets (46-65)

Pre-check: Determine if codebase uses well-known libraries vs custom implementations. Library-handled crypto is generally safe — focus on USAGE errors.

IterCheck
46-50Secret detection (API keys, passwords, tokens)
51-55JWT security (algorithm, claims, storage, revocation)
56-58OAuth 2.0 (PKCE, redirect URI, state)
59-62Admin authentication (brute force, timing, lockout)
63-65Rate limiting analysis (coverage, bypass)

Phase 4: Infrastructure (66-85)

IterCheck
66-70Container security (non-root, readonly, limits)
71-75Network security (ports, firewall, isolation)
76-78TLS/SSL (cert validity, ciphers, HSTS)
79-81SSH security (key auth, config hardening)
82-85Database security (SSL, permissions, access)

Phase 5: Code Quality & Report (86-100)

Pre-check: Check database constraints before flagging race conditions.

IterCheck
86-88Race conditions (TOCTOU, concurrent access)
89-91Business logic flaws (workflow, rate limit bypass)
92-94Error handling (safe messages, fail-safe)
95-97Resource management (connections, memory)
98Critical findings review
99Security scorecard generation
100Final report generation

Auto-Detect (Iteration 1)

  1. git rev-parse --show-toplevel, git remote -v
  2. Stack: package.json, pyproject.toml, requirements.txt, go.mod
  3. Infra: Dockerfile, docker-compose.yml, k8s manifests
  4. CI/CD: .github/workflows, .gitlab-ci.yml
  5. Skip non-applicable checks, mark N/A

Report File

On start: rename existing .ralph-report.md to .ralph-report-{YYYY-MM-DD-HHmm}.md. Auto-save every 10 iterations.

Parameters

ParamDefaultOptions
--iterations1001-200
--focusallrecon, owasp, secrets, auth, infra, code, all
--phaseall1-5
--resumeContinue from checkpoint

Context Limit Protocol

If approaching context limit: checkpoint to report file, output resume command, wait for new session.

When to Use

  • Weekly security check
  • New project onboarding
  • Before major release
  • Standard security audit