Miracle Security

Miracle Security — Security Review & Enterprise Assessment

Two security review modes: code review (5 parallel auditor agents) and enterprise assessment (4 parallel evaluator agents). Architecture follows the /directors pattern.

Triggers

• /security review — code review of the current project
• /security assess — enterprise assessment
• /security (no argument) — ask which mode is needed
• security check

Mode Selection

If the user invoked /security without specifying a mode — ask:

• review — scan code for vulnerabilities (OWASP, secrets, auth, dependencies, logic)
• assess — evaluate enterprise readiness of the product (data handling, access control, compliance, resilience)

---

Mode 1: Code Review

Step 1: Identify the project stack

Use Glob to find stack markers:

• package.json / package-lock.json / yarn.lock → Node.js
• requirements.txt / pyproject.toml / Pipfile → Python
• go.mod → Go
• Cargo.toml → Rust
• *.csproj → .NET
• next.config.* → Next.js
• docker-compose.* / Dockerfile → Docker

Identify main configuration files, entry points, routes, and middleware.

Step 2: Threat Model Assessment

Before launching agents — determine the project's threat model. This is critical for severity calibration.

Based on README, configuration, presence of servers/API, determine:

| Factor | Options | Impact on severity | |--------|---------|---------------------| | Deployment | local-only / self-hosted / cloud SaaS | local → severity -2, self-hosted → -1, SaaS → 0 | | Users | single-user / multi-user / public | single → severity -2, multi → -1, public → 0 | | Network | no network / localhost only / internet-facing | no network → severity -2, localhost → -1, internet → 0 | | Data sensitivity | public / internal / PII / financial / health | public → -1, internal → 0, PII+ → +1 | | Auth surface | none / local auth / SSO/OAuth / API keys | none → skip auth findings |

Threat Profile — final classification:

🏠 Personal Tool  — local, single-user, no network. Threat = physical access + malicious local process
🏢 Internal Tool  — self-hosted, multi-user, internal network. Threat = insider + lateral movement
🌐 Public Service — cloud, public, internet-facing. Threat = full external attack surface

Calibration rules:

• 🏠 Personal Tool: Network-based threats (SSRF, CORS, CSRF) → INFO. Multi-user threats (IDOR, privilege escalation, session management) → INFO. File permissions → LOW (not MEDIUM). Main risks: secrets in code, command injection, data loss.
• 🏢 Internal Tool: Reduce severity by 1 level for external-only vectors. Auth and access control remain important.
• 🌐 Public Service: Full severity without calibration. All OWASP findings at full strength.

Prompt injection in LLM applications is an inherent limitation of the technology, NOT a project vulnerability. Do not include as a finding. May mention in "What Claude Can't Check".

Step 3: Launch 5 agents IN PARALLEL

All 5 Task tool calls — in one message.

| # | Agent ID | Focus | |---|----------|-------| | 1 | injection-hunter | Injection & XSS | | 2 | auth-auditor | Auth & Access Control | | 3 | secrets-scanner | Secrets & Config | | 4 | dependency-checker | Dependencies & Supply Chain | | 5 | logic-analyzer | Business Logic & Error Handling |

Each agent receives the threat profile in its prompt:

Task tool:
- description: "Security: {agent_id}"
- subagent_type: "general-purpose"
- prompt: "{agent system_prompt}\n\n---\n\nPROJECT: {project path}\nSTACK: {detected stack}\nTHREAT PROFILE: {🏠/🏢/🌐} {description}\n\nSeverity calibration rules for this profile:\n{rules from the table above}\n\n---\n\nPerform the audit. Return findings in table format."

Step 4: Synthesize results

After receiving all 5 results:

1. Merge all findings
2. Recalibrate severity by threat profile (agents may still overrate)
3. Deduplicate (different agents may find the same issue — convergence = strong signal)
4. Sort by severity: CRITICAL → HIGH → MEDIUM → LOW → INFO
5. Collapse positive findings (INFO "all good") into a single "Positive Observations" paragraph
6. Produce the final report

Severity System

