O ano é 2026, e ainda ...

• Atualizar nem sempre é simples
• Patch não deveria ser uma atividade de Segurança
• Ownership também significa responsabilidade
• E isso não é um problema apenas de infraestrutura
• “Mas atualizar pode quebrar”
• O risco de fazer alguma coisa é visível. O de não fazer nada nem sempre é.
• Talvez a palavra seja justamente prudência
• Nem tudo deveria precisar virar um controle
• Uma reflexão
• Referências 📚
  • Outras publicações deste blog

Há alguns anos escrevi aqui no blog sobre Gestão de Vulnerabilidades e, mais recentemente, voltei ao assunto quando falei sobre a estruturação de processos de Gestão de Vulnerabilidades, OffSec e AppSec . Normalmente, quando falamos sobre Gestão de Vulnerabilidades, acabamos discutindo scanners, processos, indicadores, SLAs, ferramentas e formas de priorização. Porém, ultimamente tenho refletido sobre uma questão um pouco mais básica: por que ainda precisamos convencer profissionais de tecnologia de que a tecnologia pela qual são responsáveis precisa ser mantida atualizada?

Parece uma pergunta simples, talvez até óbvia, mas quem trabalha com Gestão de Vulnerabilidades provavelmente já viveu alguma versão da mesma história. Uma vulnerabilidade é identificada, Segurança reporta, o prazo começa a correr, acompanhamos, cobramos, criamos reuniões, o prazo vence, solicitamos um plano de ação, escalamos o problema e, alguns meses depois, a vulnerabilidade continua lá. É claro que esse não é o comportamento de todos os times ou profissionais, mas acontece com frequência suficiente para provocar uma reflexão: em que momento manter um sistema atualizado deixou de fazer parte da responsabilidade de quem mantém aquele sistema?

Atualizar nem sempre é simples  

Antes que alguém queira me xingar, obviamente sei que aplicar patches não significa simplesmente clicar em “Update”. Existem sistemas legados, aplicações que não suportam determinadas versões, dependências, requisitos de disponibilidade, janelas de mudança, fabricantes que tornam nossa vida bastante difícil e até aplicações que ninguém quer tocar porque a última pessoa que realmente entendia como aquilo funcionava saiu da empresa há alguns anos. Também existem situações em que aplicar determinada atualização imediatamente realmente não é possível. Tudo isso faz parte da vida real de quem trabalha com Tecnologia, e seria ingenuidade ignorar essas dificuldades.

O problema, na minha opinião, não é existir uma exceção. O problema é quando a exceção vira o processo. Quando deixamos de perguntar por que não conseguimos atualizar determinado sistema e passamos a considerar normal manter tecnologias desatualizadas indefinidamente, talvez estejamos criando um problema muito maior do que a vulnerabilidade que apareceu no scanner.

Patch não deveria ser uma atividade de Segurança  

Talvez esse seja um dos pontos que mais me incomodam nessa discussão. Quando Segurança identifica uma vulnerabilidade em um servidor e informa isso ao responsável, não foi Segurança que criou a necessidade de manutenção daquele servidor. A necessidade já estava lá. Da mesma forma, quando uma ferramenta de SCA identifica uma biblioteca vulnerável dentro de uma aplicação, não foi a ferramenta que criou o problema; ela apenas mostrou uma condição que já existia.

O NIST SP 800-40 Rev. 4 - Guide to Enterprise Patch Management Planning utiliza uma definição da qual gosto bastante ao tratar Enterprise Patch Management como manutenção preventiva da tecnologia. Acho interessante parar um pouco nessa definição. Ninguém considera estranho fazer manutenção preventiva em equipamentos, monitorar capacidade de armazenamento, renovar certificados antes do vencimento ou substituir hardware antes que ele chegue ao fim de sua vida útil. Então por que esperamos uma vulnerabilidade aparecer para descobrir que um sistema operacional, framework ou biblioteca não é atualizado há anos?

