Vá além da alcançabilidade para priorizar o que realmente importa

A maioria dos aplicativos modernos contém uma quantidade significativa de pacotes, bibliotecas e frameworks de código aberto. Estima-se, na verdade, que pelo menos 80% do código-fonte dos aplicativos modernos seja de código aberto. Além de dependerem bastante de componentes prontos para criar aplicativos, as equipes de desenvolvimento costumam implantar esses aplicativos e serviços usando imagens-base de contêineres da comunidade. Também recorrem a recursos de terceiros como assistentes de programação com IA para gerar código próprio, acelerando ainda mais a cadeia de suprimentos de software. 

O uso cada vez maior de bibliotecas de código aberto, IA generativa e contêineres traz novas preocupações com licenciamento e segurança. Só em 2023, foram descobertas quase 29 mil novas vulnerabilidades (e, em 2024, esse número já passou de 28 mil). Se a história se repetir, mais da metade das vulnerabilidades recém-descobertas terá gravidade alta ou crítica. Em outras palavras, alguns dos maiores riscos para seus aplicativos — e potencialmente para toda a sua organização — vêm de componentes que não estão sob seu controle.

Os desafios atuais da segurança de código aberto

Encontrar, priorizar e corrigir todas as vulnerabilidades de código aberto nos seus aplicativos é inviável. Até mesmo tentar corrigir apenas as vulnerabilidades de alta gravidade nas dependências de terceiros pode ser um desafio. Afinal, você precisa lidar não só com as vulnerabilidades recém-descobertas, mas também com todo o acúmulo de vulnerabilidades na sua base de código. Esse acúmulo tem várias origens: talvez você tenha herdado essas vulnerabilidades ou elas estejam em um projeto implementado muito antes de você começar a procurar vulnerabilidades de código aberto.

Até mesmo projetos pequenos podem ter centenas de vulnerabilidades em dezenas de dependências diretas (ou seja, definidas explicitamente nos manifestos de dependências). É provável que também tenham ainda mais dependências indiretas ou “transitivas” — as bibliotecas necessárias para que as dependências diretas funcionem. Multiplique tudo isso pelo número de projetos da sua organização e a lista se torna enorme. 

Técnicas estáticas de priorização não são suficientes

Muitas empresas usam fatores de risco estáticos, como a gravidade NVD/CVSS, para começar a classificar essa longa lista de vulnerabilidades e priorizar quais corrigir primeiro. No entanto, essas avaliações pontuais de risco deixam de fora muitos fatores importantes para uma priorização precisa e eficaz. 

Fatores de risco mais recentes, como o EPSS (sistema de pontuação para previsão de exploração), tentam incorporar mais informações sobre a vulnerabilidade, mas ainda deixam de fora detalhes importantes, como o contexto mais amplo do aplicativo ou do negócio. Assim como outros fatores de risco estáticos, o EPSS mantém o foco restrito e isolado em problemas individuais, e não nos seus aplicativos. Cada problema avaliado pelo EPSS diz respeito a um CVE específico, e não ao que mais afeta toda a sua organização. 

Muitas empresas passaram a recorrer à análise de alcançabilidade para aprimorar suas técnicas estáticas de priorização e entender melhor quais vulnerabilidades devem ser corrigidas primeiro. A análise estática de alcançabilidade examina a definição da vulnerabilidade, obtém informações sobre onde ela existe em determinada versão de uma biblioteca e tenta determinar se há um caminho de chamada entre o seu código próprio e a função onde a vulnerabilidade provavelmente está. Assim, as equipes podem combinar diferentes sinais estáticos, como dados de alcançabilidade e uma pontuação CVSS ou EPSS alta, para decidir quais correções priorizar.

Embora a análise estática de alcançabilidade possa ajudar no processo de priorização, ela também pode deixar lacunas. Por exemplo, ela pode ajudar a identificar caminhos de código que chamam funções vulneráveis, mas o contrário não é válido: não é possível afirmar com certeza quando algo não é alcançável. Além disso, nem todas as vulnerabilidades incluem as informações necessárias para uma análise estática de alcançabilidade. Ainda assim, há técnicas para determinar quais funções são vulneráveis em pacotes de código aberto. Por exemplo, a Snyk usa uma solução com IA que analisa commits de correção para calculá-las. 

