Aprimorando a segurança ao ignorar vulnerabilidades

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

De modo geral, a afirmação "ignore as vulnerabilidades" não é algo que se espera ouvir de uma empresa de segurança. Afinal, as vulnerabilidades são responsáveis por violações de tamanha magnitude que, durante meses, nossos feeds ficam repletos de comentários, análises e recomendações pós-incidente.

E certamente não se vê "ignorar vulnerabilidades" associado à ideia de "melhorar a segurança".

Agora você já viu — embora, como acontece com a maioria dos conselhos, haja ressalvas e condições.

Você certamente não deve ignorar todas as vulnerabilidades, mas há uma categoria de vulnerabilidades que você pode ignorar com segurança por enquanto — ou, pelo menos, deixar em segundo plano para tratar mais tarde. Deparei-me com esse conceito ao ler o relatório Estado do Gerenciamento de Vulnerabilidades de Código Aberto em 2018 da WhiteSource Software.

Além de apresentar algumas estatísticas muito interessantes, o estudo propõe que as vulnerabilidades de código aberto podem ser agrupadas em duas categorias: ineficazes e eficazes.

A premissa da categorização da WhiteSource é que algumas vulnerabilidades são ineficazes — ou seja, não podem ser exploradas porque não são acionadas por código personalizado. Segundo essa linha de raciocínio, a capacidade de analisá-las e diferenciá-las permite que as equipes de segurança e os desenvolvedores se concentrem nas vulnerabilidades consideradas eficazes, reduzindo tempo e esforço e, ao mesmo tempo, melhorando a segurança geral da aplicação.

Por exemplo, considere uma aplicação personalizada que depende de um componente de código aberto que contém uma função vulnerável. Segundo a definição da White Source, a função vulnerável deste exemplo poderia ser considerada "ineficaz" porque nunca é chamada pela aplicação personalizada. Leitores atentos perceberão que a função vulnerável poderia ser chamada por uma função em um componente de código aberto (seja outro componente ou o mesmo), tornando-a, assim, eficaz. Quando perguntei à WhiteSource sobre essa possibilidade, eles explicaram melhor sua categorização, observando que essa possibilidade é levada em consideração. Se o código vulnerável for chamado pelo código personalizado ou indiretamente por meio de outro componente de código aberto, ele será classificado como "eficaz". Por outro lado, se não houver nenhum caminho — direto ou indireto — que chame a função vulnerável, ele será classificado como "ineficaz".

Considerando que a pesquisa da WhiteSource constatou não apenas que 96,8% dos desenvolvedores utilizam componentes de código aberto, mas também que 7,5% de todos os projetos estão vulneráveis, poder priorizar as vulnerabilidades que merecem atenção certamente seria uma grande vantagem. A WhiteSource também constatou que impressionantes 64% dos produtos de código aberto continham apenas vulnerabilidades ineficazes, que, segundo a empresa, podem ser ignoradas com segurança.

Embora eu não esteja convencido de que devamos simplesmente ignorar vulnerabilidades em qualquer código só porque elas não são acionadas ativamente, reconheço o valor de usar essa distinção para priorizar o gerenciamento de vulnerabilidades. Ao se concentrarem no código vulnerável que é acionado ativamente, desenvolvedores e profissionais de segurança podem melhorar imediatamente a segurança geral de uma aplicação. Isso permite aproveitar melhor os desenvolvedores seniores, que, segundo o relatório da White Source, dedicam, em média, mais tempo à correção de vulnerabilidades do que os desenvolvedores juniores.

É necessário adotar algum tipo de método de priorização. A WhiteSource afirmou 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 3.500 são vulnerabilidades novas que se somam a um total acumulado.

Nem é preciso dizer que há muitas vulnerabilidades no código, tanto personalizado quanto de código aberto. A capacidade de priorizar a correção com base no fato de elas serem "efetivas" ou "inefetivas" está alinhada às estratégias de segurança emergentes que avaliam o risco com base na ameaça existencial, além de outros fatores. A ameaça existencial de uma vulnerabilidade inefetiva é praticamente inexistente. Ainda assim, ignorar vulnerabilidades inefetivas pode não ser a melhor abordagem a longo prazo. É possível que, com o tempo, essas vulnerabilidades se tornem efetivas. Alterações no código personalizado à medida que funcionalidades são adicionadas e/ou aprimoradas, bem como mudanças nos componentes de código aberto ao longo do tempo, podem abrir um caminho que acione uma função vulnerável. Esse é um dos motivos pelos quais a análise do código-fonte especificamente em busca de vulnerabilidades deve ser realizada continuamente, na melhor das hipóteses, ou durante a compilação final, na pior delas.

Mas, para cumprir os prazos e aproveitar o tempo dos desenvolvedores de forma eficiente, deixar as vulnerabilidades "ineficazes" para o fim da fila, de modo que as vulnerabilidades "eficazes" possam ser corrigidas imediatamente, talvez seja uma das melhores maneiras de os desenvolvedores aprimorarem a segurança neste momento.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie