# Página de segurança do fornecedor: o que conferir antes de assinar Guia · UNIFOKAL · 23 de setembro de 2026 · 8 min de leitura · Produto e integração Arquivo de contato de segurança, cabeçalhos entregues, encarregado único e política baseada em arcabouço: o que conferir na página de segurança de um fornecedor, e como conferir. Toda empresa que vende tecnologia tem uma página de segurança, e quase todas dizem as mesmas coisas: criptografia, controle de acesso, conformidade. Quem homologa fornecedor não tem como auditar o que acontece dentro da casa do outro, mas tem como conferir o que ela publica, e boa parte do que se publica pode ser checada em minutos, de fora, sem pedir nada a ninguém. Este roteiro serve para qualquer fornecedor, de identidade ou não, e parte de uma regra simples: afirmação que pode ser medida deve ser medida. A divergência entre o que a página diz e o que o servidor entrega vale mais do que qualquer selo. Ele complementa o [roteiro geral para avaliar um fornecedor de KYC](https://unifokal.com/blog/como-avaliar-fornecedor-de-kyc), com o foco na vitrine de segurança. ## O arquivo de contato de segurança A RFC 9116, publicada pela IETF em abril de 2022, padroniza um arquivo de texto chamado security.txt, servido no endereço /.well-known/security.txt do domínio, para dizer a quem encontra uma falha como avisar a empresa. Dois campos são obrigatórios: Contact, com um endereço de e-mail, um telefone ou uma página, e Expires, a data a partir da qual o conteúdo deve ser considerado velho. A RFC recomenda que essa data fique a menos de um ano no futuro e diz, na seção 5.3, que não ter o arquivo pode ser preferível a ter informação velha. Três sinais de alerta aparecem em poucos segundos de leitura. O Expires vencido mostra que ninguém cuida do arquivo. O Expires anos à frente mostra que a recomendação de validade curta foi ignorada, o que costuma andar junto com contato desatualizado. E o campo Policy, que deveria apontar para a política de divulgação de vulnerabilidades, às vezes abre uma página que não fala de divulgação nenhuma, ou devolve erro. Uma política de verdade diz o que está no escopo e o que está fora, como relatar, o que o pesquisador pode esperar e quando a falha pode ser publicada. A mesma RFC, na seção 2.3, recomenda assinar o arquivo com uma assinatura OpenPGP em texto claro. Quando a assinatura existe, confira se a chave pública está publicada no domínio da própria empresa. ## O que a página afirma contra o que a resposta entrega Muita página de segurança diz que o site usa HSTS, a política que obriga o navegador a falar com o domínio só por HTTPS. Conferir é simples: no navegador, a aba de rede das ferramentas de desenvolvedor mostra os cabeçalhos de cada resposta; no terminal, o comando `curl -I` seguido do endereço mostra os cabeçalhos da página pedida. Se a página afirma HSTS e a resposta não traz o cabeçalho Strict-Transport-Security, a afirmação não se sustenta. A documentação da MDN lembra um detalhe que pega muita gente: o navegador ignora esse cabeçalho quando ele chega por HTTP, então ele só conta na resposta HTTPS. O OWASP Secure Headers Project mantém a lista dos cabeçalhos de resposta recomendados e dos que devem ser removidos, e a HTTP Security Response Headers Cheat Sheet, também da OWASP, explica cada um. Para uma aplicação que mostra dado pessoal, um conjunto razoável inclui Strict-Transport-Security, Content-Security-Policy com a diretiva frame-ancestors, X-Content-Type-Options com nosniff, X-Frame-Options, Referrer-Policy e Permissions-Policy. Olhe mais de uma rota. A tela de login e a área logada importam mais do que a página inicial, e é comum a página de marketing estar protegida e a aplicação não. O cabeçalho X-Powered-By faz o caminho inverso: ele está na lista de remoção da OWASP porque entrega de graça a tecnologia do servidor a quem procura alvo. ## Um encarregado, um endereço A LGPD, no artigo 41, obriga o controlador a indicar um encarregado pelo tratamento de dados pessoais, e o parágrafo 1º manda divulgar a identidade e o contato dele "de forma clara e objetiva, preferencialmente no sítio eletrônico do controlador". A Resolução CD/ANPD nº 18, de julho de 2024, detalhou a regra: o artigo 8º exige manter essas informações atualizadas, e o artigo 9º pede que elas fiquem "em local de destaque e de fácil acesso" no site. A conferência aqui é de consistência. Procure o contato do encarregado na política de privacidade, nos termos, no rodapé e na página de segurança. Dois endereços diferentes em canais oficiais que não se citam indicam que um deles está desatualizado, e o pedido de um titular pode acabar numa caixa que ninguém lê. Isso importa para quem contrata: quando o fornecedor atua como operador, o titular que procura por ele precisa achar o caminho certo, e a [cláusula de cooperação no contrato de fornecedor](https://unifokal.com/blog/contrato-de-fornecedor-de-identidade-as-clausulas-que-doem) só funciona se o canal do outro lado existir. ## "Baseada em" não é "certificada" Muita política de segurança diz que segue o NIST Cybersecurity Framework, o CSF. A versão 2.0 foi publicada pelo NIST em fevereiro de 2024, no documento CSWP 29, e organiza a gestão de risco em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. O próprio NIST afirma, nas perguntas frequentes do CSF, que não oferece certificação nem endosso de produtos, implementações ou serviços relacionados ao arcabouço, e que não há planos de criar um programa de avaliação de conformidade. Ou seja: "baseada no CSF" é um jeito legítimo de dizer como a política foi organizada, e "certificada no CSF" é uma frase que não corresponde a nada. Com norma certificável a conversa é outra. A certificação ISO/IEC 27001 é emitida por um organismo certificador e tem número, escopo e validade. A certificação emitida por organismo acreditado pode ser conferida no IAF CertSearch, a base do International Accreditation Forum criada para validar o status desse tipo de certificação. Peça o número, o escopo e a validade, e confira. O escopo importa tanto quanto o certificado: uma certificação que cobre só a área administrativa não diz nada sobre a plataforma que vai tratar os seus dados. ## Subprocessadores, DPA e status Três documentos completam a vitrine. A lista de subprocessadores deve dizer, para cada terceiro que o fornecedor usa, o papel dele, que dado recebe e em que país; é ela que responde para onde o dado vai. O acordo de tratamento de dados, o DPA, é onde as medidas de segurança viram obrigação de contrato, e vale ler as ressalvas: um DPA honesto diz onde a proteção não alcança. A página de status, quando existe, deveria ficar fora da infraestrutura que ela monitora, senão cai junto no dia em que você mais precisa dela, e o [roteiro para ler o SLA de um fornecedor](https://unifokal.com/blog/ler-o-sla-de-um-fornecedor) mostra por que o número da disponibilidade sozinho não basta. Na UNIFOKAL, por exemplo, esses documentos ficam reunidos numa [central de confiança](https://unifokal.com/confianca). Cada compromisso da política de segurança aponta para um teste automatizado ou um trecho de código que o sustenta, e essa ligação é conferida a cada entrega: se a contrapartida some, a entrega é reprovada. ## Lista de conferência - O /.well-known/security.txt existe, tem Contact e Expires, o Expires está no futuro e a menos de um ano, e o Policy abre uma política de divulgação de verdade. - Os cabeçalhos que a página afirma aparecem na resposta HTTPS da página inicial, da tela de login e de uma rota da aplicação. - O cabeçalho X-Powered-By não aparece em nenhuma delas. - O contato do encarregado é o mesmo em todos os documentos públicos. - Toda menção a arcabouço diz "baseada em", e toda certificação alegada tem número, organismo, escopo e validade que você consegue conferir. - A lista de subprocessadores diz papel, dado e país, e o DPA traz as ressalvas por escrito. Nenhum item exige acesso privilegiado nem questionário. Um fornecedor que não passa nesta lista dificilmente passa no questionário longo, e um que passa ganhou o direito de ser avaliado a fundo. ## Fontes citadas - RFC 9116, A File Format to Aid in Security Vulnerability Disclosure, de E. Foudil e Y. Shafranovich, IETF, abril de 2022, seções 2.3, 2.5.3, 2.5.5, 2.5.7 e 5.3: [rfc-editor.org](https://www.rfc-editor.org/rfc/rfc9116.html) - OWASP Secure Headers Project, listas de cabeçalhos a acrescentar e a remover: [owasp.org](https://owasp.org/www-project-secure-headers/) - OWASP, HTTP Security Response Headers Cheat Sheet: [cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) - MDN Web Docs, da Mozilla, página de referência do cabeçalho Strict-Transport-Security: [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security) - Lei 13.709/2018, LGPD, artigo 41, parágrafo 1º: [planalto.gov.br](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm) - Resolução CD/ANPD nº 18, de 16 de julho de 2024, Regulamento sobre a atuação do encarregado, artigos 8º e 9º, publicada no Diário Oficial da União - NIST, CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0, fevereiro de 2024: [doi.org](https://doi.org/10.6028/NIST.CSWP.29) - NIST, perguntas frequentes do Cybersecurity Framework: [nist.gov](https://www.nist.gov/cyberframework/faqs) - International Accreditation Forum, IAF CertSearch, base de validação de certificação acreditada: [iaf.nu](https://iaf.nu/en/home/)