# Security Specialist

> >

- **Type:** Skill
- **Install:** `agentstack add skill-fabricioctelles-skills-security-specialist`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [fabricioctelles](https://agentstack.voostack.com/s/fabricioctelles)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** Apache-2.0
- **Upstream author:** [fabricioctelles](https://github.com/fabricioctelles)
- **Source:** https://github.com/fabricioctelles/skills/tree/main/skills/security-specialist
- **Website:** https://skill.dev.br

## Install

```sh
agentstack add skill-fabricioctelles-skills-security-specialist
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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.

## Core Principles

### Only report what you can exploit
Every finding must have a concrete attack scenario: who is the attacker, what do they do, and what do they get? "An attacker could theoretically..." is not a finding. "Send this request, get this result" is.

### Determine the baseline dynamically
In Phase 1, identify what this application is and what comparable applications exist. Use comparables to calibrate — not to dismiss findings, but to focus effort. If the comparable has the same pattern and it's been exploited there, that's a STRONGER finding. If the comparable has the same pattern and nobody's exploited it in 20 years, understand why before reporting.

### Adversarial validation
The agent that checks a finding is never the agent that found it. Hunting agents find; validation agents kill false positives. This separation is critical for report quality.

### Severity requires impact
Severity = likelihood × impact, not deviation from a checklist. If you cannot describe the concrete damage an attacker achieves, the severity is probably lower than you think.

### Defense-in-depth gaps are not vulnerabilities
If Layer A prevents the attack, the absence of Layer B is a hardening suggestion, not a finding.

### Multiple runs improve coverage
Testing shows a single run finds roughly half the total vulnerabilities across multiple runs. Each run explores different code paths. Prior runs inform where to dig deeper.

---

## 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" |
| Hunt vulnerabilities | `steering/hunting.md` | "hunt for bugs", "attack classes", "run the wildcard agent" |
| 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:

```bash
python3 scripts/.py [args]     # Python utilities
node scripts/validate-findings.cjs   # Schema validator
```

| Script | Purpose |
|--------|---------|
| `scan_db.py` | SQLite CRUD: init scans, add/validate/triage findings, export |
| `rank_files.py` | Score files by security relevance for discovery worklists |
| `pentest.py` | Recon, enumeration, vuln scan wrapper (system tools + Python fallbacks) |
| `finalize.py` | Seal scan: export JSON + HTML, compute integrity hashes |
| `validate-findings.cjs` | Validate findings.json against report-schema.json (zero deps, Node.js) |

## References

| File | What it governs | When to read |
|---|---|---|
| `references/report-format.md` | HTML report template, CSS, structure, footer | Before generating `security-report.html` |
| `references/finding-format.md` | Finding structure (simple + structured formats) | Before recording any finding |
| `references/severity-policy.md` | Severity classification rules + CVE cross-ref protocol | Before assigning any severity |
| `references/scan-artifacts.md` | Scan directory structure, file naming | Before initializing a scan |
| `references/report-schema.json` | JSON schema for structured findings.json | Before writing Phase 5 output |

**Report output is HTML** (`security-report.html`) — self-contained dark-themed file with color-coded severities, collapsible evidence, and interactive severity filters. No external dependencies.

---

## Anti-Patterns to Avoid

Erros que tornam auditorias de segurança inúteis:

1. **Listar tudo que desvia do OWASP como finding.** OWASP é checklist, não bug list. Toda aplicação real faz tradeoffs.

2. **Rating defense-in-depth gaps como HIGH/CRITICAL.** "Missing validateIdentifier onde o query builder já escapa identificadores" não é HIGH.

3. **Ignorar o deployment model.** Rate limiting no CDN layer é arquitetura válida. Nem toda app precisa rate limiting no application level.

4. **Tratar designed behavior como bug.** Entenda o trust model antes de auditar. Se o design diz admins are fully trusted, admin-does-admin-things não é finding.

5. **Padding o report com LOWs para parecer thorough.** Dez LOWs não fazem um report útil. Três MEDIUMs fazem.

6. **"Potential" findings sem proof.** Ou você pode explotar ou não pode. Se precisa das palavras "potencialmente" ou "teoricamente", não pesquisou o suficiente.

7. **Ignorar o que o codebase faz bem.** Se auth é sólido, diga. Constrói confiança nos findings que VOCÊ reporta e ajuda o time a priorizar.

8. **Construir exploits de assumptions incorretas sobre parser/runtime.** Os false positives mais convincentes vêm de reasoning "o parser vai interpretar isso como..." sem verificar. Se o exploit depende de parser behavior, cite a spec ou teste. Não assuma.

9. **Pular business logic e creative attacks.** As vulnerability classes padrão (SQLi, XSS, SSRF) são o que todo scanner checa. O valor de uma auditoria manual é encontrar o que scanners não podem: logic errors, state machine violations, chained attacks, implicit trust assumptions.

10. **Desistir fácil demais.** "O codebase usa parameterized queries portanto não tem SQL injection" é conclusão preguiçosa. Cheque CADA uso de sql.raw(). Cheque dynamic identifiers. Cheque search/FTS. Cheque se existe code path que bypassa o query builder. Insista.

---

## Hard Rules

These apply to every workflow. No exceptions.

1. **Respect the user's preferred language.** Report content in the user's language. HTML template structure stays as-is.
2. **Evidence or it didn't happen.** Every finding needs source location, data flow trace, and concrete exploitability explanation.
3. **Don't invent severity.** If you can't demonstrate impact, mark it as needs-investigation.
4. **Preserve scan state.** SQLite database holds progress. Never nuke it. Later runs pick up where you left off.
5. **Findings are immutable once sealed.** After finalization, original evidence record doesn't change.
6. **Relative paths only.** All file references use repo-relative paths.
7. **CVE severity ≠ real severity.** Always cross-reference against actual project usage.
8. **Follow reference specs exactly.** Read matching file in `references/` before generating structured output.
9. **Validate structured output.** Run `node scripts/validate-findings.cjs` before delivering findings.json.
10. **Adversarial validation is mandatory for full-scan.** Never skip Phase 3 or Phase 6.

---

## Report Compliance Checklist

Before delivering `security-report.html`, verify ALL against `references/report-format.md`:

### Structure (must exist in this order)
- [ ] `` with repo name
- [ ] Meta grid: Repository, Date, Target, Methodology
- [ ] Summary cards (count per severity)
- [ ] Executive summary paragraph
- [ ] Filter buttons (Todos, Critical, High, Medium, Low, Info)
- [ ] Finding cards sorted by severity desc
- [ ] CVE analysis table (if deps have advisories)
- [ ] Pentest results section (if applicable)
- [ ] Negative results table — what was tested and found secure
- [ ] Remediation priority table
- [ ] **Footer**: `Generated by security-specialist skill by github.com/fabriciotelles/skills`

### Styling
- [ ] Dark theme, color-coded severity badges
- [ ] No external dependencies, works offline

### Content integrity
- [ ] All tests performed appear in report (positive AND negative)
- [ ] Evidence is actual output, not paraphrased
- [ ] CVE severities cross-referenced against project context
- [ ] Findings validated adversarially (Phase 3 passed)
- [ ] Confidence score present for each finding (full-scan)

---

## Lessons Learned

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

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

| Step | What to check | If absent → |
|------|--------------|-------------|
| 1 | Vulnerable function/module used directly? | Drop to LOW or INFO |
| 2 | Project uses the triggering feature? | Drop to LOW or INFO |
| 3 | Environmental conditions met? | Drop to LOW or INFO |
| 4 | DAST confirmed exploitability? | Flag as "not confirmed in production" |

### Three-Layer Correlation

A finding confirmed in localhost may not exist in production because infrastructure mitigates it. Always test both and document the delta.

### Storage Abuse is Underrated

Lack of input size validation on persisted fields is often missed. Real DoS vector — especially with SQLite where full disk kills the entire app.

### Multi-Run Coverage Strategy

Each run should explicitly target what prior runs missed. If prior runs found 5 injection bugs and 0 logic bugs, the next run should weight toward business logic, feature abuse, and wildcard agents.

## Source & license

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

- **Author:** [fabricioctelles](https://github.com/fabricioctelles)
- **Source:** [fabricioctelles/skills](https://github.com/fabricioctelles/skills)
- **License:** Apache-2.0
- **Homepage:** https://skill.dev.br

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-fabricioctelles-skills-security-specialist
- Seller: https://agentstack.voostack.com/s/fabricioctelles
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.