gava-appsec 1.0.0

package/README.md

@@ -0,0 +1,56 @@
+# gava-appsec
+
+Base de **AppSec acionável** (desenvolvimento seguro) para escrever e revisar código
+seguro por padrão — em qualquer IDE que leia `AGENTS.md` (Cursor, GitHub Copilot,
+Windsurf, Codex, Gemini CLI, Zed, JetBrains).
+
+Baseada em **OWASP Top 10:2025 · OWASP ASVS 5.0.0 · API Security Top 10:2023 · CWE Top 25 · NIST SSDF / 800-63B**.
+
+```bash
+npx gava-appsec init
+```
+
+Instala no seu projeto:
+
+```
+AGENTS-appsec.md                              ← instruções de AppSec para o agente
+appsec/cheatsheet.md                          ← "estou escrevendo X → cheque Y"
+appsec/references/auth-sessao-contas.md       ← login/Argon2id, sessão, OAuth/OIDC
+appsec/references/injecoes.md                 ← SQLi, XSS, SSRF, upload, XXE...
+appsec/references/controle-acesso.md          ← IDOR/BOLA, multi-tenant, race conditions
+appsec/references/rate-limiting.md            ← limites por rota/IP/tenant, 429
+appsec/references/cripto-dados-pii.md         ← TLS, AES-GCM, segredos/vault, PII
+appsec/references/hardening-headers-cloud.md  ← headers, cookies, CORS, containers/cloud
+appsec/references/supply-chain-devsecops.md   ← SCA/SBOM, CI/CD seguro, SAST/DAST
+appsec/references/deteccao-resposta.md        ← logging, threat modeling (STRIDE), IR
+```
+
+Opções: `npx gava-appsec init --force` (sobrescreve) · `npx gava-appsec help`.
+
+## Como usar
+
+Depois do `init`, peça ao agente da sua IDE, por exemplo:
+
+```
+Escreva o endpoint de login desta API seguindo o AGENTS-appsec.md.
+```
+```
+Revise este controller de acesso a banco contra o checklist do AGENTS-appsec.md.
+```
+
+O agente cruza o código com o checklist do domínio relevante (auth, injeções, controle
+de acesso, cripto, etc.) e aplica o "Faça / Não faça" antes de entregar.
+
+## No Claude Code / Cowork
+
+Esta mesma base também está disponível como skill nativa (`desenvolvimento-seguro`)
+via marketplace:
+
+```bash
+/plugin marketplace add VgavaBR123/gava-skills
+/plugin install seguranca-plugin@gava-tools
+```
+
+## Licença
+
+[CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/) — mantido por **Gava**.

package/assets/AGENTS-appsec.md

@@ -0,0 +1,48 @@
+# Desenvolvimento Seguro — AppSec acionável (instruções para o agente)
+
+> Instale por `npx gava-appsec init`. Este arquivo é a porta de entrada; o detalhe de cada domínio está em `appsec/references/`.
+> **Base normativa**: OWASP Top 10:2025 · OWASP ASVS 5.0.0 · OWASP API Security Top 10:2023 · CWE Top 25 (MITRE) · NIST SSDF (SP 800-218) · NIST 800-63B-4 | **Escopo**: web/API
+
+## Como usar
+
+- **Ao escrever ou revisar código** que toque login, autenticação, sessão/logout, rotas/endpoints de API, acesso a banco, upload, OAuth/OIDC, rate limiting, criptografia, headers HTTP, CORS, CI/CD, dependências, containers/cloud ou dados pessoais — **mesmo sem a palavra "segurança"** —, cruze o resultado com o checklist do domínio relevante antes de entregar.
+- Consulte o arquivo de referência do domínio na tabela abaixo (leia só o relevante).
+- Meta de baseline: **OWASP ASVS L2** para qualquer app com contas/dados de clientes + os controles do **API Security Top 10** para toda superfície HTTP/JSON.
+
+## Princípio central (aplicar em toda decisão)
+
+Para cada peça de código, responda três perguntas: **ameaça** ("o que o atacante consegue fazer?"), **defesa** ("qual controle reduz isso?") e **anti-padrão** ("qual implementação parece correta mas ainda falha?"). Autenticar **não** é autorizar. Entrada do cliente é **sempre** não confiável. Negue por padrão. Valide no servidor, nunca só na UI.
+
+## Domínios (leia o arquivo relevante)
+
+| Domínio | Cobre | Arquivo |
+|---|---|---|
+| Autenticação, sessão e contas | Rotas de API, login, logout, recuperação de conta, OAuth 2.0/OIDC, anti-bot | [appsec/references/auth-sessao-contas.md](appsec/references/auth-sessao-contas.md) |
+| Injeções e validação de entrada | SQLi, NoSQL/Command/LDAP/XXE/SSTI, XSS, CSRF, SSRF, upload/path traversal, desserialização/mass assignment/open redirect | [appsec/references/injecoes.md](appsec/references/injecoes.md) |
+| Controle de acesso e lógica | Broken Access Control, IDOR/BOLA, multi-tenant, race conditions/TOCTOU, falhas de lógica | [appsec/references/controle-acesso.md](appsec/references/controle-acesso.md) |
+| Rate limiting e anti-abuso | Algoritmos, limites por rota/IP/tenant, 429, proteção de endpoints caros | [appsec/references/rate-limiting.md](appsec/references/rate-limiting.md) |
+| Criptografia, segredos e dados | TLS/repouso, AES-GCM, gestão de segredos/vault, PII e conformidade (LGPD/GDPR/PCI) | [appsec/references/cripto-dados-pii.md](appsec/references/cripto-dados-pii.md) |
+| Hardening, headers e cloud | Cabeçalhos de segurança, cookies, CORS, tratamento de erros/secure defaults, containers/Kubernetes/cloud | [appsec/references/hardening-headers-cloud.md](appsec/references/hardening-headers-cloud.md) |
+| Supply chain e DevSecOps | Dependências/SCA/SBOM, CI/CD seguro, SAST/DAST/IAST, Secure SDLC/Shift Left | [appsec/references/supply-chain-devsecops.md](appsec/references/supply-chain-devsecops.md) |
+| Detecção, resposta e referências | Logging/monitoramento, threat modeling (STRIDE), resposta a incidentes, referências-mestras | [appsec/references/deteccao-resposta.md](appsec/references/deteccao-resposta.md) |
+
+Referência rápida por gatilho: [appsec/cheatsheet.md](appsec/cheatsheet.md).
+
+## Checklist-mestre consolidado
+
+| Domínio | Controles mínimos |
+|---|---|
+| Auth e contas | Argon2id, blocklist de senha, MFA em contas sensíveis, mensagens de erro neutras, rate limit em login/reset, step-up em ações sensíveis |
+| Sessão | Cookie `Secure` + `HttpOnly` + `SameSite`, prefixo `__Host-`, regenerar ID no login e mudança de privilégio, invalidar no servidor no logout |
+| APIs | Autenticação separada de autorização, checagem por objeto/propriedade/tenant, inventário de versões e endpoints, superfícies internas em rede privada |
+| Input e injeções | Prepared statements em 100% das queries, DTOs/allowlist, validação por contexto, evitar shell, desabilitar XXE |
+| Browser security | Anti-CSRF em mutações, CSP, `frame-ancestors`, HSTS, `nosniff`, SRI, CORS explícito por origem |
+| Arquivos e SSRF | Storage fora do web root, nome aleatório, validar MIME+magic bytes, bloquear IP privado/metadata, allowlist de hosts |
+| Multi-tenant e lógica | `tenant_id` em toda query/cache/fila, transação atômica para saldo/cupom/estoque, idempotency key, máquina de estados explícita |
+| Cripto e segredos | TLS em toda credencial/sessão, AES-GCM ou ChaCha20-Poly1305, vault central + rotação, zero segredo em Git/imagem/log |
+| Cloud e containers | Non-root, capabilities mínimas, Pod Security Standards, NetworkPolicy, S3 Block Public Access, IAM least privilege, IMDSv2 |
+| Supply chain e SDLC | SBOM por build, SCA contínuo, CI/CD com menor privilégio, SAST+DAST, assinatura/proveniência, threat modeling, logging útil, playbook de IR |
+
+## Escopo e limites
+
+Cobre a maioria dos vetores de aplicação web/API com foco em consenso OWASP/NIST/MITRE/MDN. Não substitui pentest, revisão humana de segurança nem parecer jurídico. Verifique sempre a versão vigente das normas (OWASP/NIST/ANPD) antes de citar em produção.

