TL;DR
Aikido vérifie si une mise à jour de dépendance contient des breaking changes et indique ce qui a changé. Il analyse ensuite la base de code pour déterminer si ces changements ont réellement un impact sur votre codebase. Les équipes obtiennent des réponses claires avant de merger un correctif de sécurité.
Consultez la documentation ici.
Pourquoi les breaking changes sont importants
Nous savons tous que les développeurs souhaitent rester dans un état de flow, mais les problèmes de sécurité les en sortent souvent. Non seulement cela interrompt leur concentration, mais cela introduit également une incertitude quant à la marche à suivre. Les développeurs sont submergés par les alertes, mais s'ils ne savent pas si leur code peut être mergé en toute sécurité ou si la bibliothèque peut être mise à jour sans risque, ils évitent souvent d'agir.
Et cela se voit : 65 % des développeurs, ingénieurs en sécurité et leaders ont déclaré avoir contourné les contrôles de sécurité, ignoré les résultats ou retardé les correctifs en raison de la fatigue et du manque de confiance dans les conclusions, selon l'état de l'IA en sécurité et développement d'Aikido en 2026.
Aikido vise à redonner cette confiance aux développeurs. L'une des façons d'y parvenir est d'offrir 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 un correctif sans en comprendre la raison. Ils veulent également connaître les effets secondaires d'une telle action : cela casserait-il, par exemple, leur application ?
C'est précisément ce genre d'incertitude qui met les développeurs mal à l'aise.
Visibilité des breaking changes
Fournir le contexte en amont, au lieu d'ajouter à la charge cognitive des développeurs, voilà l'objectif de la fonctionnalité de breaking changes.
Avant qu'une mise à jour ne soit mergée, Aikido analyse le changelog pour déterminer si elle introduit des breaking changes. Chaque mise à jour se classe dans l'une des trois catégories suivantes : tout est clair, breaking changes apparents, ou validation manuelle requise.
1. Tout est clair
S'il n'y a pas de breaking changes, la mise à jour est clairement indiquée comme sûre.
Les développeurs peuvent alors procéder au correctif en toute confiance.
Le problème de dépendance indique la version minimale requise pour le corriger. Dans cet exemple Spring Security ci-dessous, il est clair que la CVE sera corrigée en passant à la version 6.1.2.
La mise à jour est clairement indiquée comme sûre, avec le changelog pertinent lié pour vérification, rassurant les développeurs que rien ne sera cassé lors de l'application de la mise à jour.
2. Des breaking changes apparaissent
S'il y a des breaking changes qui affectent votre application, Aikido le signalera.
Les breaking changes sont résumés directement à côté de la mise à jour.
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 à jour ne modifie pas le code de votre application, mais elle peut rompre les interactions avec des clients legacy ou des outils internes qui envoient ce type de requêtes, ainsi que d'autres cas limites.
Au lieu de cela, ils peuvent soit mettre à jour immédiatement, sachant qu'aucun client legacy n'existe et que tout le trafic passe par des proxies bien configurés, ou bien, ils pourraient tester avant de merger, planifier la mise à jour pour un sprint où le travail d'infrastructure est plus pertinent, ou même mettre à jour pour le correctif CVE mais assouplir temporairement le paramètre strict.
3. Validation manuelle requise
Si aucun journal des modifications n'existe, cette incertitude est explicitée.
Cela offre au développeur une transparence quant à l'absence de preuve concernant les modifications impactantes. Cela peut être dû au fait que le mainteneur ne documente pas les modifications impactantes ou à une mauvaise maintenance du projet. Lorsqu'aucun journal des modifications n'est disponible, la mise à niveau est plus risquée, ce qui signale aux développeurs qu'ils doivent valider la mise à niveau manuellement.
Présentation de l'analyse d'impact des mises à niveau
L'identification des modifications impactantes n'est qu'une partie du tableau.
L'analyse d'impact des mises à niveau va plus loin en analysant la base de code pour déterminer si ces modifications sont effectivement utilisées. L'analyse s'exécute automatiquement dans le cadre de la pull request.
Dans l'exemple ci-dessous, la mise à niveau de Mongoose introduit deux modifications impactantes. La pull request identifie les fichiers et les lignes exacts qui dépendent d'un comportement déprécié, explique ce qui a changé et décrit ce qui doit être mis à jour.
Aikido met en évidence ce qui nécessiterait normalement la lecture des notes de version et le traçage des utilisations directement dans la pull request.
La mise à niveau d'une dépendance ne devrait pas laisser de place à l'incertitude. Lorsque l'effet d'une modification est clair, les équipes peuvent avancer sans hésitation (et les correctifs de sécurité sont plus susceptibles d'être mergés).
Les modifications impactantes 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.
