Status quo de software de segurança?

Como o conjunto de dados da Veracode continua crescendo, com mais clientes e mais aplicativos sendo escaneados, os resultados ficam mais interessantes.

Para o web apps, o estado das vulnerabilidades permaneceu inalterado ao longo dos últimos 18 meses:

  • 1/3 dos aplicativos continuam vulneráveis a SQL Injection
  • 2/3 dos aplicativos continuam vulneráveis a XSS, e pelo menos metade de todas as vulnerabilidades encontradas no escaneamento são vulnerabilidades a XSS

Nos últimos três anos, não há mudanças significativas ocorrendo em diferentes vulnerabilidades que não possam ser explicadas por mudanças e melhorias na tecnologia ou nos métodos de testes da Veracode.

Para plataformas moveis (Android, iOS e Java ME), as vulnerabilidades mais comuns encontradas estão relacionadas à criptografia: 64% dos aplicativos Android, 58% dos aplicativos iOS, e 47% dos aplicativos Java ME têm vulnerabilidade na criptografia. Fora da criptografia, as distribuições de vulnerabilidade para as diferentes plataformas moveis são bastante distintas. É possível que essas diferenças sejam devido a pontos fortes e fracos fundamentais de cada plataforma (arquiteturas diferentes, APIs distintas e recursos-padrão fornecidos), mas acho que ainda é muito cedo para tirar conclusões significativas a partir desses dados, à medida que o tamanho do conjunto de dados é ainda muito pequeno (embora continue a aumentar de tamanho: de 1% do total da amostra para 3% durante os últimos 18 meses).

Mas as vulnerabilidades de segurança estão sendo corrigidas, certo?

Alguns dados interessantes sobre as correções, com base em clientes da Veracode reenviando a mesma base de código para escaneamentos posteriores. Quase a metade dos seus clientes reenvia todos, ou quase todos, os seus aplicativos para re-escanemaento, independentemente de quão critico o aplicativo é considerado para o negócio do cliente. O que é interessante é quais vulnerabilidades as pessoas escolhem corrigir – erros que são encontrados no primeiro escaneamento, mas que não aparecem mais depois.

Para o Java, os erros mais frequentemente corrigidos são:

  1. Caminho de pesquisa não confiável
  2. Injeção de CRL
  3. Inicialização não confiável
  4. Session fixation
  5. Função perigosa

Assim, os primeiros erros a serem corrigidos parecem ser os mais fáceis para os desenvolvedores entenderem e cuidarem – os frutos mais baixos. Decisões de correção não parecem ser baseadas no risco, mas no “vamos ver o que podemos corrigir agora e tirar os caras de segurança dos nossos pés”. Bugs de segurança estão sendo corrigidos, mas é claro que os erros de SQL Injection e XSS não estão sendo corrigidos rápido o suficiente, porque há muitas dessas vulnerabilidades a serem corrigidas, e porque muitos desenvolvedores ainda não entendem esses problemas bem o suficiente para corrigi-los ou evitá-los em primeiro lugar. Desenvolvedores de PHP são muito mais propensos a corrigir vulnerabilidades de SQL Injection do que desenvolvedores de Java ou .NET, mas não está claro o porquê.

A arte e a ciência das previsões

Os resultados do relatório foram apresentados mais no início do ano em um webinar intitulado “Vemos o futuro… e ele não é bonito”, que acompanhou os dados e as previsões que a Veracode retirou dos dados. Embora os resultados pareçam seguros, as previsões são bem menos do que isso: por exemplo, que haverá maior rotatividade nos empregos de segurança (incluindo os cargos de CISO) porque os programas AppSec não são eficazes, e o pessoal de segurança vai desistir – ou ser demitido – como um resultado. Eu não consigo enxergar a ligação entre os dados e essas conclusões. Os autores devem ler (ou reler) The signal and the noise para entender o que deve ir para um previsão de alta qualidade, e quais previsões devem ser feitas e quais não devem.

Fonte: http://imasters.com.br/infra/seguranca/status-quo-de-software-de-seguranca/

Deixe um comentário