セキュリティ前提の開発と、継続的なセキュリティ確保

影響範囲の広い脆弱性の公表が、3日間に重なった

Webのサービスは、DNSサーバー、Webサーバーやアプリケーションサーバー、プログラミング言語、共通のライブラリ、フレームワークを積み重ねて動いています。今回の3日間の公表は、そのうちDNSサーバー、アプリケーションサーバー、プログラミング言語と実行環境に重なりました。

共通のライブラリでも、OpenSSL 3.0が9月7日にサポートを終え、無償で公開される修正は出なくなりました^[9]。PHPの開発チームは、完全な回避策はなく更新だけが安全な選択肢だとしています^[3]。Linuxの配布元などが古いバージョンに修正を移植している場合もありますが、PHPの開発チーム自身は8.1以前の修正版を出していません。国内ではIPAが修正版の公開を控えた10月21日に、PHPを使っているプログラムの棚卸しと、製品に組み込まれたPHPについて開発元の情報を確かめるよう求めました^[10]。

renueの見解

開発元の修正版が出ない古いバージョンのまま動いているシステムは、今も少なくありません。10月24日のW3Techsの集計では、PHPを使うWebサイトの3分の1以上が、開発元の修正版が出ないPHP 7以前のバージョンで動いています^[11]。IPAの調査でも、回答したユーザー企業の61%が、技術の老朽化や複雑化で保守や改良が難しくなったレガシーシステムを抱えていました^[12]。

古いバージョンを上げようとすると、改修が1つの層だけでは済まないことがあります。フレームワークのバージョンを上げるにはプログラミング言語のバージョンを上げる必要があり、プログラミング言語を上げると使っているライブラリやアプリケーションサーバーのバージョンも上げる必要が出るためです。バージョンアップのたびに複数の層の改修が必要になり、期限内に修正版を適用し続けられないシステムでは、運用そのものが成り立たなくなります。

renueは、修正版を適用し続けられなくなったシステムでは、古い基盤のバージョンを少しずつ上げるだけでなく、新しく作り直すことも有効な選択肢だと考えています。作り直しは費用と期間がかかるため後回しにされがちでしたが、AIを活用すれば既存のコードの解析から設計、実装、テストまでの工数を減らせるため、作り直しは以前より現実的な選択肢になりました。

バージョンを上げるか、作り直すかの判断軸

フレームワークのサポートが終わると、そのフレームワークに脆弱性が見つかっても開発元の修正版は出ません。JavaのWebアプリで広く使われたStruts 1は2013年にサポートが終わり、開発元は「セキュリティとバグの修正は今後提供しない」としています^[13]。

現役のフレームワークでも、古いバージョンのまま運用してきたシステムではバージョンアップが連鎖します。Spring Boot 3はJava 17以上を求め、依存するAPIもJava EEからJakarta EEに移ったため、使っているAPIによってはコードの書き換えも必要です^[14]。PHPのLaravelは毎年新しいメジャーバージョンを出してセキュリティの修正を2年で終え、メジャーバージョンが上がると求めるPHPのバージョンも上がることがあります^[15]。

判断の前提になるのは、自社のシステムがどの層で何のバージョンを使っているかの一覧です。VPSやSaaSのように運用を預けている先も、自社で更新するものと提供元に対応を確かめるものを分けて、一覧に載せます。一覧がなければ、今回のような修正が出た日にどのシステムが対象かを答えられません。

一覧をもとに、まず層ごとの状況を確かめます。

• 層ごとのサポートの期限がいつ切れるか
• 1つの層のバージョンを上げると、他のどの層も上げる必要があるか
• バージョンを上げた後に動作を確かめるテストがあるか
• 仕様や設計の文書が残っているか

そのうえで、バージョンアップ案と作り直し案を、費用、期間、データの移行、システムを止める時間、稼働した後の更新の負担という同じ項目で比べます。今回の改修費だけで比べると、毎年のバージョンアップにかかる負担を見落とすおそれがあるためです。

作り直すなら、セキュリティを前提に設計する

米国CISAはセキュリティを製品の設計と製造の段階に組み込むよう求めており、この考え方をSecure by Design（セキュリティ・バイ・デザイン）と呼んでいます^[16]。国内ではデジタル庁が政府情報システム向けのガイドライン（DS-200）で、企画、設計、開発、運用のすべての工程で一貫したセキュリティを確保する方策をセキュリティ・バイ・デザインと定義しています^[17]。新しいシステムとして作り直すなら、古いシステムで後から付け足してきた対策も最初の設計から組み込め、稼働した後も同じ方針で守り続けられるため、作り直しも一つの案として考えてよいはずです。

作り直しをAIエージェントに任せる前に、CISAのゼロトラスト成熟度モデル（ZTMM）が守る対象として定める5本のピラーに沿って、前提を決めておくべきです。

• 誰が使うのか（ID）
• どの端末から使うのか（デバイス）
• どのネットワークを経由するのか（ネットワーク）
• どのアプリケーションと処理を動かすのか（アプリケーションとワークロード）
• どのデータを、どう守るのか（データ）

前提が決まれば、どの層にどの防御を置くかを作る前に決められるため、稼働した後の手戻りが減ります（参考：多層防御の記事記事「多層防御を、5本の柱（ピラー）で見える化する」へ移動）。あわせて新しく実績のあるフレームワークを選び、使う外部のライブラリを必要なものに絞り、サーバーで動かす機能を減らすべきです（参考：Next.jsの緊急パッチの記事記事「Next.jsの緊急パッチに学ぶ、ライブラリの脆弱性への備え方」へ移動）。社内向けの管理画面や管理用のAPIはインターネットから直接届かない構成にし、利用者がそのデータを見たり変えたりしてよいかをサーバー側でリクエストごとに確かめる作りも、設計の段階で決めておきます（参考：パスキーの記事記事「パスキーによるフィッシング対策と、侵入後に被害を広げない設計」へ移動）。

