Ralph Security Audit

Comprehensive security audit with 100 iterations (~30-60 min). Use when user says 'security audit', 'ralph security', 'weekly security check', 'audit this pr...

Security Scan

The skill's instructions broadly match a security-audit purpose, but it asks the agent to read environment variables, DB constraints, and write a report without declaring required credentials or explicitly warning about sensitive data — this mismatch and the potential for collecting secrets warrants caution.

Purpose & Capability

Name and description match the behavior: the SKILL.md instructs the agent to enumerate stack files, CI, infra manifests, secrets, auth, and run 100 staged checks. These capabilities are coherent with a comprehensive security audit.

Instruction Scope

Runtime instructions explicitly tell the agent to read code, check environment variables, audit DB constraints, run git commands, and write/rotate a `.ralph-report.md` file. Reading repo files and running git is consistent, but the instructions are broad (e.g., 'check DB constraints', 'Environment variable audit') and give the agent discretion to access secrets and system state not declared elsewhere.

Install Mechanism

Instruction-only skill with no install spec and no shipped code — this is low-risk from an install perspective (nothing is downloaded or written by an installer).

Credentials

The skill requests access to environment variables, uncommitted sensitive files, and possibly databases, but requires.env and primary credential are empty. That mismatch means the agent may try to access sensitive local env/state without any declared credential scope or user prompt guidance.

Persistence & Privilege

always is false and the skill does not request system-wide persistence. It instructs writing and rotating `.ralph-report.md` in the workspace (normal for an audit), which may store discovered secrets or sensitive findings locally — users should be warned to protect that file.

What to consider before installing

This skill is an instruction-only, 100-step security audit that will read project files, run git commands, scan for secrets, inspect environment variables, and write a `.ralph-report.md` in the repository. That behavior aligns with an audit, but note: (1) it will access environment variables and may surface secrets despite the skill declaring no required credentials, (2) it will write a report file that could contain sensitive findings — back up or inspect existing `.ralph-report.md` before running, and (3) if you run it against a live system the agent may request DB or infrastructure access (you would need to provide credentials separately). Only run this skill in a controlled environment where you are comfortable the agent can read the repo and env, and review the generated report before sharing it. If you need stricter boundaries, require the skill to declare which env/files it will access or run it inside an isolated container/CI job with read-only mounts.

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

Comprehensive security audit with balanced depth and duration.

References

• Severity definitions and triage guidance

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)

Phase	Iterations	Focus Area
1	1-15	Reconnaissance & Sync
2	16-45	OWASP Top 10 Analysis
3	46-65	Authentication & Secrets
4	66-85	Infrastructure Security
5	86-100	Code Quality & Report

Phase 1: Reconnaissance (1-15)

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

Phase 2: OWASP Top 10 (16-45)

Iter	OWASP	Check
16-18	A01	Broken Access Control (IDOR, CORS, path traversal)
19-21	A02	Cryptographic Failures (weak algos, key mgmt, TLS)
22-27	A03	Injection (SQL, Command, XSS, Template, Log)
28-30	A04	Insecure Design (missing controls, business logic)
31-33	A05	Security Misconfiguration (debug, errors, headers)
34-36	A06	Vulnerable Components (dependency audit)
37-39	A07	Auth Failures (credential stuffing, session mgmt)
40-42	A08	Integrity Failures (deserialization, CI/CD)
43-44	A09	Logging Failures (coverage, security)
45	A10	SSRF (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.

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

Phase 4: Infrastructure (66-85)

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

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

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

Iter	Check
86-88	Race conditions (TOCTOU, concurrent access)
89-91	Business logic flaws (workflow, rate limit bypass)
92-94	Error handling (safe messages, fail-safe)
95-97	Resource management (connections, memory)
98	Critical findings review
99	Security scorecard generation
100	Final 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

Param	Default	Options
--iterations	100	1-200
--focus	all	recon, owasp, secrets, auth, infra, code, all
--phase	all	1-5
--resume	—	Continue 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