TL;DR
Aikido prüft, ob ein Dependency-Update Breaking Changes enthält und zeigt, was sich geändert hat. Anschließend analysiert es die Codebasis, um festzustellen, ob diese Änderungen tatsächlich Auswirkungen auf Ihre Codebasis haben. Teams erhalten klare Antworten, bevor sie einen Sicherheits-Fix mergen.
Die Dokumentation finden Sie hier.
Warum Breaking Changes wichtig sind
Wir alle wissen, dass Entwickelnde im Flow-Zustand bleiben möchten, doch Sicherheitsprobleme reißen sie oft daraus. Nicht nur, weil es die Konzentration stört, sondern auch, weil es Unsicherheit darüber schafft, was als Nächstes zu tun ist. Entwickelnde sind von Warnmeldungen überfordert, aber wenn sie nicht wissen, ob ihr Code sicher zum Mergen oder die Bibliothek sicher zum Upgraden ist, sehen sie oft ganz von Maßnahmen ab.
Und das zeigt sich: 65 % der Entwickelnden, Sicherheitsingenieure und Führungskräfte gaben an, Sicherheitsprüfungen umgangen, Befunde abgetan oder Behebungen verzögert zu haben, was auf Ermüdung und mangelndes Vertrauen in die Ergebnisse zurückzuführen ist, laut 2026 Aikido's State of AI in Security & Development.
Aikido möchte den Entwickelnden dieses Vertrauen zurückgeben. Eine Möglichkeit, dies zu erreichen, sind zwei komplementäre Funktionen für Open-Source-Abhängigkeiten: Breaking Changes und Upgrade Impact Analysis.
Entwickelnde möchten nicht aufgefordert werden, eine Behebung vorzunehmen, ohne zu verstehen, warum. Sie möchten auch wissen, welche Nebenwirkungen eine solche Maßnahme hätte: Würde sie beispielsweise ihre Anwendung beschädigen?
Genau diese Art von Unsicherheit beunruhigt Entwickelnde.
Sichtbarkeit von Breaking Changes
Von vornherein Kontext bereitzustellen, anstatt die kognitive Belastung der Entwickelnden zu erhöhen, ist das Kernstück der Breaking-Changes-Funktion.
Bevor ein Upgrade gemergt wird, analysiert Aikido den Changelog, um festzustellen, ob es Breaking Changes einführt. Jedes Upgrade fällt in eine von drei Kategorien: unbedenklich, Breaking Changes erkennbar oder manuelle Validierung erforderlich.
1. Alles unbedenklich
Wenn keine Breaking Changes vorliegen, wird das Upgrade eindeutig als sicher gekennzeichnet.
Entwickelnde können dann zuversichtlich sein, die Behebung vorzunehmen.
Das Abhängigkeitsproblem zeigt die minimale Version an, die zur Behebung erforderlich ist. In diesem Spring Security Beispiel unten ist klar, dass die CVE durch ein Upgrade auf Version 6.1.2 behoben wird.
Das Upgrade ist eindeutig als sicher gekennzeichnet, mit dem relevanten Changelog zur Überprüfung verlinkt, was den Entwickelnden versichert, dass nichts beschädigt wird, wenn das Upgrade angewendet wird.
2. Breaking Changes treten auf
Wenn Breaking Changes vorliegen, die Ihre Anwendung betreffen, wird Aikido dies kennzeichnen.
Die Breaking Changes werden direkt neben dem Upgrade zusammengefasst.
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.
Das Upgrade modifiziert Ihren Anwendungscode nicht, kann aber Interaktionen mit Legacy-Clients oder internen Tools, die solche Anfragen senden, sowie andere Edge Cases unterbrechen.
Stattdessen können sie entweder sofort ein Upgrade durchführen, in dem Wissen, dass keine Legacy-Clients existieren und der gesamte Traffic über gut konfigurierte Proxys läuft, oder alternativ vor dem Mergen testen, das Upgrade für einen Sprint planen, in dem Infrastrukturarbeiten sinnvoller sind, oder sogar ein Upgrade für die CVE-Behebung durchführen, aber die strikte Einstellung vorübergehend lockern.
3. Manuelle Validierung erforderlich
Wenn kein Changelog existiert, wird diese Unsicherheit explizit gemacht.
Das gibt den Entwickelnden Transparenz darüber, dass es keine Anhaltspunkte für oder gegen Breaking Changes gibt. Dies könnte daran liegen, dass der Maintainer Breaking Changes nicht dokumentiert oder die Projektpflege mangelhaft ist. Wenn kein Changelog verfügbar ist, ist das Upgrade riskanter, was den Entwickelnden signalisiert, dass sie das Upgrade manuell validieren müssen.
Einführung von Upgrade Impact Analysis
Breaking Changes zu identifizieren ist nur die halbe Miete.
Die Upgrade Impact Analysis geht weiter, indem sie die Codebasis analysiert, um festzustellen, ob diese Änderungen tatsächlich genutzt werden. Die Analyse läuft automatisch als Teil des Pull Requests.
Im folgenden Beispiel führt ein Upgrade von Mongoose zu zwei Breaking Changes. Der Pull Request identifiziert die genauen Dateien und Zeilen, die sich auf veraltetes Verhalten verlassen, erklärt, was sich geändert hat, und skizziert, was aktualisiert werden muss.
Aikido macht direkt im Pull Request sichtbar, was normalerweise das Lesen von Release Notes und das Nachverfolgen von Verwendungen erfordern würde.
Das Upgrade einer Abhängigkeit sollte kein Rätselraten erfordern. Wenn die Auswirkung einer Änderung klar ist, können Teams ohne Zögern voranschreiten (und Security-Fixes werden eher gemergt).
Breaking Changes und die Analyse der Upgrade-Auswirkungen sind für JavaScript-, Python-, Java- (einschließlich Kotlin und Scala), Go-, .NET-, PHP- und Clojure-Projekte verfügbar.
