A arquitetura de segurança do Java e a velocidade dos patches críticos
Como componente fundamental da maioria das aplicações corporativas e de missão crítica, a plataforma Java possui uma estratégia de segurança extremamente rigorosa e bem estruturada. Dentro do projeto de código aberto OpenJDK, existe uma equipe conhecida como OpenJDK Vulnerability Group (OVG). Apesar da natureza aberta do projeto, esta equipe opera sob um manto de total privacidade. A participação no grupo é cuidadosamente controlada e apenas engenheiros com o histórico e as habilidades de segurança necessários são selecionados. Como estão sendo desenvolvidos patches para vulnerabilidades atualmente não corrigidas (aquelas que seriam classificadas abertamente como dia zero), toda a comunicação é criptografada. Ao contrário de outros grupos do projeto, as trocas de e-mail deste grupo não são publicadas.
Com base no trabalho do OVG, um cronograma bem definido entrega alterações de código-fonte para patches de segurança na terceira terça-feira de janeiro, abril, julho e outubro. A maioria (mas não todos) dos principais provedores de distribuição binária OpenJDK tem representantes no OVG. Isso garante que as atualizações nas distribuições Java Runtime sejam disponibilizadas aos usuários. Como principal desenvolvedor de Java, a Oracle lança seus patches como uma atualização crítica de patch (CPU) ao mesmo tempo que o repositório de código-fonte é atualizado. Assim que a CPU da Oracle estiver disponível publicamente, o embargo a outras distribuições OpenJDK será suspenso e elas estarão livres para publicar sua atualização. Quanto tempo isso leva depende do provedor; obviamente, quanto maior o atraso, maior o risco de exploração de vulnerabilidades não corrigidas. Para o Azul Core, que inclui as compilações Zulu do OpenJDK, as atualizações foram disponibilizadas de forma consistente dentro de uma hora após o levantamento do embargo.
Como é a boa higiene de segurança Java agora
Para garantir o mais alto nível de segurança para seus aplicativos baseados em JVM, você deve ter uma estratégia bem definida para implantar atualizações JDK em seu patrimônio. É muito comum ouvir usuários dizerem que não precisam corrigir suas máquinas porque estão protegidas por um firewall. Um firewall não é impenetrável. A violação da Equifax mencionada anteriormente utilizou uma exploração em máquinas fora do firewall; uma vez que essas máquinas fossem comprometidas, os invasores poderiam passar pelo firewall como se ele não estivesse lá.