package/assets/cheatsheet.md

@@ -0,0 +1,42 @@
+# Cheatsheet — Desenvolvimento Seguro (AppSec)
+
+Referência rápida. Para o detalhe de cada domínio, veja `references/`.
+
+## Regra de ouro (aplicar a todo código)
+Autenticar ≠ autorizar · entrada do cliente é sempre não confiável · negue por padrão · valide no servidor, nunca só na UI · separe dados de código (parametrização/encoding/APIs nativas).
+
+## Gatilhos → o que checar
+| Estou escrevendo… | Checar primeiro | Referência |
+|---|---|---|
+| Login / senha | Argon2id, MFA, rate limit, mensagem neutra, sem enumeração | auth-sessao-contas |
+| Logout / sessão | Invalidar server-side, `__Host-` cookie, regenerar ID | auth-sessao-contas |
+| OAuth / "login com…" | Authorization Code + PKCE, validar state/nonce/redirect_uri | auth-sessao-contas |
+| Rota / endpoint de API | AuthZ por objeto+tenant, não confiar em claim do cliente | auth-sessao-contas + controle-acesso |
+| Query de banco | Prepared statement em 100%, allowlist p/ campo dinâmico | injecoes |
+| Renderizar dado do usuário | Encoding por contexto, sem `innerHTML`, CSP | injecoes |
+| Chamar shell/parser/template | API nativa, desabilitar XXE, nunca template com input | injecoes |
+| Buscar URL no servidor | Allowlist de host, bloquear IP privado/metadata, IMDSv2 | injecoes |
+| Upload de arquivo | MIME+magic bytes, fora do webroot, nome novo, normalizar path | injecoes |
+| Busca por ID | Checar ownership/tenant (IDOR/BOLA) | controle-acesso |
+| Saldo/cupom/estoque | Update atômico, idempotency, sem check-then-update | controle-acesso |
+| Endpoint caro/sensível | Rate limit por rota+conta, 429+Retry-After | rate-limiting |
+| Dado sensível/segredo | AES-GCM, vault, TLS, sem hardcode; minimizar PII | cripto-dados-pii |
+| Config de resposta HTTP | HSTS, CSP, nosniff, cookies seguros, CORS explícito | hardening-headers-cloud |
+| Dockerfile / deploy cloud | Non-root, least privilege, sem bucket público, sem segredo na imagem | hardening-headers-cloud |
+| package.json / build | SBOM, SCA, SAST no PR, dependência mantida | supply-chain-devsecops |
+| Qualquer feature nova | Threat modeling (STRIDE), logging útil, requisito de segurança | deteccao-resposta |
+
+## Top anti-padrões que reprovam revisão
+- "Se o JWT é válido, está autorizado."
+- Concatenar input em SQL "só nesse caso".
+- `innerHTML = userInput`.
+- `Access-Control-Allow-Origin: *` com credenciais.
+- Segredo no `.env` commitado / na imagem Docker.
+- Logout que só apaga o cookie no frontend.
+- Ler saldo e atualizar em duas operações separadas.
+- Validar "parece uma URL" e seguir redirects livremente.
+- Confiar em `tenant_id`/`role` vindo do corpo da requisição.
+- SHA-256 "com sal" para senha (use Argon2id).
+
+## Meta de baseline
+OWASP **ASVS L2** para apps com contas/dados de clientes + **API Security Top 10** para toda superfície HTTP/JSON.

package/assets/references/auth-sessao-contas.md

