要約
Aikido 依存関係のアップデートに互換性を損なう変更が含まれているかどうかを確認し、変更内容を表示します。その後、コードベースを分析して、それらの変更が実際にあなたのコードベースに影響を与えるかどうかを判断します。チームはセキュリティ修正をマージする前に明確な回答を得られます。
こちらのドキュメントをご覧ください。
なぜ互換性のない変更が重要なのか
開発者がフロー状態を維持したいのは周知の事実だが、セキュリティ問題がそれを妨げることは多い。集中を妨げるだけでなく、次に何をすべきか不確実性が生じるからだ。開発者はアラートに圧倒されがちだが、コードをマージしても安全か、ライブラリをアップグレードしても安全か判断できない場合、行動自体を避ける傾向がある。
そしてその実態が明らかになった：2026Aikido「セキュリティと開発におけるAIの現状」レポートによると、開発者、セキュリティエンジニア、リーダーの65％が、疲労や調査結果への不信感から、セキュリティチェックを回避したり、調査結果を無視したり、修正を遅らせたりしたと回答している。
Aikido 開発者にこの自信を取り戻してもらうことを目指しています。その方法の一つが、オープンソース依存関係二つの補完的な機能：Breaking Changes（互換性のない変更）とUpgrade Impact Analysis（アップグレード影響分析）です。
開発者は、理由を理解せずに修正すべきだと言われることを望んでいません。また、そのような行動の副作用についても知りたいと考えています。例えば、アプリケーションが壊れてしまうことはないでしょうか？
まさにこの種の不確実性が開発者を不安にさせるのだ。
破壊的変更の可視性
開発者の認知負荷を増大させるのではなく、事前にコンテキストを提供することこそが、互換性のない変更機能の本質である。
アップグレードがマージされる前に、 Aikido は変更履歴を分析し、互換性を損なう変更が含まれているかどうかを判断します。すべてのアップグレードは次の3つのカテゴリのいずれかに分類されます：問題なし、明らかな互換性破綻、手動検証が必要。
1. 全て安全
互換性を損なう変更がない場合、アップグレードは安全であると明示的に表示されます。
開発者はその後、修正を自信を持って進めることができます。
依存関係の問題は、修正に必要な最小バージョンを示しています。以下のSpring Securityの例では、バージョン6.1.2にアップグレードすることでCVEが修正されることが明らかです。
アップグレードは安全であることが明確に示されており、検証用の関連変更履歴がリンクされているため、開発者はアップグレードを適用しても何も壊れないと安心できます。
2. 互換性のない変更が発生します
アプリケーションに影響する互換性のない変更がある場合、 Aikido はこれをフラグ付けします。
互換性のない変更点は、アップグレードの横に直接まとめられています。
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.
アップグレードはアプリケーションコードを変更しませんが、レガシークライアントやそのようなリクエストを送信する内部ツールとの連携が破綻する可能性があります。その他のエッジケースも同様です。
代わりに、レガシークライアントが存在せず、すべてのトラフィックが適切に設定されたプロキシを経由することを前提に即時アップグレードするか、あるいはマージ前にテストを実施し、インフラ作業がより適切なスプリントにアップグレードをスケジュールするか、CVE修正のためのアップグレードを実施しつつ一時的に厳格な設定を緩和する選択肢もある。
3. 手動による検証が必要
変更履歴が存在しない場合、その不確実性が明示される。
これにより開発者は、互換性のない変更の有無について証拠がないという透明性を得られます。これは保守担当者が互換性のない変更を文書化していないか、プロジェクトの保守が不十分なことが原因である可能性があります。変更履歴が利用できない場合、アップグレードのリスクは高まり、開発者は手動でアップグレードを検証する必要があることを示唆します。
アップグレード影響分析のご紹介
破壊的変更を特定することは、全体像の半分に過ぎない。
アップグレード影響分析はさらに一歩進んで、コードベースを分析し、それらの変更が実際に実行されるかどうかを判断します。この分析はプルリクエストの一部として自動的に実行されます。
以下の例では、Mongooseのアップグレードにより2つの互換性のない変更が発生します。プルリクエストでは、非推奨の動作に依存している具体的なファイルと行を特定し、変更内容を説明するとともに、更新が必要な箇所を明示しています。
Aikido 通常はリリースノートを読み、プルリクエスト内で直接使用箇所を追跡する必要があるものを表面化します。
依存関係のアップグレードに推測作業は必要ありません。変更の影響が明確であれば、チームは躊躇なく進められます（セキュリティ修正もマージされやすくなります）。
JavaScript、Python、Java（KotlinおよびScalaを含む）、Go、.NET、PHP、Clojureプロジェクト向けに、破壊的変更とアップグレード影響分析が利用可能です。
