Nosso primeiro ciclo de lançamento com segurança reforçada: o que aprendemos e o que vamos mudar

Kunal AnandDiretor de Produto | F5

Nota do editor (14 de outubro de 2026): A F5 agora chama as “versões reforçadas” de “versões críticas”. Essa mudança de terminologia reflete a relevância dessas versões e a importância de implantar a versão mais recente o quanto antes.

Em julho, eu escrevi sobre nossa transição para versões reforçadas mensais e notificações de segurança mensais. Na época, eu disse que essa frequência era adequada ao momento em que estávamos e que a mesma disciplina que nos levou a abandonar o ciclo trimestral nos faria mudar novamente quando o cenário assim exigisse.

Após um ciclo de lançamento, aprendemos muito. Aprendemos com clientes, com parceiros e observando como uma cadência mensal é recebida em ambientes de produção. Parte do que aprendemos está mudando nossa abordagem.

A partir da HR2, em 2 de setembro, as versões reforçadas serão lançadas a cada seis semanas, em vez de mensalmente. Também estamos suspendendo as notificações regulares de segurança que planejávamos publicar junto com elas.

Quero explicar como chegamos até aqui, porque o raciocínio por trás disso é mais importante do que as datas.

O que os clientes nos disseram

Lançamos o HR1 em 15 de julho e, em seguida, fizemos o que dissemos que faríamos: ouvimos.

O que ouvimos foi consistente e, na verdade, não dizia respeito à F5. As organizações que utilizam nossos produtos em seus fluxos mais críticos nos disseram que uma cadência mensal não lhes dava tempo suficiente para testar, preparar e implantar — não necessariamente porque nossas versões fossem difíceis de assimilar isoladamente, mas porque chegavam ao mesmo tempo que as de todos os outros fornecedores. Todo fornecedor de peso está reagindo à mesma mudança, e o impacto acumulado recai sobre a mesma equipe, com recursos limitados, dentro de cada empresa.

Seis semanas representam o reconhecimento de que uma correção que ninguém consegue implantar não é, de fato, uma correção. A velocidade com que os clientes conseguem assimilar uma mudança agora faz parte da própria equação de segurança, e uma cadência mais rápida do que essa capacidade de assimilação cria exposição em vez de reduzi-la.

A outra constatação que tivemos aponta na direção oposta. Os clientes que investiram em gerenciamento de frotas e automação estão obtendo melhorias significativas na velocidade com que conseguem realizar atualizações. Um cliente global com uma grande frota de F5 BIG-IP reduziu o tempo de atualização de mais de seis meses para aproximadamente duas semanas.

Por que estamos pausando as notificações de segurança

A segunda mudança é mais difícil, e quero ser direto sobre o motivo.

Quando anunciamos as notificações mensais de segurança, partimos do pressuposto de que um intervalo de aproximadamente 30 dias entre o lançamento da versão reforçada e a divulgação daria aos clientes um prazo viável para atualizar antes que os detalhes se tornassem públicos. Esse pressuposto refletia o que considerávamos mais adequado naquele momento.

Essa premissa não é mais válida. Conversas com clientes e com outras pessoas do setor nas últimas semanas mudaram nossa avaliação sobre a quantidade de informações realmente necessária para criar um exploit funcional. Os modelos de fronteira continuam aprimorando sua capacidade de raciocinar a partir de sinais limitados — um diff, uma descrição parcial, um intervalo de versões — até chegar a uma cadeia de ataque funcional. A janela que pensávamos estar criando para os defensores é, na prática, também uma janela para os invasores, e ela está se estreitando.

Portanto, estamos suspendendo as notificações regulares enquanto trabalhamos em conjunto para definir como deve ser a divulgação responsável neste contexto. Haverá exceções. Quando uma vulnerabilidade estiver sendo explorada ativamente, quando estivermos coordenando ações com pesquisadores ou órgãos governamentais, ou quando obrigações regulatórias ou contratuais assim exigirem, trataremos a divulgação de outra forma. Esta não é uma posição permanente em relação à transparência. É uma decisão tomada sob a premissa de que a proteção dos clientes vem em primeiro lugar, e continuaremos a reavaliá-la.

Reconheço que isso é desconfortável. Para mim, como ex-CISO, também é desconfortável. As normas de divulgação existem por bons motivos, e a comunidade de segurança as construiu ao longo de décadas de experiências difíceis. No entanto, essas normas foram concebidas para um mundo em que o intervalo entre "detalhes publicados" e "exploit disponível" era medido em semanas. Esse intervalo desapareceu, e toda organização que publica informações sobre vulnerabilidades terá de lidar com as implicações dessa mudança.

A questão mais difícil: triagem sem classificação de gravidade

Esta é a questão que, na minha opinião, o setor ainda não enfrentou plenamente.

A maioria dos programas de gerenciamento de vulnerabilidades se baseia na gravidade. Vulnerabilidades críticas são corrigidas em 24 horas, as de gravidade alta em três dias, as de gravidade média em um sprint e as de gravidade baixa quando há tempo. Esse modelo parte de duas premissas: que as classificações de gravidade preveem o risco de forma significativa e que você dispõe dessas classificações para trabalhar.

