Gerador e verificador de security.txt
Monte um security.txt válido conforme a RFC 9116 para que pesquisadores saibam como falar com você, ou cole um arquivo existente para ver o que há de errado nele. Faz parte da preparação para o Regulamento Ciber-Resiliência (Cyber Resilience Act, CRA) da UE.
Funciona inteiramente no seu navegador
Gerar um security.txt
Conferir um security.txt
Confere o texto apenas com a RFC 9116. Não acessa o seu site (nada do que você digita sai desta página, então cole o arquivo), não verifica uma assinatura OpenPGP nem testa se um endereço funciona. É um modelo, não aconselhamento jurídico.
Como criar e conferir um security.txt
- Informe pelo menos um Contact (um endereço de e-mail, um telefone ou uma página https://) e confira a data de Expires. Preencha os campos opcionais que quiser, como Policy e Preferred-Languages.
- Copie o arquivo ou baixe-o e publique-o em
/.well-known/security.txtno seu domínio, por HTTPS e como texto simples. - Para conferir um arquivo existente, cole o texto dele no verificador. Corrija os erros e depois veja os avisos. Informe o endereço de onde ele é servido para testar o campo Canonical.
- Coloque um lembrete na agenda para renovar o Expires antes que a data passe.
Para que serve um security.txt
Quando um pesquisador, um cliente ou um CERT encontra uma falha no seu software, o primeiro problema é saber a quem avisar. O security.txt é um pequeno arquivo de texto em um endereço fixo, /.well-known/security.txt, que responde a essa pergunta: um contato, uma data de validade e, opcionalmente, um link para a sua política de divulgação e uma chave pública. A RFC 9116 define o formato, e muitos scanners, plataformas de bug bounty e CERTs nacionais procuram esse arquivo antes de procurar em qualquer outro lugar.
Para um fornecedor de software na UE, ele também apoia obrigações do Regulamento Ciber-Resiliência (CRA): o Anexo I espera uma forma publicada para que terceiros relatem vulnerabilidades e um processo para tratá-las. O regulamento não cita este formato, mas ele é a maneira usual de publicar o contato. O guia de notificação para pequenos fornecedores descreve o restante da preparação, incluindo o relógio de 24 horas.
Os campos
Contact e Expires são obrigatórios. Contact pode aparecer várias vezes e deve ser um URI: mailto:, tel: ou https:. Expires aparece uma única vez, como data e hora, por exemplo 2027-12-31T23:59:59Z, e a RFC 9116 pede que fique a menos de um ano no futuro. Encryption, Acknowledgments, Policy, Hiring e Canonical são links opcionais, e todo endereço da web deve usar https. Preferred-Languages aparece uma única vez e lista códigos de idioma. Os campos que a RFC não define são ignorados por quem lê o arquivo, por isso o verificador os sinaliza como avisos: normalmente são erros de digitação.
Dicas
- Use uma caixa de e-mail que várias pessoas leiam, não o endereço de uma só pessoa, e teste-a escrevendo para ela.
- Escreva uma política de divulgação de vulnerabilidades e vincule-a com o campo Policy.
- Conheça os seus prazos antes de um relato chegar: o relógio de 24 horas do CRA transforma o momento em que você tomou conhecimento em prazos com data.
Perguntas frequentes
O Regulamento Ciber-Resiliência (CRA) exige um security.txt?
Não. O regulamento espera que os fabricantes tenham uma política de divulgação coordenada de vulnerabilidades e uma forma publicada de receber relatos de vulnerabilidades. O security.txt é a maneira comum de publicar esse contato e os especialistas o recomendam, mas o regulamento não cita o formato. Veja o guia para pequenos fornecedores.
Onde exatamente devo colocar o arquivo?
Em https://seu-dominio/.well-known/security.txt, servido por HTTPS com o tipo de conteúdo text/plain; charset=utf-8. A RFC 9116 também permite uma cópia em /security.txt para configurações mais antigas. Publique o arquivo em cada domínio ou subdomínio que você quer cobrir.
Com quanta antecedência devo definir o Expires?
A RFC 9116 diz que a data deve ficar a menos de um ano no futuro, para que os pesquisadores possam confiar que os dados de contato são mantidos em dia. O gerador usa por padrão uma data um pouco abaixo de um ano. Quando a data passa, os leitores devem ignorar o arquivo, então renove-o com folga.
Preciso assinar o arquivo com PGP?
Não, assinar é opcional, mas recomendado. Um arquivo assinado é uma mensagem OpenPGP com assinatura em texto claro, criada com gpg --clearsign security.txt. O verificador reconhece o formato assinado e confere a estrutura, mas não consegue verificar a assinatura em si; para isso, use gpg --verify.
Por que o verificador não acessa o meu site?
Para manter a página privada: ela roda inteiramente no seu navegador e não faz requisições a outros sites. Abra o arquivo em uma aba do navegador, copie o texto e cole aqui. Assim você também confere o que os visitantes realmente recebem.
Para que serve o campo Canonical?
Ele lista os endereços em que o arquivo deve ser servido, para que quem lê possa confirmar que um arquivo encontrado em determinado endereço realmente pertence a ele. Se você informar o endereço de onde serve o arquivo, o verificador testa se alguma das suas linhas Canonical corresponde a ele.