Vulnerabilidades de segurança em código
O software do sistema operativo, software de aplicação ou firmware num sistema integrado são componentes elementares de qualquer infra-estrutura digital. Contudo, a crescente aceleração e pressão de prazos em projectos de digitalização conduzem frequentemente a uma negligência de aspectos imperativos de segurança da informação. Os requisitos de desenvolvimento de software são geralmente centrados na função e enfatizam aspectos construtivos, de modo que a visão destrutiva de potenciais vulnerabilidades de segurança é na sua maioria diametralmente oposta aos objectivos de desenvolvimento reais: a muitos programadores falta simplesmente também uma visão estruturada e afiada da segurança cibernética.
Nestas condições, as equipas de desenvolvimento têm dificuldade em rever continuamente e assegurar consistentemente a codificação do seu software, como evidenciado pelas muitas vulnerabilidades que a Corporação MITRE sem fins lucrativos publica cada ano na sua lista CVE (Common Vulnerabilities and Exposures). Os patches de segurança regulares, mesmo de fabricantes de software bem conhecidos, são um indicador da tarefa Sisyphean de fechar bugs relevantes para a segurança, quanto mais de os identificar antes mesmo de serem lançados no mercado.
Código fonte aberto - um caso especial
Ao codificar software autodesenvolvido, os programadores gostam de recorrer a bibliotecas e módulos de código aberto. As vantagens práticas são óbvias: se não tiver de reinventar a roda uma e outra vez, beneficia deste impulso tecnológico, desenvolvimento rápido, custos de desenvolvimento mais baixos, mais transparência através de código fonte aberto, e maior interoperabilidade através de normas e interfaces abertas.
Também se diz frequentemente que o código de fonte aberta oferece um elevado grau de segurança, porque o código foi validado por muitos utilizadores e a inteligência de enxame da comunidade de fonte aberta permite uma rápida e eficiente correcção de bugs.
Na prática, esta confiança deve agora ser avaliada de uma forma diferenciada e crítica. O exemplo mais sério é a vulnerabilidade de segurança de dia zero Log4Shell na amplamente utilizada biblioteca de registo Log4J para aplicações Java, que foi descoberta em Novembro de 2021. Poderá ter ouvido falar do nível de alerta vermelho emitido pelo Gabinete Federal Alemão para a Segurança da Informação (BSI) para Log4Shell. A biblioteca Log4J, distribuída como um quase-padrão de funcionamento fiável através da Fundação Apache, estabeleceu-se em muitos sistemas desde 2013 - incluindo serviços web bem conhecidos como o Amazon AWS.
A complexidade destas bibliotecas bem desenvolvidas e também mantidas fornece implicitamente poderosas funcionalidades das quais um desenvolvedor importador muitas vezes desconhece no seu novo desenvolvimento combinado, mas que podem ser exploradas por atacantes.
Outro factor de insegurança dos componentes de código aberto são os chamados ataques de cadeia de fornecimento, ou seja, vulnerabilidades incorporadas pretendidas por actores maliciosos que se apresentam como parte da comunidade de código aberto e ajudam no desenvolvimento de códigos. Tal vulnerabilidade é uma forma extremamente eficiente de os hackers atacarem um grande número de organizações de utilizadores a jusante. Não admira, pois, que este vector de ataque esteja a crescer rapidamente: um estudo Sonatype diagnosticou um aumento de 650% quando se comparam 2020 e 2021.