Está quase sem tempo num SLA relativo a uma vulnerabilidade crítica numa dependência, mas não tem margem no sprint atual para os testes manuais necessários para garantir que não quebra a produção. O próprio incumprimento do prazo de remediação é uma não-conformidade no seu próximo relatório SOC 2 ou ISO 27001, mas o risco de exploração também está a aumentar com a evolução dos modelos de IA. Fica com duas más escolhas: abrandar o desenvolvimento do produto para corrigir esta vulnerabilidade ou explicar à sua equipa de segurança e a outras partes interessadas porque é que quebrou um SLA importante.
Se o cenário acima lhe parece familiar, não está sozinho. As organizações estão a ficar cada vez mais para trás na corrida para colmatar vulnerabilidades conhecidas e cumprir os respetivos SLAs de segurança. Um estudo da Verizon, publicado em 2026, mostra que a exploração de vulnerabilidades é a causa número 1 de incidentes confirmados, ultrapassando as credenciais roubadas pela primeira vez em quase 20 anos de história do relatório.
A remediação continua a perder terreno devido a uma explosão de vulnerabilidades identificadas. Do mesmo relatório da Verizon: apenas 26% das vulnerabilidades conhecidas exploradas (KEVs) foram totalmente remediadas em 2025, abaixo dos 38% do ano anterior, enquanto o tempo mediano de remediação cresceu para 43 dias, acima dos 32 do ano anterior. O relatório da Verizon atribui este facto a as organizações terem mais 50% de vulnerabilidades críticas para corrigir.
Porque é que isto continua a acontecer
Não é descabido esperar que, à medida que a importância das vulnerabilidades aumenta, fossem aplicados mais recursos ao problema e as correções acompanhassem o ritmo. Mas, se trabalha nesta área, sabe que não tem sido esse o caso. Existem duas razões principais pelas quais este problema está a piorar em vez de melhorar:
- Uma enorme parte das dependências está essencialmente sem manutenção, mas profundamente enterrada em sistemas de produção para ser simplesmente removida ou atualizada facilmente para uma nova versão principal. Pense em
log4j. - As políticas de SLA e os programas de conformidade não querem saber se existe um programador ativo a manter o projeto.
O que as equipas fazem hoje: as fases do luto de SLA
Quando o tempo se esgota, a maioria das equipas de engenharia passa por um ciclo previsível de más opções. Assemelha-se muito ao clássico modelo de luto de Kübler-Ross.
Negação: A maioria das equipas começa por aguardar por um patch a montante (upstream), mas não há garantia de quando, ou mesmo se, o programador irá corrigir a vulnerabilidade. Alguns corrigem em dias ou menos, enquanto outros não o fazem. Este problema é agravado em pacotes amplamente utilizados, mas efetivamente sem manutenção e sem um proprietário claro. Esperar apenas consome o seu prazo de SLA, sem resolver a vulnerabilidade.
Raiva: Remover e substituir a dependência problemática. Parece uma correção real, e provavelmente é para hoje. Mas quando a nova versão do pacote receber um CVE no próximo mês e outra no mês seguinte, fica preso num ciclo de substituição que custa à equipa tempo valioso na construção do produto. Raramente é o ato de substituir a versão do pacote em si que lhe custa mais, mas sim todo o trabalho adjacente para cumprir auditorias de dependências, verificar a compatibilidade de APIs e executar testes para garantir que não quebra funções críticas da aplicação em produção.
Negociação: À medida que o prazo do SLA se esgota, decide solicitar uma exceção. Isto dá-lhe mais tempo para encontrar uma solução, mas não resolve o problema subjacente. O ticket desaparece do seu painel de controlo por hoje, mas sabe que voltará a surgir. Pior ainda, aparecerá como uma ocorrência na próxima vez que um auditor ou a equipa de segurança de um cliente analisar o registo de remediação. Uma vez é provável que seja tolerável, mas quando acumula um padrão de exceções, isto pode ser pior do que um único prazo de SLA falhado.
Depressão: A última opção é aplicar o patch de segurança por iniciativa própria (backport). Esta opção é uma solução real, caso consiga dedicar tempo para compreender o CVE, isolar a correção e aplicá-la seletivamente (cherry-pick) na base de código existente. O lado negativo é que passa a ser responsável por este patch e por todos os futuros patches desta biblioteca a partir de agora. É um compromisso de recursos que provavelmente desvia a equipa da sua missão principal.
A solução: Aikido Libraries
Se levássemos a metáfora até ao fim, a fase final seria a aceitação. Desistir e aceitar a penalização de conformidade, ou arriscar uma quebra. Não aceite isso. O Aikido Libraries quebra este ciclo.
O Aikido Libraries fornece versões corrigidas das suas dependências vulneráveis. O nome do pacote e a API pública mantêm-se inalterados. A única alteração é um sufixo que identifica a correção e uma fixação (pin) ao registo do Aikido.
Cada correção começa a partir da própria correção do programador principal. O Aikido retira a alteração de segurança upstream e aplica-a à versão que está a executar. Os ajustes são feitos apenas onde o runtime mais antigo o exige. Cada um é testado automaticamente, depois revisto por uma pessoa e disponibilizado como um diff que pode ler na íntegra antes de fazer o merge.
A transparência da correção é importante para a confiança. Não está a receber a correção proprietária do Aikido para a vulnerabilidade, mas sim a correção do criador adaptada à sua versão, com o diff completo, caso pretenda inspecioná-la.
Vejamos um exemplo concreto. A versão da biblioteca jsonwebtoken 8.5.1 tem um CVE-2022-23529 classificada como High. A versão do Aikido Libraries passa a ser jsonwebtoken 8.5.1-aikido.5 e aplica o backport das correções de segurança de jsonwebtoken 9.0.0 para 8.5.1. A alteração consiste em adições: novos ficheiros de validação de chaves, um dos quais inclui um shim de compatibilidade para o runtime Node mais antigo. Atualizar para 9.0.0 para obter a mesma correção teria significado uma versão principal (major release) que deixava de suportar o Node antigo e alterava a forma como verify() lida com tokens não assinados.
O catálogo do Aikido Libraries conta atualmente com mais de 9.000 bibliotecas seguras em JavaScript, Python, Java, .NET, PHP, Go e Ruby. Também lançamos entre 50 a 100 novas correções todos os dias. Para os repositórios inscritos, disponibilizamos bibliotecas seguras e corrigidas no espaço de 48 horas para vulnerabilidades conhecidas e exploradas, e no prazo de 7 dias para CVEs Críticos e Altos.
Ative uma vez
O Aikido Libraries funciona de duas formas. Para um único pacote, é uma opção no menu AutoFix existente: fechar um CVE sem atualizar, um PR de cada vez. Para um repositório, a ativação fixa as suas dependências e envia um PR AutoFix Diário para CVEs divulgados após a ativação. Pode ativá-lo para um único repositório importante ou para toda a sua base de código a partir da interface do Aikido.
Nada disto o prende à compilação segura. Atualize sempre que quiser a API ou as funcionalidades mais recentes, e continuará a receber as correções de CVE associadas. Fechar o CVE e alterar a versão deixam de ser a mesma decisão.
Cumprimento garantido dos seus SLAs
Aponte o Aikido a um repositório e este devolverá o seu primeiro PR pronto a fundir contra uma CVE real em poucos minutos. Explore o catálogo para verificar quais das suas dependências estão cobertas, ou proteja um repositório para obter o seu primeiro patch.
