脆弱性対策は何から始める？ AI時代に見直したい技術選定と運用

最近、無検閲のオープンウェイトモデルを触っていて、これからOSSの脆弱性を秘密裏に探し、攻撃に使う人が増えるんじゃないかと思いました。

脆弱性とは、ソフトウェアや設定にある、攻撃に悪用される可能性のある弱点です。自社のシステムで何から対策すればよいか分からない場合は、まず使っているものと担当者を把握し、脆弱性の情報を確認して、影響を判断し、更新・検証する流れを作ることから始めたいです。

OSSはソースコードが公開されているので、誰でも中身を見ることができます。モデルも手元で動かせます。今後AIの性能が上がれば、コードを調べる負担が下がり、見つけた脆弱性を報告せず攻撃に使う人が出てくる可能性は十分にあると思います。

脆弱性対策は何から始める？ まずは四つの手順

脆弱性対策は一度診断すれば終わりではありません。新しい問題が見つかるたび、自社への影響を確認し、必要な対策を続ける必要があります。まずはインターネットに公開しているシステムや、顧客情報などを扱う重要なシステムから、次の流れを作ります。

1. 使っているシステムと担当者を把握する

最初に、自社のWebサイトや業務システム、サーバー、PC、利用中のクラウドサービスを洗い出します。分かる範囲でOS、ソフトウェア名とバージョン、公開範囲、保守担当者、サポート期限も記録します。

自社開発のシステムなら、ランタイムやフレームワーク、直接・間接に利用するライブラリも対象です。外注先が管理していて社内で分からなければ、構成と更新の担当範囲を確認します。クラウドサービスも、提供会社が更新する部分と利用者側が管理する部分を分けておきます。

2. 脆弱性の情報を継続して集める

脆弱性の情報は、Xで開発者やセキュリティの専門家をフォローしておくと、早く気づけることがあります。気になる情報を見かけたら、使っている技術に関係がないか確認するとよいと思います。

ただ、Xの情報は内容が不正確な場合もあるので、使っている製品の公式発表やJVNなども確認します。自社開発のシステムであれば、依存ライブラリの警告を受け取る仕組みも使いながら、誰が情報を確認するかを決めておくとよいと思います。

3. 自社への影響と対応の優先順位を判断する

情報が出ても、すべてが同じ緊急度ではありません。使っているバージョンが対象か、該当機能を使っているか、インターネットから到達できるか、実際の悪用が確認されているかを見ます。影響を受ける情報や業務も含め、公開されている修正情報をもとに判断します。

社内で判断できないときは、開発会社や外部の技術者に、対象かどうか、いつまでに何をするかを確認するのがよいと思います。

4. 検証して更新し、結果を確認する

修正版を適用する前に、バックアップや復旧方法を確認し、可能であれば検証環境で重要な業務が動くか試します。緊急性が高い場合は、業務への影響も踏まえて適用のタイミングを決めます。更新後は動作とログを確認し、結果を記録します。

すぐ更新できないときは、公開された回避策やアクセス制限、一時停止を検討し、担当者と対応期限を決めます。回避策が適用できるかは構成によって異なるため、製品の案内を確認してください。IPAのガイドも体制づくりの参考になります。

なお、脆弱性管理は情報収集から修正まで続ける取り組みです。システムに弱点がないかを調べる脆弱性診断は、その中の確認方法の一つです。診断を受けた後に、見つかった問題を誰が直し、継続して確認するかまで決めたいです。

AIで脆弱性を探せる時代に、OSSは危険なのか

私はOSSが使えなくなるとは思っていません。公開されたコードは攻撃側だけでなく、防御側も調べることができるからです。GoogleのBig SleepがSQLiteの脆弱性をリリース前に発見し、修正につながった例もあります。

一方、発見できても、その後に内容を確認して修正し、使っている人が更新しなければ問題は残ります。英国のNCSCもAIが攻撃と防御の両方の速度や規模を変え、公開されたモデルの安全対策は取り除けると指摘しています。

無検閲モデルが見つけた脆弱性による攻撃が増えている、とここで断定できるわけではありません。ただ、技術の進歩を考えると、見つけられてから対応を考えるのでは遅いケースは増えていくと思います。

PHPやNext.jsでも重大な脆弱性は見つかっている

2026年10月には、PHPで認証なしの遠隔コード実行につながり得る二つの重大な脆弱性が修正されました。影響は構成によって異なりますが、PHPの公式告知ではWebリクエストを処理する環境の更新を呼びかけています。

2025年には、Next.jsのミドルウェアによる認可を回避できる脆弱性も公表されました。古いバージョンから影響するものでしたが、影響の有無はホスティング方法や認可の実装によって異なります。Next.jsの事後報告では、Cloudflare Workersなど影響を受けない構成も説明されています。

どちらも多くの開発現場で使われている技術です。有名で長く使われているものにも、後から重大な問題が見つかることがあります。これらの事例自体が、無検閲モデルを使った攻撃を示しているわけではありません。

OSSを選ぶときは、機能より先に保守を確認したい

新しい機能が追加されていることと、セキュリティの問題に対応できることは別です。私は今後、少なくとも次の点を確認して選びたいと思っています。

• 脆弱性の報告先や公開方針が用意されているか。
• 過去の問題に対して、修正版や回避策が案内されているか。
• 使う予定のバージョンにセキュリティ更新が提供されているか。終了予定はいつか。
• 誰が保守しているか、更新が途絶えたときに代替や移行の選択肢があるか。
• そのOSSがさらに依存しているライブラリまで把握できるか。

導入後に更新できる体制まで決める

開発元が修正してくれても、自分たちのシステムを更新しなければ脆弱性は残ったままです。

納品後の更新を委託先が行うのか、社内で担当するのか。保守契約の範囲、緊急時の連絡先、サポート終了が近づいたときの移行も含めて、最初に決めておきたいです。

AIで作ったシステムも、公開後の保守は必要

AIでシステムを作るハードルは下がりました。一方で、AIが選んだライブラリを誰も把握していないまま公開すると、脆弱性が出ても自分たちに関係があるか分かりません。

私はこれから、「便利で作りやすいか」と同じくらい、「問題が出たときに直して使い続けられるか」を重く見て技術を選びたいと思います。