@@ -0,0 +1,158 @@
+# Autenticação, sessão e contas
+
+Domínios: rotas de API, login, logout, recuperação de conta, OAuth 2.0/OIDC, anti-bot.
+Base: OWASP Authentication/Session/Forgot Password/OAuth2/MFA/Credential Stuffing Cheat Sheets, NIST SP 800-63B-4, RFC 9700, OpenID Connect Core, OWASP API Security Top 10:2023.
+
+---
+
+## Proteção de rotas de API
+
+**Risco.** O erro central não é "falta de login" — é **confundir autenticação com autorização**. Uma API pode autenticar o usuário e ainda expor dados de outro cliente por não verificar autorização no nível do objeto, propriedade ou função (BOLA/IDOR, Broken Function Level Authorization). Autentique no gateway, mas **autorize no serviço e no acesso a dados**, com verificação explícita por recurso (`tenant_id`, `owner_id`, escopo, papel). Versões antigas e endpoints de debug esquecidos viram superfície de ataque persistente.
+
+**Faça**
+- Exija autenticação em todas as rotas não públicas e autorize por recurso, não só por papel.
+- Valide ownership e tenant em cada requisição, especialmente IDs vindos da URL.
+- Trate tokens como credenciais: assinatura, `audience`, `issuer`, expiração curta, escopos mínimos.
+- Separe endpoints externos, administrativos e internos com políticas distintas de authN/authZ; prefira rede privada/mTLS para internos.
+
+**Não faça**
+- Não confie em `user_id`, `tenant_id`, `role` ou `is_admin` vindos do cliente.
+- Não suponha que "rota interna" está segura só por ficar atrás do frontend.
+- Não reutilize API keys amplas para múltiplos serviços/tenants.
+- Não deixe versões antigas de API expostas sem o mesmo enforcement de autorização.
+
+**Fontes**
+- Artigos: `https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html` · `https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html` · `https://owasp.org/www-project-api-security/`
+- Normas/PDF: OWASP ASVS 5.0.0 (2025) `https://raw.githubusercontent.com/OWASP/ASVS/v5.0.0/5.0/OWASP_Application_Security_Verification_Standard_5.0.0_en.pdf` · NIST SP 800-63B-4 `https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf`
+- Vídeos: *OWASP API Security Top 10 Course* (freeCodeCamp, 2023) `https://www.youtube.com/watch?v=YYe0FdfdgDU` · *Broken Object Level Authorization* (SmartBear, 2024) `https://www.youtube.com/watch?v=nIWBp_nvzq4`
+
+---
+
+## Login
+
+**Risco.** Combinação de vazamento de senha, credential stuffing, enumeração de usuário, brute force e session hijacking. Para senhas, o padrão é **Argon2id** (mínimo OWASP: 19 MiB, t=2, p=1); alternativas: scrypt, ou bcrypt em legado com custo adequado. NIST 800-63B-4 exige hashing com sal, blocklist de senhas vazadas, desencoraja troca periódica arbitrária e eleva o mínimo para 15 caracteres quando a senha é fator único (8 dentro de MFA). MFA é a melhor defesa operacional; prefira fatores phishing-resistant quando o risco justificar.
+
+```ts
+import argon2 from "argon2";
+export const hashPassword = (pw: string) =>
+  argon2.hash(pw, { type: argon2.argon2id, memoryCost: 19 * 1024, timeCost: 2, parallelism: 1 });
+export const verifyPassword = (hash: string, pw: string) => argon2.verify(hash, pw);
+```
+
+**Faça**
+- Use Argon2id como primeira escolha; se indisponível, bcrypt/scrypt com parâmetros atuais.
+- Implemente MFA para contas admin e acessos sensíveis; step-up em eventos de risco.
+- Adote rate limiting por IP e por conta, detecção de credential stuffing e mensagens de erro genéricas.
+- Normalize credenciais e registre tentativas suspeitas sem vazar PII no log.
+
+**Não faça**
+- Não use SHA-1, SHA-256 "puro" nem criptografia reversível para armazenar senha.
+- Não revele se o usuário existe por diferença de mensagem, tempo ou status HTTP.
+- Não trate MFA por SMS como equivalente a fator resistente a phishing.
+- Não permita tentativas ilimitadas por IP, conta, ASN ou fingerprint.
+
+**Fontes**
+- Artigos: `https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html` · `https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html`
+- Normas: OWASP Password Storage Cheat Sheet `https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html` · NIST SP 800-63B-4 `https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf`
+- Vídeos: *MFA Bypass Attack Protection* (Auth0) `https://www.youtube.com/watch?v=1apSJFtkfFA` · *Account enumeration* (Troy Hunt, 2016) `https://www.youtube.com/watch?v=l4-istLShi4`
+
+---
+
+## Logout e gestão de sessão
+
+**Risco.** O erro mais comum é tratar logout como evento só no cliente. Sessão segura exige invalidação **servidor + cliente**. IDs de sessão devem ter ≥64 bits de entropia e ser **regenerados em toda mudança de privilégio** (especialmente no login) para evitar session fixation. IDs não devem carregar significado de negócio nem PII.
+
+```http
+Set-Cookie: __Host-session=RANDOM_OPAQUE_ID; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=1800
+```
+
+**Faça**
+- Invalide a sessão server-side e remova cookies com `HttpOnly`/`Secure`/`SameSite` coerentes.
+- Para tokens, use expiração curta, refresh token rotation e revogação onde o risco exigir.
+- Limpe storage do cliente; considere `Clear-Site-Data` no logout.
+- Ofereça "logout de todos os dispositivos" para contas com sessão persistente.
+
+**Não faça**
+- Não trate logout apenas como remoção visual no frontend.
+- Não mantenha refresh tokens antigos válidos após rotação ou troca de senha.
+- Não reutilize session ID após autenticação/reautenticação.
+- Não esqueça mobile, SPAs e sessões paralelas.
+
+**Fontes**
+- Artigos: `https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html` · Auth0 Refresh Token Rotation `https://auth0.com/docs/secure/tokens/refresh-tokens/refresh-token-rotation`
+- Normas: RFC 8725 (JWT BCP) `https://datatracker.ietf.org/doc/html/rfc8725` · RFC 7519 (JWT) `https://datatracker.ietf.org/doc/html/rfc7519`
+
+---
+
+## Recuperação de conta
+
+**Risco.** Fluxos de reset são alvo clássico de account takeover (ATO). Padrão seguro: token único, aleatório, curto, armazenado hasheado no servidor, enviado só a canal já verificado, invalidado no primeiro uso, seguido de notificação.
+
+**Faça**
+- Use token único, aleatório, curto e com expiração agressiva.
+- Responda de forma uniforme para "usuário existe / não existe".
+- Exija reautenticação forte para trocar e-mail, senha ou MFA.
+- Faça rate limiting por conta, IP e canal de entrega; monitore abuso de reset.
+
+**Não faça**
+- Não use links previsíveis, PIN curto sem contexto de risco ou perguntas secretas fracas.
+- Não altere senha no primeiro clique sem validações adicionais quando o risco for alto.
+- Não envie senha temporária em texto puro por e-mail.
+- Não permita que a recuperação ignore MFA sem controles compensatórios.
+
+**Fontes**
+- Artigos: `https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html`
+- Normas: OWASP MFA Cheat Sheet `https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html` · NIST SP 800-63B-4
+- Vídeos: *Account enumeration* (Troy Hunt) `https://www.youtube.com/watch?v=l4-istLShi4`
+
+---
+
+## OAuth 2.0 e OpenID Connect
+
+**Risco.** OAuth é autorização; para login federado use **OIDC**. O padrão moderno é **Authorization Code + PKCE** para SPAs e apps públicos; o Implicit Grant está depreciado. O callback é parte do perímetro de autenticação, não "só um redirect".
+
+```ts
+if (callback.state !== session.oauthState) throw new Error("invalid_state");
+if (callback.issuer !== expectedIssuer) throw new Error("invalid_issuer");
+if (callback.redirectUri !== registeredRedirectUri) throw new Error("invalid_redirect_uri");
+// trocar code por tokens no back-channel; nunca aceitar access token via front-channel
+```
+
+**Faça**
+- Use Authorization Code + PKCE para SPAs e apps públicos.
+- Valide `state`, `nonce`, `iss`, `aud`, `exp` e `redirect_uri` por comparação estrita.
+- Dê escopos mínimos e rotacione refresh tokens quando aplicável.
+- Use OIDC para autenticação e OAuth para autorização; não misture os papéis.
+
+**Não faça**
+- Não use implicit flow em projetos novos.
+- Não aceite `redirect_uri` com curingas.
+- Não trate ID token como access token.
+- Não dê refresh token amplo e eterno a cliente público sem proteção adicional.
+
+**Fontes**
+- Artigos: OpenID Connect Core `https://openid.net/specs/openid-connect-core-1_0-final.html` · Auth0 Refresh Token Rotation `https://auth0.com/docs/secure/tokens/refresh-tokens/refresh-token-rotation`
+- Normas: OWASP OAuth2 Cheat Sheet `https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html` · RFC 9700 (OAuth 2.0 Security BCP, 2025) `https://www.rfc-editor.org/info/rfc9700/`
+- Vídeos: *What's New With OAuth and OIDC?* (OktaDev) `https://www.youtube.com/watch?v=g_aVPdwBTfw` · *OAuth 2.0 and OIDC in plain English* (OktaDev, 2018) `https://www.youtube.com/watch?v=996OiexHze0`
+
+---
+
+## Anti-bot e scraping
+
+**Risco.** Bots fazem scraping, credential stuffing, ATO e criação em massa de contas. Defesa é em camadas; CAPTCHA é auxiliar, não estratégia principal.
+
+**Faça**
+- Combine CAPTCHA/score-based bot defense com rate limiting, reputação, device signals e comportamento.
+- Proteja login, recuperação, cadastro, busca e exportações com políticas diferentes.
+- Separe tráfego humano, API partner, crawler permitido e bot malicioso.
+- Monitore account creation abuse, scraping e credential stuffing como fluxos distintos.
+
+**Não faça**
+- Não dependa só de CAPTCHA visível.
+- Não use um único limite global para todo o site.
+- Não confunda scraping benigno de SEO com abuso de negócio.
+- Não permita automação massiva em endpoints "pouco importantes".
+
+**Fontes**
+- Artigos: OWASP Automated Threats `https://owasp.org/www-project-automated-threats-to-web-applications/` · Google Cloud sobre credential stuffing `https://cloud.google.com/blog/products/identity-security/how-google-cloud-can-help-stop-credential-stuffing-attacks`
+- Vídeos: *Super Bot Fight Mode* (Cloudflare, 2025) `https://www.youtube.com/watch?v=QKRQQ7_cez4`

package/assets/references/controle-acesso.md

