CRED-OMEGA: Security Engine for All API Keys (Enterprise)

Overview

This public intake copy packages

plugins/antigravity-awesome-skills-claude/skills/cred-omega

https://github.com/sickn33/antigravity-awesome-skills

Use it when the operator needs the upstream workflow, support files, and repository context to stay intact while the public validator and private enhancer continue their normal downstream flow.

This intake keeps the copied upstream files intact and uses

metadata.json

ORIGIN.md

CRED-OMEGA: Security Engine for All API Keys (Enterprise)

Imported source sections that did not map cleanly to the public headings are still preserved below or in the support files. Notable imported sections: How It Works, 1.1 As 5 Missoes Inegociaveis, 1.2 Regras De Ouro (Nunca Violar), 1.3 Mentalidade De Seguranca, 2.1 Tipos De Credenciais (Taxonomia Completa), 2.2 Onde Vazam (Superficie De Ataque).

When to Use This Skill

Use this section as the trigger filter. It should make the activation boundary explicit before the operator loads files, runs commands, or opens a pull request.

• When you need specialized assistance with this domain
• The task is unrelated to cred omega
• A simpler, more specific tool can handle the request
• The user needs general-purpose assistance without domain expertise
• Use when the request clearly matches the imported source intent: CISO operacional enterprise para gestao total de credenciais e segredos.
• Use when the operator should preserve upstream workflow detail instead of rewriting the process from scratch.

Operating Table

metadata.json

ORIGIN.md

SKILL.md

SKILL.md

## Related Skills

Workflow

This workflow is intentionally editorial and operational at the same time. It keeps the imported source useful to the operator while still satisfying the public intake standards that feed the downstream enhancer flow.

1. Confirm the user goal, the scope of the imported workflow, and whether this skill is still the right router for the task.
2. Read the overview and provenance files before loading any copied upstream support files.
3. Load only the references, examples, prompts, or scripts that materially change the outcome for the current request.
4. Execute the upstream workflow while keeping provenance and source boundaries explicit in the working notes.
5. Validate the result against the upstream expectations and the evidence you can point to in the copied files.
6. Escalate or hand off to a related skill when the work moves out of this imported workflow's center of gravity.
7. Before merge or closure, record what was used, what changed, and what the reviewer still needs to verify.

Imported Workflow Notes

Imported: 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.

Imported: 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.

Examples

Example 1: Ask for the upstream workflow directly

Use @cred-omega to handle <task>. Start from the copied upstream workflow, load only the files that change the outcome, and keep provenance visible in the answer.

Explanation: This is the safest starting point when the operator needs the imported workflow, but not the entire repository.

Example 2: Ask for a provenance-grounded review

Review @cred-omega against metadata.json and ORIGIN.md, then explain which copied upstream files you would load first and why.

Explanation: Use this before review or troubleshooting when you need a precise, auditable explanation of origin and file selection.

Example 3: Narrow the copied support files before execution

Use @cred-omega for <task>. Load only the copied references, examples, or scripts that change the outcome, and name the files explicitly before proceeding.

Explanation: This keeps the skill aligned with progressive disclosure instead of loading the whole copied package by default.

Example 4: Build a reviewer packet

Review @cred-omega using the copied upstream files plus provenance, then summarize any gaps before merge.

Explanation: This is useful when the PR is waiting for human review and you want a repeatable audit packet.

Best Practices

Treat the generated public skill as a reviewable packaging layer around the upstream repository. The goal is to keep provenance explicit and load only the copied source material that materially improves execution.

• 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
• Keep the imported skill grounded in the upstream repository; do not invent steps that the source material cannot support.
• Prefer the smallest useful set of support files so the workflow stays auditable and fast to review.
• Keep provenance, source commit, and imported file paths visible in notes and PR descriptions.
• Point directly at the copied upstream files that justify the workflow instead of relying on generic review boilerplate.

Imported Operating Notes

Imported: 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

Troubleshooting

Problem: The operator skipped the imported context and answered too generically

Symptoms: The result ignores the upstream workflow in

plugins/antigravity-awesome-skills-claude/skills/cred-omega

metadata.json

ORIGIN.md

Problem: The imported workflow feels incomplete during review

Symptoms: Reviewers can see the generated

SKILL.md

Problem: The task drifted into a different specialization

Symptoms: The imported skill starts in the right place, but the work turns into debugging, architecture, design, security, or release orchestration that a native skill handles better. Solution: Use the related skills section to hand off deliberately. Keep the imported provenance visible so the next skill inherits the right context instead of starting blind.

Related Skills

