Skip to main content

Entenda a divulgação responsável

Escrito por
Headshot of Tim Kadlec

Tim Kadlec

31 de janeiro de 2017

0 minutos de leitura

Combater vulnerabilidades de segurança é uma luta constante. É uma corrida entre quem ataca e as organizações que tentam impedir os ataques. Infelizmente, as organizações perdem com frequência. Como disse o ex-diretor do FBI, Robert Mueller: “...há apenas dois tipos de empresas: as que já foram invadidas e as que ainda serão.”

Para defender seu sistema, você precisa proteger o aplicativo inteiro. Já um invasor precisa encontrar apenas uma brecha. As organizações precisam sair na frente, e a forma como descobrem vulnerabilidades de segurança no código tem um papel importante nisso.

À primeira vista, a questão parece simples. Se você encontrar um problema de segurança, entre em contato com a organização e avise. Ela corrige o problema, e todos podem seguir em frente, mais tranquilos e seguros. Mas a realidade é que a divulgação de vulnerabilidades há muito tempo é um dos temas mais debatidos na área de segurança.

Reduzindo o período de exposição

Bruce Schneier popularizou a ideia da “janela de exposição”: o período em que uma vulnerabilidade está sujeita a exploração.

A janela de exposição começa no momento em que uma vulnerabilidade chega a um ambiente de produção. Nesse ponto, o risco de ataque é relativamente baixo. A vulnerabilidade existe, mas ainda não foi descoberta por ninguém.

Assim que alguém descobre a vulnerabilidade, o risco aumenta. A partir daí, ele continua crescendo à medida que a vulnerabilidade se torna mais conhecida. Em algum momento, uma correção ou atualização é lançada. Então, o risco começa a diminuir lentamente, conforme as pessoas instalam a correção — algo que raramente acontece rápido.

Schneier costuma usar um gráfico para visualizar o nível de risco. A área sob a curva representa a janela de exposição. Portanto, o objetivo é reduzir essa janela.

O risco aumenta após a divulgação de uma vulnerabilidade, atinge o pico antes da correção e diminui quando os usuários começam a aplicar os patches.

O debate gira em torno de qual é a melhor forma de fazer isso.

Se uma vulnerabilidade cai na floresta e ninguém a explora, ela existia?

Um dos argumentos é que, ao descobrir uma vulnerabilidade, você deve comunicá-la à organização e nunca torná-la pública. Segundo essa linha de pensamento, assim a vulnerabilidade permanece com segurança na fase menos conhecida do seu ciclo de vida, o que reduz o risco.

Essa forma de pensar tem algumas falhas. Primeiro, parte da perigosa suposição de que só uma pessoa bem-intencionada encontrou o problema. Se pessoas mal-intencionadas também o identificaram, não vão ficar esperando a organização perceber que há um problema: vão aproveitar o acesso a uma vulnerabilidade sem correção.

Outra falha dessa abordagem é presumir que a empresa se importa o suficiente com a vulnerabilidade para tomar providências. Na realidade, há um problema de incentivo. No início, essa era a forma mais comum de divulgar vulnerabilidades. Em muitos casos, isso levou organizações a levar anos para corrigir uma vulnerabilidade, acreditando que, por não ter sido divulgada, ela lhes proporcionava algum nível de segurança. Em essência, a ignorância como camada de segurança.

Em alguns casos, com medo da má repercussão que certos problemas de segurança poderiam gerar, as organizações chegavam a ameaçar a pessoa pesquisadora que tentava reportá-los. Infelizmente, isso ainda acontece de vez em quando. Por isso, algumas pessoas pesquisadoras preferem fazer a divulgação a uma organização ou pessoa que depois a comunicará à empresa. É algo que estamos dispostos a fazer — e já fizemos — aqui na Snyk. Isso ajuda a proteger a própria pessoa pesquisadora de um proprietário ou organização excessivamente agressivos.

Divulgação pública completa

No extremo oposto está a ideia de divulgação pública completa. Em vez de comunicar a vulnerabilidade à organização, a pessoa pesquisadora poderia divulgar todas as informações publicamente. A vulnerabilidade passa direto pela lenta fase de ganhar notoriedade e salta para o conhecimento geral. A partir daí, começa uma corrida entre a organização e quem ataca.

Essa abordagem cria um incentivo evidente para que a organização resolva o problema rapidamente. Mas a falha também é evidente: a mesma publicidade que gera esse incentivo coloca as organizações — e seus usuários — em risco significativo, pois quem ataca fica sabendo imediatamente da vulnerabilidade e de como explorá-la.

Divulgação responsável

Em algum ponto intermediário está a abordagem adotada pela maior parte do setor, chamada divulgação responsável. Ela envolve algumas etapas básicas.

  1. A vulnerabilidade é comunicada em particular ao proprietário ou à organização.

  2. Uma correção para a vulnerabilidade é criada, normalmente pelo proprietário ou pela organização (embora quem reportou muitas vezes ajude).

  3. A correção é publicada e distribuída aos usuários.

  4. A vulnerabilidade é divulgada publicamente. A divulgação inclui informações sobre a vulnerabilidade, como explorá-la e como corrigir o problema.

Isso pode parecer semelhante à ideia de manter vulnerabilidades em segredo, mas há uma diferença importante: a divulgação responsável geralmente estabelece um prazo razoável.