Talvez tenhamos transformado algo que deveria fazer parte da manutenção normal da tecnologia em uma atividade reativa iniciada pelo time de Segurança. Segurança encontra, reporta e começa um fluxo de acompanhamento. Com o tempo, cria-se a percepção de que aquela atividade pertence a Segurança, quando na verdade a vulnerabilidade é apenas uma consequência visível de uma necessidade de manutenção que já existia.

Ownership também significa responsabilidade  

Falamos bastante sobre ownership em Tecnologia. Falamos de “you build it, you run it”, DevOps, SRE, Product Teams, squads, autonomia e descentralização. Tudo isso trouxe avanços enormes para a forma como construímos e operamos tecnologia, mas autonomia também deveria vir acompanhada de responsabilidade.

Se sou responsável por um produto, aplicação, servidor, banco de dados, cluster ou qualquer outro componente tecnológico, deveria conhecer minimamente sua condição. Qual versão estamos utilizando? Ela ainda possui suporte? Quando termina esse suporte? Existem atualizações disponíveis? Temos componentes EOL? Nossas dependências continuam sendo mantidas? Quando foi a última atualização? Existe um processo recorrente de manutenção ou estamos esperando Segurança abrir uma vulnerabilidade?

Se a resposta for a última opção, talvez nosso problema seja um pouco maior do que aquela CVE.

Frameworks de governança como o COBIT, da ISACA, ajudam a colocar governança e gestão da informação e tecnologia dentro de uma responsabilidade organizacional maior. Da mesma forma, o ITIL possui práticas relacionadas a Change Enablement, Deployment Management, IT Asset Management, Information Security Management e Continual Improvement. São referências diferentes, com objetivos diferentes, mas que ajudam a lembrar algo bastante simples: manter, modificar, conhecer e melhorar a tecnologia são atividades normais da própria gestão de tecnologia. Elas não deveriam começar somente quando Segurança abre um ticket.

E isso não é um problema apenas de infraestrutura  

Talvez durante muitos anos tenhamos associado patch management principalmente a servidores: Windows Update, apt update, yum update, firmware, banco de dados, appliances e coisas do tipo. Porém, aplicações modernas são enormes quebra-cabeças construídos utilizando código escrito por outras pessoas. Utilizamos frameworks, libraries, packages, containers, runtimes, SDKs, dependências diretas, dependências transitivas e algumas dependências que, depois de alguns anos, ninguém sabe exatamente por que ainda estão lá. 😅

A própria OWASP, ao tratar de Vulnerable and Outdated Components, chama atenção para situações nas quais organizações não conhecem as versões dos componentes utilizados, mantêm software vulnerável, sem suporte ou desatualizado, ou não atualizam plataformas, frameworks e dependências de maneira adequada. Na documentação sobre Component Analysis, existe ainda outro ponto interessante: manter componentes continuamente atualizados pode diminuir o esforço necessário quando surge uma vulnerabilidade que exige correção urgente.

Isso deveria fazer parte da engenharia do produto. Existe uma diferença importante entre pensar “Segurança encontrou uma CVE, então precisamos atualizar a biblioteca” e pensar “somos responsáveis por esse produto, portanto manter suas dependências saudáveis faz parte do nosso trabalho”. A ação pode eventualmente ser a mesma, mas a cultura por trás dela é completamente diferente.

“Mas atualizar pode quebrar”  

Pode, e esse é um argumento perfeitamente válido. Um patch pode causar indisponibilidade, uma nova versão de biblioteca pode alterar comportamento, uma atualização de framework pode exigir mudanças na aplicação e uma atualização de infraestrutura pode afetar componentes dependentes. O problema talvez esteja justamente aí: se temos medo de atualizar nossos sistemas, precisamos entender por que temos medo de atualizá-los.

Temos testes automatizados suficientes? Temos ambientes adequados para validação? Temos observabilidade? Conseguimos realizar rollback? Nossos deploys são automatizados? Conseguimos utilizar estratégias como canary ou blue/green quando necessário? Sabemos quais aplicações dependem daquele componente? Ou cada mudança ainda é uma aventura?

