O código nunca apresentou tantas vulnerabilidades. O que até faz sentido, porque nunca houve tanto código como atualmente. No entanto, o risco cresce de forma assimétrica. No ano 2000, havia apenas 1.020 vulnerabilidades CVE registadas; em 2010, o valor caiu para 4.155. Mas em 2017, esse número explodiu para 14.714 CVEs, vindo de apenas 6.454 no ano anterior. E em 2021, foram detetadas 20.149 novas vulnerabilidades.

É verdade que nem todos os bugs de software são relevantes, mas os números mostram que o número de falhas no software está a crescer rapidamente. Além disso, convém recordar que as empresas nem sempre são rápidas na instalação de patches importantes, o que significa que as vulnerabilidades mais antigas continuam a persistir. Se juntarmos a este fator o cada vez maior profissionalismo das organizações criminosas e o seu forte apetite por lucro, compreendemos a importância de tornar o código estanque.

1. Siga algumas regras simples

Mais fácil dizer do que fazer. Enquanto programador, podemos, antes de mais nada, aderir a algumas práticas recomendadas. Alguns bugs são resultado da preguiça e podem ser facilmente evitados. Está a construir uma aplicação que processa a entrada de utilizadores? Então certifique-se de que todas as entradas são devidamente validadas. A SQL injection (SQLi) é um problema comum e perigoso.

Também é importante obter notificações de erro de qualidade, criptografia suficiente para dados confidenciais, HTTPS como padrão para páginas da Web, um sistema de login seguro quando apropriado… Não há desculpa para um utilizador receber a mensagem “a sua password é muito longa”. Todos cometemos erros, mas manter a segurança em mente desde o início do desenvolvimento de uma aplicação ajuda a mitigar eventuais problemas.

2. Vulnerable dependencies

As vulnerabilidades mais perigosas, no entanto, não são culpa nossa. A maioria das aplicações depende de libraries de terceiros. Quando um “zero-day” consegue entrar sorrateiramente lá, os portões ficam abertos. Basta recordar a simples library Log4j na qual a vulnerabilidade Log4Shell expôs metade do mundo aos cibercriminosos.

Analisar pessoalmente todas essas libraries externas é claramente uma tarefa impossível. Felizmente, existem ferramentas para ajudá-lo. Elas usam verificações automatizadas para mostrar quando a sua aplicação depende de uma library com uma vulnerabilidade conhecida. Ao fazer isso, as soluções de segurança não examinam necessariamente o código em si, mas verificam se os componentes de código aberto são confiáveis. Afinal, podemos não querer integrar aquela versão antiga do Log4j.

3. Verificando o próprio código

Essas ferramentas automatizadas também existem para o seu próprio código. As soluções vêm tanto de empresas de segurança tradicionais quanto de empresas especializadas. Elas são capazes de encontrar bugs comuns que podemos ter ignorado num dia mais agitado. Esta validação pode ser feita no repositório GitHub onde o seu projeto fica colocado, ou diretamente no seu IDE. Dessa forma, corrigimos erros antes mesmo do código ser compilado e, certamente, antes de entrar em produção. Prevenir leva menos tempo do que remediar. Uma vantagem adicional: algumas ferramentas também sugerem uma solução imediata.

Finalmente, é melhor assumir que mesmo as melhores práticas e ferramentas úteis não fornecem segurança absoluta. Quanto mais seguro for o ambiente no qual a aplicação é executada e quanto melhor for a configuração em torno dela, menor será a probabilidade de algo correr mal. Essa colaboração de segurança entre o programador e a equipa operacional de TI também faz parte do DevOps. Quando todos assumem a responsabilidade e seguem as melhores práticas, há menos probabilidade de algo falhar.

4. Mais do que um patch

E, por último, se um componente tiver um bug ou se alguém tiver cometido um erro: é necessário corrigi-lo rapidamente, mas não desligue o laptop imediatamente depois. O patch abordou a raiz do problema? Ou foi apenas colocado um “penso rápido”? Uma pesquisa recente do Google Project Zero revelou que metade dos “zero days” descobertos no primeiro semestre de 2022 foram uma variação de um bug descoberto anteriormente e mal corrigido.

O programador que leva a segurança a sério, defende a cultura certa, implementa ferramentas e recursos sempre que possível e está bem equipado contra o cenário de ameaças cada vez maior. Se assim for, não só melhora o seu currículo, como os níveis de satisfação para a empresa onde trabalha.

Segurança primeiro! Isso também o faz pensar imediatamente em cibersegurança? É um especialista em fornecer primeiros socorros para vulnerabilidades? Então definitivamente temos um trabalho para si. Confira as nossas vagas!