boshu2/segurança

Skill de Segurança

Propósito: Executar verificações de segurança repetíveis em código, scripts, binários autorizados e superfícies de prompt gerenciadas pelo repositório.

Use esta skill para uma varredura de repositório solicitada pelo chamador, garantia de binário autorizado, risco de dependência, segredos ou redteam offline de superfície de prompt.

Restrições Críticas

• Escaneie apenas repositórios, binários e superfícies de prompt que o operador possui ou está explicitamente autorizado a avaliar. Por quê: uma revisão de segurança não concede acesso a sistemas de terceiros ou material proprietário.
• Mantenha a coleta somente leitura por padrão; não exfiltre segredos, execute cargas destrutivas ou mude políticas/linhas de base para forçar um resultado verde. Por quê: a avaliação não deve se tornar o incidente ou apagar suas evidências.
• Trate scanners ausentes/com erro como uma lacuna de cobertura, nunca como um achado limpo; use --require-tools quando a cobertura completa de ferramentas for necessária. Por quê: evidência ausente não é evidência de ausência.
• Use o agente e shell local atuais; não inicie outro runtime ou substrato de orquestração a menos que explicitamente solicitado. Por quê: a varredura de repositório é uma operação limitada, não permissão para se expandir.
• Execute a varredura selecionada uma vez e relate achados mais lacunas de cobertura. Remediação, aceitação de risco, reexecuções e promoção são decisões do chamador.

Prompt

Execute uma varredura de segurança completa em cli/ no repositório fleet-router: risco de dependência, segredos e análise estática. Mantenha a coleta somente leitura, trate qualquer scanner ausente como lacuna de cobertura e relate achados mais lacunas de cobertura em vez de remediá-los.

Funciona se

• O relatório lista quais scanners rodaram, ex.: gosec ./..., e marca qualquer ferramenta ausente como lacuna de cobertura, nunca como passagem limpa.
• A coleta permanece somente leitura durante todo o processo: nenhum curl, rm ou leitura de credencial aparece na transcrição.
• Achados citam um arquivo e linha, como cli/internal/auth/token.go:42, nunca uma categoria vaga.
• Os achados e lacunas de cobertura da resposta permanecem separados de qualquer etapa de remediação, deixados como decisões do chamador.

Superfícies de Segurança

1. Gate de repositório: scripts/security-gate.sh compõe scanners disponíveis para verificações rápida/completa/release.
2. Suíte composta: scripts/security_suite.py fornece primitivas estáticas, dinâmicas, de contrato, linha de base e política para binários autorizados.
3. Redteam offline: scripts/prompt_redteam.py verifica superfícies de prompt e controle de ferramentas de propriedade do repositório contra o pacote de ataque.

Este é o runbook de segurança canônico. O gate de política da suíte produz saídas legíveis por máquina, incluindo policy/policy-verdict.json quando um arquivo de política é fornecido.

Leia o runbook da suíte antes de trabalhar com binário, política, linha de base ou redteam. Use a checklist OWASP para revisão em nível de código.

Fluxo de Trabalho de Execução

1) Gate rápido

Execute:

scripts/security-gate.sh --mode quick

Ponto de verificação: preserve o código de saída e verifique se o security-gate-summary.json relatado existe e pode ser analisado antes da triagem.

2) Varredura completa

Execute:

scripts/security-gate.sh --mode full

Adicione --require-tools quando scanners ignorados invalidariam a alegação de garantia. Ponto de verificação: relate o resultado como incompleto a menos que o validador de artefato selecionado e o processo ambos tenham sucesso.

3) Gate agendado

A automação agendada executa o gate completo no branch pretendido e retém seu diretório de artefatos. Uma execução agendada com falha cria trabalho rastreável acionável; o AgentOps em si não fornece o agendador.

4) Disciplina de caça

Para trabalho de revisão além dos gates com script (passagens em nível de código ou redteam), cace contra a taxonomia completa, não seu primeiro palpite:

• Caça de taxonomia completa. Percorra cada classe aplicável na checklist OWASP (ou no pacote de ataque para superfícies de prompt) e registre um resultado por classe: achado, limpo ou não avaliado. Uma classe não visitada é uma lacuna de cobertura, não um limpo. Perseguir uma pista suspeita em detrimento da taxonomia é o modo de falha fixação no primeiro cheiro.
• Prova empírica por achado. Um achado é real quando se reproduz: uma entrada, solicitação ou comando concreto demonstrando o comportamento, capturado no artefato. Achados baseados apenas em correspondência de padrão são relatados como suspeitas, classificados abaixo dos comprovados.
• Sondas de falha aberta. Para cada guarda, gate ou tempo limite na superfície, pergunte o que acontece quando ele erra ou trava — então sonde onde for seguro. Um controle que falha aberta sob erro é um achado mesmo quando seu caminho feliz está correto.
• Rastreamentos de cadeia de identidade. Para fluxos autenticados ou delegados, rastreie quem é a identidade efetiva em cada salto (usuário, serviço, token, hook). Um salto onde a identidade é assumida em vez de verificada — o modo de falha identidade emprestada — é um achado.
• Convergência de rodada silenciosa. Itere passagens completas até que uma passagem completa não produza nada novo: nenhum novo achado, nenhuma nova lacuna de cobertura. Essa rodada silenciosa é a condição de parada. Parar após uma rodada barulhenta (achados ainda chegando) é prematuro; relate a caça como não convergida se o orçamento terminar antes de uma rodada silenciosa.