@@ -0,0 +1,83 @@
+# Controle de acesso, multi-tenant e lógica
+
+Domínios: Broken Access Control (IDOR/BOLA), isolamento multi-tenant, falhas de lógica e race conditions/TOCTOU.
+Base: OWASP Authorization / IDOR Prevention / Business Logic / Multi-Tenant Cheat Sheets, PortSwigger Access Control e Race Conditions, OWASP Top 10:2025 A01.
+
+---
+
+## Broken Access Control
+
+**Risco.** Categoria mais crítica do OWASP Top 10. Anti-padrão recorrente: autorização só na UI ou no controller. A verificação precisa existir em **cada camada** — rota, serviço, acesso a dados, fila, relatório exportado, backoffice. Privilégio vertical → cheque papel/permissão; horizontal → cheque propriedade do recurso; APIs → cheque objeto e propriedade, não só endpoint.
+
+**Faça**
+- Reavalie autorização no backend em cada operação, objeto e função.
+- Separe claramente autoridade horizontal e vertical.
+- Use decisão centralizável de policy quando o domínio ficar complexo.
+- Teste IDOR/BOLA em APIs, filas, jobs e endpoints legados.
+
+**Não faça**
+- Não confie em esconder link, botão ou menu.
+- Não exponha IDs sequenciais sem checagem de ownership.
+- Não propague privilégios pelo frontend.
+- Não trate "admin endpoint" sem auditoria e reautenticação.
+
+**Fontes**
+- Artigos: Authorization `https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html` · PortSwigger Access Control `https://portswigger.net/web-security/access-control` · OWASP Top 10:2025 A01 `https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/`
+- Normas: IDOR Prevention `https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html` · OWASP ASVS 5.0.0
+- Vídeos: *Broken Access Control - OWASP Top 10 2025* `https://www.youtube.com/watch?v=vUFVxoV5y_I`
+
+---
+
+## Isolamento multi-tenant
+
+**Risco.** Multi-tenant inseguro quase sempre falha por lookup sem `tenant_id`, índice errado, cache compartilhado ou job assíncrono sem contexto de tenant. Identifique o tenant a partir do **contexto autenticado**, nunca de parâmetro confiado.
+
+```sql
+SELECT * FROM invoices WHERE tenant_id = $1 AND invoice_id = $2;
+-- anti-padrão: consultar só por invoice_id e "confiar" na UI
+```
+
+**Faça**
+- Torne tenant scoping obrigatório em query, cache key, fila, storage e logs.
+- Use credenciais, quotas e rate limits por tenant.
+- Identifique tenant no backend a partir de contexto autenticado.
+- Separe quebras de confiança em camadas: aplicação, banco, cache, observabilidade.
+
+**Não faça**
+- Não compartilhe cache keys, buckets, índices ou API keys entre tenants.
+- Não aceite `tenant_id` vindo do cliente sem revalidação.
+- Não permita query administrativa sem switch explícito e auditado.
+- Não misture criptografia, exportação ou backup sem contexto de tenant.
+
+**Fontes**
+- Artigos: Multi-Tenant Security `https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html` · Azure Multitenancy `https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/overview`
+- Normas: NIST SP 800-207 Zero Trust `https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf` · OWASP ASVS 5.0.0
+
+---
+
+## Falhas de lógica e race conditions / TOCTOU
+
+**Risco.** Cupons, saldo, cashback, estoque, checkout e reset são alvos favoritos: a lógica "funciona" em uso honesto, mas quebra em concorrência adversarial. Não faça "check, depois update" em etapas separadas quando o valor é sensível.
+
+```sql
+UPDATE gift_cards SET balance = balance - $1
+WHERE id = $2 AND tenant_id = $3 AND balance >= $1;
+-- depois valide rows_affected == 1
+```
+
+**Faça**
+- Modele fluxos críticos como máquina de estados explícita no servidor.
+- Recalcule preço, saldo, ownership e elegibilidade no backend.
+- Faça operações críticas idempotentes e transacionais.
+- Teste concorrência: cupom único, checkout, wallet, estoque, reset, referral, aprovação.
+
+**Não faça**
+- Não confie em sequência imposta pelo frontend.
+- Não mantenha "valide depois persista" sem proteção contra TOCTOU.
+- Não presuma que requests iguais não chegarão em paralelo.
+- Não trate abuso de negócio como se fosse só problema de WAF.
+
+**Fontes**
+- Artigos: Business Logic Security `https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html` · PortSwigger Race Conditions `https://portswigger.net/web-security/race-conditions`
+- Normas: PortSwigger *Smashing the state machine* (2023) `https://portswigger.net/research/smashing-the-state-machine`
+- Vídeos: *Race Condition Labs* (PortSwigger) `https://www.youtube.com/watch?v=A3Ah_xWDxyU`

package/assets/references/cripto-dados-pii.md

@@ -0,0 +1,78 @@
+# Criptografia, segredos e dados
+
+Domínios: criptografia em trânsito/repouso, gestão de segredos, PII e conformidade (LGPD/GDPR/PCI).
+Base: OWASP Cryptographic Storage / TLS / Secrets Management / User Privacy Cheat Sheets, NIST SP 800-57 e 800-53, LGPD, GDPR, ANPD, PCI DSS.
+Para PII a fundo, ver a skill `nist-pii-protection`; para cripto teórica, `boneh-shoup-applied-crypto`.
+
+---
+
+## Criptografia (trânsito e repouso)
+
+**Risco.** Erros comuns: reutilizar nonce, inventar esquema próprio, armazenar chave junto do dado, esquecer rotação/versão de chave, misturar "criptografia" com "hashing de senha". Para senha, **nunca** use cifra reversível — use hash adaptativo (Argon2id, ver `auth-sessao-contas.md`).
+
+```
+ciphertext = AES_GCM_Encrypt(key, nonce, plaintext, aad)  // nonce único por operação
+plaintext  = AES_GCM_Decrypt(key, nonce, ciphertext, aad)
+```
+
+**Faça**
+- Force HTTPS/TLS moderno em trânsito e criptografia forte em repouso onde houver risco real.
+- Use AES-GCM ou ChaCha20-Poly1305 para dados; hashing de senha é separado.
+- Planeje gestão de chaves: geração, rotação, revogação, segregação por uso.
+- Preserve integridade/autenticidade (AEAD), não só confidencialidade.
+
+**Não faça**
+- Não invente algoritmo ou protocolo próprio.
+- Não reuse chave para usos incompatíveis nem nonce em AES-GCM.
+- Não misture criptografia com hashing de senha.
+- Não desabilite validação de certificado em cliente ou backend.
+
+**Fontes**
+- Artigos: Cryptographic Storage `https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html` · Transport Layer Security `https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html`
+- Normas: NIST SP 800-57 Part 1 Rev.5 (Key Management) `https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r5.pdf`
+
+---
+
+## Gestão de segredos
+
+**Risco.** Segredo em `.env` local é aceitável em dev; em produção o padrão é **cofre centralizado** com acesso fino, auditoria, rotação e, idealmente, credenciais dinâmicas/temporárias.
+
+**Faça**
+- Use secret manager/vault e credenciais temporárias sempre que possível.
+- Rotacione segredos e saiba revogá-los rapidamente.
+- Escaneie CI, Git e artefatos para detectar vazamentos.
+- Restrinja leitura de segredo por workload e ambiente.
+
+**Não faça**
+- Não hardcode em código, imagem Docker, Terraform state, wiki ou log de pipeline.
+- Não compartilhe o mesmo segredo entre múltiplos sistemas sem necessidade.
+- Não deixe `.env` e backups expostos.
+- Não logue segredo em plaintext.
+
+**Fontes**
+- Artigos: Secrets Management `https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html` · AWS IAM best practices `https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html`
+- Normas: NIST SP 800-53 Rev.5 `https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-53r5.pdf`
+- Vídeos: *Inside the Breach: Secrets Exposed* (Troy Hunt, NDC 2025) `https://www.youtube.com/watch?v=Og-cFpwqjQ4`
+
+---
+
+## PII e conformidade (LGPD / GDPR / PCI)
+
+**Risco.** LGPD e GDPR exigem base legal, minimização, limitação de finalidade e governança. Para engenharia: coletar menos, reter menos, separar identificação de dados operacionais, mascarar em telas e logs, e projetar resposta a incidente com comunicação regulatória.
+
+**Faça**
+- Colete só o mínimo necessário e defina base legal/finalidade por fluxo.
+- Classifique dados, retenção, descarte e masking desde o desenho da feature.
+- Separe PII de dados operacionais quando reduzir blast radius.
+- Tenha trilha clara para direitos do titular, incidente e vendor risk.
+
+**Não faça**
+- Não peça "campo útil no futuro".
+- Não logue PII desnecessária, PAN completo ou documento bruto.
+- Não retenha indefinidamente por conveniência.
+- Não trate LGPD/GDPR/PCI como "só jurídico".
+
+**Fontes**
+- Artigos/leis: GDPR (EUR-Lex) `https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng` · LGPD (Lei 13.709/2018) `https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm`
+- Normas: ANPD Guia de segurança `https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/guia-vf.pdf` · PCI SSC document library `https://www.pcisecuritystandards.org/document_library/` · OWASP User Privacy Protection `https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html`
+- Cruzamento: use `nist-pii-protection` (classificação por nível de impacto, de-identificação vs. anonimização) e `auditoria-lgpd-fiscal`.

package/assets/references/deteccao-resposta.md

