O SEI publicou recentemente uma pesquisa fascinante que mostra uma clara relação entre a qualidade e a segurança do software.

O consenso dos pesquisadores é que pelo menos a metade, e talvez 70%, das vulnerabilidades de softwares comuns são problemas fundamentais de qualidade de código que poderiam ser evitados escrevendo melhor o software. Codificação desleixada. Não checar os dados de entrada. Erro ruim – ou nenhum – de manipulação. Colchetes no lugar errado… Um código melhor é o mais seguro.

Usando contagem de bugs para prever falhas de segurança – e vice-versa

Quanto mais bugs você tem, mais problemas de segurança você tem.

Em algum lugar entre 1% e 5% dos defeitos de software causam vulnerabilidades de segurança. O que significa que você pode ter uma boa ideia de como proteger um aplicativo baseado em quantos erros ele tem.

Se você fizer tudo certo:

1. Desenvolvedores são treinados em desenvolvimento seguro para que eles possam evitar – ou pelo menos encontrar e corrigir – os problemas de segurança.
2. O sistema é projetado e construído com um foco deliberado em qualidade e segurança.
3. Você coleta/mede dados de defeito e usa-os para avaliar e melhorar suas práticas de desenvolvimento.

Em seguida, você deve esperar encontrar apenas 1 vulnerabilidade de segurança para cada 100 (mais ou menos) bugs. Se você não prestar atenção à segurança e à qualidade, então o número de vulnerabilidades de segurança no código será, obviamente, muito maior. Quanto mais bugs você encontrar, mais vulnerabilidades de segurança você tem em algum lugar no código, ainda esperando para serem encontrados.

Heartbleed e Goto Fail = má codificação

O SEI deu uma olhada nas recentes vulnerabilidades de segurança de alto nível, incluindo Heartbleed e o bug SSL da Apple “goto fail“, que foram causadas por erros de codificação que poderiam e deveriam ter sido capturadas em revisões de código ou em testes unitários (leia a análise exaustiva de Martin Fowler aqui). Nenhuma mágica black hat de segurança aqui. Apenas padrões, boas práticas de desenvolvimento aceitas.

Essa pesquisa aponta também os limites das ferramentas de análise estática para garantir um código seguro. Erros que poderiam ter sido encontrados por pessoas que trabalham com cuidado não foram achados pelas ferramentas:

“Heartbleed criou um desafio significativo para ferramentas de garantia de software atuais, e não temos conhecimento de qualquer um desses instrumentos que tenham sido capazes de descobrir a vulnerabilidade Heartbleed no momento do anúncio”.

A única maneira de descobrir o bug Heartbleed com as principais ferramentas de hoje é a escrita de regras personalizadas ou sobrescritas, o que significa que você tem, em primeiro lugar, que antecipar que esse código é ruim. Em vez disso, você estaria gastando melhor o seu tempo revisando ou testando o código com mais cuidado.

Se você tem erros, você vai ser sacaneado

Se você tem um problema de qualidade, então possui um problema de segurança.

Segurança e confiabilidade têm que ser projetadas e desenvolvidas. Você não pode testar isso em:

Sistemas de médio e grande porte normalmente contêm muitos defeitos e estes nem sempre causam problemas quando os sistemas de software são usados precisamente como foram testados…

Mesmo um pequeno sistema pode exigir um enorme número de testes para confirmar o funcionamento correto em condições esperadas. À medida que os sistemas crescem, os números das possíveis condições podem ser infinitos. Para qualquer sistema não trivial, a área testada é pequena. O teste, por necessidade, se foca nas condições com maior probabilidade de serem encontradas e mais suscetíveis de provocar uma falha no sistema. O teste, portanto, só pode encontrar uma fração dos defeitos no sistema.

O teste funcional prova que o sistema funciona como o esperado. Esse tipo de teste, mesmo em altos níveis de cobertura, não pode provar que o sistema é confiável ou seguro. Pen test, fuzzing, DAST e testes destrutivos estressam o sistema de formas inesperadas para ver como ele se comporta. Mas o pen testing também não pode provar que o sistema é seguro – para um grande sistema, você precisaria de um número infinito de pen tests em um número infinito de teclados trabalhando um número infinito de horas para talvez  encontrar todos os bugs.

Como qualquer outro tipo de teste, o pen testing te fornece informações sobre a qualidade e a integridade de concepção e implementação do sistema – onde você cometeu erros, onde deixou escapar alguma coisa. Os resultados te dizem onde olhar mais profundamente para outros problemas no projeto ou código, ou problemas na forma como você projeta ou como você codifica. O pen testing é desperdiçado se você não usar essas informações para chegar à causa raiz e fizer as coisas melhor.

A pesquisa do SEI torna algumas coisas claras:

1. A segurança e a confiabilidade andam de mãos dadas. Os sistemas de segurança-críticas precisam ser construídos como sistemas de segurança crítica – com a mesma atenção à qualidade.
2. Você pode prever o quão seguro o seu sistema é baseado no número total de erros que foram encontrados no código.
3. As revisões de projeto e as revisões de código (incluindo métodos informais em  o seu próprio código) são as formas mais eficazes para encontrar problemas de segurança e confiabilidade. A quantidade de tempo gasto em revisões é um indicador chave da confiabilidade e da segurança do sistema: os melhores desempenhos gastam no máximo 2/3 do tempo em comentários e em desenvolvimento. Para os códigos security-critical or safety-critical, você precisa ter especialistas envolvidos em fazer avaliações.
4. Testes com análise estática devem ser parte do programa de desenvolvimento de todos. Mas não se apoie demais neles. Execute a análise estática antes das revisões de código para pegar os erros básicos e limpá-los, ou para identificar áreas problemáticas no código que precisam ser revistas cuidadosamente. Execute análise estática de código após revisões para verificar se o código está bom. Mas não tente usar a análise estática como um substituto para as revisões de código.
5. Concentre-se em escrever um código bom e limpo. A maioria dos defeitos Nível 1 (alta gravidade) é causada por erros de codificação.
6. Treine desenvolvedores em design e codificação seguros para que eles saibam o que não fazer, o que procurar na revisão de código e para que saibam como corrigir bugs de segurança corretamente.

A construção de sistemas confiáveis e seguros não é barata e não é fácil, especialmente em escala. O SEI diz que você deve assumir que sistemas complexos nunca estão livres de erros, o que significa que eles nunca serão completamente seguros. Nosso trabalho é fazer o melhor que pudermos, e espero que seja o suficiente.

***

Jim Bird faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://swreflections.blogspot.com.br/2015/01/if-you-got-bugs-youll-get-pwned.html