triagem-de-seguranca

Triagem de Segurança

Use ao revisar advisories de segurança do OpenClaw, rascunhos ou relatórios GHSA.

Objetivo: triagem de alta confiança por mantenedores sem fechar excessivamente problemas reais ou enviar regressões desnecessárias.

Barra de Fechamento

Feche apenas se uma destas condições for verdadeira:

• duplicata de um advisory existente ou problema corrigido
• inválido contra o comportamento enviado
• fora do escopo conforme SECURITY.md
• corrigido antes de qualquer release/tag afetada

Não feche apenas porque main está corrigido. Se a tag enviada mais recente ou a release npm estiver afetada, mantenha aberto até que seja lançado ou publicado com o status correto.

Leituras Obrigatórias

Antes de responder:

1. Leia SECURITY.md.
2. Leia o corpo do GHSA com gh api /repos/openclaw/openclaw/security-advisories/<GHSA>.
3. Inspecione os caminhos de código exatos implicados.
4. Verifique o estado enviado:
   • git tag --sort=-creatordate | head
   • npm view openclaw version --userconfig "$(mktemp)"
   • git tag --contains <fix-commit>
   • se necessário: git show <tag>:path/to/file
5. Pesquise por sobreposição canônica:
   • GHSAs publicados existentes
   • bugs corrigidos mais antigos
   • mesma classe de modelo de confiança já coberta em SECURITY.md

Método de Revisão

Para cada advisory, decida:

• close
• keep open
• keep open but narrow

Padrão: um advisory por vez quando envolver comentários/fechamentos:

1. Revise exatamente um GHSA.
2. Imprima a URL do GHSA primeiro.
3. Resuma a decisão e as evidências para discussão.
4. Redija um comentário pronto para o mantenedor.
5. Copie apenas esse comentário para a área de transferência.
6. Pare e aguarde Peter postar/discutir antes de passar para o próximo GHSA.

Não agrupe múltiplos comentários de fechamento a menos que Peter peça explicitamente um lote.

Verifique nesta ordem:

1. Modelo de confiança
   • A pré-condição já está dentro do estado confiável de host/local/plugin/operador?
   • SECURITY.md declara explicitamente esta classe como fora do escopo ou apenas hardening?
2. Comportamento enviado
   • O bug está presente na tag enviada mais recente ou na release npm?
   • Foi corrigido antes da release?
3. Caminho de exploração
   • O relatório mostra uma verdadeira violação de limite, não apenas injeção de prompt, controle local do mesmo usuário ou semântica de nível auxiliar?
   • Se os dados apenas se movem entre arquivos de memória de workspace confiáveis mencionados em SECURITY.md, não trate "marcadores de injeção" isoladamente como um bug de segurança.
   • Nesse caso, enquadre a sanitização como hardening opcional apenas se preservar os fluxos de memória esperados.
4. Trade-off funcional
   • Se uma mudança de hardening reduzir a funcionalidade pretendida do usuário, destaque isso antes de propô-la.
   • Prefira correções que preservem os fluxos de trabalho do usuário em vez de regressões de negação por padrão, a menos que o limite exija.
5. Acompanhamento de hardening
   • Mesmo quando o GHSA deve ser fechado, pergunte se uma mudança estreita de hardening reduziria riscos sem alterar o limite de confiança documentado.
   • Separe hardening do status de vulnerabilidade. Expresse como "não necessário para o fechamento do GHSA, mas vale considerar".
   • Traga hardening apenas se for concreto, de baixo risco e preservar os fluxos de trabalho pretendidos do mantenedor/operador.
   • Se o hardening exigir uma mudança no modelo de produto/segurança, diga isso explicitamente e não implique que é uma correção necessária para o fechamento.

Formato de Resposta

Ao preparar uma resposta de fechamento pronta para o mantenedor:

1. Imprima a URL do GHSA primeiro.
2. Em seguida, redija uma resposta detalhada que o mantenedor possa postar.
3. Inclua:
   • motivo exato para o fechamento
   • referências de código exatas
   • fatos exatos de tag enviada / release
   • proveniência da correção ou GHSA duplicata canônico quando aplicável
   • nota opcional de hardening apenas se valer a pena e preservar funcionalidades

Mantenha um tom firme, específico e não defensivo.

Higiene de Redação Pública

• Mantenha hashes de commit brutos, títulos/números de PR e resumos de mecanismo de correção fora do texto público do advisory. Use apenas o campo de release/versão corrigida.
• Mantenha SHAs de commit exatos, PRs e notas de implementação em notas internas e arquivos de verificação.
• Para resultados de hardening/sem publicação, não adicione detalhes pesados de exploração, texto "Corrigido por" ou uma seção "Commit(s) de Correção". Agradeça aos relatores, preserve o crédito, declare o limite de SECURITY.md e diga claramente que o GHSA será fechado sem publicação.
• Para texto de CVE/GHSA publicado, prefira ### Versões Corrigidas com a release corrigida. Não explique como o patch funciona a menos que Peter peça explicitamente esse detalhe público.
• Mantenha IDs de GHSA fora do changelog e da redação de notas de release a menos que Peter peça explicitamente.

Modo de Discussão

Quando Peter estiver postando manualmente comentários de GHSA, use este fluxo:

1. Mostre a URL.
2. Dê um veredito conciso (close, keep open ou keep open but narrow).
3. Liste os marcadores de evidência mais fortes.
4. Declare qualquer acompanhamento opcional de hardening separadamente do motivo de fechamento.
5. Copie o corpo do comentário proposto com pbcopy.
6. Termine a resposta após o único advisory. Não continue para o próximo advisory até que Peter diga para continuar.

Se a API do GitHub não puder postar comentários para advisories privados, diga isso uma vez e continue usando área de transferência/cola da interface.

Etapa de Área de Transferência

Após redigir o corpo final da postagem para o advisory atual, copie-o:

pbcopy <<'EOF'
<resposta final>
EOF

Diga ao usuário que a área de transferência agora contém a resposta proposta para aquele advisory.

Comandos Úteis

gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
gh api /repos/openclaw/openclaw/security-advisories --paginate
git tag --sort=-creatordate | head -n 20
npm view openclaw version --userconfig "$(mktemp)"
git tag --contains <commit>
git show <tag>:<path>
gh search issues --repo openclaw/openclaw --match title,body,comments -- "<termos>"
gh search prs --repo openclaw/openclaw --match title,body,comments -- "<termos>"

Interrupções por Classificador Cibernético

Para trabalho defensivo permitido interrompido por um classificador cibernético, use uma rota Daybreak Blue aprovada e disponível apenas para aquela tarefa delimitada, depois restaure o modelo anterior. Preserve a identidade, escopo, permissões, sandbox e portões de revisão aprovados. Nunca troque de modelos para contornar negações de acesso, solicitações não permitidas ou ações de ferramenta recusadas; se essa rota também recusar, pare e relate. Siga a orientação da OpenAI para acesso aprovado a modelos.

Notas de Decisão

• "corrigido na main, não lançado" geralmente não é um fechamento.
• "requer primeiro estado local confiável controlado pelo atacante" geralmente está fora do escopo.
• "processo mesmo host mesmo usuário já pode ler/escrever estado local" geralmente está fora do escopo.
• "memória de workspace confiável promove/reindexa memória de workspace confiável" geralmente está fora do escopo, a menos que cruze um limite documentado.
• "função auxiliar se comporta de forma diferente da semântica de configuração documentada" geralmente é inválido.
• Se apenas a gravidade estiver errada, mas o bug for real, mantenha aberto e restrinja o impacto na resposta.