@@ -0,0 +1,88 @@
+# Detecção, resposta e referências-mestras
+
+Domínios: logging e monitoramento, threat modeling (STRIDE), resposta a incidentes, referências-mestras.
+Base: OWASP Logging / Threat Modeling Cheat Sheets, CISA IR playbooks, NIST CSF 2.0 e SP 800-61r3, OWASP Top 10:2025, ASVS 5.0.0, MITRE CWE.
+
+---
+
+## Logging e monitoramento
+
+**Risco.** Log útil para segurança não é "debug com tudo". Um bom log permite correlação, detecção e auditoria; um log ruim vira novo vazamento.
+
+**Faça**
+- Logue autenticação, autorização, mudança de privilégio, reset, fraude e ações administrativas.
+- Tenha correlação por request/trace/user/tenant sem gravar dado sensível bruto.
+- Defina alertas para padrões suspeitos, não só dashboards.
+- Garanta integridade, retenção e acesso restrito aos logs.
+
+**Não faça**
+- Não logue senha, token, cookie de sessão, segredo ou PII desnecessária.
+- Não use formatos inconsistentes impossíveis de correlacionar.
+- Não dependa só de logs de infraestrutura.
+- Não ignore falhas de logging em fluxos críticos.
+
+**Fontes**
+- Artigos: OWASP Logging `https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html` · Logging Vocabulary `https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html`
+- Normas: OWASP ASVS 5.0.0 · NIST CSF 2.0 `https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf`
+- Vídeos: *Ensuring Data Integrity in Incident Response* (SANS DFIR, 2025) `https://www.youtube.com/watch?v=gylFpAzRIoc`
+
+---
+
+## Threat modeling
+
+**Risco.** É a ferramenta mais barata para evitar classes inteiras de bug antes do código. STRIDE é a taxonomia prática para começar; o projeto OWASP aceita STRIDE, PASTA, LINDDUN, abuse cases e attack trees.
+
+**Faça**
+- Modele trust boundaries, ativos, entradas, dependências externas e abuse cases.
+- Use STRIDE como linguagem mínima comum do time.
+- Atualize o threat model quando arquitetura, auth, integrações ou dados mudarem.
+- Transforme ameaças priorizadas em requisito, teste e observabilidade.
+
+**Não faça**
+- Não trate threat modeling como workshop isolado sem backlog.
+- Não foque só em componentes técnicos e esqueça o fluxo de negócio.
+- Não ignore terceiros, pipelines e supply chain.
+- Não produza diagrama bonito sem decisão acionável.
+
+**Fontes**
+- Artigos: Threat Modeling `https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html` · Attack Surface Analysis `https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html`
+- Vídeos: *Threat Modeling 101: Star Wars Edition* (STRONGER, 2023) `https://www.youtube.com/watch?v=ND7JV-kD8IA`
+
+---
+
+## Resposta a incidentes
+
+**Risco.** Para aplicações, o mínimo é: preparação, detecção, contenção, erradicação, recuperação e pós-incidente. NIST finalizou o SP 800-61r3 (2025), integrando IR à gestão de risco e ao CSF 2.0. Em produto: saber desabilitar credenciais, forçar logout, rotacionar segredos, preservar evidências e decidir comunicação regulatória.
+
+**Faça**
+- Defina playbook para triagem, contenção, erradicação, recuperação e lições aprendidas.
+- Garanta contatos, owners, runbooks e critérios de severidade antes do incidente.
+- Preserve evidências e timestamps desde a triagem.
+- Pratique tabletop: vazamento de segredo, ATO, ransomware, bucket exposto, supply chain.
+
+**Não faça**
+- Não improvise comunicação e contenção no meio do incidente.
+- Não apague evidências cedo demais.
+- Não gire segredos ou resete ambiente sem entender o escopo mínimo.
+- Não encerre incidente sem ações corretivas verificáveis.
+
+**Fontes**
+- Artigos: CISA IR & Vulnerability Response Playbooks `https://www.cisa.gov/resources-tools/resources/federal-government-cybersecurity-incident-and-vulnerability-response-playbooks`
+- Normas: CISA Incident Response Plan Basics `https://www.cisa.gov/sites/default/files/publications/Incident-Response-Plan-Basics_508c.pdf` · NIST CSF 2.0 `https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf`
+- Vídeos: *Incident Response 9-Line* (SANS DFIR, 2021) `https://www.youtube.com/watch?v=hU3i-jEF9cU`
+
+---
+
+## Referências-mestras
+
+As cinco fontes primárias para a Skill:
+- **OWASP Top 10:2025** — visão de riscos / awareness `https://owasp.org/www-project-top-ten/`
+- **OWASP ASVS 5.0.0** — requisitos verificáveis (baseline L2) `https://raw.githubusercontent.com/OWASP/ASVS/v5.0.0/5.0/OWASP_Application_Security_Verification_Standard_5.0.0_en.pdf`
+- **OWASP API Security Top 10:2023** — superfícies de API `https://owasp.org/www-project-api-security/`
+- **CWE Top 25 (MITRE)** — causas-raiz para regras de revisão/código `https://cwe.mitre.org/top25/`
+- **NIST SSDF (SP 800-218)** — processo de desenvolvimento seguro `https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf`
+
+Complementares: NIST 800-63B-4 (auth), RFC 9700 (OAuth security), NIST SP 800-61r3 (resposta a incidentes), NIST CSF 2.0.
+
+**Faça** — use OWASP Top 10 para awareness, ASVS para requisito verificável, WSTG para teste, CWE Top 25 para treinar classes-raiz, e mapeie seus checklists internos para essas referências.
+**Não faça** — não use OWASP Top 10 como checklist único de engenharia, nem confunda documento de awareness com padrão verificável.

package/assets/references/hardening-headers-cloud.md

@@ -0,0 +1,94 @@
+# Hardening, cabeçalhos e cloud
+
+Domínios: cabeçalhos de segurança e cookies, CORS, tratamento de erros e secure defaults, containers e cloud.
+Base: MDN HTTP Headers, OWASP HTTP Headers / Clickjacking / Error Handling / Docker / Kubernetes Cheat Sheets, docs oficiais AWS/GCP/Azure e Kubernetes.
+
+---
+
+## Cabeçalhos de segurança e cookies
+
+**Risco.** Defaults inseguros de header/cookie abrem XSS, clickjacking, downgrade de HTTPS e vazamento de referer.
+
+**Faça**
+- Configure HSTS, CSP, `X-Content-Type-Options: nosniff`, `frame-ancestors`/`X-Frame-Options`, `Referrer-Policy`.
+- Cookies com `HttpOnly`, `Secure`, `SameSite` e prefixo `__Host-`/`__Secure-` quando aplicável.
+- Use SRI para assets de terceiros.
+- Teste headers em staging e produção com ferramentas automatizadas.
+
+**Não faça**
+- Não aplique CSP permissiva com `unsafe-inline` por padrão.
+- Não deixe cookie de sessão sem `Secure` e `HttpOnly`.
+- Não misture cookies de auth com domínios amplos sem necessidade.
+- Não presuma que um header "ligado" está bem configurado.
+
+**Fontes**
+- Artigos: MDN HSTS `https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security` · MDN X-Frame-Options `https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options`
+- Normas: HTTP Security Headers `https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html` · CSP `https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html` · Clickjacking `https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html`
+- Vídeos: *Understanding CSP* (Troy Hunt, 2016) `https://www.youtube.com/watch?v=L97wtYCqfwM`
+
+---
+
+## CORS
+
+**Risco.** CORS não é autenticação nem autorização — é contrato entre navegador e servidor. `Access-Control-Allow-Origin: *` com `Allow-Credentials: true` é inválido (o próprio navegador rejeita).
+
+**Faça**
+- Permita apenas origens exatas necessárias que você controla.
+- Controle `Access-Control-Allow-Credentials` com extremo cuidado.
+- Restrinja métodos e headers aceitos; trate preflight, cache e ambientes de preview explicitamente.
+- Se a API não é chamada por browser cross-origin, desative CORS.
+
+**Não faça**
+- Não use `*` com credenciais.
+- Não reflita a origin automaticamente.
+- Não confunda CORS com anti-CSRF.
+- Não abra CORS em endpoints internos por conveniência de frontend.
+
+**Fontes**
+- Artigos: MDN CORS `https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS` · PortSwigger CORS `https://portswigger.net/web-security/cors`
+- Normas: OWASP HTML5 Security `https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html`
+
+---
+
+## Tratamento de erros e secure defaults
+
+**Risco.** Stacktrace, nome de tabela, mensagem de parser, header interno e path de arquivo viram inteligência para o atacante. O usuário recebe erro genérico; o detalhe fica em log interno.
+
+**Faça**
+- Mostre erro genérico ao cliente; detalhe técnico só em log controlado.
+- Desative debug, stack trace público e banners de tecnologia em produção.
+- Aplique least privilege por padrão em app, banco, cloud e CI/CD.
+- Fail-safe: se a policy falhar, negue o acesso.
+
+**Não faça**
+- Não exponha stack trace, SQL, path local, segredo ou config interna.
+- Não deixe feature sensível "aberta por padrão".
+- Não use exceção como canal de negócio.
+- Não confie em ambiente "interno" para relaxar defaults.
+
+**Fontes**
+- Artigos: Error Handling `https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html` · Secure Product Design `https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html`
+- Normas: CISA Secure by Design · NIST SP 800-207 Zero Trust `https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf`
+
+---
+
+## Containers e cloud
+
+**Risco.** Padrão recorrente em incidentes: storage público, role coringa, ambiente de teste acessível, segredo na imagem. Toda role "temporária" vira permanente se ninguém a remover.
+
+**Faça**
+- Rode container como usuário não-root, imagem mínima e base confiável.
+- Aplique Pod Security Standards / admission policies e NetworkPolicies no cluster.
+- Use IAM least privilege, roles temporárias e bloqueio de bucket público (S3 Block Public Access).
+- Escaneie imagens, IaC e runtime com política de build/release.
+
+**Não faça**
+- Não empacote segredo na imagem.
+- Não rode com `privileged`, hostPath, root FS mutável ou capabilities desnecessárias.
+- Não deixe S3/buckets/blobs públicos por padrão.
+- Não trate namespace como isolamento suficiente para tudo.
+
+**Fontes**
+- Artigos: Docker Engine security `https://docs.docker.com/engine/security/` · AWS IAM best practices `https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html` · S3 Block Public Access `https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html`
+- Normas: OWASP Docker Security `https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html` · OWASP Kubernetes Security `https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html` · K8s Pod Security Standards `https://kubernetes.io/docs/concepts/security/pod-security-standards/`
+- Vídeos: *GKE security posture tools* (GoogleCloudTech) `https://www.youtube.com/watch?v=Qe1nS3H1nvo`