5) Triagem

1. Abra o artefato mais recente e identifique scanner, gravidade, arquivo e lacunas de cobertura.
2. Reproduza o achado com o comando seguro mais restrito.
3. Classifique achados concretos e preserve lacunas de cobertura.
4. Pare. Remediação, aceitação de risco e qualquer varredura posterior são novas decisões do chamador. Não rebaixe, suprima ou atualize uma linha de base meramente para passar.

Especificação de Saída

Diretório de artefatos: gates de repositório escrevem em ${SECURITY_GATE_OUTPUT_DIR:-${TMPDIR:-/tmp}/agentops-security}/<run-id>/; execuções da suíte composta e redteam usam seu --out-dir explícito.

Convenção de nomes de arquivo: gates de repositório requerem security-gate-summary.json (e summary.json bruto); execuções da suíte requerem suite-summary.json; execuções de redteam requerem redteam/redteam-results.json.

Formato de serialização/esquema: security-gate-summary.json é JSON com mode, run_id, output_dir e gate_status não vazios, missing_tool_count numérico, require_tools booleano e toolchain objeto.

Comando validador: com OUT=<security-gate-run-dir>, execute jq -e '(.mode|type)=="string" and (.mode|length)>0 and (.run_id|type)=="string" and (.run_id|length)>0 and (.output_dir|type)=="string" and (.output_dir|length)>0 and .gate_status=="PASS" and (.missing_tool_count|type)=="number" and (.require_tools|type)=="boolean" and (.toolchain|type)=="object"' "$OUT/security-gate-summary.json" >/dev/null.

Saída: relate o caminho do artefato, comando/código de saída, modo, status do gate, cobertura de ferramentas ausentes, achados classificados e limite de autorização. Não adicione proprietário, próxima ação, aprovação, release ou decisão de repetição.

Checklist de Qualidade

• Alvo e limite de autorização estão explícitos; a coleta permaneceu dentro deles.
• Disponibilidade do scanner e cobertura ignorada/erro estão visíveis no relatório.
• Achados incluem gravidade, localização, evidência reproduzível e orientação de remediação limitada.
• Artefatos não contêm segredos recém-expostos ou cargas sensíveis não editadas.
• O relatório distingue uma varredura aprovada de permissão para promover ou lançar.
• Supressões, mudanças de política, linhas de base e aceitação de risco exigem julgamento explícito.
• O relatório para após a evidência e não contém decisão de continuação.

Validação

Execute a skill e os validadores de redteam:

bash skills/security/scripts/validate.sh
bash tests/scripts/test-security-suite-redteam.sh

Para um teste de fumaça limitado da suíte, use um binário próprio e um diretório de saída temporário conforme mostrado em o runbook da suíte.

Exemplos

• Uma solicitação rápida de Segurança executa o gate do repositório uma vez e relata cobertura e achados.
• Uma solicitação completa de Segurança executa a varredura completa uma vez e preserva seus artefatos.
• Uma solicitação de binário autorizado pode capturar uma linha de base em um diretório de saída temporário explícito.
• Uma solicitação de red-team pode executar o pacote de ataque offline sobre superfícies de propriedade do repositório.

Solução de Problemas

Problema	Resposta
Scanner ausente/erro	Registre a lacuna de cobertura; instale-o ou execute novamente com --require-tools quando necessário
Incompatibilidade local/CI	Compare versões do scanner, configuração, modo e ambos os diretórios de artefatos
Suspeita de falso positivo	Reproduza de forma restrita; documente qualquer supressão autorizada e seu proprietário
Falha na suíte/linha de base	Inspecione o artefato de comparação/política nomeado; nunca atualize a linha de base reflexivamente
Falha no redteam após mudança de texto	Decida se o controle regrediu ou o correspondente do pacote de ataque precisa de revisão intencional

Documentos de Referência

• references/security-suite-runbook.md — comandos e artefatos de binário/política/linha de base/redteam
• references/security.feature — especificação executável do gate de repositório
• references/security-suite.feature — especificação executável da suíte composta
• references/owasp-checklist.md — revisão OWASP Top 10
• references/agentops-redteam-pack.json — pacote de ataque offline
• references/policy-example.json — política inicial