Skip to main content

Indo além do “shift left” para ampliar a segurança de aplicações em todas as direções

Escrito por
feature datacenters black

9 de julho de 2024

0 minutos de leitura

Uma semana antes da RSA 2024, a Forrester previu quais assuntos e temas ganhariam destaque na conferência. A empresa ressaltou que veríamos um foco em segurança proativa, definida como “uma abordagem estratégica para controlar a postura de segurança e reduzir violações por meio de visibilidade, priorização e correção eficazes.” 

Fui à conferência com essa previsão em mente. No entanto, fiquei surpreso com o que encontrei. Infelizmente, ainda vi muitos fornecedores se concentrando apenas na visibilidade das vulnerabilidades, sem abordar os outros aspectos da segurança proativa mencionados pela Forrester na definição acima. 

No entanto, uma abordagem de segurança proativa é essencial para as equipes de segurança e desenvolvimento de hoje. Muitas dessas equipes já se sentem sobrecarregadas pela reatividade dos processos atuais e precisam lidar com pontos cegos em todo o SDLC.  As equipes de segurança acabam se concentrando nos problemas errados e deixando passar os mais críticos. Também podem atrapalhar os processos de desenvolvimento e, ao mesmo tempo, deixar brechas para riscos desconhecidos. Uma abordagem reativa também obriga os desenvolvedores a lidar com longas listas de alertas sem prioridade e medidas de segurança rígidas demais. O foco crescente do setor em aplicações e o maior uso de IA só vão agravar todos esses problemas. 

As equipes de hoje precisam de uma segurança proativa eficaz, que inclua priorização e correção eficientes, em vez de se concentrar apenas na visibilidade. Além disso, a própria visibilidade precisa ter o foco certo: no nível dos ativos, como as aplicações, e não apenas em uma visão agregada das vulnerabilidades.

Mas como nós, como setor, podemos ir além dessa abordagem focada apenas na visibilidade? Talvez seja preciso mudar nossa maneira de pensar sobre o que significa shift left. Não se trata apenas de antecipar a segurança em um fluxo unidimensional de desenvolvimento de software, mas de adotar uma abordagem multidirecional. Na RSA, comecei a pensar nesse conceito usando a metáfora de uma bússola. E se, em vez de nos concentrarmos em avançar para a esquerda, ampliássemos a segurança em todas as direções: norte, sul, leste, e oeste? 

Segurança de aplicações multidirecional

Ao ampliar a segurança de aplicações para todas essas direções metafóricas, podemos ter mais visibilidade e contexto de tudo o que acontece ao longo do SDLC. Veja como essa abordagem pode funcionar:

Norte

As equipes de segurança usam várias ferramentas de teste de segurança de aplicações (AST) em seus programas de AppSec, como testes estáticos de segurança de aplicações (SAST) e análise de composição de software (SCA). Em geral, elas dependem de uma solução de terceiros para agregar e analisar os dados de vulnerabilidades provenientes dessas ferramentas separadas e avaliar o sucesso do programa. 

No entanto, muitas ferramentas de agregação se concentram apenas na quantidade de vulnerabilidades e deixam de lado informações contextuais essenciais, como o contexto geral da aplicação e do negócio. Para entender o desempenho de seus programas de segurança de aplicações ao longo do tempo, as equipes precisam ir além das métricas tradicionais, como o número de vulnerabilidades e o tempo necessário para corrigi-las. Em vez disso, devem analisar métricas valiosas relacionadas aos problemas, à cobertura e aos ativos específicos do negócio. Olhar para o norte significa ter uma “visão panorâmica” da aplicação como um todo e de seu contexto, em vez de considerar cada vulnerabilidade um problema isolado.

Sul 

As equipes de desenvolvimento e segurança também precisam de mais contexto para cada alerta de segurança. Podemos pensar nisso como a direção “sul” da nossa abordagem multidirecional, pois significa aprofundar o contexto de segurança em cada etapa do desenvolvimento. As classificações tradicionais de risco, como o Common Vulnerability Scoring System (CVSS), não incluem todos os dados necessários para entender de fato o nível de risco que uma vulnerabilidade representa para a organização nem quem é responsável por corrigir os problemas mais urgentes. 