package/assets/references/injecoes.md

@@ -0,0 +1,185 @@
+# Injeções e validação de entrada
+
+Domínios: SQL Injection, outras injeções (NoSQL/Command/LDAP/XXE/SSTI), XSS, CSRF, SSRF, upload/path traversal, desserialização/mass assignment/open redirect.
+Base: OWASP Cheat Sheets (SQLi, XSS, CSRF, SSRF, File Upload, Deserialization, Mass Assignment), PortSwigger Web Security Academy, MDN.
+
+Princípio: toda entrada controlada pelo atacante que chega intacta a um interpretador (SQL, shell, template, parser, browser) é uma injeção em potencial. A defesa correta quase nunca é "sanitizar" — é **separar dados de código** (parametrização, APIs nativas, encoding por contexto).
+
+---
+
+## SQL Injection
+
+**Risco.** Entrada do atacante chega intacta ao interpretador SQL. Defesa correta: **query parametrizada / prepared statement**. Escaping é último recurso. ORMs ajudam mas não blindam quando há concatenação, raw query sem bind, ou cláusulas dinâmicas (`ORDER BY`, `LIMIT`, nome de coluna).
+
+```ts
+const sql = "SELECT id, email FROM users WHERE email = $1";
+const row = await db.query(sql, [email]); // nunca interpolar string
+```
+
+**Faça**
+- Use prepared statements / parameter binding em 100% das queries dinâmicas.
+- Restrinja privilégios do usuário do banco ao mínimo necessário.
+- Use allowlist para colunas, ordenação e filtros dinâmicos.
+- Teste também stored procedures, relatórios e endpoints de export.
+
+**Não faça**
+- Não concatene input em SQL, nem "só para admin".
+- Não confie que o ORM elimina todo SQLi automaticamente.
+- Não conceda `DROP`, `ALTER`, `SUPERUSER` ao app.
+- Não esqueça busca, paginação, sort e filtros compostos.
+
+**Fontes**
+- Artigos: PortSwigger SQLi `https://portswigger.net/web-security/sql-injection` · OWASP Database Security `https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html`
+- Normas: SQLi Prevention `https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html` · Query Parameterization `https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html`
+- Vídeos: *What is SQL injection?* (PortSwigger) `https://www.youtube.com/watch?v=wX6tszfgYp4` · *Running an SQL Injection Attack* (Computerphile, 2016) `https://www.youtube.com/watch?v=ciNHn38EyRc`
+
+---
+
+## Outras injeções (NoSQL, Command, LDAP, XXE, SSTI)
+
+**Risco.** NoSQL injection surge com operadores (`$ne`, `$gt`) construídos com input. Command injection aparece ao chamar shell com dados externos — a defesa preferida é **não chamar shell** e usar API nativa. LDAP pede escape/bind seguro. XXE se mitiga desabilitando DTD e entidades externas. SSTI ocorre quando input vira template — impacto frequente é **RCE**.
+
+**Faça**
+- NoSQL: valide operadores permitidos e proíba execução raw/eval.
+- Command: prefira APIs nativas a shell e separe argumentos do comando.
+- LDAP: use APIs de escape / bind seguro.
+- XXE: desabilite external entities, DTDs e resolução remota.
+- SSTI: nunca concatene template com input do usuário.
+
+**Não faça**
+- Não exponha engine de template, shell, filtro LDAP ou parser XML a input livre.
+- Não aceite JSON arbitrário com operadores especiais do banco.
+- Não trate "sanitização caseira" como defesa suficiente.
+- Não confunda SSTI com XSS: o impacto costuma ser RCE.
+
+**Fontes**
+- Artigos: PortSwigger NoSQL `https://portswigger.net/web-security/nosql-injection` · PortSwigger SSTI `https://portswigger.net/web-security/server-side-template-injection`
+- Normas: NoSQL `https://cheatsheetseries.owasp.org/cheatsheets/NoSQL_Security_Cheat_Sheet.html` · OS Command Injection `https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html` · LDAP `https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html` · XXE `https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html`
+- Vídeos: *Server-Side Template Injections Explained* (PwnFunction, 2021) `https://www.youtube.com/watch?v=SN6EVIG4c-0`
+
+---
+
+## XSS
+
+**Risco.** Família: refletido, armazenado e DOM-based. Defesa real combina **encoding por contexto de saída** (HTML, atributo, JS, URL, CSS), templates com auto-escape, proibição de sinks perigosos e CSP como defesa em profundidade (não como única barreira).
+
+```ts
+element.innerHTML = userBio;   // ruim
+element.textContent = userBio; // bom
+```
+
+**Faça**
+- Escape por contexto de saída — HTML, atributo, JS, CSS e URL são contextos diferentes.
+- Use templates seguros, `textContent`, `setAttribute` e DOMPurify quando necessário.
+- Ative CSP estrita como defesa em profundidade.
+- Trate DOM XSS e JS de terceiros como parte do mesmo problema.
+
+**Não faça**
+- Não use `innerHTML`, `document.write` ou sinks perigosos com input não confiável.
+- Não tente resolver XSS só com blacklist de caracteres.
+- Não aplique um único encoder para todos os contextos.
+- Não considere CSP substituto do encoding correto.
+
+**Fontes**
+- Artigos: PortSwigger XSS `https://portswigger.net/web-security/cross-site-scripting` · MDN CSP `https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy`
+- Normas: XSS Prevention `https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html` · DOM XSS `https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html`
+- Vídeos: *Cross-Site Scripting (XSS) Explained* (PwnFunction, 2020) `https://www.youtube.com/watch?v=EoaDgUgS6QA`
+
+---
+
+## CSRF
+
+**Risco.** O navegador do usuário autenticado envia uma ação que o servidor aceita como legítima. Use proteção nativa do framework; senão, token anti-CSRF + `SameSite`. **XSS derrota quase toda proteção CSRF** — os dois andam juntos.
+
+**Faça**
+- Use token anti-CSRF para ações state-changing quando a auth depende de cookies.
+- Habilite `SameSite` corretamente e valide `Origin`/`Referer` quando fizer sentido.
+- Use `Sec-Fetch-Site` / Fetch Metadata como filtro adicional.
+- Prefira bearer token fora de cookies em cenários adequados.
+
+**Não faça**
+- Não assuma que CORS resolve CSRF.
+- Não dispense token anti-CSRF só porque usa POST.
+- Não ignore XSS.
+- Não mantenha endpoints sensíveis aceitando GET.
+
+**Fontes**
+- Artigos: PortSwigger CSRF `https://portswigger.net/web-security/csrf`
+- Normas: CSRF Prevention `https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html`
+- Vídeos: *CSRF and the Same-Origin Policy* (LiveOverflow, 2017) `https://www.youtube.com/watch?v=KaEj_qZgiKY` · *Cross Site Request Forgery* (Computerphile, 2017) `https://www.youtube.com/watch?v=vRBihr41JTo`
+
+---
+
+## SSRF
+
+**Risco.** Permitir que o servidor fale com destinos que o cliente não alcança — metadata de cloud, redes internas, localhost. Em cloud, trate o metadata service como ativo crítico (AWS: IMDSv2, desabilite IMDSv1).
+
+```ts
+const allowedHosts = new Set(["api.parceiro.com", "cdn.parceiro.com"]);
+const u = new URL(inputUrl);
+if (u.protocol !== "https:") throw new Error("invalid_scheme");
+if (!allowedHosts.has(u.hostname)) throw new Error("host_not_allowed");
+// resolução DNS + bloqueio de IP privado/loopback no cliente HTTP/egress proxy
+```
+
+**Faça**
+- Valide URL por parse robusto, allowlist de host, esquema e porta.
+- Force resolução DNS segura e bloqueie IPs internos, loopback e ranges de metadata.
+- Use proxy de saída controlado e isolamento de rede para serviços que fazem fetch.
+- Em cloud, bloqueie IMDS legado e use IMDSv2 / equivalentes.
+
+**Não faça**
+- Não confie em regex simples para validar URL.
+- Não siga redirects livremente para destinos não verificados.
+- Não permita protocolos desnecessários (`file:`, `gopher:`, `dict:`, `ftp:`).
+- Não exponha serviço de fetch genérico para usuários.
+
+**Fontes**
+- Artigos: PortSwigger SSRF `https://portswigger.net/web-security/ssrf` · AWS IMDSv2 `https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html`
+- Normas: SSRF Prevention `https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html`
+- Vídeos: *A New Era of SSRF - Orange Tsai* (2017) `https://www.youtube.com/watch?v=D1S-G8rJrEk`
+
+---
+
+## Upload de arquivos e Path Traversal
+
+**Risco.** Upload inseguro vira RCE, malware ou leitura/escrita indevida. Traversal com `../` ainda é falha recorrente.
+
+**Faça**
+- Valide extensão, MIME, assinatura mágica, tamanho e quantidade.
+- Armazene fora do webroot e sirva por identificador interno, não por path livre.
+- Gere nome novo no servidor; aplique antivírus/CDR quando o caso exigir; reencode imagens.
+- Normalize path e faça allowlist de diretórios-alvo.
+
+**Não faça**
+- Não confie no `Content-Type` enviado pelo cliente.
+- Não permita upload executável em pasta servida diretamente.
+- Não use nome/caminho original sem canonicalização.
+- Não monte filepath com concatenação ingênua.
+
+**Fontes**
+- Artigos: PortSwigger Path Traversal `https://portswigger.net/web-security/file-path-traversal` · OWASP Path Traversal `https://owasp.org/www-community/attacks/Path_Traversal`
+- Normas: File Upload `https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html` · Input Validation `https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html`
+
+---
+
+## Desserialização, Mass Assignment e Open Redirect
+
+**Risco.** Desserialização de dados não confiáveis leva a RCE/corrupção. Mass assignment liga o payload inteiro ao objeto de domínio (over-posting de `role`, `balance`, `isAdmin`). Open redirect facilita phishing e abuso de fluxos OAuth.
+
+**Faça**
+- Prefira formatos simples e esquemas explícitos a desserializar objetos arbitrários.
+- Use DTOs / allowlist de campos graváveis para impedir over-posting.
+- Em redirects, use destinos pré-cadastrados ou IDs internos.
+- Assine e valide integridade de dados serializados quando não houver alternativa.
+
+**Não faça**
+- Não desserialize dados não confiáveis para classes com gadget chains.
+- Não faça bind automático do body inteiro ao modelo de domínio.
+- Não aceite `next`, `returnUrl` ou `redirect` arbitrários.
+- Não exponha propriedades sensíveis ao binder.
+
+**Fontes**
+- Artigos: PortSwigger Deserialization `https://portswigger.net/web-security/deserialization` · PortSwigger Open Redirect `https://portswigger.net/web-security/open-redirection`
+- Normas: Deserialization `https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html` · Mass Assignment `https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html` · Unvalidated Redirects `https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html`
+- Vídeos: *Insecure Deserialization Attack Explained* (PwnFunction, 2020) `https://www.youtube.com/watch?v=jwzeJU_62IQ`

