アプリケーションには多数のパッケージやライブラリが含まれている。しかし、どれが侵害され、不正なコードが仕込まれているかを判断するのは容易ではない。そのような状況下で、新たなバージョンがリリースされるたびにすぐ適用していると、意図せず自分のアプリケーションまで汚染され、攻撃を受ける恐れがある。

　西川氏は「今まで教科書では、『脆弱（ぜいじゃく）性を修正するために、できるだけ早くアップデートしましょう』とされてきました。しかし、ソフトウェアサプライチェーン攻撃の登場によって、min-release-ageのような待機期間設定を入れておかなければ、逆に悪性コードが入る込んでしまう状況です」と述べ、「パッチがリリースされたらすぐに適用しよう」というこれまでのセキュリティの基本通りにはいかない、複雑な状況にあると指摘した。

　もちろん、セキュリティパッチは、安全性が確認できるならば迅速に適用するに越したことはない。そのために、バージョン情報や脆弱性情報の管理を支援する「GitHub Dependabot」などのツールもある。だが、「GitHub Dependabotにもたびたびバグが報告されています。そもそもDependabotのコアもOSSであり、これが侵害されれば一気にやられてしまう可能性もあります」と西川氏は警告する。

　状況を複雑にしているもう一つの要因がAIだ。

　AIの進化に伴い、公表・検出される脆弱性の数は急激に増加している。2025年の1年間に報告・公表された脆弱性は4万8185件に上った。CSIRTなどのセキュリティコミュニティーであるFIRSTは、2026年当初、この1年で公表される脆弱性は約5万9000件に上るだろうと予想していたが、上半期だけで想定以上のペースとなり、年間約6万6000件へと予想を上方更新した。

　西川氏はさらに、「これらはあくまでCVE-IDが付けられ、トリアージされた脆弱性だけですから、実際にはもっと増える可能性があります」と述べている。

　加えて、脆弱性が発見されてから悪用されるまでの期間も年々、短縮している。Zero Day Clockの調査によると、脆弱性が発表されてから攻撃されるまでの時間は、2025年は平均21.5日だったが、2026年は18時間まで縮まった。

　「公開から悪用までの期間の中央値はわずか5日です。もはや、脆弱性一つ一つについて、コンテキストを踏まえながら『この脆弱性は自組織に影響を与えるかどうか』を手動で判断を下していくのはおそらく限界に来ています」（西川氏）

　AIの登場によって攻撃のスピードが早まる分、パッチを適用するスピードも上げていかなければいけない。

　ただでさえ、どの脆弱性からパッチを適用するかを見極めるトリアージには慎重な判断が求められる。さらに、アップデート自体に不正なコードが混入している可能性まで考慮しなければならない現在では、こうした対応を手作業だけでこなすことはもはや現実的ではない。西川氏は、そのような時代が到来しつつあると警鐘を鳴らした。

いっそう高まる多層防御やレジリエンスの重要性

　西川氏はこうした状況を踏まえ、多層防御がいっそう要になり、インシデントが発生し得ることを前提にしたレジリエンスに重きを置くべきだとした。

　西川氏は、「今までは『攻撃を受けたら対応しましょう』という前提で対策してきました。しかし今や、既に攻撃を受けている可能性があることを踏まえ、常日頃から準備をしておく必要があります」と述べ、攻撃が到達する前にブロックするWAFやプロキシといった何らかの手段で緩和策を取るべきだとした。

　セキュリティパッチを適用するか、しないかの決定には、いっそう高度な判断が求められる。一方、判断に必要な技術や知見を持ち、しかも、文化や規模といった自社のコンテキストも踏まえて判断を下せるような「セキュリティエンジニア」となるとなかなか存在しないのが実情であり、それも課題の一つだという。

3つのポイントを重視しながら対策の検討を

　西川氏はさらに、こうしたソリューションはさておき、サプライチェーン攻撃が横行する中、3つのポイントを考慮しながら対策を検討してほしいと呼び掛けた。

　1つ目は、パッチ適用を手動に頼るのではなく、自動化を取り入れスピードアップすることだ。「この先、脆弱性はどんどん多く検出されていくでしょう。これに対し圧倒的な対応スピードが必要になります。従って手動ではなく、LLMを使うなどして、セキュリティパッチ適用のスピードを上げていく必要があります」（西川氏）

　2つ目は、システムやソフトウェアを構成する「部品」をできるだけ減らし、環境をできるだけ簡素化していくことだ。

　「アタックサーフェスが多ければ多いほど攻撃者は狙いやすくなります。また、攻撃者も、機密情報や秘匿性の高い情報にアクセスするには開発者を攻撃するのが最短ルートだということに気付き、開発者を狙った攻撃がどんどん増えています」（西川氏）。

　こうした事態を考慮すると、開発に利用してきたミドルウェアやライブラリから、開発者が利用するエディタやWebブラウザの拡張機能、プラグインに至るまで、「これは本当に必要なのか」を見直し、減らしていくことを検討すべきだとした。

　そして3つ目は、レジリエンス向上に向けた取り組みだ。防御策や緩和策に加え、自分たちが攻撃を受ける前提で対応策の準備を進め、具体的に「例えばこのアクセスキーが漏えいした場合、どこをローテーションする必要があるか」といった事柄を検討し、この困難な時代に備えてほしいとした。