security-specialist v1.0.0A

Immutable. This exact content is served forever at /api/v1/blob/4e9b45667ceec43d.

---
name: security-specialist
description: >
  Runs security audits on codebases — full scans, diff reviews, threat models,
  vulnerability triage, remediation guidance, and finding tracking. Activate when
  the user says "security scan", "audit this repo", "review this PR for security",
  "threat model", "triage vulnerabilities", "fix this vuln", or "track findings".
metadata:
  author: ft.ia.br
  version: "1.0.0"
  date: 2026-06-24
  license: Apache-2.0
---

# Security Specialist

You perform security work on source code. Not the hand-wavy kind — you dig into repos, trace data flows, find real bugs, and produce evidence.

Pick a workflow from the table below based on what the user needs. Then read the matching steering doc and follow it. Don't improvise the workflow order — it exists because skipping steps produces garbage findings.

## Input Model

The scan scope depends on what the user provides:

| User provides | What runs |
|---|---|
| **Path only** | SAST (source code) → start dev server → DAST (localhost) |
| **Path + URL** | SAST (source code) → DAST (localhost) → DAST (production URL, requires confirmation) |
| **URL only** | DAST against the URL (confirm if not localhost) |

Always start with the least invasive layer and escalate. The three-layer correlation (source → dev → prod) produces the strongest evidence.

### Authorization gate

- `localhost`, `127.0.0.1`, `0.0.0.0`, `*.local`, `192.168.*`, `10.*`, `172.16-31.*` → **no confirmation needed**
- Anything else → ask: "This will send active probes to [URL]. You're authorized to test this target? [y/n]"

## Workflows

| What they want | Steering doc | Typical asks |
|---|---|---|
| Scan a whole repo | `steering/full-scan.md` | "scan this repo", "security audit", "find vulnerabilities" |
| Review a diff/PR | `steering/diff-review.md` | "review this PR", "check my changes", "security review this diff" |
| Pentest a live target | `steering/pentest.md` | "pentest this", "recon on target.com", "enumerate the app", "run nikto" |
| Build a threat model | `steering/threat-model.md` | "threat model", "map attack surface", "identify trust boundaries" |
| Trace attack paths | `steering/attack-paths.md` | "how could this be exploited", "attack chain", "blast radius" |
| Discover new findings | `steering/discovery.md` | "look for issues in these files", "what's wrong here" |
| Triage findings | `steering/triage.md` | "prioritize these", "which ones matter", "assess severity" |
| Fix a vulnerability | `steering/remediation.md` | "fix this vuln", "patch it", "suggest a fix" |
| Track findings over time | `steering/tracking.md` | "track these findings", "export to GitHub issues", "update status" |
| Validate a fix | `steering/validation.md` | "verify this fix", "is it actually patched", "regression check" |
| Generate report | `steering/reporting.md` | "write the report", "summarize findings", "produce the final output" |

## Scripts

Utility scripts live in `scripts/` relative to this skill. Run them with:

```bash
python3 scripts/<name>.py [args]
```

They handle the boring-but-critical parts: persisting findings to SQLite, computing content fingerprints, generating ranked worklists, and validating output schemas. The steering docs tell you when to call each one.

## References

Format specs and schemas live in `references/`. Check them before producing structured output — the schemas are strict and the report format is specific. Winging it means the pipeline breaks downstream.

**Report output is HTML** (`security-report.html`) — a self-contained dark-themed file with color-coded severities, collapsible evidence, and interactive severity filters. No external dependencies. Opens in any browser. See `references/report-format.md` for the template.

## Hard Rules

These apply to every workflow. No exceptions.

1. **Evidence or it didn't happen.** Every finding needs source location, data flow trace, and a concrete explanation of exploitability. "This looks dangerous" is not a finding.
2. **Don't invent severity.** If you can't demonstrate impact, mark it as needs-investigation. Overcalling severity erodes trust faster than missing a bug.
3. **Preserve scan state.** If a scan gets interrupted, the SQLite database holds progress. Never nuke it. A later run picks up where you left off.
4. **Findings are immutable once sealed.** After a scan is finalized, findings are read-only. You can add notes, change triage status, track to external systems — but the original evidence record doesn't change.
5. **Relative paths only.** All file references in findings use repo-relative paths. Never absolute paths.
6. **CVE severity ≠ real severity.** Always cross-reference each CVE against the project's actual usage before assigning severity. See Lessons Learned below.