package/assets/references/rate-limiting.md

@@ -0,0 +1,24 @@
+# Rate limiting e anti-abuso
+
+Base: OWASP Denial of Service / Automated Threats Cheat Sheets, OWASP API Security Top 10:2023 (API4 Unrestricted Resource Consumption), CISA DDoS guidance.
+
+**Risco.** Sem limites, endpoints caros e sensíveis (login, reset, signup, busca, export) viram vetor de brute force, credential stuffing, DoS de aplicação e abuso de custo. Limite em camadas: gateway/WAF, aplicação e, quando necessário, por operação de negócio. Algoritmos comuns: fixed window, sliding window, token bucket (bom para burst) e leaky bucket. Responda com **HTTP 429** e `Retry-After`. Abuso de baixo volume e sequências maliciosas podem escapar de um limitador puramente volumétrico.
+
+**Faça**
+- Tenha limites por IP, usuário, token, tenant e rota — não um só limite global.
+- Use algoritmos adequados: token bucket para controle de burst, sliding window para fairness.
+- Responda com headers de quota e comportamento previsível (`429` + `Retry-After`).
+- Proteja `/login`, `/reset`, `/signup`, exportações, busca e endpoints caros separadamente.
+
+**Não faça**
+- Não aplique um limite único para toda a aplicação.
+- Não dependa só de WAF para abuso de negócio.
+- Não esqueça IPv6, proxies, NATs e autenticação compartilhada (chave por conta, não só por IP).
+- Não deixe jobs caros e endpoints de busca sem custo controlado.
+
+**Fontes**
+- Artigos: OWASP Denial of Service `https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html` · OWASP Automated Threats `https://owasp.org/www-project-automated-threats-to-web-applications/`
+- Normas: OWASP API4:2023 Unrestricted Resource Consumption `https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/` · CISA DDoS `https://www.cisa.gov/sites/default/files/2024-03/understanding-and-responding-to-distributed-denial-of-service-attacks_508c.pdf`
+- Vídeos: *OWASP API Top 10 2023 — Unrestricted Resource Consumption* (Equixly, 2024) `https://www.youtube.com/watch?v=47nt8UGBws0`
+
+**Nota de implementação.** NGINX usa leaky bucket; Envoy oferece token bucket; WAFs modernos agregam por IP, header, cookie, método ou combinações. Combine rate limiting com detecção de automação (ver anti-bot em `auth-sessao-contas.md`).

package/assets/references/supply-chain-devsecops.md

