Security.txt: facilitando reporte de vulnerabilidades

1. O que é o Security.txt e por que ele importa para Devs?

O security.txt é um arquivo de texto padronizado pela RFC 9116 que fornece um canal oficial e direto para pesquisadores de segurança reportarem vulnerabilidades a uma organização. Para times de desenvolvimento, ele representa a diferença entre receber relatórios de bugs de segurança de forma organizada e centralizada versus depender de canais informais como redes sociais, e-mails de suporte ou formulários genéricos.

Benefícios diretos para Devs:

  • Redução de ruído: Pesquisadores sérios sabem onde reportar, evitando que issues de segurança se percam em tickets de suporte ou repositórios públicos.
  • Canal oficial: Cria um fluxo previsível e documentado para receber e triar vulnerabilidades.
  • Conformidade: Atende a requisitos de transparência e responsabilidade, especialmente em projetos open source.

Diferente de programas de bug bounty (que envolvem recompensas financeiras) ou contatos genéricos no rodapé do site, o security.txt é um padrão universalmente reconhecido por pesquisadores e ferramentas automatizadas.

2. Estrutura e campos obrigatórios do arquivo

O arquivo security.txt segue uma estrutura simples de pares chave-valor. Abaixo estão os campos principais:

Campos obrigatórios

Contact: mailto:security@exemplo.com
Expires: 2025-12-31T23:59:59Z
  • Contact: URI para reporte de vulnerabilidades. Pode ser e-mail (mailto:), URL de formulário (https://), ou até mesmo um contato via chat (xmpp:).
  • Expires: Data de validade no formato ISO 8601. Após essa data, o arquivo deve ser renovado. A ausência de renovação pode indicar que o canal não está mais ativo.

Campos opcionais recomendados

Encryption: https://exemplo.com/pgp-key.txt
Preferred-Languages: pt-BR, en
Policy: https://exemplo.com/security-policy.html
Acknowledgments: https://exemplo.com/hall-of-fame.html
  • Encryption: URL para chave PGP pública, permitindo comunicação criptografada.
  • Preferred-Languages: Lista de idiomas preferenciais para comunicação.
  • Policy: Link para a política de segurança da empresa (escopo, regras, contato).
  • Acknowledgments: Página de reconhecimento público para pesquisadores que reportaram vulnerabilidades.

3. Implementação prática: onde e como hospedar

Localização padrão

O arquivo deve ser acessível em dois locais:

  1. /.well-known/security.txt (recomendado pela RFC)
  2. /security.txt (redirecionamento ou cópia)

Exemplo de arquivo funcional

# Security.txt para Exemplo.com
# Contato para reporte de vulnerabilidades

Contact: mailto:security@exemplo.com
Expires: 2025-12-31T23:59:59Z
Encryption: https://exemplo.com/.well-known/pgp-key.txt
Preferred-Languages: pt-BR, en
Policy: https://exemplo.com/security-policy.html
Acknowledgments: https://exemplo.com/security-hall-of-fame

Configuração de servidor Nginx

# Nginx: Servir security.txt no local correto
location /.well-known/security.txt {
    alias /var/www/security.txt;
    default_type text/plain;
    add_header Cache-Control "no-store";
    add_header X-Content-Type-Options "nosniff";
}

location = /security.txt {
    return 301 /.well-known/security.txt;
}

Configuração de servidor Apache

# Apache: Servir security.txt com headers de segurança
<Files "security.txt">
    Header set Cache-Control "no-store"
    Header set X-Content-Type-Options "nosniff"
</Files>
Redirect 301 /.well-known/security.txt /security.txt

Validação

Ferramentas como securitytxt.org permitem testar se seu arquivo está acessível e formatado corretamente.

4. Integração com o fluxo de desenvolvimento

Automatizando a geração via CI/CD (GitHub Actions)

# .github/workflows/generate-security-txt.yml
name: Generate Security.txt

on:
  schedule:
    - cron: '0 0 1 * *'  # Executa no primeiro dia de cada mês
  workflow_dispatch:

jobs:
  generate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate security.txt
        run: |
          cat > public/.well-known/security.txt << EOF
          Contact: mailto:security@exemplo.com
          Expires: $(date -d "+1 year" +%Y-%m-%dT23:59:59Z)
          Encryption: https://exemplo.com/.well-known/pgp-key.txt
          Preferred-Languages: pt-BR, en
          Policy: https://exemplo.com/security-policy.html
          EOF

      - name: Commit and push
        run: |
          git config user.name "Security Bot"
          git config user.email "security-bot@exemplo.com"
          git add public/.well-known/security.txt
          git commit -m "Update security.txt expiration date"
          git push

Versionamento no git

Mantenha o security.txt no repositório principal, junto ao código. Isso garante rastreabilidade e facilita revisões de pull request.

5. Boas práticas de segurança ao expor contato

Riscos de expor e-mails diretamente

  • Spam: Endereços de e-mail públicos são rapidamente coletados por bots.
  • Engenharia social: Atacantes podem usar o contato para fingir ser pesquisadores legítimos.
  • DDoS: Formulários sem proteção podem ser abusados para sobrecarregar sistemas.

Mitigações recomendadas

# Exemplo de formulário seguro com CAPTCHA
Contact: https://exemplo.com/reportar-vulnerabilidade
  • Use aliases descartáveis: Crie endereços específicos para security.txt com rate limiting no servidor de e-mail.
  • Implemente CAPTCHA: Em formulários web, adicione validação para evitar abuso automatizado.
  • Valide remetentes: Exija autenticação do pesquisador (ex.: e-mail verificado, chave PGP conhecida).
  • Limite requisições: Configure rate limiting no endpoint de contato (ex.: 10 requisições por minuto por IP).

6. Casos de uso reais e lições aprendidas

Exemplos de adoção

  • Google: Utiliza https://google.com/.well-known/security.txt com contato via formulário e política detalhada.
  • Mozilla: Mantém arquivo em https://mozilla.org/.well-known/security.txt com chave PGP e lista de idiomas.
  • GitHub: Em https://github.com/.well-known/security.txt, redireciona para o programa de bug bounty no HackerOne.

Como o arquivo acelerou a triagem de bugs críticos

Em 2022, um pesquisador reportou uma vulnerabilidade crítica no sistema de autenticação de uma fintech brasileira através do security.txt. O contato direto evitou que o bug fosse exposto em fóruns públicos, permitindo correção em 48 horas.

Erros comuns

  • Expiração vencida: Arquivos com data expirada são ignorados por pesquisadores e ferramentas.
  • Contato quebrado: Links mortos ou e-mails que retornam erro.
  • Múltiplos endpoints: Contatos diferentes em /.well-known/security.txt e /security.txt causam confusão.

7. Manutenção contínua e monitoramento

Checklist periódico (recomendado a cada 3 meses)

  • [ ] Validar que o link de contato está funcionando
  • [ ] Renovar a data de expiração (máximo 1 ano)
  • [ ] Atualizar chave PGP se necessário
  • [ ] Revisar política de segurança vinculada
  • [ ] Testar acessibilidade via ferramentas de validação

Ferramentas de monitoramento

  • SecurityTrails: Monitora security.txt de domínios e alerta sobre mudanças.
  • Shodan: Indexa arquivos security.txt públicos.
  • HackerOne: Plataforma de bug bounty que respeita o security.txt como canal oficial.

Lidando com mudanças

Quando houver mudanças de equipe ou ferramentas de reporte:

  1. Atualize o campo Contact imediatamente.
  2. Mantenha o contato antigo ativo por pelo menos 30 dias (com redirecionamento).
  3. Comunique a mudança em listas de segurança e fóruns relevantes.

Referências