Em vez disso, as equipes precisam entender os seguintes fatores relacionados a cada alerta:

  • Qual é a criticidade para o negócio da aplicação que contém a vulnerabilidade?

  • Há outros fatores que influenciam a criticidade das vulnerabilidades (por exemplo, segurança da infraestrutura em nuvem que oferece proteção adicional para o código em questão etc.)?

  • Quem gerou o código em questão e está mais bem posicionado para corrigir os erros?

  • Que tipo de ativo contém a vulnerabilidade? Essa informação pode ajudar as equipes de desenvolvimento a identificar a melhor maneira de corrigir o problema.

Leste

Para ter uma visão melhor dos riscos, as organizações também precisam se concentrar na segurança em tempo de execução — a direção “leste” da nossa abordagem. Esse contexto ajuda as equipes de segurança a entender qual código a aplicação usa em tempo de execução e quais ativos representam pouco ou nenhum risco por não serem usados enquanto a aplicação está em execução. O contexto de execução ajuda as equipes a reduzir ainda mais a lista de vulnerabilidades, eliminando falsos positivos relacionados a vulnerabilidades que não ameaçam a aplicação em execução. 

Oeste (ou seja, esquerda)

Há algum tempo, o setor vem discutindo a abordagem shift left para a segurança. No entanto, esse compromisso de corrigir problemas no início do ciclo de desenvolvimento precisa evoluir junto com as mudanças nos processos de desenvolvimento. A definição de “esquerda” continuará evoluindo, e as equipes de segurança precisarão ajustar suas ferramentas e seus processos para acompanhar as práticas adotadas pelas equipes de desenvolvimento.

Por exemplo, hoje as equipes de segurança estão percebendo que precisam agir mais rápido, porque os desenvolvedores estão usando assistentes de código com IA para gerar código em uma velocidade sem precedentes. Para aplicar shift left de um jeito compatível com essas mudanças no desenvolvimento, muitas equipes de segurança usam ferramentas de segurança com IA para proteger essa rápida explosão de novos códigos sem desacelerar a inovação dos desenvolvedores.

A abordagem multidirecional de segurança da Snyk

Aqui na Snyk, criamos uma abordagem de segurança de aplicações que cobre as quatro direções. Essa estratégia multidirecional trouxe resultados positivos para nossos clientes, como o aumento da produtividade dos desenvolvedores e a redução geral dos riscos.

Nossa oferta mais recente de gerenciamento da postura de segurança de aplicações (ASPM), Snyk AppRisk Pro, traz recursos aprimorados de detecção e priorização de riscos, inteligência de execução avançada, integrações adicionais com plataformas de desenvolvimento, compatibilidade com ferramentas de detecção de segredos e recursos abrangentes de análise de dados. 

Saiba mais sobre o Snyk AppRisk Pro hoje.

Leia mais

AI Background min crop
Blog

A IA está acionando todos os riscos que você aceitou: sete insights do painel de segurança de IA sem filtros

A IA está tornando os ataques mais baratos e rápidos, expondo riscos que as organizações já carregam. Quatro líderes de segurança explicam por que a defesa na velocidade das máquinas e a correção mais rápida são essenciais.

blog feature ai violet
Blog

VulnBump: agentes de IA conseguem corrigir dependências vulneráveis sem quebrar o build?

O VulnBump testa agentes de IA em 307 atualizações reais de dependências. Uma correção só é considerada válida se eliminar a vulnerabilidade e mantiver o build e os testes passando.

blog feature snyk container custom base recommendations
Blog

Conheça o Evo Agentic AppSec: segurança que acompanha o ritmo do desenvolvimento com IA

O desenvolvimento impulsionado por IA está ultrapassando os fluxos de trabalho tradicionais de segurança. O Agentic AppSec da Snyk usa agentes de segurança para encontrar, corrigir e verificar vulnerabilidades continuamente, enquanto as pessoas definem os critérios.