#!/intro

A segurança nunca é opcional, mesmo num blog estático.

Este site é gerado com Hugo e disponibilizado como conteúdo estático, sem comentários, sessões ou bases de dados. À primeira vista, pode parecer simples. No entanto, simplicidade não é sinónimo de invulnerabilidade. Os componentes envolvidos no desenvolvimento, integração e publicação podem constituir vetores de ataque, mesmo em projetos minimalistas.

A integridade, autenticidade e segurança do conteúdo disponibilizado neste site são encaradas com seriedade. Embora funcione de forma puramente estática e sem funcionalidades interativas, é adotada uma postura de vigilância proativa relativamente a potenciais vetores de ataque.

O conteúdo é distribuído através da infraestrutura da Cloudflare, beneficiando de caching, proteção contra ataques de negação de serviço e validação de certificados. Ainda assim, podem ocorrer incidentes a nível da cadeia de desenvolvimento, nomeadamente durante a construção (build) ou distribuição.

Esta política destina-se a qualquer indivíduo que, por responsabilidade, ética profissional ou atenção ao detalhe, identifique vulnerabilidades, comportamentos anómalos ou indícios de comprometimento. Sempre que tal ocorra, a divulgação pública deve ser evitada antes do contacto prévio com o responsável pelo site. A cooperação responsável contribui para a mitigação de riscos e para a proteção dos visitantes.

Este documento descreve o procedimento recomendado para comunicar toto o tipo de problemas de segurança.

Segue abaixo o /manual completo.

> ambito

Esta política aplica-se a vulnerabilidades ou comportamentos anómalos que possam afetar a integridade, autenticidade ou fiabilidade do conteúdo apresentado neste site. Inclui situações como modificações não autorizadas ao código HTML, CSS ou JavaScript entregue aos utilizadores, bem como a inserção de scripts maliciosos, redirecionamentos imprevistos ou qualquer forma de código injetado. Consideram-se também abrangidos os casos de comprometimento de bibliotecas ou recursos externos fornecidos através de redes de distribuição de conteúdo, falhas que afetem a integridade dos builds gerados, assim como ataques ou interferências na cadeia de distribuição, incluindo cenários de intercetação do tipo man-in-the-middle ou corrupção nos processos de entrega.

Estão excluídas do âmbito desta política as questões de natureza estética, erros tipográficos ou lapsos editoriais. Também não se consideram incluídos os problemas de usabilidade, de compatibilidade com navegadores ou de acessibilidade. Relatórios gerados de forma automatizada e sem evidência técnica concreta não são abrangidos, tal como explorações que dependam de acesso físico ao ambiente de alojamento ou de controlo administrativo sobre a infraestrutura da Cloudflare.

> contacto

Relatórios de segurança devem ser enviados de forma estritamente confidencial para o endereço de correio eletrónico disponível na página de apresentação.

A fim de assegurar uma análise técnica eficaz, solicita-se que o relatório contenha, sempre que possível:

  • Identificação do recurso ou endereço afetado;

  • Descrição clara e objetiva da anomalia detetada;

  • Instruções para reprodução do comportamento (se aplicável);

  • Avaliação preliminar do impacto e grau de severidade;

  • Data e hora aproximadas da observação.

Opcionalmente, é possível utilizar cifra com PGP. A chave pública encontra-se disponível na página de apresentação.

> compromisso

Após a receção de um relatório considerado válido, proceder-se-á à verificação e análise da informação no prazo máximo de cinco dias úteis. Sempre que possível, será enviada uma confirmação da receção ao remetente. Caso se justifique, serão aplicadas medidas de mitigação ou correção apropriadas. O autor do relatório será mantido informado sobre o progresso das ações desenvolvidas, sempre que tal comunicação seja considerada adequada e relevante.

> divulgação_responsável

É adotado um modelo de divulgação responsável. Agradece-se que qualquer divulgação pública seja adiada até que tenha oportunidade de investigar e, se necessário, resolver o problema de forma adequada. Mesmo que exista incerteza quanto à gravidade do que foi detetado, o contacto é fortemente recomendado.

Um alerta falso é sempre preferível a uma vulnerabilidade não identificada ou por mitigar.

> status: secured
> exit 0