security-hygiene

name	security-hygiene
description	Detecta riscos básicos de segurança em repositórios (segredos expostos, configurações perigosas, padrões inseguros) e gera recomendações com evidências.

Skill: Security Hygiene (Repo Doctor)

Quando usar esta skill

Use esta skill quando o objetivo for:

• Encontrar segredos expostos (tokens, chaves, credenciais) no repositório
• Identificar configurações inseguras em CI/CD (GitHub Actions) e scripts
• Detectar padrões de código potencialmente perigosos (ex.: eval, child_process sem validação)
• Gerar recomendações curtas e acionáveis, sempre com evidência

Escopo (o que está dentro)

✅ Inclui:

• Procura de segredos versionados e arquivos suspeitos (.env, credentials, dumps)
• Revisão de workflows do GitHub Actions (permissões, uso de secrets, ações não pinadas)
• Heurísticas de risco em Node.js/TypeScript (exec, eval, deserialização insegura)

❌ Não inclui:

• Pentest, exploração, ou prova de conceito
• Auditoria completa de dependências por CVE (a menos que o projeto já integre scanners)

Entradas esperadas

• Árvore de arquivos do repo
• Conteúdo de:
  • .github/workflows/*
  • package.json (+ lockfile se existir)
  • arquivos .env* (se existirem)
  • código-fonte relevante (TS/JS)

Como analisar (passo a passo)

1. Identifique sinais de segredos

   • Procure por padrões comuns de tokens (ex.: ghp_, xoxb-, AIza, sk-, etc.)
   • Verifique commits/arquivos com nomes suspeitos: .env, secrets, credentials, id_rsa

2. Revise GitHub Actions

   • Verifique permissões (permissions:) e prefira mínimo privilégio
   • Sinalize ações não pinadas por SHA
   • Verifique pull_request_target e contextos perigosos
   • Avalie exposição de secrets em steps/logs

3. Revise código de risco

   • eval, Function(), child_process.exec, spawn com input externo
   • JSON.parse em payloads não confiáveis sem validação
   • URLs/redirects sem allowlist

Regras obrigatórias (qualidade)

• Cada achado deve incluir:

  • arquivo + range de linhas
  • explicação do risco (clara e curta)
  • recomendação prática (com passos)
  • severidade: S0/S1/S2/S3
  • prioridade: P0/P1/P2/P3

• Não faça suposições sobre intenção do autor.

• Evite “corrigir tudo”: foque no que é mais provável e mais impactante.

Formato de saída (achados)

Use este template por achado:

[Sx/Py] Título curto do risco

• Arquivo: path/to/file.ts:L10-L42
• Evidência: (1–3 linhas relevantes, sem despejar arquivos longos)
• Risco: explicação objetiva (1 parágrafo)
• Recomendação: passos acionáveis (bullets)
• Critérios de aceite: como validar que foi resolvido

Sugestões de remediação (padrões)

• Secrets:
  • Remover do histórico (se necessário)
  • Rotacionar credenciais
  • Introduzir .env.example e secrets via CI/Actions
• GitHub Actions:
  • Pin por SHA
  • permissions: read-all → mínimo necessário
  • Revisar pull_request_target
• Código:
  • Validar input com schema (ex.: zod)
  • Allowlist de comandos/paths
  • Evitar eval

Limites e cuidado

• Se houver achado de segredo real: trate como S0/P0 e recomende rotação imediata.
• Não exponha tokens completos no relatório: mascare (ex.: ghp_****).