ただし、新しいフレームワークを選んでも数年後には同じようにサポートの期限が来るため、作り直しは一度で終わる対策ではなく、稼働した後もセキュリティを保ち続ける仕組みと組み合わせて初めて意味を持つものです。

稼働した後も、継続的にセキュリティを確保する

米国NISTは、安全なソフトウェア開発の実践集であるSSDF（Secure Software Development Framework）で、多くの開発の進め方はセキュリティを詳しく扱っていないため、安全な開発の実践を開発の流れに組み込む必要があるとしています^[18]。開発、セキュリティ、運用の担当者が協力し、開発から運用までの各段階でセキュリティの確認と改善を続ける考え方がDevSecOpsです。DS-200も、開発と運用が連携するDevOpsにセキュリティを組み込み、開発の速さを損なわずにセキュリティを確保する体制や手法としてDevSecOpsを説明しており、DevSecOpsはセキュリティ・バイ・デザインを開発と運用の中で実現する手段にあたります^[17]。確認の多くを自動化し、リリースの前に1回だけ診断するのではなく、コードの変更や更新のたびに確認が回るようにします。運用で見つかった問題は、実装だけを直して終わらせず、設計の方針に戻して同じ問題が繰り返されないようにするべきです。

DevSecOpsで開発と運用の流れに組み込む作業は、ZTMMがピラーをまたぐ機能として置く可視化と分析、自動化とオーケストレーション、ガバナンスの3つに対応させると、次の表のように整理できます。

renueでも、脆弱性の情報を拾い、侵害の兆候を調べ、更新するまでの流れをAIエージェントで自動化する社内の基盤を構築しています（参考：基本方針の5章基本方針のページへ移動）。今回のNode.jsの修正も、社内のシステムに適用済みです。

修正版をすぐに適用できないシステムで取れる手段は、攻撃者が届く範囲を減らすことです。社内の人しか使わない画面はインターネットから届かないようにし、役目を終えたシステムは止め、データの漏えいや改ざんによる影響が大きいシステムは修正版を適用するまで止めます。止めるかどうかは、脆弱性の影響と業務を止める影響を比べて、あらかじめ決めた責任者が判断します。

説明責任を果たせる状態にしておく

ガバナンスは社外への説明責任にもつながり、その中心は、どういう考え方でシステムを設計し、どう運用しているかを取引先や利用者に説明できる状態にしておくことです。

対策を重ねても、攻撃を完全に防ぐことはできません。Anthropicが2026年4月に防御側に限って提供したClaude Mythos Previewは、重要なソフトウェアの脆弱性を見つけるために使われていますが、同じ水準の能力を攻撃者が手にすれば、基本対策だけでは防げない攻撃もあり得ます（参考：基本方針の4章基本方針のページへ移動）。事故が起きたときに、設計の考え方と日々の確認の記録をもとに、実施していた対策と、調査で分かった侵入の経路や被害の範囲を説明できることが、説明責任を果たす前提です。

AIで、作り直しの負担を減らす

IPAの委員会は、レガシーシステムのモダン化に向けて、生成AIなどでレガシーコードを解析しコードを生成する手法の開発と展開を挙げています^[12]。既存のコードをAIに読ませて仕様とテストのたたき台を先に起こし、業務担当者の確認と新旧のシステムの入出力の比較で確かめれば、作り直した後のシステムが元の業務を同じように処理できるかを判断できます。

システムの実装を外部に委託してきた企業でも、AIを活用すれば作り直しを委託先に任せきりにせず、設計の判断と確認を自社で持ちやすくなる点も利点です。

ただし、AIが書いたコードにも脆弱性は入り得るため、人が書いたコードと同じDevSecOpsの流れで検査し、同じ記録を残す必要があります。

今日確かめること

出典

1. JPRS「BIND 9.xの脆弱性（CVE-2026-94300）に関する緊急情報」（2026年10月22日）
2. 窓の杜「『Apache Tomcat』に最大深刻度"CRITICAL"の脆弱性」（2026年10月22日）
3. PHP「Security advisory」（2026年10月21日）
4. Node.js「October 2026 Security Releases」（2026年10月21日）
5. Oracle「Oracle Critical Patch Update Advisory - October 2026」（2026年10月20日）
6. Oracle「Oracle Security Alert Advisory - CVE-2026-91403」（2026年10月21日）
7. Apache Tomcat「Apache Tomcat 11.x vulnerabilities」
8. Apache Tomcat「Which version do I want?」
9. OpenSSL Corporation「OpenSSL 3.0 end of life」（2026年9月7日）
10. IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」（2026年10月21日）
11. W3Techs「Usage statistics of PHP for websites」（2026年10月24日）
12. IPA「レガシーシステムモダン化委員会総括レポート DXの現在地とレガシーシステム脱却に向けて」（2025年5月28日）
13. Apache Struts「Struts 1 EOL Announcement」
14. Spring Boot「Spring Boot 3.0 Release Notes」
15. Laravel「Release Notes」
16. CISA「Secure by Design」
17. デジタル庁「DS-200 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」（2024年1月31日）
18. NIST「SP 800-218 Secure Software Development Framework (SSDF) Version 1.1」（2022年2月）