fbpx

Quanto pode custar um bug?

Os bugs são inevitáveis no desenvolvimento de um produto. Por isso, existem diversas técnicas de desenvolvimento e processos de controle de qualidade realizados durante o ciclo de desenvolvimento de software que buscam evitar que um erro afete a experiência do usuário.

Ainda assim, uma quantidade muito significativa de problemas surge nas mãos dos clientes. Eventualmente, uma falha pode custar muito para a empresa, tanto em aspectos financeiros como na reputação dela.

Os dados mais abrangentes, parte de uma pesquisa realizada em 2013 pela Judge Business School da Universidade de Cambridge, apontam custos anuais de 312 bilhões de dólares decorrentes de falhas de software no mundo todo. Colocando em perspectiva, se essa quantia fosse o PIB de um país, ficaria em 36ª no ranking da economia mundial daquele ano, à frente de países como Israel, Finlândia e Chile.

Tipos de bugs

Sem nos aprofundarmos demais, vamos considerar algumas áreas em que os bugs podem afetar diretamente a experiência do usuário:

  • Desempenho: Ninguém tolera por muito tempo usar um aplicativo lento, que trava repetidamente. Às vezes, a falha prejudica o funcionamento do sistema como um todo, ou mesmo do hardware, consumindo bateria demais ou provocando superaquecimento. Não dá pra aceitar, né?
  • Funcionalidade: Esse tipo também gera muita frustração. Alguns erros podem limitar ou inibir totalmente funções que o usuário espera. Podem se originar em falhas de implementação da especificação, erros de programação da interface, uso incorreto de APIs, entre outros.
  • Segurança: Aqui moram os piores pesadelos. Expor inadvertidamente informações sensíveis, comprometendo a privacidade do cliente ou usuário final, pode causar tempestades de relações públicas e consequências graves para a continuidade do negócio.

Veremos alguns exemplos de diferentes tipos mais tarde. Mas primeiro vamos falar sobre…

Falhas de segurança!

A web é o principal alvo de ataques, mas nenhuma plataforma está livre do problema. Mesmo sistemas totalmente fechados, como console de jogos e carros, são alvos constantes e quase sempre eventualmente vencidos por hackers.

O peso das falhas de segurança criou um mercado inteiro. Inicialmente, era comum pesquisadores e hackers divulgarem seus achados, demonstrando como uma brecha poderia ser explorada, sem muita preocupação. No entanto, a ascensão da internet trouxe consequências sérias para a negligência com falhas de segurança, tornando dados sigilosos e transações bancárias vulneráveis a ataques.

Existem algumas recomendações para fazer esse tipo de pesquisa com responsabilidade. A maior parte das diretrizes vem de uma política proposta em 2000 por um hacker (RFPolicy), revisada e discutida continuamente desde então.

Encontrando bugs

A abordagem recomendada é reportar o bug para a empresa, colaborar no entendimento da falha, e lhes dar tempo suficiente para corrigir o problema antes de mostrar publicamente o trabalho (essa tática é chamada de Responsible Disclosure). O prazo da política original para revelar uma falha era de 2 dias após comunicar a empresa, caso não houvesse resposta. Foi posteriormente revisada para 5 dias, e discussões na comunidade passaram a sugerir 30 dias. Porém, na prática, cada hacker ou programa de pesquisa define seu próprio prazo.

Um caso recente criou algum desconforto quando a iniciativa Project Zero, do Google, que emprega um prazo de 90 dias, divulgou um erro que ainda não tinha sido corrigido no Windows 8.1. Na verdade, não foi a primeira vez, e aconteceu novamente há poucos dias. O que parece estar cada vez mais próximo de um consenso é que os prazos fixos incentivam os fabricantes a criar e distribuir as correções mais rápido.

Em certos casos, como para falhas que podem oferecer risco direto à vida das pessoas, a tendência é que exista maior colaboração entre os pesquisadores e as empresas. Brechas de segurança em sistemas automotivos se encaixam nesse cenário. Já falamos de um relato deste tipo aqui.

Recompensa para encontrar bugs (bug bounty)

Existem empresas especializadas em testes e até algumas que se dedicam à encontrar e explorar as falhas para vender o serviço para clientes ligados ou não ao governo. Um caso recente, na investigação do FBI sobre o ataque em San Bernardino (Califórnia), resultou em um pagamento de mais de US$ 1,3 milhões para encontrar uma forma de desbloquear o iPhone de um dos terroristas.

Algumas organizações ajudam a fazer a ponte entre pesquisadores e empresas interessadas em testar seus produtos para falhas de segurança. As remunerações somaram mais de US$ 10 milhões desde 2013, e o interesse pelo termo bug bounty explodiu entre 2015 e 2016. Empresas participantes incluem Google, Facebook, Microsoft, Tesla, Uber, Dropbox, Snapchat e quase 200 outras.

Dados do Google Trends mostrando a evolução da busca 'bug bounty' desde 2004. (Fonte: State of Bug Bounty, 2016)

Dados do Google Trends mostrando a evolução da busca ‘bug bounty’ desde 2004. (Fonte: State of Bug Bounty, 2016)

Além disso, programas e eventos de bug bounty criados pelas próprias empresas de tecnologia passaram a ser cada vez mais comuns, especialmente no caso de gigantes como Google e Facebook. Esses eventos atraem milhares de hackers, distribuem prêmios e ajudam as empresas a corrigir problemas de segurança com maior agilidade.

Quanto custa um bug?

