Capítulo 11: Divulgação de vulnerabilidades e atualizações de segurança

11.0 Resumo

• MUST: Fornece canais públicos de envio de vulnerabilidades (por exemplo, security.txt e e-mail de suporte).
• SHOULD: Fornece mecanismos de envio criptografados (por exemplo, chave PGP) para envio seguro de detalhes.
• SHOULD: Defina uma cadência clara de resposta e correção (cronogramas de SLA/alvo) e comunique-se por meio da página de status quando necessário.
• MUST: Tratar vulnerabilidades que potencialmente afetem os compromissos de Conhecimento Zero (XSS, injeção na cadeia de suprimentos, vazamento de fragmentos de log) como prioridade máxima.
• MUST: Implementar evolução versionada (cryptoVersion) e definir estratégias de compatibilidade, migração e descontinuação.

11.1 Canais e contato de envio de vulnerabilidades

11.2 Prazos de resposta e princípios de comunicação

Os cronogramas dependem da escala e da complexidade da equipe, mas o projeto DEVE fornecer uma cadência de metas previsível e comunicar-se prontamente caso as metas sejam perdidas. Alvos recomendados (ajustáveis com base na realidade e publicados em /security ou security.txt):

• Primeira Resposta: por exemplo, confirme o recebimento e atribua o ID de rastreamento dentro de 48 horas.
• Avaliação Inicial: Por exemplo, classificação de gravidade completa e avaliação do escopo de impacto em 7 dias.
• Corrigir lançamento: Progresso baseado na gravidade; P0/P1 priorizado para correção e liberação rápida.

SHOULD: Mantenha a comunicação necessária durante o processamento (por exemplo, reproduzido/não reproduzido, necessidade de mais informações, janela de correção estimada) e evite divulgar publicamente detalhes exploráveis.

11.3 Processo de Divulgação

1. Receipt: Registrar informações do relatório, etapas de reprodução, impacto e contato do pesquisador; atribuir proprietário e rastreamento.
2. Verification: Reproduz-se em ambiente isolado; avaliar o escopo do impacto, a capacidade de exploração e os componentes afetados (Frontend/Backend/Edge/Storage).
3. Remediation: Implementar patch, adicionar casos de teste/regressão, adicionar regras de proteção se necessário (WAF/Rate Limit/Policy Tightening).
4. Release: Canary libera e monitora as principais métricas; liberação completa após a confirmação de não haver regressão ou novos riscos.
5. Announcement: Explique publicamente o impacto, corrija o conteúdo e as ações necessárias do usuário (se houver) sem expandir a superfície de ataque.

Para vulnerabilidades críticas ou eventos de alto impacto para o usuário, SHOULD publicar atualizações de eventos ou post-mortems via /status alinhado com o processo de RI do Capítulo 10.

11.4 Vulnerabilidades que afetam os limites de conhecimento zero

O núcleo do compromisso Zero-Knowledge é: O servidor não pode acessar o CEK, o ambiente de download/descriptografia é isolado tanto quanto possível, sem scripts de terceiros. Portanto, as seguintes categorias DEVEM ser tratadas como prioridade máxima:

• XSS / Injeção: Capacidade de executar scripts arbitrários em páginas de download/descriptografia, lendo fragmentos ou material de chave de memória.
• Injeção na cadeia de suprimentos: Envenenamento por dependência, substituição de artefato de compilação, injeção de CDN/Edge levando à adulteração de script.
• Registro/Monitoramento de Vazamento: fragmento de URL, CEK, token ou texto simples registrado acidentalmente e acessível.
• Política de carregamento de recursos incorreta: Páginas de download/descriptografia importando scripts de terceiros, relaxamento do CSP expandindo a superfície de execução.

O descarte deve incluir: contenção imediata (código de risco off-line/política de restrição/vetor de proibição), liberação rápida de correção, análise de impacto retrospectiva, e uma declaração clara no anúncio sobre "se o material principal ou o texto simples foi potencialmente exposto".

11.5 Atualizações de segurança e verificação de regressão

• MUST: Estabeleça casos de regressão para alterações relacionadas à segurança (Auth, Controle de Acesso, CSP, Filtragem de Log, Fluxos de Criptografia).
• SHOULD: execute verificações automatizadas em páginas críticas (download/descriptografia) para garantir que nenhum script de terceiros e políticas de cabeçalho correspondam às expectativas.
• SHOULD: execute novos testes externos de itens verificáveis (por exemplo, verificações de TLS/cabeçalho de segurança) após o lançamento da correção.
• SHOULD: documente claramente as alterações de compatibilidade introduzidas por correções (por exemplo, links antigos/manifesto antigo) na documentação.

Consistente com o Capítulo 12: Varreduras de terceiros verificam algumas linhas de base da Web, mas não podem provar diretamente detalhes completos da implementação do Conhecimento Zero/E2EE; portanto, a verificação da regressão deve abranger tanto a implementação do protocolo quanto as linhas de base visíveis.

11.6 Versionamento de protocolo e criptografia (cryptoVersion)

A criptografia e implementação de protocolo do FileBolt DEVEM suportar versionamento para facilitar atualizações de algoritmos, corrigir defeitos de implementação e introduzir um isolamento mais forte. Recomendado usar campos explícitos (por exemplo, cryptoVersion) vinculado ao manifesto/metadados.

• Versão Explícita: Toda transferência/manifesto DEVE declarar seu cryptoVersion para determinar algoritmos, parâmetros e regras de codificação.
• Nenhuma inferência implícita: o cliente DEVE decidir a lógica de análise e descriptografia com base em campos de manifesto explícitos, e não em heurísticas de adivinhação ou fallback.
• Falha Fechada: DEVE falhar no fechamento ao encontrar versões desconhecidas ou parâmetros inconsistentes, nunca fazendo downgrade para modos inseguros.

11.7 Compatibilidade, migração e descontinuação

11.8 IDs de reivindicação relacionadas (reservados)

Este capítulo aborda "Canais de divulgação de vulnerabilidades, fluxos de trabalho, controle de versão e depreciação". Os IDs de reivindicação correspondentes serão adicionados ao Apêndice: Lista mestre de IDs de reivindicação como a única fonte autorizada.