TL;DR
Aikido checks if a dependency update contains breaking changes and shows what changed. It then analyzes the codebase to determine whether those changes actually impact your codebase. Teams get clear answers before merging a security fix.
Check out the docs here.
Why breaking changes matter
We all know developers want to keep in the flow state, but security issues often pull them out of it. Not just because it interrupts focus, but because it introduces uncertainty about what to do next. Developers are overwhelmed by alerts, but If they don’t know if their code is safe to merge or the library is safe to upgrade, they often avoid taking action altogether.
And it shows: 65% of developers, security engineers, and leaders said they bypassed security checks, dismissed findings or delayed fixes because of fatigue and lack of trust in findings, according to 2026 Aikido's State of AI in Security & Development.
Aikido aims to give developers this confidence back. One of the ways we’re doing that is through two complementary features for open source dependencies: Breaking Changes and Upgrade Impact Analysis.
Developers don’t want to be told that they ought to make a fix without understanding why. They also want to know what the side effects of any such action are: would it, for instance, break their application?
This is exactly the kind of uncertainty that makes developers uneasy.
Breaking changes visibility
Providing context upfront, instead of adding to developers’ cognitive load, is what the breaking changes feature is all about.
Before an upgrade is merged, Aikido analyzes the changelog to determine whether it introduces breaking changes. Every upgrade falls into one of three buckets: all clear, breaking changes apparent, or manual validation required.
1. All clear
If there are no breaking changes, the upgrade is clearly marked as safe.
Developers can then be confident to go ahead with the fix.
The dependency issue shows the minimal version required to fix it. In this Spring Security example below, it’s clear that the CVE will be fixed by upgrading to version 6.1.2.
The upgrade is clearly marked as safe, with the relevant changelog linked for verification, reassuring developers that nothing will break when the upgrade is applied.
2. Breaking changes appear
If there are breaking changes that affect your application, then Aikido will flag this.
The breaking changes are summarized directly alongside the upgrade.
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.
The upgrade doesn’t modify your application code, but it can break interactions with legacy clients or internal tools that send those types of requests, along with other edge cases.
Instead, they can either upgrade immediately, knowing that no legacy clients exist and that all traffic goes through well-configured proxies, or alternatively, they could test before merging, schedule the upgrade for a sprint where infrastructure work makes more sense, or even upgrade for the CVE fix but temporarily relax the strict setting.
3. Manual validation required
If no changelog exists, that uncertainty is made explicit.
That provides the developer with transparency that there is no evidence either way on breaking changes. This could be down to the maintainer not documenting breaking changes or poor project maintenance. When no changelog is available, the upgrade is riskier, which signals to developers that they need to validate the upgrade manually.
Introducing Upgrade Impact Analysis
Identifying breaking changes is only half the picture.
Upgrade impact analysis goes further by analyzing the codebase to determine whether those changes are actually exercised. The analysis runs automatically as part of the pull request.
In the example below, upgrading Mongoose introduces two breaking changes. The pull request identifies the exact files and lines that rely on deprecated behavior, explains what changed, and outlines what needs to be updated.
Aikido surfaces what would normally require reading release notes and tracing usages directly in the pull request.
Upgrading a dependency shouldn’t require guesswork. When the effect of a change is clear, teams can move forward without hesitation (and security fixes are more likely to get merged).
Breaking Changes and Upgrade Impact Analysis are available for JavaScript, Python, Java (including Kotlin and Scala), Go, .NET, PHP, and Clojure projects.
