opencode-skills-collection 4.0.53 → 4.0.54

package/bundled-skills/cred-omega/references/detailed-guide.md

@@ -0,0 +1,872 @@
+# CRED-OMEGA: Security Engine for All API Keys (Enterprise) - Detailed Guide
+
+> This file contains the detailed procedure and reference material extracted from `SKILL.md` for focused loading. The root skill defines activation, examples, safety constraints, and limitations.
+
+## Overview
+
+CISO operacional enterprise para gestao total de credenciais e segredos. Descobre, classifica, protege e governa TODAS as API keys, tokens, secrets, service accounts e credenciais em qualquer provedor (OpenAI, Google Cloud, Meta/WhatsApp/Facebook/Instagram, Telegram, AWS, Azure, Stripe, Twilio, e qualquer API futura). Auditoria de codigo, git history, containers, CI/CD, VPS, logs e backups.
+
+
+## How It Works
+
+> Voce e o **SAFE-CHECK** — Agente Supremo de Seguranca de Credenciais.
+> Sua missao: prevenir vazamentos, reduzir permissoes ao minimo, impor rotacao
+> e expirar segredos, criar governanca continua para TODO tipo de credencial
+> em TODOS os provedores, com execucao pratica em VPS e repositorios locais.
+
+---
+
+### 1.1 As 5 Missoes Inegociaveis
+
+1. **DESCOBRIR** — Encontrar onde estao (ou poderiam estar) segredos: codigo, .env, commits antigos, CI/CD, containers, logs, backups, variaveis, paineis de provedores, docker images, build artifacts
+2. **ELIMINAR EXPOSICAO** — Nenhum segredo em repo, nenhum segredo em front-end, nenhum segredo em logs, nenhum segredo em historico git, nenhum segredo em error messages
+3. **REDUZIR BLAST RADIUS** — Least privilege, escopo minimo, restricoes de origem (IP/referrer/dominio/app), quotas, rate limits, separacao por ambiente
+4. **MODERNIZAR AUTENTICACAO** — Preferir tokens de curta duracao, OAuth 2.0, federation (OIDC), workload identity, secret managers; desencorajar chaves long-lived
+5. **IMPLANTAR GOVERNANCA** — Inventario (registry), rotacao obrigatoria, auditoria recorrente, deteccao de anomalia, resposta a incidentes, compliance continuo
+
+### 1.2 Regras De Ouro (Nunca Violar)
+
+- **NUNCA** peca para o usuario colar chaves/tokens no chat
+- Se o usuario colar uma chave por engano: tratar como INCIDENTE — orientar revogacao imediata e rotacao
+- Todo segredo deve existir APENAS em Secret Manager/Vault/env seguro e ser injetado em runtime
+- NENHUM client-side (browser/mobile) pode conter chave de API — zero excecoes
+- Todo token/key deve ter: owner, finalidade, ambiente, TTL/expiracao, restricoes e plano de rotacao
+- Logs NUNCA contem segredos — aplicar redaction em toda saida
+- Principio do menor privilegio: se nao precisa, nao tem acesso
+
+### 1.3 Mentalidade De Seguranca
+
+Pense como um atacante para defender como um profissional:
+- "Se eu vazasse essa chave, qual o pior cenario?" — essa pergunta define a criticidade
+- "Quanto tempo leva pra detectar o vazamento?" — isso define a urgencia da governanca
+- "Quem mais tem acesso?" — isso define o blast radius
+- "Existe alternativa mais segura?" — isso define o caminho de modernizacao
+
+---
+
+### 2.1 Tipos De Credenciais (Taxonomia Completa)
+
+| Categoria | Exemplos | Criticidade Base |
+|-----------|----------|-----------------|
+| API Keys (strings) | OpenAI sk-*, Google AIza*, Stripe sk_live_* | CRITICA |
+| OAuth Secrets | client_id + client_secret | CRITICA |
+| Access/Refresh Tokens | Bearer tokens, JWT, refresh_token | ALTA |
+| Service Account Keys | GCP JSON, AWS IAM credentials | CRITICA |
+| Webhook Secrets | signing secrets, HMAC keys | ALTA |
+| JWT Signing Keys | private keys para assinatura | CRITICA |
+| SSH/TLS Keys | .pem, .p12, .key, id_rsa | CRITICA |
+| DB Credentials | connection strings, passwords | CRITICA |
+| Bot Tokens | Telegram bot token, Discord bot token | ALTA |
+| App Secrets | Meta App Secret, Twitter API Secret | CRITICA |
+| Conversion/Pixel Tokens | Meta CAPI token, GA measurement secret | MEDIA |
+| Encryption Keys | AES keys, master keys | CRITICA |
+| Session Cookies | cookies de sessao privilegiada | MEDIA |
+| CI/CD Tokens | GitHub PAT, GitLab tokens, deploy keys | ALTA |
+| Cloud Provider Keys | AWS_ACCESS_KEY_ID, AZURE_CLIENT_SECRET | CRITICA |
+
+### 2.2 Onde Vazam (Superficie De Ataque)
+
+**Codigo e Config:**
+- `.env`, `.env.local`, `.env.production`, `.env.development`
+- `config.js`, `config.ts`, `settings.json`, `firebase.json`, `appsettings.json`
+- `docker-compose.yml`, `Dockerfile`, `k8s secrets`, `helm values`
+- Hardcoded em codigo-fonte (pior cenario)
+
+**Historico e Versionamento:**
+- Historico do git (mesmo apos apagar — `git log --all`)
+- Pull requests (code review com segredos)
+- Forks publicos de repos privados
+
+**Build e Deploy:**
+- `dist/`, `.next/`, `build/`, `node_modules/` (dependencias com segredos)
+- CI/CD logs (GitHub Actions, Jenkins, GitLab CI)
+- Docker images (layers contendo segredos)
+- Terraform state files
+
+**Runtime e Observabilidade:**
+- `console.log()` acidental em producao
+- Error tracking (Sentry, Bugsnag) com stack traces contendo segredos
+- APM e tracing (Datadog, New Relic) capturando headers
+- Log aggregators (ELK, CloudWatch)
+
+**Humano e Processo:**
+- Screenshots e screen recordings
+- Tickets (Jira, Linear) com segredos colados
+- Slack/Teams/email com chaves compartilhadas
+- Documentacao interna (Confluence, Notion)
+- Backups nao criptografados (zip, tar, snapshots)
+
+---
+
+
+## Fase 0 — Reconhecimento (Mapear Ambiente)
+
+Antes de qualquer acao, entender o terreno:
+
+```
+CHECKLIST FASE 0:
+[ ] Infraestrutura: VPS provider (Hostinger/AWS/GCP/etc), OS, acesso root?
+[ ] Repositorios: GitHub/GitLab/Bitbucket? Publicos ou privados?
+[ ] Linguagem principal: Node/TS, Python, Go, Java, etc?
+[ ] Containerizacao: Docker? Docker Compose? Kubernetes?
+[ ] CI/CD: GitHub Actions? Jenkins? GitLab CI?
+[ ] Servicos externos: quais APIs usa (OpenAI, Meta, Telegram, GCP, etc)?
+[ ] Secret management atual: .env? Vault? Secret Manager? Nenhum?
+[ ] Equipe: quantas pessoas tem acesso? Quem administra credenciais?
+[ ] Ambientes: dev/stage/prod separados?
+[ ] Monitoramento: algum alerta de custo/uso?
+```
+
+
+## Fase 1 — Descoberta (Varredura Profunda)
+
+#### 1A. Varredura de Codigo (padroes de alta precisao)
+
+```bash
+
+## Scanner Principal — Padroes Regex De Alta Cobertura
+
+rg -n --hidden --no-ignore -S \
+  "(api[_-]?key|secret|token|bearer|authorization|x-api-key|client_secret|private_key|BEGIN PRIVATE KEY|BEGIN RSA|service_account|refresh_token|password\s*=|passwd|credential)" \
+  . --glob '!node_modules' --glob '!.git' --glob '!*.lock'
+```
+
+#### 1B. Arquivos Classicos de Segredo
+
+```bash
+
+## Encontrar Arquivos Que Tipicamente Contem Segredos
+
+find . -maxdepth 8 -type f \( \
+  -name ".env" -o -name ".env.*" -o -name "*.pem" -o -name "*.p12" \
+  -o -name "*.key" -o -name "*service-account*.json" \
+  -o -name "*credentials*.json" -o -name "*.pfx" \
+  -o -name "id_rsa*" -o -name "*.keystore" \
+  -o -name "terraform.tfstate*" -o -name "*.tfvars" \
+\) -print 2>/dev/null
+```
+
+#### 1C. Padroes Especificos por Provedor
+
+```bash
+
+## Openai (Sk-...)
+
+rg -n "sk-[a-zA-Z0-9]{20,}" . --glob '!node_modules' --glob '!.git'
+
+## Google Cloud (Aiza...)
+
+rg -n "AIza[a-zA-Z0-9_-]{35}" . --glob '!node_modules' --glob '!.git'
+
+## Aws (Akia...)
+
+rg -n "AKIA[A-Z0-9]{16}" . --glob '!node_modules' --glob '!.git'
+
+## Stripe (Sk_Live_...)
+
+rg -n "sk_live_[a-zA-Z0-9]{20,}" . --glob '!node_modules' --glob '!.git'
+
+## Meta/Facebook (Token Longo Numerico)
+
+rg -n "EAA[a-zA-Z0-9]{50,}" . --glob '!node_modules' --glob '!.git'
+
+## Telegram Bot Token
+
+rg -n "[0-9]{8,10}:[a-zA-Z0-9_-]{35}" . --glob '!node_modules' --glob '!.git'
+
+## Github Pat
+
+rg -n "ghp_[a-zA-Z0-9]{36}" . --glob '!node_modules' --glob '!.git'
+
+## Jwt (Eyj...)
+
+rg -n "eyJ[a-zA-Z0-9_-]{10,}\\.eyJ[a-zA-Z0-9_-]{10,}" . --glob '!node_modules' --glob '!.git'
+
+## Generic High-Entropy Strings (Possivel Segredo)
+
+rg -n "['\"][a-zA-Z0-9+/]{40,}['\"]" . --glob '!*.lock' --glob '!node_modules' --glob '!.git'
+```
+
+#### 1D. Historico do Git (onde o bicho pega)
+
+```bash
+
+## Buscar Segredos Em Todos Os Commits
+
+git log --all --oneline | head -50
+
+## Padroes Especificos No Historico
+
+git grep -n "sk-"   $(git rev-list --all) 2>/dev/null | head -20
+git grep -n "AIza"  $(git rev-list --all) 2>/dev/null | head -20
+git grep -n "AKIA"  $(git rev-list --all) 2>/dev/null | head -20
+git grep -n "BEGIN PRIVATE KEY" $(git rev-list --all) 2>/dev/null | head -20
+git grep -n "password" $(git rev-list --all) 2>/dev/null | head -20
+
+## Diffs Que Removeram Segredos (Sinal De Vazamento Anterior)
+
+git log --all -p --diff-filter=D -- "*.env" "*.pem" "*.key" 2>/dev/null | head -50
+```
+
+#### 1E. Docker e Containers
+
+```bash
+
+## Listar Images Locais
+
+docker images --format "{{.Repository}}:{{.Tag}}" 2>/dev/null | head -20
+
+## Checar Docker-Compose Por Segredos Inline
+
+rg -n "(password|secret|token|key)" docker-compose*.yml 2>/dev/null
+```
+
+#### 1F. Variaveis de Ambiente (sem expor valores)
+
+```bash
+
+## Listar Nomes De Variaveis Suspeitas (Sem Valores!)
+
+env | rg -i "(openai|gcp|google|meta|facebook|whatsapp|telegram|token|secret|key|password|credential|api)" | sed 's/=.*/=***REDACTED***/'
+```
+
+#### 1G. CI/CD e Pipelines
+
+```bash
+
+## Github Actions — Checar Se Secrets Estao Sendo Logados
+
+rg -rn "echo.*\$\{\{.*secrets" .github/ 2>/dev/null
+rg -rn "env:.*\$\{\{.*secrets" .github/ 2>/dev/null
+
+## Checar Se .Env Esta Sendo Copiado No Ci
+
+rg -n "\.env" .github/workflows/ Jenkinsfile .gitlab-ci.yml 2>/dev/null
+```
+
+
+## Fase 2 — Classificacao De Risco
+
+Para cada achado, classificar usando esta matriz:
+
+| Nivel | Criterio | Acao | SLA |
+|-------|----------|------|-----|
+| **P0 — CRITICO** | Segredo confirmado exposto em repo publico ou produção | Revogar AGORA, rotacionar, notificar | < 1 hora |
+| **P1 — ALTO** | Segredo em repo privado, historico git, ou CI logs | Revogar, rotacionar, limpar historico | < 24 horas |
+| **P2 — MEDIO** | Permissoes excessivas, chave sem restricao, sem rotacao | Restringir, adicionar restricoes, agendar rotacao | < 1 semana |
+| **P3 — BAIXO** | Chave dormante, sem dono identificado, best practice faltando | Documentar, atribuir dono, planejar melhoria | < 1 mes |
+
+**Formula de Criticidade:**
+```
+Criticidade = (Exposicao x Privilegio x Blast_Radius) / Tempo_Deteccao
+- Exposicao: publico(10), privado-multi(7), privado-solo(4), vault(1)
+- Privilegio: admin(10), write(7), read(4), minimal(1)
+- Blast_Radius: producao-all(10), producao-parcial(7), staging(4), dev(1)
+- Tempo_Deteccao: sem_monitoramento(10), semanal(5), diario(2), realtime(1)
+```
+
+
+## Fase 3 — Contencao (Acao Imediata)
+
+Para P0 e P1, executar imediatamente:
+
+1. **Revogar** — invalidar a chave/token no painel do provedor
+2. **Rotacionar** — gerar nova credencial com escopo minimo
+3. **Substituir** — atualizar em todos os locais que usam a credencial antiga
+4. **Verificar** — confirmar que servicos voltaram a funcionar com nova credencial
+5. **Limpar** — remover do historico git se necessario:
+   ```bash
+   # BFG Repo-Cleaner (mais seguro que filter-branch)
+   # java -jar bfg.jar --replace-text passwords.txt repo.git
+   # Ou git filter-repo para remover arquivos
+   ```
+
+
+## Fase 4 — Hardening (Protecao Profunda)
+
+#### 4.1 Regras Universais (todas as APIs)
+
+**Regra 1: Chave NUNCA no front-end**
+- Browser/mobile = ambiente hostil. Se a chave aparece no JS entregue ao usuario, ja era.
+- Solucao padrao-ouro: API Gateway/Proxy na VPS
+- O front chama SEU endpoint → sua VPS chama o provedor com segredo em Secret Store
+
+**Regra 2: Separacao por ambiente**
+- DEV, STAGING, PROD com chaves DIFERENTES e contas diferentes quando possivel
+- Se DEV vaza, PROD nao cai junto
+- Nomenclatura: `OPENAI_API_KEY_DEV`, `OPENAI_API_KEY_PROD`
+
+**Regra 3: Restricao e escopo minimo**
+- IP allowlist (quando suportado)
+- Dominio/referrer restriction
+- Bundle ID (mobile)
+- APIs/scopes permitidos (minimo necessario)
+- Se provedor nao suporta: criar restricoes no proxy (rate limit + auth + quotas)
+
+**Regra 4: Rotacao e expiracao**
+- Toda chave tem validade definida (30-90 dias conforme criticidade)
+- Chaves sem dono e sem data = lixo perigoso → revogar
+- Calendar reminders para rotacao
+
+**Regra 5: Observabilidade sem exposicao**
+- Alertas de orcamento/anomalia por provedor
+- Logs de auditoria SEM segredos (redaction obrigatorio)
+- Thresholds para cortar abuso automaticamente
+- Dashboard de custo consolidado
+
+**Regra 6: Defense in Depth**
+- Multiplas camadas: proxy + rate limit + auth + IP restriction + quota + monitoring
+- Se uma camada falha, as outras seguram
+
+#### 4.2 Arquitetura de Proxy Server-Side
+
+```
+[Cliente/Browser]
+       |
+       v
+[Seu Proxy (VPS)] ← autenticacao do usuario (JWT/session)
+       |             rate limiting por usuario/rota
+       |             logging (sem segredos)
+       |             quota por ambiente
+       |             kill switch
+       v
+[API do Provedor] ← chave injetada do Secret Store
+```
+
+Estrutura de pastas na VPS:
+```
+/opt/api-gateway/
+  /src/
+    server.js          # Express/Fastify proxy
+    middleware/
+      auth.js          # JWT/session validation
+      rateLimit.js     # Rate limiting por rota/usuario
+      quota.js         # Quotas por ambiente/usuario
+
+
+## Fase 5 — Governanca Continua
+
+#### 5.1 Secret Registry (modelo de dados)
+
+Manter um registro vivo de TODAS as credenciais:
+
+```json
+{
+  "registry_version": "1.0",
+  "last_audit": "2026-03-03T00:00:00Z",
+  "secrets": [
+    {
+      "secret_id": "openai-prod-main",
+      "provider": "openai",
+      "type": "api_key",
+      "environment": "production",
+      "owner": "backend-team",
+      "purpose": "GPT-4 chat completions para app principal",
+      "storage_location": "vps-env-secure",
+      "created_at": "2026-01-15",
+      "expires_at": "2026-04-15",
+      "last_rotated_at": "2026-01-15",
+      "rotation_policy_days": 90,
+      "restrictions": {
+        "ip_allowlist": ["203.0.113.10"],
+        "rate_limit": "100/min",
+        "budget_monthly_usd": 500
+      },
+      "criticality": "P1",
+      "status": "active",
+      "last_verified": "2026-03-01",
+      "notes": ""
+    }
+  ]
+}
+```
+
+#### 5.2 Rotinas de Governanca
+
+**Semanal (15 min):**
+- Procurar chaves novas nao registradas
+- Chaves sem uso 30 dias → investigar → revogar se inativas
+- Permissoes excedentes → reduzir
+- Checar alertas de custo/anomalia
+
+**Mensal (1 hora):**
+- Auditoria completa do registry
+- Verificar expiracoes proximas (< 30 dias)
+- Revisar blast radius de cada credencial
+- Atualizar documentacao de seguranca
+- Testar kill switches e rollback procedures
+
+**Trimestral (2 horas):**
+- Rotacao de TODAS as credenciais criticas
+- Revisao de arquitetura de seguranca
+- Pen test basico (varredura completa)
+- Atualizacao de playbooks por provedor
+- Treinamento da equipe (se aplicavel)
+
+#### 5.3 Anti-Regressao (Pre-commit + CI)
+
+**Pre-commit hook (.pre-commit-config.yaml):**
+```yaml
+repos:
+  - repo: local
+    hooks:
+      - id: secret-scan
+        name: Secret Scanner
+        entry: python scripts/secret_scanner.py
+        language: python
+        types: [text]
+        stages: [commit]
+```
+
+**CI Check (GitHub Actions):**
+```yaml
+name: Secret Scan
+on: [pull_request]
+jobs:
+  scan:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/
+
+### 4.1 Openai
+
+**Risco tipico:** Chave vazada → consumo/custo descontrolado → milhares de dolares em horas.
+
+**Hardening:**
+- Chave SO no servidor (VPS) — nunca no front
+- Criar chaves por projeto/ambiente (nunca uma chave unica para tudo)
+- Usar Organization API keys (nao pessoais) quando possivel
+- Proxy com: rate limit por IP/usuario, limites por modelo (gpt-4 mais caro), logs de consumo, kill switch
+- Configurar usage limits no dashboard da OpenAI
+- Monitorar usage API: `GET /v1/usage` ou dashboard
+
+**Checklist OpenAI:**
+```
+[ ] Nenhuma chave no front-end
+[ ] Chaves separadas por ambiente (dev/prod)
+[ ] Usage limits configurados no dashboard
+[ ] Proxy server-side com rate limiting
+[ ] Monitoramento de custo/uso ativo
+[ ] Rotacao a cada 90 dias
+[ ] Alertas de anomalia de consumo
+```
+
+### 4.2 Google Cloud (Gcp)
+
+**Risco tipico:** Service account key JSON vazada = acesso total a recursos cloud.
+
+**Hardening:**
+- Usar Secret Manager para armazenar credenciais
+- EVITAR service account keys long-lived — preferir Workload Identity Federation
+- Aplicar least privilege (IAM minimo — usar IAM Recommender)
+- Remover permissoes nao usadas
+- Rotacionar e expirar chaves de service account
+- Configurar budget alerts + billing anomaly detection
+- Manter contatos essenciais atualizados
+- Ativar VPC Service Controls quando aplicavel
+
+**Checklist GCP:**
+```
+[ ] Nenhum JSON de service account no repo
+[ ] Workload Identity Federation quando possivel
+[ ] IAM minimo (usar Recommender)
+[ ] Chaves dormantes deletadas
+[ ] Budget alerts configurados
+[ ] Secret Manager em uso
+[ ] Audit logs ativados
+```
+
+### 4.3 Meta (Whatsapp / Facebook / Instagram)
+
+**Risco tipico:** App Secret/token vazado + webhooks mal validados = controle da integracao.
+
+**Hardening:**
+- App Secret e tokens SO no backend
+- Webhooks com validacao de assinatura (HMAC-SHA256) — OBRIGATORIO
+- Revisar permissoes/roles no Business Manager — principio do menor privilegio
+- Tokens separados por ambiente
+- Rotacionar tokens e revisar apps ativos periodicamente
+- Limitar callbacks/dominios permitidos no app settings
+- System User tokens para automacoes (nao tokens pessoais)
+
+**Checklist Meta:**
+```
+[ ] App Secret/tokens fora do client-side
+[ ] Webhook com validacao HMAC-SHA256
+[ ] Permissoes minimas no Business Manager
+[ ] System User tokens (nao pessoais)
+[ ] Dominios de callback restritos
+[ ] Tokens por ambiente
+[ ] Revisao trimestral de apps ativos
+```
+
+### 4.4 Telegram (Bots)
+
+**Risco tipico:** Token do bot vazou = controle total do bot (ler mensagens, enviar spam).
+
+**Hardening:**
+- Token do bot SO no backend
+- Webhook com secret_token e validacao
+- Rate limiting e anti-spam
+- Logs SEM expor update completo (pode conter dados sensiveis de usuarios)
+- Usar webhook (nao polling) em producao
+- Definir allowed_updates para receber so o necessario
+
+**Checklist Telegram:**
+```
+[ ] Token so server-side
+[ ] Webhook com secret_token
+[ ] Validacao de IP (Telegram IPs: 149.154.160.0/20, 91.108.4.0/22)
+[ ] Rate limiting ativo
+[ ] Allowed_updates configurado (minimo necessario)
+[ ] Logs redacted
+```
+
+### 4.5 Aws
+
+**Risco tipico:** AWS_ACCESS_KEY_ID + SECRET vazados = acesso ilimitado a cloud.
+
+**Hardening:**
+- NUNCA usar root account keys
+- IAM roles > IAM users > long-lived keys
+- MFA obrigatorio em todas as contas
+- SCP (Service Control Policies) para limitar blast radius
+- CloudTrail ativado para auditoria
+- GuardDuty para deteccao de anomalias
+- Rotacao automatica via Secrets Manager
+
+**Checklist AWS:**
+```
+[ ] Zero root account keys
+[ ] IAM roles preferenciais
+[ ] MFA em todas as contas
+[ ] CloudTrail ativado
+[ ] Secrets Manager em uso
+[ ] Budget alerts configurados
+```
+
+### 4.6 Stripe / Pagamentos
+
+**Risco tipico:** sk_live_ vazada = capacidade de criar charges, refunds, acessar dados de clientes.
+
+**Hardening:**
+- Restricted keys com permissoes minimas
+- Webhook signing secret validado em TODA request
+- Modo teste (sk_test_) para dev — NUNCA sk_live_ em dev
+- IP restriction quando possivel
+- Logs de auditoria do Stripe dashboard
+
+**Checklist Stripe:**
+```
+[ ] sk_live_ so em producao, so server-side
+[ ] Restricted keys com escopo minimo
+[ ] Webhook signature validation
+[ ] IP restriction ativa
+[ ] Logs de auditoria revisados
+```
+
+---
+
+
+## /Audit (Audit_All)
+
+Executar descoberta completa e gerar relatorio:
+1. Rodar TODAS as varreduras da Fase 1
+2. Classificar cada achado (Fase 2)
+3. Gerar relatorio com sumario executivo + inventario + acoes
+
+
+## /Lockdown (Lockdown_All)
+
+Aplicar hardening e anti-regressao em todo o ecossistema:
+1. Verificar cada credencial contra checklist do provedor
+2. Aplicar restricoes faltantes
+3. Instalar pre-commit hooks
+4. Configurar CI checks
+5. Gerar relatorio de hardening
+
+
+## /Rotate (Rotate_All)
+
+Plano e execucao guiada de rotacao:
+1. Listar todas credenciais com rotacao vencida ou proxima
+2. Gerar plano de rotacao (ordem, dependencias, rollback)
+3. Guiar execucao passo-a-passo (sem tocar em segredos diretamente)
+4. Atualizar registry
+
+
+## /Incident (Incident_Mode)
+
+Resposta imediata a vazamento/abuso:
+1. **CONTER** — Revogar chave/token, desativar webhooks, travar proxy (kill switch)
+2. **ERRADICAR** — Remover do codigo, reescrever historico git, scan amplo
+3. **RECUPERAR** — Gerar novas credenciais com escopo minimo, reimplantar
+4. **APRENDER** — Adicionar regra anti-regressao, post-mortem, atualizar playbook
+
+
+## /Govern (Set_Governance)
+
+Criar/atualizar registry + politicas + rotinas:
+1. Criar/atualizar secret registry JSON
+2. Definir politicas por criticidade
+3. Agendar rotinas (semanal/mensal/trimestral)
+4. Configurar alertas e dashboards
+
+
+## /Status
+
+Visao rapida da saude de seguranca:
+1. Total de credenciais no registry
+2. Quantas expiram em < 30 dias
+3. Quantas sem restricao adequada
+4. Ultimo audit e proximo agendado
+5. Incidentes abertos
+
+---
+
+
+## 6. Formato De Entrega (Sempre)
+
+Toda resposta de auditoria/acao segue esta estrutura:
+
+```
+A) SUMARIO EXECUTIVO
+   - Top riscos (P0/P1) com acao imediata
+   - Score geral de seguranca (0-100)
+   - Tendencia (melhorando/estavel/piorando)
+
+B) INVENTARIO DE CREDENCIAIS
+   - Tipos encontrados
+   - Locais de armazenamento
+   - Criticidade por item
+
+C) PLANO DE CORRECAO (por prioridade)
+   - P0: acao AGORA
+   - P1: acao em 24h
+   - P2: acao em 1 semana
+   - P3: acao em 1 mes
+
+D) PLAYBOOKS POR PROVEDOR
+   - Checklist especifico
+   - Comandos/passos exatos
+
+E) AUTOMACAO
+   - Scripts de varredura
+   - Pre-commit hooks
+   - CI checks
+   - Rotina semanal/mensal
+
+F) SECRET REGISTRY
+   - JSON atualizado
+   - Politica de governanca
+```
+
+---
+
+### 7.1 Severidade E Tempo De Resposta
+
+| Severidade | Descricao | SLA | Quem |
+|-----------|-----------|-----|------|
+| SEV-1 | Chave admin/root vazada publicamente | < 15 min | Toda equipe |
+| SEV-2 | Token de producao exposto em repo privado | < 1 hora | Dev + Ops |
+| SEV-3 | Chave de dev exposta, permissoes limitadas | < 4 horas | Dev responsavel |
+| SEV-4 | Potencial exposicao, nao confirmada | < 24 horas | Dev responsavel |
+
+### 7.2 Protocolo De 4 Passos
+
+**1. CONTER (imediato)**
+```bash
+
+## Bloquear Ip/Origem Suspeita
+
+```
+
+**2. ERRADICAR (< 1 hora)**
+```bash
+
+## Verificar Se Nao Ha Copias Em Backups/Forks/Mirrors
+
+```
+
+**3. RECUPERAR (< 4 horas)**
+```bash
+
+## Atualizar Registry
+
+```
+
+**4. APRENDER (< 48 horas)**
+```bash
+
+## Verificar Custos/Cobranças Anomalos Nos Provedores
+
+```
+
+---
+
+### 8.1 Scanner De Segredos (Python)
+
+Localizado em: `scripts/secret_scanner.py`
+- Varredura de arquivos com 30+ padroes regex
+- Deteccao por provedor (OpenAI, GCP, AWS, Meta, Telegram, Stripe, etc.)
+- Modo CI (--ci) com exit code nao-zero se encontrar
+- Modo pre-commit (--staged) para verificar so arquivos staged
+- Saida JSON ou texto
+
+### 8.2 Registry Manager
+
+Localizado em: `scripts/registry_manager.py`
+- CRUD de entries no secret registry
+- Alertas de expiracao
+- Status report
+- Export CSV para auditoria
+
+### 8.3 Pre-Commit Hook
+
+Localizado em: `scripts/pre_commit_hook.sh`
+- Wrapper para secret_scanner.py em modo staged
+- Bloqueia commit se encontrar segredo
+- Mensagem clara de como resolver
+
+### 8.4 Audit Report Generator
+
+Localizado em: `scripts/audit_report.py`
+- Executa todas as varreduras
+- Gera relatorio formatado (markdown)
+- Inclui score de seguranca
+- Sugestoes por provedor
+
+---
+
+### 9.1 Estrutura De Diretorios
+
+```
+/opt/
+  /api-gateway/        # Proxy server-side
+  /secrets/            # Referencias (NUNCA segredos em arquivo!)
+  /audit/              # Scripts de varredura + relatorios
+  /logs/               # Logs com redaction
+
+/home/<user>/
+  /apps/               # Seus projetos
+  /.env.production     # Segredos (chmod 600)
+
+/etc/
+  /systemd/system/     # Services para proxy e apps
+```
+
+### 9.2 Padrao De Seguranca Na Vps
+
+```
+1. Firewall (ufw/iptables):
+   - Permitir: 80, 443, 22 (com fail2ban)
+   - Bloquear todo o resto
+
+2. SSH:
+   - Desabilitar login por senha
+   - Usar chaves SSH apenas
+   - fail2ban ativo
+
+3. Segredos:
+   - .env com chmod 600, owner root
+   - Ou usar Docker secrets / environment
+   - NUNCA em arquivos acessiveis pela web
+
+4. Proxy:
+   - Rate limit por rota
+   - Auth JWT/session obrigatorio
+   - Logs sem segredos
+   - Kill switch (desligar proxy rapidamente)
+
+5. Monitoramento:
+   - Alertas de custo por provedor
+   - Alertas de uso anomalo
+   - Health checks automaticos
+```
+
+---
+
+### 10.1 Comportamento Transversal
+
+Esta skill opera de forma TRANSVERSAL — mesmo quando outras skills estao ativas:
+
+- Se durante QUALQUER tarefa detectar uma chave exposta em codigo → alertar imediatamente
+- Se um usuario pedir para "colocar a chave no config.js" → explicar o risco e oferecer alternativa segura
+- Se detectar .env sendo commitado → bloquear e orientar .gitignore
+- Se ver hardcoded credentials → sugerir refatoracao para env vars
+
+### 10.2 Sinais De Alerta Automaticos
+
+Monitore estes sinais durante QUALQUER operacao:
+- Strings que parecem chaves/tokens em codigo
+- Arquivos .env sendo criados sem .gitignore correspondente
+- Docker commands que copiam .env para dentro da image
+- CI/CD configs que echo ${{ secrets.* }}
+- Front-end code que referencia API keys diretamente
+
+---
+
+
+## Score De Seguranca (0-100)
+
+| Dimensao | Peso | Criterio |
+|----------|------|----------|
+| Exposicao Zero | 25% | Nenhum segredo em repo/front/logs |
+| Least Privilege | 20% | Todas credenciais com escopo minimo |
+| Rotacao | 15% | Todas dentro da politica de rotacao |
+| Restricoes | 15% | IP/dominio/escopo aplicados |
+| Monitoramento | 10% | Alertas de custo/anomalia ativos |
+| Governanca | 10% | Registry completo e atualizado |
+| Anti-regressao | 5% | Pre-commit + CI ativos |
+
+
+## Formula
+
+```
+Score = SUM(dimensao_peso * dimensao_score)
+onde dimensao_score = (itens_ok / itens_total) * 100
+```
+
+---
+
+
+## Skills Complementares
+
+| Skill | Integracao |
+|-------|-----------|
+| **007** | Threat modeling + Red Team — cred-omega cuida de segredos, 007 de arquitetura |
+| **instagram** | Protecao de Meta tokens, Graph API secrets |
+| **whatsapp-cloud-api** | Protecao de WABA tokens, webhook secrets |
+| **telegram** | Protecao de bot tokens |
+| **ai-studio-image** | Protecao de Google API keys |
+| **stability-ai** | Protecao de Stability API keys |
+| **context-agent** | Persistir estado de auditoria entre sessoes |
+| **skill-sentinel** | Auditar seguranca das proprias skills |
+
+
+## Quando Outra Skill Deve Chamar Cred-Omega
+
+Qualquer skill que lide com APIs externas deve consultar cred-omega para:
+1. Validar que credenciais estao armazenadas de forma segura
+2. Verificar restricoes adequadas
+3. Confirmar presenca no registry
+4. Verificar rotacao em dia
+
+
+## Best Practices
+
+- Provide clear, specific context about your project and requirements
+- Review all suggestions before applying them to production code
+- Combine with other complementary skills for comprehensive analysis
+
+
+## Common Pitfalls
+
+- Using this skill for tasks outside its domain expertise
+- Applying recommendations without understanding your specific context
+- Not providing enough project context for accurate analysis
+
+
+## Related Skills
+
+- `007` - Complementary skill for enhanced analysis