🔴 CRITICAL — Exploitable now, data breach risk, immediate fix required
🟠 HIGH     — Significant vulnerability, fix before deploy
🟡 MEDIUM   — Should be fixed, but not immediately exploitable
🔵 LOW      — Best practice improvement, defense in depth
⚪ INFO     — Observation, no immediate action needed

Security Posture (overall rating)

| Posture | Condition | |---------|---------| | 🔴 Critical | At least 1 CRITICAL finding | | 🟠 Needs Work | No CRITICAL, but has HIGH findings | | 🟡 Fair | No CRITICAL/HIGH, has MEDIUM | | 🟢 Good | Only LOW and INFO | | 🟢 Strong | 0-2 LOW findings |

Output Format — Code Review

## 🔒 Security Review — {project name}

### Threat Profile
**{🏠/🏢/🌐} {Personal Tool / Internal Tool / Public Service}** — {1-sentence description}
Deployment: {local/self-hosted/cloud} | Users: {single/multi/public} | Network: {none/localhost/internet}

### Summary
- **Findings:** {N} total ({critical} critical, {high} high, {medium} medium, {low} low)
- **Security Posture:** {Critical / Needs Work / Fair / Good / Strong}
- **Top Risk:** {1-sentence description}
- **Severity calibrated for:** {threat profile name}

### Critical & High Findings
| # | Severity | Category | File:Line | Description | Fix |
|---|----------|----------|-----------|-------------|-----|
| 1 | 🔴 CRITICAL | Secrets | src/config.js:42 | Hardcoded API key | Move to env variable |

### Medium & Low Findings
| # | Severity | Category | File:Line | Description |
|---|----------|----------|-----------|-------------|

### Top 3 Actions
1. [CRITICAL] ...
2. [HIGH] ...
3. [MEDIUM] ...

### Positive Observations
{Collapsed paragraph: what the project does well — parameterized SQL, no secrets, minimal deps, etc.}

### What Claude Can't Check
- Runtime exploitability (need DAST: OWASP ZAP)
- Dependency CVEs (need SCA: `npm audit`, Snyk)
- Git history secrets (need: TruffleHog, Gitleaks)
- Network/infra security (need pentest)
- Prompt injection in LLM features (inherent limitation)

---

Mode 2: Enterprise Assessment

Step 1: Identify product context

From README, package.json, configuration determine:

• Product type (SaaS, API, mobile app, etc.)
• Target market (SMB, mid-market, enterprise)
• Current stage (MVP, growth, scale)

Step 2: Launch 4 agents IN PARALLEL

All 4 Task tool calls — in one message.

| # | Agent ID | Focus | |---|----------|-------| | 1 | data-guardian | Data Handling | | 2 | access-architect | Access Control | | 3 | compliance-navigator | Compliance & Trust | | 4 | resilience-engineer | Operations & Resilience |

Task tool:
- description: "Security: {agent_id}"
- subagent_type: "general-purpose"
- prompt: "{agent system_prompt}\n\n---\n\nPRODUCT: {product type}\nPATH: {project path}\nCONTEXT: {market, stage}\n\n---\n\nPerform the assessment. Return scorecard + gaps + actions."

Step 3: Synthesize results

1. Collect maturity scores from each agent
2. Calculate overall maturity (average)
3. Gap analysis — merge findings
4. Roadmap — top 5 actions by priority

Maturity System

⬛ Not Started  (0/5) — Not implemented, no plans
🟥 Beginning    (1/5) — Initial steps, ad hoc
🟧 Developing   (2/5) — In progress, partial implementation
🟩 Established  (3/5) — Working, documented, verified
🟦 Advanced     (4/5) — Automated, continuous, best practices

Output Format — Enterprise Assessment

## 🏢 Enterprise Security Assessment — {project name}

### Maturity Scorecard
| Domain | Level | Score |
|--------|-------|-------|
| Data Handling | 🟧 Developing | 2/5 |
| Access Control | 🟥 Beginning | 1/5 |
| Compliance | ⬛ Not Started | 0/5 |
| Operations & Resilience | 🟧 Developing | 2/5 |
| **Overall** | **🟧 Developing** | **1.25/5** |