Por exemplo, aqui na Snyk, inicialmente damos ao proprietário de um pacote 30 dias para responder à nossa comunicação — um prazo bastante comum no desenvolvimento de código aberto, em que as pessoas responsáveis pelos projetos costumam ter outro emprego. Em alguns casos, o proprietário responde e, então, podemos indicar caminhos para uma correção e trabalhar com ele para definir um prazo razoável para divulgar a vulnerabilidade publicamente, permitindo que as pessoas tomem medidas para se proteger.

Em um mundo perfeito, toda divulgação de vulnerabilidade seguiria esse processo. Mas a realidade é um pouco diferente, e às vezes o proprietário não responde. Seguir a divulgação responsável significa que, se uma organização não responder dentro do prazo estabelecido, a pessoa que reportou pode optar por tornar a vulnerabilidade pública. Assim, os usuários ficam cientes do risco e podem decidir se querem aceitá-lo em seus próprios sistemas. Isso também incentiva proprietários e organizações a priorizar a resolução do problema, já que ele agora é de conhecimento público.

Na Snyk, fazemos o possível para dar às pessoas proprietárias ou às organizações uma vantagem inicial. Se não recebermos resposta em até 30 dias, entramos em contato novamente e concedemos mais 10 dias. Se ainda não houver resposta, repetimos o processo mais uma vez. Ao todo, damos 50 dias úteis para responder. Só divulgamos publicamente se não houver resposta nesse período ou se o proprietário disser que não quer coordenar a divulgação.

Há uma exceção importante nesse processo. Nossos clientes corporativos recebem notificações antecipadas sobre a vulnerabilidade sob um acordo de confidencialidade (NDA), que garante que ela ainda não será divulgada publicamente.

A ética da divulgação

Em 2016, uma empresa de segurança cibernética descobriu vulnerabilidades em equipamentos da St. Jude Medical (marca-passos, desfibriladores etc.). Em vez de seguir um processo de divulgação responsável, a empresa publicou dados incompletos sobre as vulnerabilidades e, em seguida, firmou uma parceria com outra organização para vender a descoberto ações da St. Jude Medical.

O caso reacendeu com força o debate sobre divulgação responsável. O CEO da empresa argumentou que, devido às experiências anteriores com a St. Jude, não acreditava que essa abordagem seria prática.

Mesmo deixando de lado a ética questionável de vender ações a descoberto após publicar dados incompletos, os danos dessa abordagem são significativos. Os dados incompletos prejudicam a reputação da St. Jude sem ajudar a empresa a resolver os problemas em questão. Em vez disso, deixam a St. Jude e quem ataca em condições iguais: ambos sabem que existe um problema e correm para descobrir quem vai encontrá-lo primeiro. Nunca saberemos se a St. Jude teria respondido em um prazo razoável — ela nem sequer teve essa opção.

A segurança é uma área interessante: para trabalhar bem nela, é preciso desconfiar até certo ponto das pessoas que terão acesso aos seus servidores e aplicativos. Por isso, é ainda mais importante agir com confiança e ética ao trabalhar para melhorar a segurança na internet.

É fundamental divulgar vulnerabilidades de maneira ética e responsável, causando o menor dano possível à organização ou ao proprietário e, ao mesmo tempo, protegendo os usuários. Acreditamos firmemente que um processo de divulgação responsável oferece o equilíbrio certo. Ele dá às organizações uma vantagem inicial: elas são informadas da vulnerabilidade em particular e têm tempo para resolvê-la antes que a janela de risco se amplie demais.

E isso é feito sem colocar os usuários em risco. Se uma organização não priorizar a vulnerabilidade ou não responder, o problema não será varrido para debaixo do tapete: ele poderá ser divulgado publicamente para que usuários desavisados tomem conhecimento e adotem as medidas adequadas.

A segurança é importante demais para ser varrida para debaixo do tapete, e há muito a aprender com as vulnerabilidades para deixar isso acontecer. Mas as organizações merecem a chance de corrigir essas vulnerabilidades antes que sejam divulgadas publicamente. Trabalhar com segurança já é desafiador o suficiente, sem dar uma vantagem desnecessária a quem ataca.

Se você quiser saber mais sobre como lidamos com a divulgação de vulnerabilidades na Snyk, nossa política completa está disponível online. Se você descobrir uma vulnerabilidade e quiser nossa ajuda para divulgá-la, também teremos prazer em ajudar.

Leia mais

blog feature ai lilac
Blog

Transforme seu backlog de vulnerabilidades em pull requests com remediação agentiva

O Evo Remediation Agent está em Open Preview e traz a resolução automatizada de dependências para o Evo Agentic AppSec. Agora, as equipes de AppSec podem executar campanhas contínuas de remediação

illustration hero ai
Blog

PHP corrige duas vulnerabilidades críticas de RCE sem autenticação (CVE-2026-109618, CVE-2026-109619): atualize agora

Duas falhas críticas no ciclo de requisições do PHP podem permitir execução remota de código sem autenticação. Atualize para uma versão corrigida ou instale um backport do fornecedor para versões mais antigas.

AI Background min crop
Blog

A IA está acionando todos os riscos que você aceitou: sete insights do painel de segurança de IA sem filtros

A IA está tornando os ataques mais baratos e rápidos, expondo riscos que as organizações já carregam. Quatro líderes de segurança explicam por que a defesa na velocidade das máquinas e a correção mais rápida são essenciais.