Ambas as premissas estão perdendo validade.

A primeira está se desfazendo porque invasores que usam modelos de ponta não precisam de uma vulnerabilidade crítica. Eles encadeiam falhas. Três problemas de baixa gravidade que, individualmente, poderiam ficar perto do fim de uma fila de triagem tornam-se um caminho viável para comprometer um sistema quando um modelo consegue analisar os três simultaneamente. Ao examinarmos nosso próprio código, estamos encontrando essa classe de problemas: falhas de menor gravidade que poderiam ser encadeadas. Eliminá-las sistematicamente é o que torna o software mais seguro. Avaliá-las individualmente por gravidade é o que faz com que permaneçam sem correção.

A segunda premissa está perdendo força porque os fornecedores — inclusive nós — passarão a divulgar menos detalhes e mais tarde. Isso fará com que as equipes de segurança sintam que estão perdendo o controle, e eu entendo o motivo.

Então, o que fazer em vez disso?

Priorize pela exposição, não pela classificação. A acessibilidade, a exposição à Internet, o raio de impacto e a criticidade para o negócio são critérios mais consistentes do que uma pontuação CVSS que talvez você nem receba. Um ativo exposto e sem correção representa um risco, independentemente do que diz o aviso de segurança.

Mantenha-se atualizado como prática. As organizações que se sairão bem nesse ambiente serão aquelas que considerarem a execução da versão reforçada mais recente um compromisso operacional permanente, em vez de um evento desencadeado por uma classificação de gravidade. Essa é uma mudança tanto cultural quanto técnica e, para que seja mantida, requer o respaldo da liderança executiva.

Invista agora na capacidade de absorção. Automação, visibilidade da frota, janelas de manutenção recorrentes e reversão testada são o que torna viável um ritmo mais acelerado. Esses investimentos parecem opcionais neste momento. Daqui a um ano, não parecerão mais.

Parta do princípio de que essa lacuna existirá e proteja-se contra ela. Nenhuma organização aplica correções instantaneamente. A proteção em tempo de execução — detecção comportamental, aplicação de patches virtuais e controles que não dependem do conhecimento da vulnerabilidade específica — pode ajudar a proteger durante o intervalo entre a disponibilização de uma correção e sua implantação. Esse intervalo não vai desaparecer. Planeje levando-o em conta, em vez de tentar contorná-lo.

Sobre mudar de ideia

Tomamos uma decisão em julho com base nas melhores informações de que dispúnhamos. Nós a colocamos em prática, aprendemos com clientes e parceiros e fizemos ajustes. A alternativa — manter uma posição só porque a havíamos anunciado — teria sido pior para clientes e parceiros.

Eu disse em julho que continuaríamos nos adaptando à medida que o cenário e as suas necessidades evoluíssem. É assim que isso funciona na prática. A posição mais honesta para qualquer fornecedor neste momento é reconhecer que as práticas estabelecidas estão sendo reavaliadas em tempo real em todo o setor, e quem afirma já ter resolvido tudo isso por completo não está prestando atenção.

O que não muda é o padrão de excelência que exigimos de nós mesmos. As organizações colocam a F5 entre seus usuários e suas aplicações, seus agentes e suas APIs. Essa posição explica por que identificamos e corrigimos problemas no ritmo em que fazemos isso, por que testamos da forma como testamos e por que tomamos a decisão que tomamos sobre a divulgação. Agradecemos o feedback que ajudou a moldar essa decisão. Continuem enviando suas opiniões e mantenham-se atualizados.

Sobre o autor

Kunal AnandDiretor de Produto | F5

Kunal Anand lidera a organização de produtos da F5 como Chief Product Officer. Responsável pela visão, estratégia e execução de produtos, ele garante o desenvolvimento de soluções inovadoras que resolvem desafios críticos e proporcionam experiências excepcionais aos clientes. Em sua função anterior como Chief Technology and AI Officer, Kunal definiu a estratégia e a visão de tecnologia e IA da empresa. Antes da F5, Kunal exerceu simultaneamente os cargos de Chief Technology Officer e Chief Information Security Officer na Imperva. Sua trajetória na Imperva começou em 2018, com a aquisição da Prevoty, uma startup de segurança de aplicações que ele cofundou em 2013. Antes de ingressar na Prevoty, foi Diretor de Tecnologia na BBC Worldwide. Kunal tem um amplo histórico de inovação e conhecimento técnico especializado, além de ter ocupado cargos de liderança em equipes de segurança, dados, tecnologia e engenharia na Gravity, MySpace e no Laboratório de Propulsão a Jato da NASA. Kunal tem mais de 15 anos de experiência em IA e aprendizado de máquina, abrangendo treinamento de modelos, uso de algoritmos baseados em IA para aprimorar produtos e projeto e implementação de arquiteturas de IA. Kunal é bacharel em Ciência da Computação pelo Babson College.

Mais publicações de Kunal Anand