O prazo previsto no SLA para uma vulnerabilidade de dependência crítica está prestes a expirar, mas não há espaço no sprint atual para os testes manuais necessários para garantir que não se interrompa a produção. O próprio incumprimento do prazo de correção constituirá uma constatação no seu próximo relatório SOC 2 ou ISO 27001, mas o risco de exploração também está a aumentar com o avanço dos modelos de IA. Fica-lhe apenas uma de duas más opções: abrandar o desenvolvimento do produto para corrigir esta vulnerabilidade ou explicar à sua equipa de segurança e a outras partes interessadas por que razão violou um SLA importante.
Se o cenário acima lhe parece familiar, saiba que não está sozinho. As organizações estão a ficar cada vez mais para trás na corrida para corrigir vulnerabilidades conhecidas e cumprir os seus SLAs de segurança. Um estudo da Verizon, publicado em 2026, revela que a exploração de vulnerabilidades é a principal causa de violações confirmadas, ultrapassando o roubo de credenciais pela primeira vez nos quase 20 anos de história do relatório.
A correção de vulnerabilidades continua a perder terreno devido a um aumento exponencial no número de vulnerabilidades identificadas. Segundo o mesmo relatório da Verizon: apenas 26% das vulnerabilidades conhecidas e exploradas (KEVs) foram totalmente corrigidas em 2025, uma descida em relação aos 38% do ano anterior, enquanto o tempo mediano de correção aumentou para 43 dias, face aos 32 do ano anterior. O relatório da Verizon atribui esta situação ao facto de 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, sejam canalizados mais recursos para resolver o problema e que as correções acompanhem essa evolução. No entanto, se trabalha nesta área, sabe que isso simplesmente não tem acontecido. Existem duas razões principais pelas quais este problema está a agravar-se em vez de melhorar:
- Uma grande parte das dependências está, na prática, sem manutenção, mas está tão profundamente integrada nos sistemas de produção que não é possível simplesmente removê-las ou migrá-las facilmente para uma versão principal mais recente. Pense em
log4j. - As políticas de SLA e os programas de conformidade não têm em conta se existe ou não um responsável pela manutenção ativo.
O que as equipas fazem hoje: as fases do luto na aprendizagem de uma segunda língua (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 uma correção do desenvolvedor original, mas não há garantia de quando — ou se alguma vez — o responsável pela manutenção irá corrigir a vulnerabilidade. Alguns responsáveis pela manutenção corrigem a vulnerabilidade em poucos dias ou menos, enquanto outros não o fazem. Este problema agrava-se no caso de pacotes amplamente utilizados, mas que, na prática, não são mantidos e não têm, efetivamente, um responsável. A espera apenas esgota o tempo previsto no SLA, sem que a vulnerabilidade seja corrigida.
Raiva: Retirar e substituir a dependência problemática. Parece uma solução eficaz e, provavelmente, é mesmo, por hoje. Mas quando a nova versão do pacote receber um CVE no mês que vem e outro no mês seguinte, fica-se preso num ciclo de substituições que custa tempo real à sua equipa na construção do produto. Raramente é o ato de substituir a versão do pacote em si que realmente custa, mas sim todo o trabalho adicional para cumprir as auditorias de dependências, verificar a compatibilidade da API e executar testes para garantir que não se danificam funções críticas da aplicação em produção.
Negociação: À medida que o prazo do SLA vai esgotando-se, decide solicitar uma exceção. Isto dá-lhe mais tempo para encontrar uma solução, mas não resolve o problema subjacente. O ticket desapareceu do seu painel por hoje, mas sabe que irá reaparecer. Pior ainda, irá surgir como uma non-conformidade da próxima vez que um auditor ou a equipa de segurança de um cliente analisar o registo de correções. Uma vez, provavelmente, ainda se consegue sobreviver, mas quando se cria um padrão de exceções, isto pode ser pior do que um único prazo do SLA não cumprido.
Depressão: A última opção é fazer você mesmo o backport do patch de segurança. Esta opção é uma solução viável, se conseguir dedicar tempo para compreender o CVE, isolar a correção e incorporá-la seletivamente na base de código existente. A desvantagem é que, a partir de agora, ficará responsável por este patch e por todos os patches futuros desta biblioteca. Trata-se de um compromisso em termos de recursos que provavelmente desviará a sua equipa da sua missão principal.
A solução: Bibliotecas « Aikido »
Se levássemos a metáfora até ao fim, a fase final seria a aceitação. Desistir e arcar com as consequências da conformidade, ou arriscar uma ruptura. Não aceites isso. O « Aikido Libraries» rompe este ciclo.
Aikido O Libraries fornece versões corrigidas das suas dependências vulneráveis. O nome do pacote e a API pública permanecem inalterados. A única alteração é um sufixo que identifica a correção e uma referência ao registo em Aikido.
Cada patch tem como ponto de partida a correção do próprio mantenedor. O Aikido retira a alteração de segurança do upstream e aplica-a à versão que utiliza. Só são feitos ajustes nos casos em que o runtime mais antigo assim o exija. Cada um é testado automaticamente, depois revisto por uma pessoa e enviado como um diff que pode ler na íntegra antes de o integrar.
A transparência do patch é importante para a confiança. Não está a receber a correção proprietária da Aikido para a vulnerabilidade, mas sim a correção do responsável pela manutenção, adaptada à sua versão, com o diff completo, caso queira analisá-lo.
Vejamos um exemplo concreto. A versão da biblioteca jsonwebtoken 8.5.1 tem um CVE-2022-23529 classificada como «Elevada». A versão das Bibliotecas « Aikido » passa a ser jsonwebtoken 8.5.1-aikido.5 e retroaplica as correções de segurança provenientes 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 uma camada de compatibilidade para o ambiente de execução mais antigo do Node. A atualização para 9.0.0 pois essa mesma correção teria implicado no lançamento de uma versão principal que deixasse de suportar versões mais antigas do Node e alterasse a forma como verify() trata de tokens sem assinatura.
O catálogo da Aikido Libraries conta atualmente com mais de 9 000 bibliotecas seguras em JavaScript, Python, Java, .NET, PHP, Go e Ruby. Além disso, disponibilizamos entre 50 e 100 novas correções por dia. Para os repositórios inscritos, disponibilizamos bibliotecas seguras corrigidas no prazo de 48 horas para vulnerabilidades conhecidas que já foram exploradas e no prazo de 7 dias para CVEs de gravidade «Crítica» e «Elevada».
Ligue-o uma vez
Aikido As bibliotecas funcionam de duas formas. Para um único pacote, trata-se de uma opção no menu AutoFix já existente: encerrar 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 diário do AutoFix para os CVEs divulgados após a ativação. Pode ativá-la para um único repositório importante ou para toda a sua base de código a partir da interface de utilizador do Aikido .
Nada disto o obriga a ficar com a versão segura. Atualize sempre que quiser a API ou funcionalidades mais recentes e continuará a receber as correções de CVE que vêm incluídas nessa versão. Fechar o CVE e alterar a versão deixam de ser a mesma decisão.
Cumpra sempre os seus SLAs
Aponte o Aikido para um repositório e, em poucos minutos, obterá o seu primeiro PR pronto para fusão relativo a um CVE real. Explore o catálogo para ver quais das suas dependências estão abrangidas ou proteja um repositório para obter o seu primeiro patch.