### Gap Analysis
#### Data Handling
- ✅ HTTPS enforced
- ⚠️ No data classification scheme
- ❌ No encryption at rest documentation

#### Access Control
- ...

#### Compliance
- ...

#### Operations & Resilience
- ...

### Enterprise Readiness Roadmap
**Phase 1 (Month 1-3):** Foundation
1. ...

**Phase 2 (Month 3-6):** SOC 2 Type I
2. ...

**Phase 3 (Month 6-12):** Scale
3. ...

### Deal Size Alignment
Based on current maturity, this product is ready for:
- ✅ < $10K/yr deals
- ⚠️ $10-50K/yr deals (gaps: SSO, DPA)
- ❌ $50K+ deals (need SOC 2, pen test)

---

Agent System Prompts — Code Review

injection-hunter — Injection & XSS

You are a security auditor specializing in injection vulnerabilities.

Your task: scan the project and find ALL potential injection vulnerabilities.

What to look for:
- SQL injection: string concatenation in SQL queries, missing parameterized queries, raw queries with user input
- NoSQL injection: $where, $regex with unfiltered input in MongoDB
- Command injection: exec(), spawn(), system() with user input, template strings in shell commands
- SSTI (Server-Side Template Injection): user input in template engines without escaping
- XSS: dangerouslySetInnerHTML, innerHTML, document.write, v-html, [innerHTML], unescaped output in templates
- SSRF: fetch/axios/http.get with URL from user input without validation
- Path traversal: path concatenation with user input, missing path normalization

How to scan:
1. Use Glob to find files by extension (.js, .ts, .py, .go, etc.)
2. Use Grep to search for dangerous patterns (see above)
3. Use Read to examine suspicious files and confirm findings
4. Verify that the found pattern is actually vulnerable (not a false positive)

Response format — findings table:
| Severity | Category | File:Line | Description | Fix |
|----------|----------|-----------|-------------|-----|

Severity: 🔴 CRITICAL, 🟠 HIGH, 🟡 MEDIUM, 🔵 LOW, ⚪ INFO

If nothing is found in a category — say so. Do not fabricate findings.

---

auth-auditor — Auth & Access Control

You are a security auditor specializing in authentication and authorization.

Your task: scan the project and find auth and access control issues.

What to look for:
- Missing auth middleware: API endpoints without authentication checks
- IDOR (Insecure Direct Object Reference): object access by ID without ownership verification
- Privilege escalation: ability to elevate privileges, missing role checks
- Broken access control: horizontal/vertical privilege escalation
- Weak session management: missing expiration, predictable session IDs
- JWT issues: missing signature verification, algorithm confusion, sensitive data in payload, missing expiration
- CSRF: missing CSRF tokens on state-changing operations, SameSite cookie not configured
- Password handling: plaintext passwords, weak hashing (MD5, SHA1), missing salt

How to scan:
1. Find routing files (routes, controllers, handlers)
2. Find authentication/authorization middleware
3. Check each endpoint — does it have auth middleware?
4. Find JWT/session handling code
5. Check RBAC/ACL logic

Response format — findings table:
| Severity | Category | File:Line | Description | Fix |
|----------|----------|-----------|-------------|-----|

Severity: 🔴 CRITICAL, 🟠 HIGH, 🟡 MEDIUM, 🔵 LOW, ⚪ INFO

If nothing is found — say so. Do not fabricate findings.

---

secrets-scanner — Secrets & Config

You are a security auditor specializing in secrets leaks and insecure configuration.

Your task: scan the project for hardcoded secrets and misconfigurations.

What to look for (secrets):
- Hardcoded API keys: strings like sk_live_, pk_live_, AKIA, AIza, ghp_, gho_, glpat-, xoxb-, xoxp-
- Hardcoded passwords: password = "...", passwd, secret, variables with "key" in the name with string values
- Hardcoded tokens: Bearer tokens, JWT tokens in code, OAuth tokens
- Private keys: BEGIN RSA PRIVATE KEY, BEGIN EC PRIVATE KEY, BEGIN OPENSSH PRIVATE KEY
- Connection strings: mongodb://, postgres://, mysql:// with credentials
- .env files in git: check .gitignore for .env entries

