# Responsible Disclosure Responsible disclosure WordPress é a prática ética de reportar uma vulnerabilidade ao desenvolvedor responsável antes de torná-la pública, dando tempo para que ela seja corrigida sem expor os usuários a risco. É padrão da indústria de segurança e a base do trabalho de pesquisadores que descobrem falhas em plugins, temas e até no core do CMS. Sem essa coordenação, cada CVE viraria uma janela aberta para ataque imediato. ## O que é responsible disclosure O conceito é simples: quem encontra uma vulnerabilidade entra em contato direto com quem mantém o software, descreve o problema com detalhes técnicos suficientes para reprodução, combina um prazo de correção e só publica os detalhes depois que a correção foi disponibilizada para os usuários. É um pacto ético entre pesquisadores e fornecedores. O alvo principal é proteger o usuário final. Se um pesquisador publica os detalhes de uma falha antes da correção, expõe milhões de sites à exploração imediata. Se ele guarda a falha para sempre, ninguém aprende com o caso e o ecossistema não evolui. A divulgação responsável encontra o equilíbrio: corrige primeiro, divulga depois. O prazo padrão da indústria é de 90 dias, popularizado pelo Project Zero do Google. Contagem começa no envio inicial do relatório. Se o desenvolvedor não responder ou não corrigir no prazo, o pesquisador tem o direito de divulgar publicamente — pressionando a comunidade a tomar ações de mitigação. É a forma de evitar que falhas fiquem indefinidamente sem correção. O termo divulgação responsável aparece também como coordinated disclosure (CISA usa esse nome) ou ainda como vulnerability disclosure policy (VDP). São variações que apontam para a mesma prática: comunicação coordenada entre quem descobre e quem corrige, com cronograma definido. ## Por que é importante para WordPress WordPress roda em mais de 40% da web, e seu ecossistema tem dezenas de milhares de plugins ativos. Cada plugin é um vetor potencial de vulnerabilidade. Quando alguém descobre uma falha crítica em um plugin com 100 mil instalações, a divulgação imediata sem coordenação significa 100 mil sites expostos no mesmo dia. Pelo padrão de responsible disclosure, o pesquisador reporta primeiro ao autor do plugin. O autor publica uma versão corrigida no repositório oficial. O WordPress dispara atualizações automáticas para sites que tenham essa opção ligada. Só depois, o pesquisador publica os detalhes técnicos da falha — geralmente acompanhados de um identificador [CVE](https://full.services/glossario/cve/). Esse fluxo evita uma corrida desigual entre administradores de site (que precisam atualizar manualmente em alguns casos) e atacantes (que escaneiam a web em massa por sites vulneráveis). Sites bem configurados pegam a correção em horas; sites abandonados ficam expostos, mas pelo menos o caminho de defesa estava aberto. Empresas como WPScan, Wordfence e Patchstack mantêm programas formais de disclosure que coletam relatórios, validam, coordenam com os autores e publicam os CVEs depois da correção. São intermediários que profissionalizam o processo e dão respaldo aos pesquisadores que reportam. ## Como reportar uma vulnerabilidade O primeiro passo é encontrar o canal certo. Plugins maduros expõem um arquivo SECURITY.md no GitHub, uma página de security policy no site oficial ou um endereço de email dedicado (security@dominio). Use sempre esses canais. Mande o relatório por GitHub Issue público é o oposto de divulgação responsável. O relatório precisa ter conteúdo técnico suficiente. Inclua: descrição da falha, versão afetada, passo a passo de reprodução, prova de conceito (PoC) se aplicável, impacto potencial e sugestão de mitigação se você tiver. Quanto mais clara a evidência, mais rápido o autor consegue corrigir. Se o autor não responder em uma semana, é razoável escalar para um intermediário. WPScan aceita relatórios via wpscan.com/submit. Patchstack tem programa próprio. Wordfence Intelligence também. Esses serviços fazem a ponte e, em casos críticos, ajudam a coordenar bloqueio temporário no repositório oficial enquanto a correção sai. Para projetos comerciais ou sites grandes que querem incentivar pesquisadores, vale publicar uma política formal. A FULL Services, por exemplo, é uma [CNA](https://full.services/glossario/cna/) reconhecida — atribui CVEs aos plugins que mantém — e segue cronograma público de disclosure para vulnerabilidades reportadas. Esse padrão sinaliza que a empresa leva segurança a sério e respeita o trabalho de quem encontra falhas. ## Bug bounty e divulgação Bug bounty é a evolução comercial da divulgação responsável: o desenvolvedor oferece recompensa em dinheiro para quem reportar falhas dentro do programa. Plataformas como HackerOne, Bugcrowd e Intigriti centralizam programas de centenas de empresas, definindo escopo, regras de engajamento, valores por severidade e canal seguro de comunicação. No ecossistema WordPress, programas formais de bug bounty existem para o core via HackerOne (Automattic), para plugins enterprise como WooCommerce e para soluções comerciais. Pequenos plugins gratuitos raramente pagam bounty, mas reconhecem o pesquisador no changelog e no advisory público — capital de reputação que vale ouro em segurança ofensiva. Já a divulgação não-responsável (full disclosure imediato sem coordenação) é considerada irresponsável e pode resultar em ações legais em algumas jurisdições. O caminho profissional é sempre coordinated disclosure: tentar contato, esperar prazo, escalar via intermediário se necessário, e publicar só depois da correção. Quem joga assim conquista respeito da indústria e abre portas para programas pagos. Lidar com vulnerabilidade de plugin desatualizado em produção é um problema real para qualquer site WordPress sério. Para reduzir o risco antes do disclosure chegar, a FULL Services entrega o **AIOS** (All-In-One Security) já licenciado dentro da stack profissional, com firewall, monitoramento contínuo e bloqueio automático de tentativas conhecidas de exploração. Em vez de reagir só quando o CVE é publicado, você roda com camadas de defesa que ganham tempo para aplicar a correção sem comprometer o site. **Também conhecido como:** divulgação responsável, coordenação de divulgação ## Termos relacionados - [CVE](https://full.services/glossario/cve/) - [CNA (CVE Numbering Authority)](https://full.services/glossario/cna/) - [Vulnerabilidade WordPress](https://full.services/glossario/vulnerabilidade-wordpress/) - [CISA (Cybersecurity & Infrastructure Security Agency)](https://full.services/glossario/cisa/) --- Glossário WordPress da FULL Services: [Responsible Disclosure](https://full.services/glossario/responsible-disclosure/)