TL;DR
O Aikido verifica se uma atualização de dependência contém breaking changes e mostra o que mudou. Em seguida, ele analisa a base de código para determinar se essas mudanças realmente impactam sua base de código. As equipes obtêm respostas claras antes de mesclar uma correção de segurança.
Confira a documentação aqui.
Por que as breaking changes importam
Todos sabemos que os desenvolvedores querem manter o estado de fluxo, mas as questões de segurança frequentemente os tiram dele. Não apenas porque interrompe o foco, mas porque introduz incerteza sobre o que fazer em seguida. Os desenvolvedores são sobrecarregados por alertas, mas se não souberem se seu código é seguro para mesclar ou se a biblioteca é segura para fazer upgrade, eles frequentemente evitam tomar qualquer ação.
E isso se reflete: 65% dos desenvolvedores, engenheiros de segurança e líderes afirmaram que ignoraram verificações de segurança, descartaram descobertas ou atrasaram correções devido à fadiga e à falta de confiança nos resultados, de acordo com o Estado da IA em Segurança e Desenvolvimento da Aikido em 2026.
O Aikido visa devolver essa confiança aos desenvolvedores. Uma das maneiras de fazer isso é através de duas funcionalidades complementares para dependências de código aberto: Breaking Changes e Análise de Impacto de Upgrade.
Os desenvolvedores não querem ser informados de que devem fazer uma correção sem entender o porquê. Eles também querem saber quais são os efeitos colaterais de tal ação: isso, por exemplo, quebraria sua aplicação?
Este é exatamente o tipo de incerteza que deixa os desenvolvedores apreensivos.
Visibilidade de Breaking Changes
Fornecer contexto antecipadamente, em vez de aumentar a carga cognitiva dos desenvolvedores, é o objetivo principal da funcionalidade de breaking changes.
Antes que um upgrade seja mesclado, o Aikido analisa o changelog para determinar se ele introduz breaking changes. Cada upgrade se enquadra em uma de três categorias: tudo certo, breaking changes aparentes ou validação manual necessária.
1. Tudo certo
Se não houver mudanças disruptivas, a atualização é claramente marcada como segura.
Os desenvolvedores podem então ter confiança para prosseguir com a correção.
O problema de dependência mostra a versão mínima necessária para corrigi-lo. Neste exemplo de Spring Security abaixo, fica claro que a CVE será corrigida com a atualização para a versão 6.1.2.
A atualização é claramente marcada como segura, com o changelog relevante vinculado para verificação, tranquilizando os desenvolvedores de que nada será quebrado quando a atualização for aplicada.
2. Mudanças disruptivas aparecem
Se houver mudanças disruptivas que afetem sua aplicação, o Aikido sinalizará isso.
As mudanças disruptivas são resumidas diretamente ao lado da atualização.
In this example, Tomcat may have previously allowed requests with slightly malformed headers, or those that had a missing <host> header, or even conflicting host information. The new version rejects those requests with a 400 Bad Request by default.
A atualização não modifica o código da sua aplicação, mas pode quebrar interações com clientes legados ou ferramentas internas que enviam esses tipos de requisições, juntamente com outros casos de borda.
Em vez disso, eles podem atualizar imediatamente, sabendo que não existem clientes legados e que todo o tráfego passa por proxies bem configurados, ou, alternativamente, podem testar antes de fazer o merge, agendar a atualização para um sprint onde o trabalho de infraestrutura faça mais sentido, ou até mesmo atualizar para a correção da CVE, mas relaxar temporariamente a configuração estrita.
3. Validação manual necessária
Se não existir um changelog, essa incerteza é explicitada.
Isso proporciona ao desenvolvedor a transparência de que não há evidências de mudanças disruptivas em nenhum dos sentidos. Isso pode ser devido ao mantenedor não documentar as mudanças disruptivas ou a uma manutenção deficiente do projeto. Quando nenhum changelog está disponível, a atualização é mais arriscada, o que sinaliza aos desenvolvedores que eles precisam validar a atualização manualmente.
Apresentando a Análise de Impacto de Atualização
Identificar mudanças disruptivas é apenas parte do cenário.
A análise de impacto de atualização vai além, analisando a base de código para determinar se essas mudanças são realmente exercidas. A análise é executada automaticamente como parte do pull request.
No exemplo abaixo, a atualização do Mongoose introduz duas mudanças disruptivas. O pull request identifica os arquivos e linhas exatos que dependem de comportamento depreciado, explica o que mudou e descreve o que precisa ser atualizado.
O Aikido exibe o que normalmente exigiria a leitura de notas de lançamento e o rastreamento de usos diretamente no pull request.
Atualizar uma dependência não deveria exigir suposições. Quando o efeito de uma mudança é claro, as equipes podem avançar sem hesitação (e as correções de segurança têm mais chances de serem incorporadas).
Mudanças Disruptivas e Análise de Impacto de Atualização estão disponíveis para projetos JavaScript, Python, Java (incluindo Kotlin e Scala), Go, .NET, PHP e Clojure.
