BLOG

Melhorar a segurança ao ignorar vulnerabilidades

Miniatura de Lori MacVittie
Lori MacVittie
Publicado em 05 de novembro de 2018

De modo geral, a afirmação "ignorar vulnerabilidades" não é algo que você espera ouvir de uma empresa de segurança. Afinal, as vulnerabilidades são responsáveis por violações de tal magnitude que enchem nossos feeds por meses com comentários post-mortem, análises e recomendações.

E você certamente não vê "ignorar vulnerabilidades" emparelhado com a noção de "melhorar a segurança". 

Agora você tem - embora, como acontece com a maioria dos conselhos, eles venham com ressalvas e qualificações.

Você certamente não deve ignorar todas as vulnerabilidades, mas acontece que há uma classe de vulnerabilidades que você pode ignorar com segurança agora mesmo - ou pelo menos deixar de priorizar para um dia chuvoso. Eu me deparei com esse conceito enquanto lia o relatório State of Open Source Vulnerability Management de 2018 da WhiteSource Software .

Além de algumas estatísticas muito interessantes, o artigo apresenta a ideia de que as vulnerabilidades de código aberto podem ser agrupadas em duas categorias: ineficazes e eficazes.

A premissa da categorização do WhiteSource é que algumas vulnerabilidades são ineficazes, ou seja, não são exploráveis porque não são invocadas por código personalizado. Ser capaz de analisar e diferenciar, segundo a história, significa segurança e os desenvolvedores podem se concentrar nas vulnerabilidades consideradas eficazes e, assim, reduzir tempo e esforço, ao mesmo tempo em que melhoram a segurança geral do aplicativo.  

Por exemplo, considere um aplicativo personalizado que depende de um componente de código aberto que contém uma função vulnerável. De acordo com a definição da White Source, a função vulnerável neste exemplo pode ser declarada "ineficaz" porque nunca é invocada pelo aplicativo personalizado. Leitores atentos notarão que a função vulnerável pode ser invocada por uma função em um componente de código aberto (outro componente ou o mesmo) e, assim, torná-la efetiva. Quando perguntei à WhiteSource sobre essa possibilidade, eles expandiram sua categorização, observando que essa possibilidade é levada em consideração. Se o código vulnerável for invocado a partir de código personalizado ou indiretamente por meio de outro componente de código aberto, ele será rotulado como "efetivo". Por outro lado, se não houver nenhum caminho — direto ou indireto — que invoque a função vulnerável, ela é rotulada como "ineficaz".  

Considerando que a pesquisa da WhiteSource determinou não apenas que 96,8% dos desenvolvedores dependem de componentes de código aberto, mas que 7,5% de todos os projetos são vulneráveis, ser capaz de priorizar em quais vulnerabilidades focar certamente seria uma vantagem. A WhiteSource determinou ainda que impressionantes 64% dos produtos de código aberto continham apenas vulnerabilidades ineficazes , que eles afirmam que podem ser ignoradas com segurança.

Agora, embora eu não esteja convencido de que devemos simplesmente ignorar vulnerabilidades em qualquer código porque elas não são ativamente invocadas, vejo valor em usar tal distinção para priorizar o gerenciamento de vulnerabilidades. Ao se concentrar no código vulnerável que é ativamente invocado, desenvolvedores e profissionais de segurança podem melhorar imediatamente a segurança geral de um aplicativo. Isso faz melhor uso dos desenvolvedores seniores, que, segundo o relatório da White Source, gastam mais tempo, em média, abordando vulnerabilidades do que os desenvolvedores juniores.

Algum tipo de método de priorização precisa ser implementado. A WhiteSource declarou que houve quase 3.500 vulnerabilidades relatadas em 2017, um aumento de 60% em relação a 2016. Nem todas essas 3.500 vulnerabilidades relatadas afetam todos os aplicativos ou organizações, mas devemos lembrar que esses números são cumulativos. Ou seja, as 3500 são novas vulnerabilidades que são adicionadas a um total corrente.

Não é preciso dizer que há muitas vulnerabilidades no código, tanto personalizado quanto de código aberto. Ser capaz de priorizar a correção com base em se ela é "eficaz" ou "ineficaz" está alinhado com as estratégias de segurança emergentes que pontuam o risco com base na ameaça existencial, além de outros fatores. A ameaça existencial de uma vulnerabilidade ineficaz é quase inexistente. Dito isso, ignorar vulnerabilidades ineficazes pode não ser a melhor abordagem a longo prazo. É possível que, eventualmente, tais vulnerabilidades sejam efetivas. Alterações no código personalizado à medida que recursos são adicionados e/ou aprimorados, bem como alterações ao longo do tempo em componentes de código aberto, podem levar à abertura de um caminho que invoca uma função vulnerável. Esta é uma das razões pelas quais a análise do código-fonte especificamente para vulnerabilidades deve ocorrer continuamente, na melhor das hipóteses, e durante a compilação final, na pior.

Mas, no interesse de cumprir prazos e usar o tempo do desenvolvedor de forma eficiente, empurrar as vulnerabilidades "ineficazes" para o final da fila para que as vulnerabilidades "eficazes" possam ser corrigidas imediatamente pode ser uma das melhores maneiras pelas quais os desenvolvedores podem melhorar a segurança agora.