Resumo

  • A RFC 9116 padroniza a descoberta de um contato para vulnerabilidades e o prazo de validade das informações publicadas, mas não prova entrega, abertura de caso ou custódia operacional.
  • Um comprovante do canal deve unir o arquivo coletado a uma sondagem segura, ao resultado de transporte, à confirmação, ao dono da fila, aos alvos de escalonamento e aos gatilhos de reteste.

Análise

Uma equipe renova seu security.txt durante a revisão anual do site. O endereço está bem formado, a política abre, a data de vencimento foi empurrada por onze meses e o scanner registra conformidade. Enquanto isso, a caixa compartilhada perdeu os membros quando o diretório corporativo foi reorganizado. Os e-mails são aceitos, mas ninguém os lê.

A contradição existe apenas se o arquivo for tratado como prova de uma operação inteira. A RFC 9116 não faz essa promessa.

Seu objetivo é reduzir a dificuldade de descobrir onde relatar uma vulnerabilidade. O formato exige ao menos um campo Contact e exatamente um Expires. Em serviços web, o local é /.well-known/security.txt, por HTTPS, em texto puro UTF-8. O registro de URIs conhecidas da IANA classifica security.txt como permanente e atribui o controle de mudanças à IETF. Pessoas e ferramentas ganham um ponto de descoberta interoperável.

O prazo tem força própria. Depois de Expires, as informações são consideradas obsoletas, e a RFC recomenda uma data a menos de um ano. O texto alerta que referências incorretas ou antigas podem impedir que a organização receba o relato ou encaminhá-lo a terceiros. Revisar a publicação é, portanto, necessário.

Ainda assim, a data é escolhida por quem publica. Ela não vem do servidor de e-mail, do banco de dados do formulário ou da fila de atendimento. Atualizar o documento não testa a infraestrutura que começa depois do clique ou do envio.

Publicação e serviço têm relógios diferentes

O relógio de publicação marca criação, revisão e vencimento do arquivo. O relógio de serviço marca aceitação da mensagem, confirmação, avaliação inicial, atribuição, escalonamento e comunicação do resultado. Confundir os dois permite que uma revisão editorial renove a aparência de um processo quebrado.

Há também limites distintos. Primeiro, escopo. Pela RFC 9116, o arquivo vale para o domínio ou endereço IP usado na recuperação, sem se estender automaticamente a pais, subdomínios ou todo o portfólio. Uma política pode descrever abrangência adicional, desde que o vínculo fique explícito.

Segundo, transporte. Um mailto: válido pode apontar para um alias que rejeita remetentes externos. Um formulário pode carregar e falhar após o envio. Uma plataforma contratada pode gerar um caso sem notificar a equipe. O sucesso do HTTPS no arquivo não observa nenhum desses eventos.

Terceiro, confidencialidade. Encryption aponta para uma chave ou impressão digital. A RFC deixa para o pesquisador a verificação de autenticidade. A chave estar acessível não comprova que o plantão conhece a chave privada, que a rotação terminou ou que a passagem entre equipes preservou a capacidade de decifrar.

Quarto, confirmação. Um número de caso ou resposta conciliável é a primeira evidência de que entrega se tornou custódia. Uma resposta automática isolada prova somente que uma regra rodou. É preciso saber se existe uma fila monitorada por trás dela.

Quinto, tratamento. Alguém deve avaliar, encaminhar itens fora de escopo, coordenar a correção e informar o desfecho. A Diretriz Operacional Vinculante 20-01 da CISA explicita essa camada para as agências civis federais dos Estados Unidos sujeitas a ela. Exige procedimentos para acompanhar relatos até a resolução, coordenar remediação, avaliar impacto, tratar itens fora do escopo e manter comunicação. Também requer metas para confirmação, avaliação inicial e resolução. Não é uma regra da RFC 9116 nem uma obrigação global; é um exemplo oficial da operação que a descoberta, sozinha, não demonstra.

Um teste que não finge ser incidente

O comprovante começa com a URI canônica consultada, a impressão do arquivo, o horário da coleta, o Expires exibido e o escopo do host ou serviço. Identifica o contato preferido segundo a ordem publicada. Para um formulário, registra a versão; para criptografia, a impressão digital observada.

Depois vem uma sonda sintética autorizada. Ela declara ser uma verificação de roteamento, informa como encerrá-la e não inclui vulnerabilidade real, código de exploração, segredo ou dado pessoal. O comprovante anota envio, aceite ou rejeição pelo transporte, horário da confirmação, identificador de caso, dono funcional da fila e substituto, além das metas de avaliação e escalonamento.

Cada observação precisa manter seu tamanho. Uma resposta SMTP positiva prova aceite por um salto, não leitura. Uma tela de agradecimento prova que a aplicação respondeu, não que o caso foi persistido. Um e-mail automático prova uma automação, não a atenção de um analista. O que não foi testado permanece explicitamente não testado.

A sondagem deve ser proporcional. Testes frequentes com aparência de criticidade consumiriam a capacidade real. A equipe receptora deve aprovar um marcador inequívoco. Migração de e-mail ou DNS, nova versão do formulário, troca de identidade, rotação de chave, mudança de fornecedor, saída de responsável, revisão da política ou entrada de domínio novo são gatilhos melhores que uma cadência cega. Sem mudança, basta testar em intervalo modesto, antes do vencimento público.

Preservar o papel do security.txt

O comprovante não substitui o arquivo. security.txt continua sendo a superfície pública de descoberta. Canonical, Policy, Preferred-Languages e Encryption eliminam ambiguidades diferentes. Uma assinatura digital pode reforçar integridade e origem.

O registro adicional responde apenas quando a rota declarada completou pela última vez o caminho mínimo até uma custódia identificável. “Arquivo atual, e-mail aceito, sem confirmação” é um estado válido. “Formulário cria caso, responsável presente, substituto não validado” também. Estados parciais apontam o reparo melhor que um selo único.

O resumo para um painel pode dizer: arquivo coletado em 7 de setembro; vence em 1º de março; sonda aceita; caso confirmado após quinze minutos; responsável validado; escalonamento não testado. Cada trecho tem evidência e hora próprias. Nenhum promete que uma futura vulnerabilidade será confirmada, priorizada corretamente ou resolvida no prazo.

Fontes

  1. RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure
  2. Registro de Well-Known URIs da IANA
  3. Diretriz Operacional Vinculante 20-01 da CISA