A menos que você more em uma ilha remota sem conexão com a Internet, certamente já ouviu falar sobre os  problemas do Log4j  que afetaram tantos aplicativos e serviços de Internet nos últimos 10 dias. A descoberta coincidente desse bug crítico no contexto das mensagens do console Minecraft (digitar uma mensagem no cliente do jogo Minecraft pode permitir que alguém execute código em um servidor Minecraft) devido ao uso de uma biblioteca de log Java extremamente popular  chamada Log4j , causou cada empresa de TI e todas as empresas que usam aplicativos de software para verificar se o problema estava afetando o software da empresa, serviços hospedados, sites internos e qualquer outro cenário de caso de uso.

A lista de aplicativos de software afetados (há  um aqui , por exemplo) é bastante impressionante, porque apesar de ter perdido parte do hype e do impulso de marketing, Java é e continua sendo uma das linguagens mais populares do mundo, e a JVM uma das mais ambientes de execução de tempo de execução populares.

Código nativo do RAD Studio e sem dependência de Java

Agora, o que isso significa para a Embarcadero em geral e para o RAD Studio em particular? Diretamente, não muito. O software construído em Delphi ou C++Builder não usa ou depende de forma alguma de Java (com exceção de aplicativos Android) e, portanto, não usa Log4j. Mais em geral, Delphi e C++Builder criam aplicativos compilados nativamente, que estão menos sujeitos a problemas de ambiente de execução (aqui estou me referindo a ambientes de execução Java, .NET ou JavaScript). No entanto, neste caso, o problema não estava no ambiente de execução, mas em uma biblioteca popular, e os desenvolvedores do RAD Studio usam componentes complementares e bibliotecas de terceiros, como qualquer outra comunidade de desenvolvedores.

Deixe-me esclarecer mais uma vez: Um servidor web ou serviço web construído em Delphi ou C++Builder (ou C++ em geral) não é afetado pelo problema do Log4j. O mesmo é verdade, é claro, para aplicativos da Web criados em ASP.NET, Python ou PHP. O problema é específico para software escrito em Java – e há muitos softwares Java por aí, conforme link acima.

Voltando ao Delphi e ao C++Builder, ter código compilado ajuda na segurança, mas não é suficiente. Também é importante escolher apenas bibliotecas e componentes nos quais você possa confiar totalmente (no mínimo, exigindo que o código-fonte seja incluído). Além disso, também é importante para um desenvolvedor escrever código com foco específico em segurança. Como foi mencionado na semana passada,  a codificação de copiar e colar  (embora não seja diretamente responsável pelo problema do Log4j) é um estilo de codificação do outro lado da escrita de aplicativos seguros.

Contribuindo de volta para o código aberto

Há também outra questão-chave que os problemas do Log4j tornaram óbvio: existem projetos multimilionários gerenciados por grandes corporações que dependem de projetos de código aberto sem financiamento, gerenciados por desenvolvedores em seu tempo livre (fora de seus empregos regulares). A ideia de que você pode usar o código aberto para economizar custos sem contribuir com tempo, recursos ou dinheiro para os projetos que você alavanca está se tornando um grande problema no setor.

Isso também vale para o ecossistema Delphi e C++Builder: a Embarcadero começou a financiar e doar para algumas bibliotecas de código aberto, mas devemos fazer mais. Também incentivamos todos os aplicativos de negócios que aproveitam significativamente as bibliotecas e ferramentas Delphi de código aberto a contribuir de volta para eles – inclusive por meio de avaliações de segurança!

Quantos projetos de código aberto você usa para seus aplicativos profissionais e quando foi a última vez que você doou para algum deles?

A segurança é multifacetada

A segurança é um continuum que requer vários ângulos e cada um dos itens abaixo pode ajudar:

• Aplicativos compilados nativamente
• Sem dependência de um ambiente de execução de tempo de execução
• Uso de bibliotecas e componentes de terceiros verificados e confiáveis
• Comprometendo-se a contribuir de volta para os projetos de código aberto que você aproveita
• Foco de segurança ao escrever código (sem codificação de copiar e colar)
• Ferramentas para verificar o código-fonte de um aplicativo
• Armazenamento seguro do código-fonte (para evitar injeção de código-fonte)
• Ambiente de compilação seguro (para evitar injeção de código binário)
• Assinatura executável do aplicativo

Embora não seja abrangente e tenha um viés para código compilado (acreditamos que realmente importa), esperamos que esta lista e a reação geral ao incidente do Log4j possam ajudar você e sua organização a repensar a segurança e agregar mais valor ao papel dos desenvolvedores – que são a pedra angular de qualquer cenário de desenvolvimento seguro.

Boa codificação com seu RAD Studio sem Log4j 😉