As equipes que mudam a segurança para a esquerda e se concentram na capacidade de ataque enviam um código mais seguro

Views: 118
0 0
Read Time:2 Minute, 54 Second

ShiftLeft divulgou seu segundo Relatório Anual de Progresso do AppSec, documentando tendências críticas na segurança de aplicativos e como as organizações estão mudando a segurança para lidar com o volume cada vez maior de ataques e vulnerabilidades divulgadas.

Redução de 97% nas vulnerabilidades de software de código aberto (OSS)

Ao identificar e priorizar os vulns do OSS que são realmente attackáveis, as equipes e desenvolvedores do AppSec corrigem o que importa, enviam o código mais rápido e, na verdade, melhoram a segurança com menos e melhores correções.

Redução de 37% ao ano no Tempo Médio para Remediar (MTTR)

O foco do laser na capacidade de ataque e na redução de falsos positivos permite que os desenvolvedores façam correções mais rápidas e reduzam o MTTR. Isso melhora a postura de segurança e reduz a probabilidade de ataques, reduzindo o tempo em que as vulnerabilidades são expostas. Na verdade, ShiftLeft descobriu que as equipes de desenvolvimento estavam corrigindo 76% das vulnerabilidades acionáveis em dois sprints (12 dias).

Tempo médio de varredura de 90 segundos

As varreduras rápidas permitem que as equipes façam varredura com mais frequência, melhorando a cobertura de segurança para aplicativos de iteração rápida e permitindo uma melhor cobertura de aplicativos muito grandes que anteriormente exigiam horas ou dias para serem digitalizados.

Aumento significativo na frequência de varredura

Digitalizações mais rápidas, inserção automatizada em pipelines de CI e maior cobertura de varredura em mais idiomas também permitiram que as equipes do AppSec mudassem da verificação de vulnerabilidades mensais ou semanais para varreduras diárias. O relatório rastreou um aumento de 68% ano após ano nas varreduras diárias.

Exposição Log4j vulnerável estimada a 4%

Devido à natureza generalizada e generalizada do Log4j, muitas equipes de segurança de aplicativos tiveram dificuldade para identificar todas as instâncias da biblioteca de registro em sua pilha de aplicativos. Instâncias obscurecidas e aninhadas (em arquivos JAR, por exemplo) causaram problemas específicos. O ShiftLeft analisou as varreduras para a vulnerabilidade Log4j e mapeou os fluxos de dados reais através de aplicativos de produção, combinando os resultados da análise de Testes de Segurança de Aplicativos Estáticos (SAST) e Análise de Composição de Software (SCA). A análise descobriu que apenas 4% de todas as instâncias do Log4j estavam vulneráveis. As equipes que tinham essas informações economizaram meses de tempo desperdiçado caçando e corrigindo instâncias do Log4j que representavam pouco ou nenhum risco.

“Com base em nossas descobertas, duas em cada três equipes de desenvolvimento estão literalmente perdendo tempo com os 97% das correções que não são attackáveis e fornecem pouco benefício de segurança”, disse Manish Gupta, CEO da ShiftLeft. “Por outro lado, as equipes que mudam a segurança para a esquerda e se concentram na capacidade de ataque enviam um código mais seguro, com mais frequência. Isso melhora claramente a segurança de seus aplicativos, ao mesmo tempo em que melhora a produtividade do desenvolvedor e a velocidade do produto.”

O relatório destaca como a mudança na segurança dos aplicativos deixada para envolver os desenvolvedores no início do ciclo de vida do desenvolvimento de software resulta em correções mais rápidas e menos desperdício de energia priorizando e corrigindo vulnerabilidades que representam pouco ou nenhum risco. Também ressalta a importância de uma abordagem tecnológica holística que integre SAST e SCA para fornecer uma imagem clara da capacidade de ataque e subsequente priorização de correções de segurança para reduzir o foco em corrigir o que importa.

FONTE: HELPNET SECURITY

Previous post Por que a confiança digital precisa ser um imperativo estratégico para a sua empresa?
Next post O Enveil ZeroReveal ML Encrypted Training permite o uso seguro de fontes de dados entre silos

Deixe um comentário