脆弱性 CVEを検出した際のアドバイスは、いつも同じです。「アップグレードしてください」。パッチが適用されたバージョンに移行して、チケットをクローズし、次の作業に進めるようにするのです。これはもはや反射的な行動となっており、実際にうまくいくかどうかを立ち止まって考える人は誰もいません。
提案されている修正には、具体的には3つの問題があります。アップグレード先のバージョンが存在せず、今後も登場しない、パッチが適用されたバージョンがまだリリースされていない、あるいは修正がリリースされたものの、アプリケーションが動作しなくなる、といった問題です。
要するに、ベストプラクティスやSOC2からISO27001に至るあらゆるフレームワークでは、依存関係 保つよう推奨しています。しかし、アップグレードは問題の解決にはつながりませんが、多くのツールが提示できる解決策はそれしかないのが現状です。
必ずしもそれが間違った判断だったわけではありません。メンテナンス担当者は（ありがたいことに）最新バージョンの脆弱性を修正し続けており、長年にわたりそれだけで十分でした。
CVEが報告される > メンテナンス担当者がパッチを適用する > ユーザーがアップグレードする > 修正が適用される。
しかし、メンテナンス担当者は通常、過去のバージョンに遡って修正を行うことはありません。そのため、各チームは可能な限り常に最新バージョンにアップグレードするよう習慣づけられ、攻撃者たちはそのパターンに気づき、エクスプロイト 学びました。 現在、CVEの修正を得るためにアップグレードを行う際、アップデートのどこかにマルウェアが混入している可能性があるため、最新バージョンを取得することがもはや自動的に安全とは限らなくなっています。
今年初め、攻撃者たちは、npmで最もダウンロード数の多いパッケージのいくつかを担当するメンテナーのアカウントを乗っ取りました。そのパッケージとは「chalk」と「debug」で、これら2つを合わせると、週間のダウンロード数は20億回を超えています。攻撃者たちは公式チャネルを通じて悪意のあるバージョンを公開し、自動更新が設定されていたすべてのパイプラインがそれらをそのまま取り込んでしまいました。ベストプラクティスに従っていたチームでさえ、数分後にはマルウェアを配布してしまう事態となりました。
これは、どちらを選んでも損をする状況です。最新の状態を維持すればマルウェアに感染するリスクがあり、更新を先送りすればセキュリティ上の負債が蓄積されていきます。これを、我々は「アップグレードの罠」と呼んでいます。実行しているバージョンと、それに適用されるセキュリティ修正プログラムは、必ずしも同じ判断である必要はありません。
アップグレードが失敗する3つの原因
もちろん、「アップグレード」は多くの場合有効であり、依然として重要な手段です。しかし、それが通用しなくなる状況が3つあります。
1つ目は、移行すべき固定されたバージョンが存在しない（そして今後も存在しない）場合です。例えば、 リクエスト、 Node.js で最もよく使われている HTTP クライアントの一つですが、2020 年以降、非推奨となっています。それにもかかわらず、今でも至る所で目にするのが、たいていは、もう何年も誰も手をつけていない親パッケージに引きずり込まれているからです。request に対してSCA を実行すると、サーバーサイドリクエストフォージェリ（SSRF）対策のバイパスに関する CVE が検出されます。SCA によると、この問題の修正策は何だと思いますか？ そう、アップグレードすることです。
しかし、肝心なのは、アップグレードできる対象が何もないということだ。そして、今後も決して現れることはないだろう。 リクエスト ここ数年、メンテナンスが行われていない。このアドバイザリも事実上それを認めており、この脆弱性はメンテナンス担当者がもはやサポートしていないバージョン（つまりすべてのバージョン）にのみ影響すると指摘している。したがって、このケースでは、「アップグレード」とは実際には削除することを意味する。 リクエスト 外に出て、次のようなものへと移り、 axios または node-fetch. これは書き換えと移行作業を意味し、誰かがそれに時間を割けるようになるまで、そのCVEはそのまま放置されたままになってしまうということです。
2つ目のアップグレードのタイプは、修正プログラムが存在しない場合です まだ パッケージが有効であるにもかかわらず。広く使われているライブラリ lodash 昨年、4.17.23までのすべての公開バージョンに影響を及ぼす2つの脆弱性が公表されていた期間がありました。それが最新バージョンだったため、アップグレード先となるバージョンは存在しませんでした。 npm audit CVEを報告し、修正プログラムが提供されていないことを伝えました。そのため、アップグレードを勧めるアドバイスは妥当ではあったものの、修正済みのリリースがまだ公開されていなかったため、実際には実行不可能でした。
3つ目は、修正プログラムがリリースされた結果、アプリケーションが動作しなくなってしまう場合です。 CVE-2026-48937 Node.js の事例が最近の例です。この脆弱性 に対する修正は脆弱性 SEMVER-MAJOR の更新 nghttp2 依存関係と、HTTP/2 優先度シグナリングのサポートの廃止。この脆弱性に関連する動作と廃止される機能は、同じ基盤となるコードの一部であったため、セキュリティ修正を適用する際に、その変更に伴う互換性破綻も併せて適用せざるを得ませんでした。ユーザーは、grep コマンドを使って setPriority そして .priority() そして、彼らがアップグレードを一切行えないうちに、それらを削除した。
これは、どのようなアップグレードにもつきもののリスクです。新しいリリースでは、パッケージの動作が大幅に変更され、それまで正常に動作していたものが動作しなくなったり、他の依存関係 併せてアップグレード依存関係 、あるいはインストールする前に移行作業が必要なメジャーバージョンとしてリリースされたりすることがあります。
さらに言えば、あるパッケージをバージョンアップすると、他の5つのパッケージもバージョンアップしなければならない場合があります。そのうちの1つが、システムが依存している機能を壊してしまう可能性もあります。そうなると、エンジニアリング部門は、収益を生み出すロードマップ項目とアップグレードのどちらを選ぶかという選択を迫られます。どちらが優先されるかは想像に難くないでしょう 😬。その結果、技術的負債が蓄積され、CVEも山積みになってしまうのです。
AIが状況を一変させた
多くの企業では、処理しきれないほど膨大なCVEの未処理案件を抱えており、最新の最先端モデルが脆弱性をより迅速に発見できることから、不安を抱えています。 しかし、さらに大きな脅威となっているのは、中程度の深刻度のCVEを組み合わせて、重大エクスプロイト に変えてしまう可能性があることです。現在の、スキャン、優先順位付け、そしてその作業をエンジニアに割り当てるというモデルでは、この問題に対処するのに十分なスピードでスケールアップできません。AIは事実上、既存の問題を悪化させており、組織にとってその解決がより緊急の課題となっています。
業界はこれに対してどのような対応をとっているのか
長い間、アップグレードこそが唯一現実的な解決策でした。それに伴って発生したCVEの未処理案件やビルドの不具合は、選択肢が限られていたことによる予測可能な結果でした。この問題に対するアプローチは、大きく分けて3つあります。そのうち2つは、ある問題を別の問題と引き換えにするものです。3つ目は、新たな問題を引き起こすリスクを負うことなく、実際にCVEを解決するものです。
1つ目は、利用時点でのスクリーニングです。パッケージがビルドに組み込まれる前に、「この依存関係をインストールしても安全か」というチェックが行われます。これは、特に「chalk」や「debug」のような攻撃が発生した後は、不可欠な対策です。しかし、すでに本番環境に導入されている脆弱なパッケージに対しては適用できません。これは修正策というよりは「ゲート」のようなものであり、その範囲外の場合は、依然としてアップグレードが唯一の解決策となります。
2つ目は、チームを堅牢化された代替スタックに移行させることです。チームがすでに運用しているものを修正する代わりに、他社が開発した独自のエコシステムへと押し込まれることになります。これは新規開発のアプリケーションであれば有効かもしれませんが、特定のライブラリやベースイメージに縛られている本番システムの場合、問題の修正が移行プロジェクトへと変わってしまいます。いったん移行してしまえば、そこから抜け出すこと自体が新たなプロジェクトとなります。
3つ目は、修正をすでに使用中のバージョンにバックポートすることです。ほとんどの組織には、これを行うためのリソース、専門知識、あるいは意欲がありません。CVEがアップストリームで修正された際、その修正を行う最小限のコード部分を新しいリリースから切り出し、すでに稼働中の古いバージョンにクリーンに適用します。 他に何も変更されていないことを検証するには、真の専門知識と継続的なメンテナンスが必要です。ディストリビューションでは、長年にわたりこの手法のバリエーションが実践されてきました。しかし、アプリケーションライブラリ全体にわたって、CVEが報告されるペースに合わせて自動的にこれを行うことは、まったく別の問題です。このアプローチでは、アプリケーションがすでに信頼しているバージョンを維持し、修正のみを適用するため、凍結されたバージョンに対してCVEが蓄積されることも、最新リリースを取得してそれに付随するあらゆる変更を取り込むこともありません。
ソフトウェアスタックを、長年住み続けている家だと考えてみてください。ほとんどのツールは、玄関から入ってくるものを選別するか、修理リストを渡して「自分で何とかして」と言うか、あるいは自分たちが建てた新しい、より小さな家に引っ越すよう求めてくるかのいずれかです。しかし、ほとんどのチームが実際に望んでいるのは、今住んでいる家を修理することなのです。
Aikido を使えば、アプリケーションが依存しているオープンソースパッケージの脆弱性を、アップグレードすることなく修正できるオプションが利用可能になりました。