• @conductor-validator

  - Use when the work is better handled by that native specialization after this imported skill establishes context.

• @confluence-automation

  - Use when the work is better handled by that native specialization after this imported skill establishes context.

• @content-creator

  - Use when the work is better handled by that native specialization after this imported skill establishes context.

• @content-marketer

  - Use when the work is better handled by that native specialization after this imported skill establishes context.

Additional Resources

Use this support matrix and the linked files below as the operator packet for this imported skill. They should reflect real copied source material, not generic scaffolding.

references

references/n/a

examples

examples/n/a

scripts

scripts/n/a

agents

agents/n/a

assets

assets/n/a

Imported Reference Notes

Imported: 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

Imported: 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

Imported: 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

Imported: 2.1 Tipos De Credenciais (Taxonomia Completa)

Imported: 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)

Imported: 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?

Imported: Fase 1 — Descoberta (Varredura Profunda)

1A. Varredura de Codigo (padroes de alta precisao)

#### Imported: 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

#### Imported: 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

#### Imported: Openai (Sk-...)

rg -n "sk-[a-zA-Z0-9]{20,}" . --glob '!node_modules' --glob '!.git'

#### Imported: Google Cloud (Aiza...)

rg -n "AIza[a-zA-Z0-9_-]{35}" . --glob '!node_modules' --glob '!.git'

#### Imported: Aws (Akia...)

rg -n "AKIA[A-Z0-9]{16}" . --glob '!node_modules' --glob '!.git'

#### Imported: Stripe (Sk_Live_...)

rg -n "sk_live_[a-zA-Z0-9]{20,}" . --glob '!node_modules' --glob '!.git'

#### Imported: Meta/Facebook (Token Longo Numerico)

rg -n "EAA[a-zA-Z0-9]{50,}" . --glob '!node_modules' --glob '!.git'

#### Imported: Telegram Bot Token

rg -n "[0-9]{8,10}:[a-zA-Z0-9_-]{35}" . --glob '!node_modules' --glob '!.git'

#### Imported: Github Pat

rg -n "ghp_[a-zA-Z0-9]{36}" . --glob '!node_modules' --glob '!.git'

#### Imported: Jwt (Eyj...)

rg -n "eyJ[a-zA-Z0-9_-]{10,}\\.eyJ[a-zA-Z0-9_-]{10,}" . --glob '!node_modules' --glob '!.git'

#### Imported: 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)

#### Imported: Buscar Segredos Em Todos Os Commits

git log --all --oneline | head -50

#### Imported: 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

#### Imported: 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

#### Imported: Listar Images Locais

docker images --format "{{.Repository}}:{{.Tag}}" 2>/dev/null | head -20

#### Imported: 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)

#### Imported: 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

#### Imported: Github Actions — Checar Se Secrets Estao Sendo Logados

rg -rn "echo.*\$\{\{.*secrets" .github/ 2>/dev/null
rg -rn "env:.*\$\{\{.*secrets" .github/ 2>/dev/null

#### Imported: Checar Se .Env Esta Sendo Copiado No Ci

rg -n "\.env" .github/workflows/ Jenkinsfile .gitlab-ci.yml 2>/dev/null

Imported: Fase 2 — Classificacao De Risco

Para cada achado, classificar usando esta matriz:

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)

Imported: 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:

   # 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
   

Imported: 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

#### Imported: 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):

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):

name: Secret Scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/

#### Imported: 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

#### Imported: 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

#### Imported: 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

#### Imported: 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

#### Imported: 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

#### Imported: 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

---

#### Imported: /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

#### Imported: /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

#### Imported: /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

#### Imported: /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

#### Imported: /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

#### Imported: /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

---

#### Imported: 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

---

#### Imported: 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 |

#### Imported: 7.2 Protocolo De 4 Passos

**1. CONTER (imediato)**
```bash

#### Imported: Bloquear Ip/Origem Suspeita

2. ERRADICAR (< 1 hora)

#### Imported: Verificar Se Nao Ha Copias Em Backups/Forks/Mirrors

3. RECUPERAR (< 4 horas)

#### Imported: Atualizar Registry

4. APRENDER (< 48 horas)

#### Imported: Verificar Custos/Cobranças Anomalos Nos Provedores

Imported: 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

Imported: 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

Imported: 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

Imported: 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

Imported: 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

Imported: 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

Imported: 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

Imported: 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

Imported: Score De Seguranca (0-100)

Imported: Formula

Score = SUM(dimensao_peso * dimensao_score)
onde dimensao_score = (itens_ok / itens_total) * 100

Imported: Skills Complementares

Imported: 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

Imported: 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

Imported: Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.