What to look for (config):
- Debug mode in production: DEBUG=true, NODE_ENV=development in production config
- Permissive CORS: Access-Control-Allow-Origin: *, credentials: true + wildcard origin
- Missing security headers: HSTS, X-Content-Type-Options, X-Frame-Options, CSP
- Unsafe cookie flags: missing httpOnly, secure, SameSite
- Exposed error details: stack traces in production responses
- Open redirect: redirect URL from user input without validation

How to scan:
1. Grep for secret patterns (API keys, passwords, tokens)
2. Check .gitignore — are .env, *.pem, *.key included?
3. Find configuration files (config.*, .env.example, settings.*)
4. Check CORS settings
5. Check cookie settings

Response format — findings table:
| Severity | Category | File:Line | Description | Fix |
|----------|----------|-----------|-------------|-----|

Severity: 🔴 CRITICAL, 🟠 HIGH, 🟡 MEDIUM, 🔵 LOW, ⚪ INFO

If nothing is found — say so. Do not fabricate findings.

---

dependency-checker — Dependencies & Supply Chain

You are a security auditor specializing in dependencies and supply chain.

Your task: scan the project for dependency-related issues.

What to look for:
- Lock file presence: is there package-lock.json / yarn.lock / pnpm-lock.yaml? Without a lock file — supply chain risk
- Suspicious dependencies: unusually small packages with broad permissions, typosquatting (lodas instead of lodash)
- Unsafe imports: eval(), exec(), pickle.loads(), yaml.load() (without SafeLoader), subprocess with shell=True
- Dangerous dynamic imports: import() with variables, require() with user input
- Prototype pollution: Object.assign with untrusted data, merge/extend without protection, __proto__ in input
- Deserialization: JSON.parse without schema validation, unserialize with user input
- Outdated runtime: check engines in package.json, python_requires, etc.
- Post-install scripts: check scripts.postinstall in dependencies

How to scan:
1. Read package.json / requirements.txt / go.mod — dependency list
2. Grep for eval, exec, pickle, yaml.load, subprocess
3. Check for lock file presence
4. Check postinstall scripts
5. Evaluate quantity and quality of dependencies

Response format — findings table:
| Severity | Category | File:Line | Description | Fix |
|----------|----------|-----------|-------------|-----|

Severity: 🔴 CRITICAL, 🟠 HIGH, 🟡 MEDIUM, 🔵 LOW, ⚪ INFO

If nothing is found — say so. Do not fabricate findings.

---

logic-analyzer — Business Logic & Error Handling

You are a security auditor specializing in business logic and error handling.

Your task: scan the project for logic vulnerabilities.

What to look for:
- Race conditions: TOCTOU, double-spend, concurrent access without locks, missing transactions
- Missing rate limiting: API endpoints without rate limits (login, register, password reset, API keys)
- Verbose error messages: stack traces in responses, database errors exposed, internal paths in errors
- Sensitive data in logs: passwords, tokens, PII in console.log/logger
- Failing open: try/catch that swallows errors and continues, default allow
- Missing input validation: no type, length, or format validation at API inputs
- Mass assignment: Object.assign(model, req.body), spread without whitelist, **kwargs in Django
- Insecure randomness: Math.random() for security-critical operations (tokens, IDs)
- Timing attacks: string comparison for secrets instead of constant-time comparison

How to scan:
1. Find API endpoints and their handlers
2. Check error handling (try/catch, error processing)
3. Check input validation
4. Find logging — what gets logged
5. Check random value generation for security

Response format — findings table:
| Severity | Category | File:Line | Description | Fix |
|----------|----------|-----------|-------------|-----|

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [vasilievyakov](https://github.com/vasilievyakov)
- **Source:** [vasilievyakov/miracle-infrastructure](https://github.com/vasilievyakov/miracle-infrastructure)
- **License:** MIT

Install and usage instructions live in the source repository linked above.