A pesquisa DORA é particularmente interessante nesse contexto porque há anos estuda a capacidade das organizações de realizar mudanças de software de maneira rápida e confiável. Métricas como deployment frequency, change fail rate e failed deployment recovery time ajudam a deslocar a discussão de simplesmente evitar mudanças para desenvolver a capacidade de mudar com segurança. Talvez, portanto, a pergunta não devesse ser apenas “e se o patch quebrar?”, mas também “por que nossa engenharia não nos permite atualizar com segurança?”. Essa segunda pergunta provavelmente revela problemas muito mais interessantes do que a vulnerabilidade específica que iniciou a discussão.

O risco de fazer alguma coisa é visível. O de não fazer nada nem sempre é.  

Talvez exista também um componente comportamental nessa história. Se aplicarmos um patch hoje e a aplicação parar, teremos um incidente hoje. Alguém vai ligar, alguém vai reclamar e alguém provavelmente precisará explicar o que aconteceu. Existe uma consequência clara e imediata. Agora imagine a decisão oposta: não aplicar. Hoje nada acontece, amanhã também não, passam três meses e continua tudo funcionando. Aos poucos surge a sensação de que não fazer nada foi a decisão correta.

Mas não necessariamente foi. Apenas ainda não experimentamos a consequência daquela decisão.

É um pouco como dirigir sem cinto de segurança. Podemos dirigir durante anos sem precisar dele e isso não significa que foi prudente dirigir sem ele. A ausência de um incidente não transforma automaticamente uma decisão ruim em uma boa decisão.

Talvez a palavra seja justamente prudência  

Quanto mais penso nesse assunto, menos acredito que seja exclusivamente um problema de Segurança. Talvez seja uma questão de prudência na gestão da tecnologia. E é interessante observar que referências de áreas bastante diferentes acabam convergindo para essa necessidade.

A ISO/IEC 27002:2022, por exemplo, possui controles relacionados ao gerenciamento de vulnerabilidades técnicas. O PCI DSS v4.0.1, em seus requisitos 6 e 11, estabelece expectativas relacionadas à identificação e ao tratamento de vulnerabilidades em sistemas e aplicações. A OWASP fala explicitamente sobre componentes vulneráveis e desatualizados. O NIST trata patch management como manutenção preventiva. O ITIL aborda práticas relacionadas ao ciclo de vida, mudança, deployment, ativos e melhoria contínua, enquanto o COBIT coloca tecnologia dentro de um sistema maior de governança e accountability. Já a pesquisa DORA nos ajuda a olhar para nossa capacidade de realizar mudanças de maneira frequente e confiável.

São comunidades diferentes olhando para o problema por perspectivas diferentes: Segurança, Governança, Gestão de Serviços, Engenharia de Software, Operações e Compliance. Talvez isso seja um bom indicativo de que não estamos simplesmente diante de um “problema do time de Segurança”.

Nem tudo deveria precisar virar um controle  

Nem todo comportamento correto precisa existir porque existe uma norma obrigando. Nem tudo precisa virar política, SLA, indicador ou reunião de acompanhamento. Algumas coisas deveriam acontecer simplesmente porque somos profissionais responsáveis pela tecnologia que colocamos e mantemos em produção.

Se um componente chegou ao fim do suporte, precisamos planejar sua substituição. Se determinada plataforma acumula anos de defasagem, temos dívida técnica. Se repetidamente não conseguimos atualizar uma aplicação, precisamos questionar sua arquitetura. Se cada patch exige um projeto extraordinário, talvez seja necessário questionar nosso modelo operacional. Se não sabemos quais bibliotecas nossas aplicações utilizam, precisamos melhorar nosso processo de desenvolvimento. Isso não deveria ser apenas uma discussão de Segurança. Isso é engenharia.