@@ -0,0 +1,72 @@
+# Cadeia de suprimentos e DevSecOps
+
+Domínios: segurança de dependências (SCA/SBOM), CI/CD seguro, SAST/DAST/IAST, Secure SDLC / Shift Left.
+Base: NIST SSDF (SP 800-218), CISA SBOM, CycloneDX, OWASP Dependency-Check/Track, OWASP CI/CD Security Cheat Sheet, GitHub code scanning.
+
+---
+
+## Dependências, SCA e SBOM
+
+**Risco.** "Atualizar biblioteca" deixou de ser suficiente. Baseline: inventário de componentes, SBOM por build, scan contínuo de CVEs, revisão de transitivas críticas e priorização por explorabilidade e exposição real — não só CVSS.
+
+**Faça**
+- Gere SBOM por build e associe ao artefato liberado.
+- Rode SCA continuamente; trate CVEs por criticidade, reachability e exposição real.
+- Prefira dependências mantidas, com política de atualização e provenance verificável.
+- Tenha inventário de bibliotecas, imagens base e componentes transitivos.
+
+**Não faça**
+- Não atualize bibliotecas só quando "der problema".
+- Não ignore dependência transitiva ou imagem base.
+- Não trate SBOM como documento estático sem uso operacional.
+- Não libere pacote sem trilha de proveniência e scan mínimo.
+
+**Fontes**
+- Artigos: CISA SBOM `https://www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom` · OWASP Dependency-Check `https://owasp.org/www-project-dependency-check/` · OWASP Dependency-Track `https://owasp.org/www-project-dependency-track/`
+- Normas: CycloneDX `https://cyclonedx.org/` · CISA 2025 Minimum Elements for an SBOM `https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom` · NIST SP 800-218 (SSDF) `https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf`
+- Vídeos: *OWASP Dependency-Track & CycloneDX* `https://www.youtube.com/watch?v=QV2JcwHpjeQ`
+
+---
+
+## CI/CD e SAST, DAST, IAST
+
+**Risco.** O pipeline é ativo de alto valor: segredos, runners, plugins, permissões de merge, tokens de publicação e workflows. Menor privilégio e ciclo de vida das identidades do pipeline são fundamentais.
+
+**Faça**
+- Rode SAST em PR/merge, DAST em ambiente implantado, IAST onde a stack suportar; secrets scanning no PR.
+- Proteja runners, segredos, artefatos e permissões do pipeline.
+- Assine artefatos (proveniência) e exija checks de segurança mínimos para promover release.
+- Separe pipelines por ambiente e minimize permissões de plugins e integrações.
+
+**Não faça**
+- Não use token de deploy amplo em todos os jobs.
+- Não confie em um só tipo de scanner.
+- Não deixe runners compartilhados com credenciais persistentes.
+- Não permita bypass informal de controles críticos.
+
+**Fontes**
+- Artigos: GitHub code scanning `https://docs.github.com/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning` · OWASP DevSecOps Guideline (DAST) `https://owasp.org/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing`
+- Normas: OWASP CI/CD Security `https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html` · NIST SP 800-218
+
+---
+
+## Secure SDLC e Shift Left
+
+**Risco.** "Shift left" não é jogar tudo no desenvolvedor — é mover decisões de segurança para design, backlog, arquitetura, revisão de código e definição de pronto. Segurança só no pentest final é tarde demais.
+
+**Faça**
+- Faça threat modeling, requisitos de segurança e casos de abuso antes do código.
+- Traduza ASVS / OWASP Top 10 em critérios de aceite e checklists de engenharia.
+- Ensine segurança no fluxo: templates, linters, code review, guardrails.
+- Mantenha backlog contínuo de dívida de segurança, não campanha eventual.
+
+**Não faça**
+- Não deixe segurança só para pentest final.
+- Não dependa de "boas intenções" sem processo verificável.
+- Não separe AppSec do time de produto ao ponto de virar gargalo.
+- Não meça maturidade apenas por número de findings.
+
+**Fontes**
+- Artigos: NIST SSDF v1.1 `https://csrc.nist.gov/pubs/sp/800/218/final` · OWASP ASVS Project `https://owasp.org/www-project-application-security-verification-standard/`
+- Normas: NIST SP 800-218 `https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf` · OWASP SAMM (modelo de maturidade)
+- Vídeos: *Get Ready for the OWASP ASVS 5.0* (Josh Grossman, DevSecNext 2025) `https://www.youtube.com/watch?v=2NIEHvGYcH4`

package/bin/cli.js

@@ -0,0 +1,78 @@
+#!/usr/bin/env node
+'use strict';
+
+/*
+ * gava-appsec — instala a base de AppSec acionável (desenvolvimento seguro) no projeto atual.
+ * Uso:
+ *   npx gava-appsec init         # copia AGENTS-appsec.md + appsec/ para o cwd
+ *   npx gava-appsec init --force # sobrescreve arquivos existentes
+ */
+
+const fs = require('fs');
+const path = require('path');
+
+const PKG_ROOT = path.resolve(__dirname, '..');
+const ASSETS = path.join(PKG_ROOT, 'assets');
+const CWD = process.cwd();
+
+const args = process.argv.slice(2);
+const cmd = args[0];
+const force = args.includes('--force') || args.includes('-f');
+
+function log(msg) { process.stdout.write(msg + '\n'); }
+
+function copyFile(src, destRel) {
+  const dest = path.join(CWD, destRel);
+  if (fs.existsSync(dest) && !force) {
+    log('  ⏭  já existe (use --force para sobrescrever): ' + destRel);
+    return;
+  }
+  fs.mkdirSync(path.dirname(dest), { recursive: true });
+  fs.copyFileSync(src, dest);
+  log('  ✓  ' + destRel);
+}
+
+function init() {
+  log('\n🛡️  Instalando a base de AppSec (desenvolvimento seguro) neste projeto...\n');
+
+  // 1. Instruções de AppSec na raiz (lidas por Cursor, Copilot, Windsurf, Codex, etc.)
+  copyFile(path.join(ASSETS, 'AGENTS-appsec.md'), 'AGENTS-appsec.md');
+
+  // 2. Cheatsheet (referência rápida por gatilho)
+  copyFile(path.join(ASSETS, 'cheatsheet.md'), path.join('appsec', 'cheatsheet.md'));
+
+  // 3. Referências detalhadas por domínio em appsec/references/
+  const refDir = path.join(ASSETS, 'references');
+  if (fs.existsSync(refDir)) {
+    for (const f of fs.readdirSync(refDir)) {
+      copyFile(path.join(refDir, f), path.join('appsec', 'references', f));
+    }
+  }
+
+  log('\n✅ Pronto!');
+  log('   • AGENTS-appsec.md na raiz — peça ao agente da sua IDE para segui-lo ao escrever/revisar código.');
+  log('   • appsec/cheatsheet.md — referência rápida "estou escrevendo X → cheque Y".');
+  log('   • appsec/references/ — detalhe por domínio (auth, injeções, controle de acesso, cripto, etc.).');
+  log('\n   Dica: se a sua IDE só lê AGENTS.md, aponte o agente para o AGENTS-appsec.md');
+  log('   ou cole o conteúdo dele no seu AGENTS.md quando for codar/revisar segurança.\n');
+}
+
+function help() {
+  log('\ngava-appsec — base de AppSec acionável (OWASP Top 10:2025 / ASVS 5.0) para qualquer IDE\n');
+  log('Uso:');
+  log('  npx gava-appsec init           Instala AGENTS-appsec.md + appsec/ no projeto');
+  log('  npx gava-appsec init --force   Sobrescreve arquivos existentes');
+  log('  npx gava-appsec help           Mostra esta ajuda\n');
+}
+
+switch (cmd) {
+  case 'init': init(); break;
+  case 'help':
+  case '--help':
+  case '-h':
+  case undefined: help(); break;
+  default:
+    log('Comando desconhecido: ' + cmd);
+    help();
+    process.exit(1);
+}

package/package.json

@@ -0,0 +1,33 @@
+{
+  "name": "gava-appsec",
+  "version": "1.0.0",
+  "description": "Base de AppSec acionável (desenvolvimento seguro) para qualquer IDE — instala um AGENTS.md de segurança de aplicação e referências por domínio (login/Argon2id, IDOR/ownership, prepared statements, OWASP Top 10:2025/ASVS 5.0) no seu projeto.",
+  "bin": {
+    "gava-appsec": "bin/cli.js"
+  },
+  "files": [
+    "bin/",
+    "assets/"
+  ],
+  "keywords": [
+    "appsec",
+    "security",
+    "owasp",
+    "asvs",
+    "secure-coding",
+    "sql-injection",
+    "authentication",
+    "agents-md",
+    "ai-coding"
+  ],
+  "author": "Gava",
+  "license": "CC-BY-SA-4.0",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/VgavaBR123/gava-skills.git",
+    "directory": "packages/gava-appsec"
+  },
+  "engines": {
+    "node": ">=14"
+  }
+}