As equipas de TI precisam de priorizar melhor os esforços de correção de software

As equipas de Cibersegurança precisam de fazer um melhor trabalho na priorização das vulnerabilidades que querem que os desenvolvedores de aplicações corrijam. Uma sondagem global de 1.224 profissionais de segurança, desenvolvimento e operações de TI, publicada hoje pela JFrog, um fornecedor de uma plataforma de integração contínua/entrega contínua (CI/CD) para criação de software, revela que 60% dos inquiridos normalmente passam apenas quatro dias ou mais a remediar vulnerabilidades de aplicações num determinado mês.

O problema é que a maior parte desse tempo é, provavelmente, gasto a remediar vulnerabilidades que ou não estão incluídas nas bibliotecas de software que estão realmente a ser executadas, ou a própria aplicação nunca se conecta à internet. Mais preocupante ainda, após analisar 212 vulnerabilidades, os investigadores de segurança da JFrog reduziram a gravidade de 85% das vulnerabilidades classificadas como críticas e 73% das classificadas como altas.

Os mesmos investigadores também descobriram que 74% das vulnerabilidades e exposições comuns (CVEs) relatadas com pontuações elevadas e críticas no Common Vulnerability Scoring System (CVSS) atribuídas às 100 principais imagens da comunidade Docker Hub não eram exploráveis.

Sobrecarga de relatórios de vulnerabilidade

Um dos segredos bem guardados da TI é que os desenvolvedores de aplicações tendem a não levar muito a sério os relatórios de vulnerabilidade gerados pelas equipas de cibersegurança. As equipas de cibersegurança têm partilhado longas listas de vulnerabilidades com as equipas de desenvolvimento de aplicações há anos, mas muitas dessas equipas descobrem que, quando investigam esses alertas, frequentemente é mais um caso de uma equipa de cibersegurança a dar o alarme quando não há motivo.

É claro que, inevitavelmente, haverá uma situação em que uma equipa de desenvolvimento ignorará um alerta que se revelará catastrófico. Se as equipas de cibersegurança quiserem garantir que os seus alertas não estão a ser ignorados, precisam de perceber que as equipas de desenvolvimento de aplicações não têm uma quantidade infinita de tempo disponível para construir e implementar patches de software. Elas ainda precisam de escrever novo código, independentemente do número de vulnerabilidades que uma equipa de cibersegurança pense ter descoberto. O mais crítico para qualquer equipa de cibersegurança é garantir que dão prioridade aos pedidos de patches com base não apenas na gravidade de uma vulnerabilidade, mas também no grau em que ela é realmente explorável.

Scans de código inconsistentes

Alcançar esse objetivo, naturalmente, significa trabalhar de forma mais colaborativa com as equipas de desenvolvimento de aplicações no contexto de um fluxo de trabalho de DevSecOps para analisar o código tanto antes quanto depois de uma aplicação ser implementada. De facto, o inquérito JFrog observa que as análises de código são frequentemente aplicadas de forma inconsistente de uma organização para outra. Um total de 42% disse que é melhor realizar análises de segurança à medida que o código está a ser escrito, em comparação com 41% que preferem realizar análises em novos pacotes de software antes de os instalar. Um total de 41% dos inquiridos disse que o tempo de execução é o local menos desejável para executar análises. Mais de metade (56%) afirmou que a sua organização aplica análises de segurança tanto ao nível do código quanto ao nível de análise binária.

Existem, é claro, muitos patches para, por exemplo, sistemas operativos que uma equipa de cibersegurança deve ser capaz de aplicar por si mesma sem quebrar quaisquer aplicações. Se a aplicação falhar, reverter esse patch deve ser relativamente simples. No entanto, corrigir aplicações é uma questão completamente diferente. As equipas de cibersegurança que tentam corrigir uma aplicação personalizada estão a assumir a responsabilidade por uma tarefa que provavelmente terminará mal.

É claro que pode chegar um dia em que não haverá mais vulnerabilidades no software, mas enquanto o software for escrito por humanos ou gerado por máquinas que foram treinadas utilizando software escrito por humanos, haverá sempre vulnerabilidades conhecidas e desconhecidas que precisarão ser abordadas cuidadosamente.