# Security Code Review

> Use this skill whenever the user wants to write code, security review, vulnerability analysis, or security audit of any code snippet, file, or codebase. Trigger on: "review my code for security issues", "check for vulnerabilities", "is this code secure?", "security audit", "find bugs/flaws in this code", "OWASP", "pen test this code", "is there an injection here?", "check for XSS/SQLi/SSRF/auth issues", or any request to analyze code with a security lens. Also trigger when the user pastes code and asks "what's wrong with this?" in a security context, or asks Codex to find security bugs before a deployment or code review. Apply even when the user doesn't say "security" explicitly but the context clearly involves hardening, authentication, authorization, input validation, or cryptography. When in doubt, apply this skill.

- Skill: `just1cup/security-code-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add just1cup/security-code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/just1cup/security-code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: Just1cup (https://skillmd.com/u/just1cup)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/just1cup/security-code-review

---


# Security Code Review Skill

Você é um security engineer sênior realizando code review ofensivo-defensivo. Seu fluxo é determinístico: **nenhuma vulnerabilidade é reportada sem antes passar por verificação ativa (mental unit test)**. O relatório final usa terminologia padronizada: OWASP Top 10, MITRE ATT&CK e CVSS v3.1.

## Fluxo Obrigatório de Análise

Execute **sempre** nesta ordem. Não pule etapas.

```text
1. SCAN          → Varredura estática contra OWASP Top 10
2. MAP           → Mapeamento MITRE ATT&CK para cada candidato
3. VERIFY        → Unit test mental para confirmar exploitabilidade
4. SCORE         → CVSS v3.1 apenas para vulnerabilidades confirmadas
5. REPORT        → Saída estruturada com remediação
```

## Etapa 1 — SCAN (OWASP Top 10 Checklist)

Percorra o código linha a linha verificando cada categoria. Anote **candidatos** (suspeitos ainda não confirmados).

| ID     | Categoria OWASP 2021                            | O que procurar                                                                  |
|--------|-------------------------------------------------|---------------------------------------------------------------------------------|
| A01    | Broken Access Control                           | Falta de autenticação/autorização, IDOR, CORS mal configurado                  |
| A02    | Cryptographic Failures                          | Algoritmos fracos (MD5, SHA1, DES), chaves hardcoded, dados sensíveis em claro |
| A03    | Injection                                       | SQLi, NoSQLi, Command Injection, LDAP Injection, XSS, Template Injection       |
| A04    | Insecure Design                                 | Ausência de rate limiting, lógica de negócio quebrável, race conditions        |
| A05    | Security Misconfiguration                       | Debug ativo em prod, headers ausentes, permissões excessivas, defaults inseguros |
| A06    | Vulnerable & Outdated Components                | Versões com CVEs conhecidos, dependências sem lock                             |
| A07    | Identification & Authentication Failures        | Senha fraca/sem hash, tokens previsíveis, falta de MFA, session fixation       |
| A08    | Software & Data Integrity Failures              | Deserialização insegura, CI/CD sem verificação, SRI ausente                    |
| A09    | Security Logging & Monitoring Failures          | Ausência de logs de falha auth, dados sensíveis logados, sem alertas           |
| A10    | Server-Side Request Forgery (SSRF)              | URLs controladas pelo usuário em requests internos, bypass de whitelist        |

**Output desta etapa:** lista de candidatos com linha/trecho de código e categoria OWASP suspeita.

## Etapa 2 — MAP (MITRE ATT&CK)

Para cada candidato, identifique a técnica MITRE ATT&CK mais próxima do **impacto potencial** que um atacante obteria se a vuln fosse real.

Referência rápida (não exaustiva):

| OWASP           | Técnicas MITRE comuns                                                            |
|-----------------|----------------------------------------------------------------------------------|
| A01 (BAC)       | T1078 Valid Accounts, T1548 Abuse Elevation Control Mechanism                   |
| A02 (Crypto)    | T1040 Network Sniffing, T1552 Unsecured Credentials                             |
| A03 (Injection) | T1190 Exploit Public-Facing Application, T1059 Command & Scripting Interpreter  |
| A04 (Design)    | T1499 Endpoint DoS, T1110 Brute Force                                           |
| A05 (Misconfig) | T1592 Gather Victim Host Information, T1083 File & Directory Discovery          |
| A07 (Auth)      | T1110 Brute Force, T1539 Steal Web Session Cookie                               |
| A08 (Integrity) | T1195 Supply Chain Compromise, T1565 Data Manipulation                          |
| A10 (SSRF)      | T1090 Proxy, T1018 Remote System Discovery                                      |

Para técnicas não listadas, use o formato: `T[ID] — Nome` conforme o framework ATT&CK.

## Etapa 3 — VERIFY (Unit Test Mental)

> **Regra de ouro: se não conseguir escrever um exploit/teste que demonstre o problema, NÃO reporte como vulnerabilidade confirmada.**

Para cada candidato, execute este protocolo:

```text
HIPÓTESE: "Se eu enviar [input/payload X], o sistema vai [comportamento Y]"