Em última análise, combinar a análise estática de alcançabilidade com CVSS/EPSS aprimora as técnicas de priorização. Mas é possível avançar ainda mais, incorporando um contexto essencial: a importância de cada artefato para o negócio. Por isso, além da alcançabilidade estática, as equipes precisam considerar fatores contextuais para priorizar vulnerabilidades com precisão, com base no risco real para o negócio.

As organizações precisam de uma abordagem holística para priorizar riscos

Um ponto importante sobre vulnerabilidades: gravidade crítica e alcançabilidade não significam que elas possam ser exploradas. 

Vamos analisar essa ideia: imagine que você tenha duas vulnerabilidades — uma vulnerabilidade crítica e “alcançável” em um ambiente interno de desenvolvimento isolado e outra de gravidade média, sem dados de alcançabilidade, em produção. Qual você deve corrigir primeiro? E se a vulnerabilidade de gravidade média em produção tiver uma exploração fácil e conhecida e estiver em um contêiner exposto à internet na borda da rede? Embora a vulnerabilidade de gravidade média pareça a escolha óbvia, apenas os sinais estáticos podem acabar classificando a vulnerabilidade do ambiente isolado como prioridade maior!

Com esse exemplo, fica claro que a análise estática de alcançabilidade muitas vezes não mostra o quadro completo. Embora ela ofereça informações para priorizar vulnerabilidades, não permite que as equipes gerenciem o risco como um todo. Corrigir um grande número de vulnerabilidades críticas pode parecer ótimo no papel, mas o impacto real está em remediar aquelas que representam o maior dano potencial para o seu negócio e seus resultados financeiros.

Veja outros sinais que ajudam a preencher as lacunas deixadas pela análise estática de alcançabilidade: 

• A vulnerabilidade se aplica ao sistema operacional em que o serviço está sendo executado?

• O aplicativo é crítico para o negócio? Qual função específica ele desempenha e como ela se relaciona com as principais atividades da empresa?

• Ele está implantado? Em caso afirmativo, onde? Está acessível publicamente ou exposto à internet? Os pacotes estão carregados?

• O serviço que contém a vulnerabilidade tem acesso a dados confidenciais?

Priorização contextual de riscos com a Snyk

Como as empresas não conseguem corrigir todas as vulnerabilidades de código aberto — nem mesmo todas as de gravidade alta ou crítica —, é fundamental priorizar os problemas de segurança corretamente. Na Snyk, ajudamos as organizações não só a encontrar e corrigir vulnerabilidades de software, mas também a priorizar a remediação com base no risco real para a empresa. Nossas soluções reforçam os processos de segurança de aplicativos das organizações com: 

• A priorização baseada em riscos permite que as organizações entendam com clareza a probabilidade de uma exploração e o impacto que ela teria.

• Alcançabilidade do código à nuvem, incluindo a análise estática de alcançabilidade, que analisa o código e as funções vulneráveis, e a alcançabilidade dinâmica, que examina o ambiente de implantação e execução do aplicativo. Nossa solução usa IA e é validada por especialistas humanos em segurança, o que aumenta a precisão e a cobertura.

• Contexto do aplicativo proveniente de SCMs, portais para desenvolvedores, CMDBs e outras fontes. Esse contexto detalhado permite que as empresas restrinjam ainda mais as vulnerabilidades a corrigir, considerando a responsabilidade pelo código, a atualização do repositório e outros fatores.

• Flexibilidade para empresas, com a possibilidade de integrar diretamente à solução Snyk diretrizes proprietárias de segurança e conformidade.

• Pontuação holística de risco, fácil de usar nos seus esforços de AppSec. Com essas pontuações, você pode priorizar problemas de SCA em todo o ambiente ou analisar em profundidade o impacto de fatores de risco específicos, incluindo a alcançabilidade estática.

Veja como o Snyk AppRisk funciona: assista à nossa demonstração sob demanda.