O custo de um bug depende, é claro, de quando ele foi encontrado e qual a sua importância. É desejável encontrar a maioria dos bugs no início do ciclo de desenvolvimento, ou seja, aqui é importante lembrar que, quanto antes, melhor e mais barato. Também é essencial realizar os testes de software durante e ao final de cada ciclo de desenvolvimento e, de preferência, com a ajuda de uma equipe independente de testes.

O teste de software é sempre menos custoso, e pode poupar a empresa de uma enorme dor de cabeça. Casos em que falhas importantes seguem obscuras até o consumidor ou a implementação em produção criam situações dignas de pesadelos. Conheça alguns exemplos:

Ariane 5 501

A explosão no vôo de estréia do foguete Ariane 5, em 1996, causou uma perda de US$ 370 milhões. É um caso clássico das proporções que um erro de software pode tomar.

Ariane 5 501

O sistema de autodestruição foi acionado após uma separação inesperada dos motores auxiliares, por conta de um ângulo de ataque aerodinâmico excessivo. Isso aconteceu porque foi realizada uma correção desnecessária na abertura das saídas dos motores, ordenada pelo computador de bordo, que provocou a mudança de ângulo durante o vôo.

A instrução ocorreu após um sinal do sistema de referência inercial. No entanto, no momento do erro, parte dos dados eram de sensores utilizados apenas antes do lançamento. O sensor ainda estava ativo porque o código foi reaproveitado do Ariane 4, que requeria que ele permanecesse ligado durante 40 segundos após o lançamento, algo que não seria necessário para o Ariane 5. O sistema acusou erro de operação e falhou.

A causa foi uma conversão ilegal de 64 bits para 16 bits naquele valor de velocidade horizontal, que sequer deveria ter sido passado ao sistema. Existe código padrão para prevenir essa falha, mas engenheiros resolveram não utilizar essas linhas de código nessa rotina, embora a tivessem empregado em outras partes do código.

A cereja do bolo? O sistema redundante continha exatamente o mesmo código. Você pode ler mais sobre esse caso clássico aqui e aqui.

GM faz recall de 4,3 milhões de veículos

Em setembro de 2016, sem dar maiores detalhes da falha, a montadora explicou que o motivo de estar fazendo um recall tão grande era um erro de software que pode evitar que airbags se inflem em uma batida.

Dependendo de raras circunstâncias envolvendo a dinâmica do veículo imediatamente antes de uma batida, o bug poderia causar o início automático de um teste de diagnóstico no sistema do airbag, tornando-o temporariamente inoperante.

Sendo otimistas e simplistas, ignorando custos burocráticos, vamos imaginar que um técnico de manutenção é capaz de atender 3 recalls por hora. O salário médio desse profissional da GM nos EUA, em novembro de 2016, era de US$ 16,44 a cada hora trabalhada. Difícil estimar a média mundial, mas vamos ser conservadores e considerar metade, US$ 8,22. Portanto, teríamos um total de 1,43 milhões de horas necessárias, que gerariam um custo superior a US$ 11 milhões.

Erros nos caixas da Starbucks

Em abril de 2015, por conta de uma falha de atualização no software dos caixas registradores, 60% das lojas americanas e canadenses da franquia Starbucks passaram 3 horas distribuindo café de graça. Não foram estimados prejuízos oficiais, mas façamos um exercício.

Custo de um bug: caso starbucks

Utilizando dados de faturamento da época, a média de faturamento diário era de US$ 32 milhões nos EUA e Canadá. Se 60% das lojas apresentaram dificuldades, falamos de US$ 19,2 milhões. As 3 horas com a falha representam 25% das 12h em que a maioria das lojas opera. Seriam aproximadamente US$ 4,8 milhões de prejuízo.

No entanto, a falha começou às 16h de uma sexta-feira, e uma consulta rápida no Google mostra que este é o horário de pico em lojas de várias regiões na América do Norte, e que o público cai lentamente nas horas subsequentes. Ou seja, é provável que o valor tenha ultrapassado US$ 6 milhões. Os clientes certamente gostaram, mas o departamento de TI e comercial deve ter tido um dia muito estressante.

Heartbleed, bug no OpenSSL afeta mais de 500 mil servidores

Muitos servidores utilizam a biblioteca OpenSSL para prover acesso seguro aos seus sites. Mas um erro de verificação de limites de uma variável na implementação da extensão Heartbeat do protocolo TLS permitia que uma simples verificação de conexão pudesse ser manipulada para enganar o servidor, que retornaria dados privados da memória do seu computador.

Na época em que a falha foi revelada, 17% dos servidores seguros na internet poderiam estar vulneráveis (!). O bug estava no código havia 2 anos, o que significa que pode ter sido explorado antes. O impacto foi considerável, provocando a substituição de centenas de milhares de certificados digitais.

Uma estimativa mostrou que a certificadora digital GlobalSign poderia ter um custo adicional de mais de US$ 400 mil mensais na sua “conta de internet”, só pelo aumento de tamanho do arquivo que contém a referência de certificados revogados, de 22 KB para 4,9 MB.

E aí?

Como você viu, erros de software podem sair muito caro. Seja pela segurança dos dados dos clientes ou garantia de operação sem erros, a verdade é que empresas pagam por falhas de software porque é muito mais barato e fácil de tratar do que a alternativa, ou seja, lidar com recalls, correções urgentes e processos.

Garantir bons testes antes do lançamento dos produtos é uma opção melhor ainda. Me mande um e-mail em bruno.abreu@sofist.com.br ou ligue em (19) 3291-5321. A One Day Testing pode ajudar a garantir a qualidade do seu produto da forma mais eficaz. Se precisar, é só chamar!