O novo modelo de ameaça do Java
Na última década de migração para a nuvem, o modelo de ameaças contra aplicativos Java e a maneira como precisamos defendê-los mudou.
Na última década de migração para a nuvem, o modelo de ameaças contra aplicativos Java e a maneira como precisamos defendê-los mudou. O OpenJDK já fez uma mudança positiva nessa área ao descontinuar o antigo SecurityManager, uma relíquia que protegia uma era passada de CDs da AOL e mapas em papel. A próxima mudança positiva na segurança é fortalecer a cadeia de suprimentos de componentes de software, saber o que está em execução e o que está vulnerável e comunicar essas informações a especialistas não técnicos cujos dados estão em risco.
Parte desse modelo de ameaça é impulsionado por bibliotecas vulneráveis como o Log4j do ano passado. Embora o Log4j seja uma ótima biblioteca de registro e esteja ativo na aplicação de patches, muitas equipes se esforçaram para identificar onde precisavam aplicar esses patches. Para desenvolvedores ou equipes Java individuais que conheciam seu código e podiam implantar, o patch era simples — você atualizava uma biblioteca e pronto. A realidade, porém, é que o software se move rápido e longe, muitas vezes deixando o locus de controle desses especialistas técnicos para as partes interessadas que não têm experiência para gerenciar um problema nesse nível. Em uma confusão, as equipes que não conheciam as especificidades do Java procuraram em todos os lugares, incluindo software NET e fóruns Python. Uma parte importante do modelo de ameaças de um aplicativo Java agora envolve a capacidade de rastrear componentes e entender onde nossos aplicativos contêm componentes conhecidos como vulneráveis, como o Log4j.
O que é a cadeia de suprimentos de um aplicativo Java comum?
Uma maneira simples de olhar para a cadeia de suprimentos é que a maioria dos participantes são produtores e/ou consumidores. Os arquitetos corporativos podem já estar familiarizados com a analogia, pois as cadeias de suprimentos se movem como filas e, portanto, podem usar terminologia semelhante. Exemplos desta cadeia de suprimentos incluem:
O objetivo final é mover aplicativos para produção e executá-los — esse ambiente de produção é apenas um consumidor porque não produz novos artefatos (nos ciclos de DevOps, a saída da produção é o feedback).
O principal motivador por trás da avaliação da “cadeia de fornecimento de software” é obter rapidamente a resposta a essas perguntas:
1. Que software tenho, incluindo componentes que compõem sistemas maiores?
2. Quando um software ou biblioteca é identificado como vulnerável, isso me afeta e, em caso afirmativo, onde?
Como uma JVM pode gerenciar a cadeia de suprimentos dos meus aplicativos Java?
Existem muitas abordagens usadas para aplicativos de inventário hoje. O software personalizado geralmente usa ferramentas para criar SBOMs durante o pipeline de CI/CD; O Maven fornece isso por meio de seu plugin dependency: tree. Outra abordagem envolve a varredura de contêiner para analisar o ambiente de encapsulamento no qual o software é executado. Outra abordagem envolve a integração de agentes no software. Cada abordagem exige que uma equipe atue durante uma etapa da cadeia de suprimentos e não detecte desvios de produção ou itens baixados que são comumente implantados fora dessas etapas. Uma das vantagens exclusivas da JVM é que ela deve estar presente em todos os lugares para executar o software e uma JVM já possui as informações necessárias porque é responsável por carregar o código.
