最近の脆弱性増加とその影響
シニアソフトエンジニアのriddleです。このポッドキャストは、IT業界のいろんな話やリアルをお届けします。
今回は、最近セキュリティのインシデント対応するのめっちゃ大変じゃねっていう話をしたいと思います。
最近ね、クロードコードのMUTOSというものが出てきてですね、いろんな古くからあるソフトウェアの脆弱性が見つかってやばいよ、みたいな話もありましたが、
それも関係ないのかわかんないですけど、最近例えばLinuxとかNext.jsとかTurnstackとかNginxとか、本当にいろんなところで脆弱性が毎日のように見つかってますよね。
で、その出てくる脆弱性も軽いものじゃなくて、結構重ためなもの。ローカルからルート取れちゃうとか、外部から攻撃的みたいなものが多くてですね、
使ってる人はもう絶対にアップデートしないといけないっていうレベルのものが大半だと思います。
これどう考えてもAIによってですね、今まで専門家じゃないとわからなかったようなものがAIを使って、ある程度知識があれば誰でも解析できるとか、
最近はGitHub Actionをベースにした攻撃も多いので、GitHub Actionを正しく使えていないというのが正しい表現かわかりませんが、
結構GitHub Actionの癖のあるところみたいなものを使われてですね、そこからサプライチェーンアタックみたいなものが広がっているというのもあると思いますし、
また昔と比べてですね、OSSを使っているソフトウェア開発結構多いと思いますので、GitHubとかで公開されているものですね、
それを使って利用してサービスを行っている業態が増えてきたことで、サプライチェーンアタックの被害がより拡大しているというふうにも考えられることができると思います。
過去と現在の脆弱性対応の比較
私が10年以上前にSIRにいたときには、例えば何か脆弱性が起こった際にですね、その脆弱性が大きいですと、例えばバッシュに脆弱性がありましたとなったら、
バッシュを利用している全てのサーバーにですね、実際にその脆弱性の対象になっているバージョンかどうかを調べて、それをお客さんに報告して、
例えばCVEのスコアが結構高めなので対応した方がいいですよとか、今回使っているものにはあまり関係ないのでやらなくていいですよみたいなレポートを上げて、
そこから必要があればお仕事として受注してもらってやるというような感じだったんですね。
なので、そんなに年に何回もあるものじゃなかったですし、それなりに人もいたので全然うまく回せていたんですが、
今だとね、これ同じこと起きたら毎日のようにとってもじゃないけど出てくるんで、調査する側も大変ですし、お客さん側もその度に都度発注っていうのもさすがにね、
大変だと思います。予算を取るのもそうですし、なんか前も同じなったよねみたいな感じで、反抗してもらう人に納得してもらうのも大変ですし、
実際でもそういう現場まだまだあると思うんで、実際にそのあたり苦労されている方もいらっしゃるんじゃないかなと思います。
現在の脆弱性対応の課題と現実
私は現在SIRではないので、実際に自分たちのプロダクトを作っているみたいな形になるので、
実際にその脆弱性が出てきたら使っているプロダクトに対してセキュリティパッチを適用していくっていうことを常日頃やっているとやっているんですけれども、
その数もやっぱり多いんですよね。ディペンダボってリノベートで毎日ちょっとずつバージョンアップをするみたいなことをやっていつつも、それとは別に管理しざるを得ない、
例えばOSのパッチだったりだとか、ツール類もありますし、最近はCVEが出てるけど、ベンダーへの報告が遅れたのかあんまり正規ルートじゃないのかわかんないですけど、
なかなかアップデートパッチが出なかったりとか、セキュリティパッチが出なかったりとかで、危険だということはわかっているがアップデートはできないみたいなことがちらほらあります。
またですね、影響範囲を調べたりとか、あと実際にそのパッチが出てきて、それを当てるってなった時にも一定の工数がかかったりするので、どうしても仕事を普段やってたらそこのセキュリティのことってそんなに普段ってあんま考えないと思うんですけども、
こういう脆弱性対応があると、その脆弱性対応に対して一定時間を持っていかれるので、これだけ頻度が高く行われるとですね、だいぶ想定外の作業でスケジュールが埋まっちゃうんですよね。
かといって中途半端にやるわけにもいかないし、しっかりやらないといけないし、というところで最近は結構セキュリティ対応っていうところのタスクがどんどん積もってきますね。
またそれにあたって、以前も紹介しましたが、サプライチェーンアタック自体をもうちょっと防ぐような仕組みだったりだとか、中長期でOSSへの依存度をどういうふうにコントロールしていくべきかだったりだとか、
AI が進化していった時に、セキュリティとして守るためにどうAIを利活用していくのか、もしくはどうやって事前に発見していくのかとか、
GitHub Actions との付き合い方とか、みたいなところでいろんな波及してですね、考えないといけない中長期のテーマがボコボコボコボコ出てくるんですよね。
中長期的な対策と代替案の検討
すごいざっくり言うと、もうじゃあインターネットに面しているツールは使わないようにしましょう、GitHub Actions は使わないようにしましょうとか、
基本的にもうOSSを使うのやめましょう、エンタープライズ系のものを通常契約して使いましょう、みたいな選択肢も時間とお金がいろいろあればできると思うんですよ。
とはいえ、別にエンタープライズ系のものを作ったら中身はOSSだったりするわけで、裏側はね。
プラス、サポートがついてエンタープライズプランとして出したりとか、プラスでいいパッチが出せたりとかもすると思うんですけど、
結局そこで脆弱性があったら同じのをアップデートしないといけないんで、やることそんな変わらないんですよね。
GitHub から離れればいいじゃん、みたいな話もありますけど、
タックサーフェスとしての GitHub が1個減ったとしても、結局何か外部に露見しているようなプロダクトを作っている場合はですね、
そういうルートで攻撃される可能性もあるので、GitHub アクションを使わないというだけでは、少しリスクは下がりますけど、
全体的には別にゼロになるわけじゃないので、ちゃんと動向を追っていく必要があるし、
例えば自社で AI 導入してないです、みたいな会社だったら、攻撃者は AI 使って攻撃してくるんで、
それを防御するために全部人力でやるっていうのは、さすがに非効率的すぎるというか、無理だと思うので守るのが。
そういうところのバランスを見つつ、AI の導入もしていくというところで、いろいろ作業があるかなと思います。
AI時代のセキュリティ対策の変革
そういう感じでですね、実際にセキュリティという側面で見ると、攻撃者にとってはノーリスクでですね、
いろんな攻撃だったり、新しい脆弱性を法制作の行動を解釈することで生み出せる反面、
守る側とかね、それを対応する側、対応に出てくる CVE のうちどれが重要で、
そのパッチをいつ当てればいいのか、みたいなところに頭を悩ませないといけないので、
ちょっと今までのセキュリティ対策のやり方とはですね、ちょっと AI のこの時代においてはスピード化を求められるものが違うので、
もうちょっとサイクロを早めるのか、もしくはもう全然違うアプローチで、
例えば通信内容を都度確認して AI が問題ないと判断したら通すみたいなね、
ちょっとこれさすがにその今の LLM とかのだとさすがにレイテンシーが乗っかりすぎるので無理ですけど、
そういう文脈になっていく可能性もあるかもしれない、昔の IPS、IDS に。
ということで今回は2026年の5月、最近 OS 周りとか Next.js 周りでいろんな脆弱性が見つかって、
現場はこんな感じになってるよとか、中長期的にはこういうことをもっと考えなきゃいけないんじゃないかな、みたいなところをテーマにお話ししました。
まとめと今後の展望
このポッドキャストはハッシュタグリライティで皆様からの感想やコメント募集しております。
またチャンネルの概要欄にあります google フォームのリンクからもご投稿可能です。
ありがとうございました。