Você sabe que as suas aplicações não vivem numa bolha. Elas são compostas por pacotes de código aberto, contentores, recursos geridos na nuvem, VMs, APIs e muito mais. Cada parte tem a sua própria área de segurança e o seu próprio scanner: análise estática de código (SAST) verificam vulnerabilidades no código-fonte, ferramentasanálise de composição de software SCA) verificam dependências, segurança na nuvem monitorizam configurações e container procuram exploits conhecidos em imagens.
Então, depois de ter todos esses scanners instalados... está seguro, certo?
Mais ou menos. Está definitivamente a analisar cada camada.
Mas a que custo?
Por que os scanners de segurança o sobrecarregam com falsos positivos
Um scanner pode alertá-lo sobre uma função vulnerável no seu código, sem saber que ela está protegida por uma API upstream. Ou pode detectar um perigo relacionado a um CVE em uma camada container , sem saber que a sua aplicação real nunca chega a esse caminho de código. Da mesma forma, um scanner na nuvem pode sinalizar uma função IAM que excede as suas permissões, sem perceber que ela está vinculada apenas a uma carga de trabalho de teste que não pode aceder aos dados de produção.
O resultado? As suas equipas ficam inundadas com uma tonelada de descobertas isoladas. Sim, todas elas são tecnicamente precisas, mas vêm com pouco contexto para determinar se o problema é realmente perigoso.
Ou, como disse recentemente um engenheiro de segurança de uma grande empresa:«Consegue dizer se uma vulnerabilidade afeta os meus bens mais valiosos ou o menu virtual do almoço?»
Embora os falsos positivos e falsos negativos isolados sejam um risco, o risco maior é perder cadeias de dependências que determinam se problemas aparentemente inofensivos se combinam em caminhos de exploração reais — ou se muitos problemas aparentemente prejudiciais não são, na verdade, um problema.
E ouvimos isso das equipas constantemente:
«Não controlamos as nossas dependências.»
O motivo? É muito difícil gerir a cadeia de abastecimento; os pacotes de código aberto trazem consigo dependências indiretas. Mesmo com ferramentas container ou nativas da nuvem, a maioria das organizações não consegue determinar com segurança o que é importante. Como resultado, acabam por perseguir vulnerabilidades de forma reativa.
Por que o contexto da vulnerabilidade é importante na segurança de aplicações e Cloud
O típico SAST ou SCA têm uma visão muito simplista e literal.
Por exemplo, quando ele vê que um pacote está listado num CVE, ele o marca como crítico.
Isso parece ser a melhor prática no papel; afinal, é melhor ser avesso ao risco, seria de se esperar. Mas, na realidade, isso apenas dispara falsos alarmes porque:
- Muitas vezes, a sua aplicação nem sequer está a chamar a função vulnerável.
- A função pode estar enterrada dentro de uma dependência transitiva que você nunca tocou diretamente.
- Ou está por trás de uma importação destinada apenas aos desenvolvedores, que nunca chega à produção.
Assim, as equipas recebem uma lista excessivamente detalhada de problemas «críticos» e têm de passar horas a investigá-los, apenas para perceber que nem sequer são críticos.
Ao mesmo tempo, os caminhos reais que poderiam ser explorados podem passar despercebidos.
Criando um gráfico de dependências completo entre código, contentores e Cloud
A razão pela qual muitos scanners apresentam resultados ruidosos ou incompletos é que eles não têm o contexto adicional necessário para fornecer clareza. As ferramentas tradicionais tratam cada camada — código-fonte, pacotes de código aberto, contentores, recursos de nuvem — como problemas separados, muitas vezes tratados por produtos separados.
Isso significa que falta um único gráfico de dependências que una todos eles. Não há visibilidade das dependências cruzadas. Isso significa que você será notificado sobre problemas não críticos e poderá perder os problemas que realmente importam.
Mas a visibilidade não se resume apenas ao contexto; trata-se também de consistência. Todos os gestores de pacotes lidam com vulnerabilidades transitivas de maneiras diferentes.
Por exemplo:
- O npm/yarn em JavaScript oferece árvores de dependências e permite substituir/fixar pacotes aninhados.
- O Maven em Java pode puxar versões inesperadas de bibliotecas, exigindo configurações adicionais para manter pacotes transitivos arriscados fora.
Sem um gráfico unificado, as equipas acabam por adicionar mais ferramentas apenas para controlar o que enviaram.
Alguns engenheiros pensam: «se não o instalamos diretamente, não nos pode prejudicar», o que agrava o problema. As vulnerabilidades existem em várias camadas.
Então, o que as equipas devem fazer?
Use Reachability Analysis eliminar falsos alarmes em dependências
reachability analysis verdadeira reachability analysis significar que, em vez de apenas sinalizar «tem um pacote vulnerável no gráfico», a sua plataforma pode descobrir se o seu código está:
- Chamar realmente a função vulnerável, ou
- Envolvido numa falha exposta à entrada do utilizador, ou
- Executando em um container acessível pela Internet
Se a resposta a todas estas perguntas for não, então ignora-a. Se for sim, então escalona.
Também é importante filtrar vulnerabilidades transitivas por trás de dependências de desenvolvedores ou pacotes de teste que nunca chegam à produção. Isso pode reduzir muito o ruído, o que significa menos falsos positivos e mais tempo para os desenvolvedores se concentrarem na criação de software.
A maioria dos scanners pode verificar se um pacote está listado num CVE. Mas muito poucos conseguem rastrear se o seu código real chama a função vulnerável, se está incluído num container à Internet e se é executado num recurso de nuvem com IAM arriscado — tudo numa única visualização.
Correlacionando vulnerabilidades entre códigos, contentores e Cloud
Esta é a grande questão. Compreender o que está a acontecer em todos os lugares é fundamental para poupar muito tempo à sua equipa e reduzir as hipóteses de ser apanhado de surpresa.
Isso significa estender esse gráfico de dependências além do nível do pacote para contentores,infraestrutura como código, configurações de nuvem — e sobrepor a acessibilidade entre eles.
Por exemplo, poderia perguntar:
- Esta vulnerabilidade afeta as suas dependências? Sim
- É realmente chamado pela sua aplicação? Não
- Está incluído num container implementado container entrada pública? Não
→ Ignorar - Esta vulnerabilidade requer que uma porta específica esteja aberta? Sim
- A vulnerabilidade está presente numa máquina virtual na nuvem? Sim
- A porta necessária está aberta na VM? Não
→ Ignorar
remediação automatizada: corrigindo vulnerabilidades reais mais rapidamente
Uma vez confirmada como uma vulnerabilidade real e acessível, o cenário ideal é determinar a atualização mínima segura e corrigi-la automaticamente.
Algumas ferramentas podem:
- Descubra automaticamente a atualização mínima segura
- Verifique se isso não violará suas restrições semver.
- Corrija automaticamente sem introduzir regressões
Isso significa que não é necessário procurar dependências manualmente e muito menos noites sem dormir.
Gerencie dependências como parte de uma estratégia de segurança unificada
Ao reunir o seu código, contentores e configurações de nuvem num único gráfico, reduz o ruído e vê o que está realmente exposto. Sem perseguir falsos alarmes.
E quando há um problema real, ele não é apenas sinalizado — ele é corrigido. Assim, a sua equipa gasta menos tempo a analisar alertas inúteis e mais tempo a trabalhar.
Veja como Aikido as dependências de desenvolvimento para CVEs nos nossos documentos. Confira gerenciamento de vulnerabilidades nosso gerenciamento de vulnerabilidades tudo-em-um aqui.
Proteja seu software agora
.avif)