E talvez seja exatamente aqui que esteja a parte que mais me incomoda. Um time de Segurança não deveria precisar passar boa parte do seu tempo dizendo para outros profissionais de Tecnologia: “atualize seu servidor”, “atualize sua biblioteca”, “essa versão não possui mais suporte”, “o prazo venceu”, “precisamos de um plano”, “você já conseguiu aplicar o patch?”. Depois repetir a mesma conversa na semana seguinte, no mês seguinte e, algumas vezes, no trimestre seguinte.

Segurança possui um papel importante. Precisamos identificar problemas, trazer contexto, ajudar na priorização, testar, questionar, orientar e alertar. Mas existe um limite para aquilo que conseguimos resolver através de scanners, processos, dashboards, reuniões e escalonamentos. Depois desse limite existe algo muito mais simples: responsabilidade profissional.

Uma reflexão  

Então gostaria de terminar deixando algumas perguntas para quem trabalha com Tecnologia. Se você trabalha com infraestrutura, a manutenção de segurança faz parte do seu ciclo normal de operação ou acontece apenas quando Segurança abre uma vulnerabilidade? Se você desenvolve software, atualizar frameworks e dependências faz parte da manutenção normal do seu produto ou só entra no backlog quando alguma ferramenta reclama? Se você é Product Owner, existe capacidade reservada para manter a saúde técnica do produto ou tudo precisa necessariamente virar feature? Se você trabalha com Arquitetura, nossas decisões permitem que os componentes evoluam ou estamos criando sistemas tão acoplados que qualquer atualização vira um projeto?

E, principalmente, se você lidera times de Tecnologia: se amanhã o time de Segurança parasse de cobrar vulnerabilidades, seus times continuariam atualizando seus ambientes e aplicações?

Talvez essa seja a pergunta mais importante deste texto. Se a resposta for “não”, provavelmente você não possui um processo maduro de manutenção. Possui um processo de cobrança de Segurança, e são coisas bastante diferentes.

Podemos implementar scanners melhores, melhorar processos, criar indicadores e adotar NIST, ISO, PCI, COBIT, ITIL, OWASP e qualquer outro framework. Tudo isso ajuda, mas nenhum deles consegue substituir algo muito mais básico: prudência, diligência, conscientização e responsabilidade sobre aquilo que colocamos e mantemos em produção.

Talvez, antes de procurar a próxima ferramenta ou processo de gestão de vulnerabilidades que melhor se encaixa com sua organização, precisemos voltar a discutir uma coisa bem mais simples:

O que significa ser owner de uma tecnologia?

👾

Referências 📚  

NIST SP 800-40 Rev. 4 - Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology
https://csrc.nist.gov/pubs/sp/800/40/r4/final

ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls
Especialmente o controle 8.8 - Management of technical vulnerabilities.
https://www.iso.org/standard/75652.html

PCI DSS v4.0.1 - Payment Card Industry Data Security Standard
Especialmente Requirements 6 e 11.
https://www.pcisecuritystandards.org/document_library/

OWASP Top 10 - A06: Vulnerable and Outdated Components
https://owasp.org/Top10/2021/A06_2021-Vulnerable_and_Outdated_Components/

OWASP - Component Analysis
https://owasp.org/www-community/Component_Analysis

OWASP - Software Component Verification Standard (SCVS)
https://scvs.owasp.org/

DORA - Software Delivery Performance
https://dora.dev/guides/dora-metrics/

ISACA - COBIT
https://www.isaca.org/resources/cobit

ITIL - ITIL Practices
https://www.peoplecert.org/ITIL4-practices

Outras publicações deste blog  

Gestão de Vulnerabilidades com Greenbone OpenVAS
https://tiagotavares.io/blog/gestao-de-vulnerabilidades-com-greenbone-openvas_dez2021/

Processo de Gestão de Vulnerabilidades e Automação para OffSec e AppSec utilizando Atlassian Jira
https://tiagotavares.io/blog/vulnerability_management_jira_context_offsec_appsec/