TL;DR
Aikido si une mise à jour de dépendance contient des modifications importantes et affiche ce qui a changé. Il analyse ensuite le code source pour déterminer si ces modifications ont réellement un impact sur votre code source. Les équipes obtiennent des réponses claires avant de fusionner un correctif de sécurité.
Consultez la documentation ici.
Pourquoi les changements radicaux sont importants
Nous savons tous que les développeurs veulent rester dans un état de fluidité, mais les problèmes de sécurité les en détournent souvent. Non seulement parce que cela perturbe leur concentration, mais aussi parce que cela introduit une incertitude quant à la marche à suivre. Les développeurs sont submergés d'alertes, mais s'ils ne savent pas si leur code peut être merge en toute sécurité merge la bibliothèque peut être mise à niveau en toute sécurité, ils évitent souvent de prendre des mesures.
Et cela se voit : selon le rapport 2026 Aikido State of AI in Security & Development, 65 % des développeurs, ingénieurs en sécurité et dirigeants ont déclaré avoir contourné les contrôles de sécurité, ignoré les résultats ou retardé les corrections en raison de la fatigue et du manque de confiance dans les résultats.
Aikido à redonner cette confiance aux développeurs. Pour ce faire, nous proposons notamment deux fonctionnalités complémentaires pour les dépendances open source : Breaking Changes et Upgrade Impact Analysis.
Les développeurs ne veulent pas qu'on leur dise qu'ils doivent apporter une correction sans comprendre pourquoi. Ils veulent également connaître les effets secondaires d'une telle action : cela risquerait-il, par exemple, de perturber le fonctionnement de leur application ?
C'est exactement ce genre d'incertitude qui inquiète les développeurs.
Visibilité des changements majeurs
Fournir le contexte dès le départ, plutôt que d'alourdir la charge cognitive des développeurs, voilà en quoi consiste la fonctionnalité « breaking changes ».
Avant qu'une mise à niveau ne soit fusionnée, Aikido le journal des modifications afin de déterminer si elle introduit des changements majeurs. Chaque mise à niveau est classée dans l'une des trois catégories suivantes : tout est clair, changements majeurs apparents ou validation manuelle requise.
1. Tout est clair.
S'il n'y a pas de changements majeurs, la mise à niveau est clairement indiquée comme sûre.
Les développeurs peuvent alors procéder à la correction en toute confiance.
Le problème de dépendance indique la version minimale requise pour le résoudre. Dans l'exemple Spring Security ci-dessous, il est clair que le CVE sera corrigé en passant à la version 6.1.2.
La mise à jour est clairement indiquée comme sûre, avec le journal des modifications correspondant accessible via un lien pour vérification, ce qui garantit aux développeurs que rien ne sera endommagé lors de l'application de la mise à jour.
2. Des changements radicaux apparaissent
Si des modifications importantes affectent votre application, Aikido en Aikido .
Les modifications importantes sont résumées directement à côté de la mise à niveau.
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.
La mise à niveau ne modifie pas le code de votre application, mais elle peut perturber les interactions avec les clients hérités ou les outils internes qui envoient ce type de requêtes, ainsi que d'autres cas particuliers.
Au lieu de cela, ils peuvent soit procéder immédiatement à la mise à niveau, sachant qu'il n'existe aucun client hérité et que tout le trafic passe par des proxys bien configurés, soit effectuer des tests avant la fusion, planifier la mise à niveau pour un sprint où les travaux d'infrastructure ont plus de sens, ou même procéder à la mise à niveau pour le correctif CVE tout en assouplissant temporairement le paramètre strict.
3. Validation manuelle requise
Si aucun journal des modifications n'existe, cette incertitude est explicitement mentionnée.
Cela offre au développeur une transparence totale, car il n'existe aucune preuve permettant de confirmer ou d'infirmer l'existence de modifications importantes. Cela peut s'expliquer par le fait que le responsable de la maintenance n'a pas documenté les modifications importantes ou par une mauvaise maintenance du projet. En l'absence de journal des modifications, la mise à niveau est plus risquée, ce qui indique aux développeurs qu'ils doivent valider la mise à niveau manuellement.
Présentation de l'analyse d'impact des mises à niveau
Identifier les changements majeurs n'est qu'une partie du travail.
L'analyse d'impact de la mise à niveau va plus loin en analysant le code source afin de déterminer si ces modifications sont réellement appliquées. L'analyse s'exécute automatiquement dans le cadre de la demande d'extraction.
Dans l'exemple ci-dessous, la mise à niveau de Mongoose introduit deux changements majeurs. La demande d'extraction identifie les fichiers et les lignes exacts qui dépendent d'un comportement obsolète, explique ce qui a changé et décrit ce qui doit être mis à jour.
Aikido ce qui nécessiterait normalement la lecture des notes de mise à jour et le suivi des utilisations directement dans la demande d'extraction.
La mise à niveau d'une dépendance ne devrait pas nécessiter de conjectures. Lorsque l'effet d'un changement est clair, les équipes peuvent aller de l'avant sans hésitation (et les correctifs de sécurité sont plus susceptibles d'être fusionnés).
Les modifications majeures et l'analyse d'impact des mises à niveau sont disponibles pour les projets JavaScript, Python, Java (y compris Kotlin et Scala), Go, .NET, PHP et Clojure.
