Exploitabilityだけでは答えにならない。Breakabilityこそ重要です。

AppSecのパラドックス：なぜ、もっと修正が進まないのか？

なぜ開発者は、AppSecの脆弱性を見つけるたびに、すぐすべて修正しないのでしょうか？最もよくある答えは、時間です。最新のセキュリティツールは、コードベース内の脆弱性を何千件も検出することがあります。すべて修正しようとすれば、開発チームのキャパシティを使い切ってしまい、多くの場合、機能開発やその他の優先事項と競合します。

しかし、脆弱性の修正に必要な時間は近年変化しています。以前は、検出結果を調査し、修正方法を学び、コードを手作業で変更するだけで、一日がかりになることも珍しくありませんでした。現在では、自動化やAI支援ツールがその作業の多くを担い、コーヒーを淹れる間にマージ可能なコード変更を準備できます。特にSCAの脆弱性では、既知の脆弱なバージョンから、CVEを修正した新しいバージョンにパッケージを更新するだけで済むことがよくあります。

では、時間がもはやボトルネックではないとしたら、何が問題なのでしょうか？信頼です。開発者がセキュリティ問題への対処を望まないから修正を無視するわけではありません。むしろ、コードを壊してしまうのではないかという不安から、修正をためらうことが多いのです。

優先順位付けに欠けていた要素、Breakabilityの登場

チームがより確かな判断で優先順位を付けられるよう、Snyk Open Sourceに新機能Breakability Riskを導入します。

Breakabilityの第1段階では、開発者が日々問いかける疑問に取り組みました。Snykが推奨した修正を適用すると、アプリが壊れてしまわないか？依存関係の更新には、どれも何らかのリスクが伴います。「単純な」パッケージ参照の更新であっても、APIの変更によってコードのコンパイルに失敗することがあります。さらに厄介なのは、APIメソッドのシグネチャは変わらなくても、微妙な動作の変更が加わり、コードはコンパイルできるのに実行時に失敗するケースです。

直接依存関係のうち、2つ以上が同じ推移的依存関係を共有していることはよくあります。複数の直接依存関係が同じ基盤パッケージに依存している場合、CVEを修正するために依存関係グラフの一部を更新すると、別の依存関係との新たな互換性問題が生じることがあります。これが恐ろしい「依存関係地獄」です。

Breakability Riskは、今すぐ安全に適用できる更新と、さらに詳しい調査が必要な更新を見分けます。

信頼がセキュリティを前進させる

Breakability分析の実験を重ねた結果、一貫した傾向が見えてきました。アプリケーションを壊すリスクが低いと分かれば、開発者が修正をマージする可能性は大幅に高まります。実験では、Breakabilityリスクの低い更新は、リスクの高い変更と比べて4倍の割合でマージされました。

分析によると、すべての修正の約3分の1がBreakabilityリスクの低いカテゴリーに該当します。平均的なSnykのお客様の場合、こうした低リスクの更新を優先することで、年間でさらに数千件の脆弱性を修正できる可能性があります。

Breakabilityの実例：低リスクと高リスク

Snykは、優先順位付けを支援し、修正を加速するマージリスクタグをプルリクエスト内に直接表示するようになりました。Snyk Open Sourceでは、開発者のスキル向上に役立つ詳細情報、コンテキストに応じたリスクスコア、学習リソースをSnyk Learnで提供しています。

シナリオ1：「すぐできる改善」

このシナリオでは、複数の正規表現サービス拒否（ReDoS）脆弱性を修正するため、Snyk Open Sourceがチームに対し、[libxmljs2]の新しいバージョンへの更新を促すプルリクエストを作成しています。

• 分析：このアップグレードで主に変更されるのは、サポート終了となったNode.jsバージョンのサポートが終了する点です

• Breakability Risk：重大な動作変更がないため、Snykはマージリスク：低と判定します

• 判断：ボタンを押して、コードを保護し、次に進みましょう。

シナリオ2：「慎重に進める」

ここでは、[i18n]の更新によってプロトタイプ汚染が修正されますが、グローバルシングルトンからインスタンスベースの構成へと、アーキテクチャが変更されます。

• 分析：ライブラリの基本的な使用パターンが変わっています。

• Breakability Risk：ライブラリのアーキテクチャに破壊的変更があるため、Snykはマージリスク：高と判定します。

• 判断：自分のコードを確認し、必要な変更を加えるまではマージしないでください。

新しい修正の優先順位付け

どの修正ワークフローでも、最初に問うべきことはシンプルだと考えています。最小限の手間とリスクで、この問題を修正できるか？

答えが「はい」なら、修正しましょう。Breakabilityを活用すれば、チームは低リスクの更新から対処でき、CVEのバックログの3分の1、さらには半分近くをワンクリックで修正できるようになります。「何かを壊してしまう」という不安を取り除くことで、チームは自信を持ってバックログの大部分を解消できます。長年開発チームを悩ませてきたセキュリティ負債を修正し、エンジニアリングの作業負荷を増やすことなくセキュリティリスクを減らせます。

SnykはReachabilityやRisk Scoreを廃止するわけではありません。

優先順位付けの視点としてReachabilityは有用ですが、「この脆弱性には絶対に到達できない」と「この脆弱性に到達する経路が見つかっていない」には大きな違いがあります。後者の状況は前者よりはるかに多く見られます。「到達可能な経路が見つからない」からといって、到達可能な経路が存在しないと考えるのは安全ではありません。特に現在は、攻撃者がAIハッキングツールを使って弱点を見つけ、かつてない速さで悪用しているのです。到達しない可能性がある脆弱性のパッケージリスクを受け入れるのではなく、悪影響のリスクを抑えながら、より簡単に修正できるようにしています。

BreakabilityとSnyk AI Security Fabric

この新しい修正のアプローチは、AI Security Fabricを推進するうえで重要です。AIセキュリティの運用化に向けた実践的な道筋で説明したように、Breakabilityは推奨される修正への信頼を高め、単なる優先順位付けの視点を超えることで、リスク低減の最適化に役立ちます。また、予測可能で信頼に基づくプロセスを実現し、チームが破壊的変更への不安を減らしながら、より多くの修正をより速くマージできるようにします。

Breakabilityを始める

Breakabilityの第1段階は、すべてのSnyk Open Sourceのお客様が利用できるSnyk Preview機能として提供中です。有効にすると、Snykが作成したプルリクエストに対する破壊的変更リスクの評価をすぐに確認できます。ぜひお試しいただき、ご感想をお聞かせください。

脆弱性の優先順位付けと修正を、より確かな判断で見直しませんか？AIによるインサイトが、チームを検出の先へと導き、予測可能で拡張性の高いリスク低減を実現する方法をご紹介します。eBook「シフトレフトから、設計段階からのセキュリティへ」を今すぐダウンロードしてください。