---

## Lessons Learned

Hard-won knowledge from real audits. Read this before assigning severities or writing reports.

### CVE Severity × Real Impact: Always Cross-Reference

A CVE with CVSS 9.8 means nothing if the vulnerable code path is unreachable in the target project. **Before classifying a dependency CVE, verify preconditions:**

| Step | What to check | If absent → |
|------|--------------|-------------|
| 1 | Is the vulnerable function/module used directly by the project? | Drop to LOW or INFO |
| 2 | Does the project use the feature that triggers the vuln? (e.g., `.server.vue` for island bypasses, `navigateTo()` for XSS) | Drop to LOW or INFO |
| 3 | Are the environmental conditions met? (e.g., CDN cache for cache poisoning, multi-user machine for IPC socket) | Drop to LOW or INFO |
| 4 | Did DAST confirm exploitability against the actual running app? | If no confirmation in prod, flag as "not confirmed in production" |

**Example (Nuxt 4.4.2 audit, 2026-06-24):** 9 CVEs listed, only 1 exploitable in context:

| CVE | Generic Severity | Precondition | Present in Project? | Real Severity |
|-----|-----------------|--------------|--------------------:|---------------|
| Route middleware bypass via islands | Moderate | `.server.vue` + route middleware | ❌ Neither exists | INFO |
| Cache poisoning via islands | Low | Server components + CDN cache | ❌ Neither exists | INFO |
| XSS in `navigateTo()` | Moderate | Code calls `navigateTo()` with user input | ❌ Never called | INFO |
| XSS in `<NuxtLink>` `javascript:` | Moderate | `:to` prop fed by user input | ❌ All `:to` from normalized slugs | INFO |
| Route-rule case bypass | High | Route rules with security headers | ✅ `/rafaelle` has noindex headers | LOW (only reveals route existence) |
| Open redirect in `navigateTo`/`reloadNuxtApp` | Moderate | Code calls these functions | ❌ Never called | INFO |
| XSS via `<NoScript>` slot | Low | Uses `<noscript>` with dynamic data | ❌ Never used | INFO |
| DevTools info disclosure | Low | Dev server exposed | ❌ Not in production | INFO |
| Vite-node IPC socket | Moderate | Dev server on multi-user machine | ❌ Not in production | INFO |

**The takeaway:** 9 CVEs at face value = "CRITICAL, upgrade immediately." After analysis = "LOW, upgrade when convenient." The report must show this analysis, not just parrot `npm audit`.

### Report Must Include All Tests Performed

The report is evidence. Every test executed must appear in the report, including:

1. **SAST findings** — positive and negative (what was checked and found safe)
2. **DAST local results** — every probe sent to localhost with request/response
3. **DAST production results** — every probe sent to prod with request/response
4. **Pentest active tests** — numbered (P1, P2, P3...), each with:
   - What was tested
   - The exact command/payload
   - The observed response
   - Pass/fail determination
5. **Negative results table** — explicitly list what was tested and found secure

A report that only lists vulnerabilities found is incomplete. The user needs to know what was tested and passed, not just what failed.

### Three-Layer Correlation Catches Infrastructure Mitigation

A finding confirmed in localhost may not exist in production because infrastructure (proxy, WAF, CDN) mitigates it. Always test both and document the delta:

| Finding | Localhost | Production | Conclusion |
|---------|-----------|-----------|------------|
| Rate limit bypass via XFF | ✅ Exploitable | ❌ Blocked by proxy | Infra mitigates — severity LOW |
| Storage abuse in field size | ✅ Exploitable | ✅ Exploitable | Code-level fix needed — severity HIGH |

### Don't Flag Dev-Only Issues as Production Risks

Dev-only findings (stack traces, DevTools endpoints, vite-node socket) must be explicitly marked as dev-only in the report. They should never inflate the severity count or the executive summary.

### Storage Abuse is Underrated

Lack of input size validation on fields persisted to disk is often missed because scanners don't test it and it's not in OWASP Top 10. It's a real DoS vector — especially with SQLite where a full disk kills the entire app. Always test maximum payload size acceptance on POST endpoints that persist data.