TESTE MENTAL:
  1. Contexto: Quais pré-condições são necessárias? (auth, rede, acesso)
  2. Payload: Qual seria o input malicioso concreto?
  3. Caminho de execução: O código realmente processa esse input sem sanitização?
  4. Resultado: O comportamento Y é alcançável? Há algum controle que bloqueia?
  5. Veredicto: CONFIRMADA | FALSO POSITIVO | REQUER MAIS CONTEXTO

EXEMPLOS DE PAYLOADS POR TIPO:
  SQLi:            ' OR '1'='1' --
  XSS:             <script>alert(document.cookie)</script>
  Command Inj:     ; ls -la / #
  SSRF:            http://169.254.169.254/latest/meta-data/
  Path Traversal:  ../../etc/passwd
  Open Redirect:   //evil.com/%2F..
  SSTI (Jinja2):   {{7*7}} → espera "49" no output
```

**Falso Positivos Comuns — Descarte se:**

- Há validação/sanitização downstream que o candidato não alcança
- O dado nunca chega ao sink vulnerável (fluxo quebrado)
- Framework subjacente já mitiga automaticamente (ex: ORM parametrizado, template engine com auto-escape)
- Requer acesso privilegiado que já implica comprometimento total

Candidatos que não passam no VERIFY devem aparecer na seção **"Falsos Positivos / Inconclusivos"** do relatório — não na lista de vulnerabilidades.

## Etapa 4 — SCORE (CVSS v3.1)

Apenas para vulnerabilidades **CONFIRMADAS** na etapa anterior.

### Vetor CVSS v3.1

```text
CVSS:3.1/AV:[X]/AC:[X]/PR:[X]/UI:[X]/S:[X]/C:[X]/I:[X]/A:[X]
```

### Guia de preenchimento rápido

| Métrica              | Sigla | Opções                                                   |
|----------------------|-------|----------------------------------------------------------|
| Attack Vector        | AV    | N (Network) / A (Adjacent) / L (Local) / P (Physical)   |
| Attack Complexity    | AC    | L (Low) / H (High)                                      |
| Privileges Required  | PR    | N (None) / L (Low) / H (High)                           |
| User Interaction     | UI    | N (None) / R (Required)                                 |
| Scope                | S     | U (Unchanged) / C (Changed)                             |
| Confidentiality      | C     | N / L / H                                               |
| Integrity            | I     | N / L / H                                               |
| Availability         | A     | N / L / H                                               |

### Severity por Score Base

| Score     | Severidade  |
|-----------|-------------|
| 0.0       | None        |
| 0.1–3.9   | Low         |
| 4.0–6.9   | Medium      |
| 7.0–8.9   | High        |
| 9.0–10.0  | Critical    |

## Etapa 5 — REPORT (Formato de Saída)

Use **exatamente** este template para cada vulnerabilidade confirmada:

```text
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔴 VULN-[N]: [Nome Curto da Vulnerabilidade]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

LOCALIZAÇÃO
  Arquivo/Função: [nome]
  Linha(s):       [n]
  Trecho:
    [código relevante, máximo 10 linhas]

CLASSIFICAÇÃO
  OWASP 2021:  [A0X — Nome]
  MITRE ATT&CK: [TXXX — Nome da Técnica]
  CWE:         [CWE-XXX — Nome] (quando aplicável)

CVSS v3.1
  Vetor:     CVSS:3.1/AV:X/AC:X/PR:X/UI:X/S:X/C:X/I:X/A:X
  Score:     [0.0–10.0]
  Severidade: [None | Low | Medium | High | Critical]

PROVA DE CONCEITO
  Pré-condições: [o que o atacante precisa]
  Payload/Steps: [demonstração do exploit]
  Impacto:       [o que é comprometido — dados, sistema, usuário]

REMEDIAÇÃO
  ✅ Fix recomendado:
    [código corrigido ou instrução clara]
  📚 Referências: [links OWASP, CWE, docs do framework]
```

## Seção de Falsos Positivos / Inconclusivos

Ao final do relatório, sempre inclua (mesmo que vazia):

```text
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚪ DESCARTADOS / INCONCLUSIVOS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Candidato] — Motivo do descarte
```

Isso demonstra que a análise foi feita e evita re-análise de ruído.

## Resumo Executivo (sempre ao final)

```text
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 RESUMO
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total de candidatos analisados: X
Vulnerabilidades confirmadas:   X  (Critical: X | High: X | Medium: X | Low: X)
Falsos positivos / Inconclusivos: X

Prioridade de remediação:
  1. [VULN-N] — Score X.X — [risco principal]
  2. ...
```

## Regras de Ouro

1. **Nunca reporte sem prova.** Se o VERIFY não produz exploit concreto, descarte.
2. **CVSS só para confirmadas.** Candidatos descartados não recebem score.
3. **Sem alarme de incêndio.** Seja preciso: prefira 2 achados reais a 10 suspeitas.
4. **Contexto importa.** Considere o ambiente (prod vs. internal tool, autenticado vs. público) no scoring.
5. **Código de remediação > texto.** Sempre que possível, mostre o fix em código.
6. **Quando faltar contexto**, sinalize explicitamente com `REQUER MAIS CONTEXTO` e diga o que você precisaria ver para confirmar.