Resumo

  • O draft-bruhns-securitytxt-product-security-00, publicado em 10 de setembro de 2026, propõe os campos opcionais Product-Security e Product-Security-Policy para o formato do RFC 9116.
  • O primeiro indica URIs para relatos de vulnerabilidades em produtos; o segundo aponta para uma política HTTPS sobre escopo, triagem, prazo e divulgação.
  • Trata-se de um Internet-Draft individual, sem adoção por grupo de trabalho ou aprovação do IETF. A IANA ainda não registra nenhum dos dois campos.
  • A separação de filas melhora o encaminhamento inicial, mas não comprova qual equipe assumiu um modelo, uma versão, um build redistribuído ou um componente externo.

O protocolo entregou; a organização ainda precisa decidir

Imagine um pesquisador com uma falha reproduzida em uma versão antiga de um appliance. A marca mantém um portal ativo e publica um contato exclusivo para segurança de produto. O relato recebe protocolo automático. Só depois surge a dúvida: a versão pertence ao fabricante original, à empresa que comprou a linha ou ao integrador que distribuiu aquele build?

Não há necessariamente falha de e-mail. O canal pode ter funcionado exatamente como anunciado. O que falta é uma decisão de custódia sobre o artefato. A URI escolhe a primeira fila; ela não revela quem controla o código, tem capacidade de corrigir ou aceitou coordenar a divulgação.

Essa diferença aumenta com white label, aquisições e dependências. O nome comercial permanece na carcaça enquanto o contrato de manutenção muda. Uma biblioteca pode afetar várias marcas. Um produto fora de suporte continua instalado. O domínio da empresa fornece uma origem, não a cronologia completa dessas responsabilidades.

O conteúdo proposto é limitado e verificável

O Datatracker classifica Product Security Fields for security.txt como Internet-Draft individual. O histórico mostra apenas a revisão 00, de 10 de setembro. A publicação abre o texto à discussão; não representa endosso do IETF, adoção por grupo de trabalho nem publicação como RFC.

Na revisão 00, Product-Security pode aparecer várias vezes. Cada linha contém uma URI de contato para vulnerabilidades de produto, sujeita às mesmas restrições de URI de Contact. A ordem expressa a preferência do publicador.

Product-Security-Policy aparece uma vez e aponta para HTTPS. A página deveria informar produtos cobertos, confirmação e triagem, expectativas de resposta, divulgação e embargo, relato anônimo e garantias a pesquisas de boa-fé.

O rascunho acerta ao tornar o escopo uma pergunta explícita. Mas ele não define um identificador universal de produto nem verifica se a política cita o modelo e a versão enviados pelo pesquisador. O link cria um lugar para a resposta; não cria a resposta.

O pedido à IANA ainda não virou registro

O texto pede duas novas entradas sob Expert Review. No momento observado, o registro de campos security.txt da IANA não contém Product-Security ou Product-Security-Policy. Ele lista campos atuais como Contact, Expires, Canonical, Encryption, Policy e Preferred-Languages, além de extensões registradas como CSAF, Bug-Bounty e Hiring.

Essa sequência não pode ser invertida. A seção IANA Considerations formula uma solicitação sobre o futuro. O RFC 8126 descreve Expert Review como avaliação por especialistas designados segundo as regras do registro. A existência do rascunho não produz a alocação.

Testes locais podem coexistir com ferramentas antigas. O RFC 9116 manda ignorar extensões desconhecidas. Por isso o novo documento recomenda que Contact continue recebendo relatos de produto, preservando uma rota para parsers que não reconhecem o campo proposto. Isso oferece compatibilidade, não adoção comprovada.

O arquivo nasce num domínio, não num inventário

O escopo comum do RFC 9116 é a origem de onde o arquivo foi obtido. Um security.txt recuperado para um domínio ou IP vale para aquele recurso e não se estende automaticamente a pais ou subdomínios. A organização pode publicar contatos sobre produtos e serviços, mas o formato não mantém catálogo de modelos, versões e responsáveis.

O pesquisador apresenta dados de outro tipo: família, número de modelo, pacote, versão, build, branch ou commit. Do lado do publicador estão a origem web, a política e as filas. A ligação entre os dois precisa de uma justificativa registrada.

Sem ela, uma revisão futura comprova apenas que o relato foi enviado ao domínio da marca. Não mostra se o time aceitou aquele release, repassou a um terceiro ou aplicou uma política que depois foi alterada. A página atual pode apagar silenciosamente o contexto do dia do relato.

Integridade da publicação não é competência sobre o produto

O RFC 9116 exige Expires, oferece Canonical e recomenda assinatura. Esses mecanismos ajudam a detectar informação velha, localizar a cópia pretendida e reduzir o risco de um servidor comprometido apontar o pesquisador para contatos do atacante.

Cada um tem limite. A assinatura liga conteúdo a uma chave, não um componente a um mantenedor. A URL canônica identifica o arquivo, não a versão de produto. A validade temporal mostra que o publicador ainda sustenta aquela declaração, não que a equipe receptora assumiu o caso.

O RFC também afirma que encontrar ou não encontrar o arquivo não autoriza nem proíbe testes. Uma política pode explicar proteção de boa-fé, mas o alcance precisa ser lido no texto aplicável. O nome de um campo não amplia garantias jurídicas.

Registrar o encontro entre artefato e responsável

Um recibo de encaminhamento deve começar pelos identificadores fornecidos no relato: família, modelo, componente, pacote, versão, build, firmware e canal de distribuição, conforme disponíveis. Depois registra origem e URL canônica do security.txt, horário de coleta, Expires, resultado da assinatura e a entrada Product-Security escolhida com sua posição na preferência.

Também deve preservar a URL de Product-Security-Policy e o hash ou versão do conteúdo. O receptor aponta a cláusula de escopo usada para aceitar, rejeitar ou redirecionar, a equipe que assumiu custódia e o número do caso ou da passagem. O detalhe confidencial da falha pode permanecer restrito; a decisão não precisa desaparecer.

Daniel Kade propõe esse registro como critério editorial; nem a revisão 00, nem o RFC 9116, nem a IANA o exigem. Ele começa onde termina o teste de disponibilidade do contato. Um canal ativo mostra recebimento; o recibo do artefato mostra qual responsabilidade foi assumida depois.

Fontes