Ricardo Pupo Larguesa: Tecnologia, diga-me com quem andas...
Ele é engenheiro de computação, sócio-fundador da T2S, professor e pesquisador na Fatec Rubens Lara
Recentemente, fomos surpreendidos com uma notícia tensa: uma falha de segurança foi descoberta numa biblioteca chamada Log4j. Mas qual o problema, indagará o leitor. O problema é que uma infinidade de sistemas tem como base esta conhecida biblioteca e a brecha de segurança expunha todos que a utilizam. No setor portuário, a segurança é obviamente um tema importante e todos os departamentos de Tecnologia da Informação se mobilizaram para mitigar os problemas.
Em sistemas de informação, assim como em qualquer tecnologia, é comum encapsular funcionalidades em módulos que possam ser incorporados em novos projetos. Chamamos esses componentes de bibliotecas, e há uma imensidão de bibliotecas de softwares por aí.
O Log4j, mantida pela Apache Software Foundation, é um dos mais famosos. Criada em 2001, é responsável por organizar e armazenar o registro de uso dos sistemas. Essa biblioteca permite fazer com que um sistema armazene informações de uso que são utilizadas para investigar e resolver problemas de uso das aplicações. O Log4j é muito útil para os desenvolvedores.
Gratuito e de código aberto, pode ser utilizado sem custo algum e seu código pode ser visualizado por qualquer pessoa. Significa também que qualquer desenvolvedor pode colaborar com o time que o criou.
A falha de segurança do Log4j, uma biblioteca tão popular e madura, acabou se tornando uma falha indireta para milhares de aplicações que ficaram expostas.
Esse problema provocou uma reflexão sobre o uso de bibliotecas de terceiros: bibliotecas de código-aberto são confiáveis?
Essa foi uma questão muito discutida. Como o Log4j é de código aberto, o código fonte inteiro (incluindo a vulnerabilidade) fica à disposição de todos (incluindo os hackers) e isso poderia facilitar a descoberta e o uso malicioso. E é verdade! Porém, também permite a descoberta por pessoas bem intencionadas antes mesmo que se torne um problema, e conta com a colaboração ágil e em escala global de toda a comunidade de desenvolvimento de sistemas.
Bibliotecas privadas também podem apresentar vulnerabilidades e a solução ficaria restrita apenas ao time interno da empresa. Além disso, um invasor não precisa do código fonte para encontrar vulnerabilidades. Ele explora as interfaces de comunicação dos sistemas com ferramentas específicas que são muito mais eficientes do que ler as milhares de linhas do complexo código em busca de uma brecha.
Não acho que bibliotecas de código aberto sejam mais vulneráveis do que bibliotecas de código proprietário. E ainda acho que a inovação aberta traz muito mais benefícios que ameaças.
Como lição, cabe a nós aproveitar o ocorrido para arrumar a casa revisando nossos sistemas e os sistemas que nossos sistemas usam. É como se diz: diga-me com quem andas e eu te digo se é seguro… ou alguma coisa assim.
