開発者のためのセキュリティコンプライアンスガイド

要約

かつて、コンプライアンスは「他人事」でした。ガバナンス・リスク管理・コンプライアンス（GRC）チームが質問票に回答し、監査人が年に一度訪れ、開発者はひたすらアプリケーションをリリースし続けていました。しかし、その時代は終わりました。世界中で、規制当局や標準化団体は、コードを記述しアプリケーションをリリースするチーム、すなわちエンジニアリングチームに直接課される一連のセキュリティ関連の義務について、見解を一致させています。 

‍

事実上すべての主要な枠組みや規制に共通して見られる原則があります：

1. ソフトウェアコンポーネントの正確な在庫管理を行い、その形式はますます「ソフトウェア部品表（SBOM）」の形をとっている。
2. 既知の脆弱性については、定められた期間内に是正措置を講じる。重大度が高いものについては、多くの場合30日以内とする。
3. 脆弱性の特定、優先順位付け、および是正措置に関する、文書化され、再現可能なプロセスを示すこと。

‍

サポート終了（EOL）となったソフトウェアは、定義上、これら3つの要件すべてを満たせません。フレームワークのバージョン、ランタイム、またはライブラリへのセキュリティパッチの提供が停止すると、それ以降に発見されるすべてのCVEは、通常のルートでは恒久的に修正されない状態となります。パッチは提供されません。この事実こそが、「AngularJSを使用している」や「まだNode.js 16を使っている」といった話を、単なる技術的負債の議論からコンプライアンス上の問題へと変える要因となるのです。

‍

本ホワイトペーパーでは、主要な規格、フレームワーク、指針、規制についてそれぞれ解説し、開発者が実際に管理できる4つの要素、すなわち脆弱性の対応、オープンソースソフトウェア、サポート対象バージョン、およびサポート終了ソフトウェアに焦点を当てています。それぞれについて、具体的な事例と実用的な提言を示しています。

‍

アメリカ合衆国

PCI DSS 4.x（ペイメント・カード・インダストリー・データ・セキュリティ・スタンダード）

適用対象：決済カードデータを保存、処理、または送信するすべての事業体。契約上義務付けられており、カードブランドおよびアクワイアリング銀行によって実施が義務付けられています。

‍

要件内容。要件6.3.1では、組織に対し、業界で広く認められている情報源を用いて新たなセキュリティ脆弱性を特定し、リスクランクを割り当てることを求めています。要件6.3.2では、独自開発およびカスタムソフトウェアのインベントリ作成を求め、これには組み込まれているサードパーティ製およびオープンソースのコンポーネントも含まれます。 要件6.3.3では、重大または高深刻度の脆弱性に対するパッチをリリースから1か月以内に適用し、その他の該当するパッチについては組織が定める期間（通常は3か月）以内に適用することが求められています。要件11.3.1では、少なくとも四半期に1回の内部脆弱性スキャンが追加で求められ、11.3.1.1では、重大または高深刻度ではない脆弱性について、対象を絞ったリスク分析を行うことが求められています。 これらの要件を総括すると、要件12.3.4では、使用中のすべてのハードウェアおよびソフトウェアについて年次レビューを実施し、各技術が引き続きベンダーからのセキュリティ修正プログラムを受け取っていること、継続的なコンプライアンスを維持していること、およびサポート終了の発表について追跡されていることを確認するとともに、旧式化またはサポート終了した技術に対する是正措置について、経営陣が承認した計画を策定することを義務付けています。

‍

EOLソフトウェアが問題となる理由。6.3.3の「1か月」という期限は、パッチが存在することを前提としています。EOLとなったフレームワークに対して重大なCVEが公表された場合、ベンダーやオープンソースプロジェクトによるパッチが提供されることは決してないため、この要件を満たすことは構造的に不可能となります。カードホルダーデータ環境において、既知の重大なCVEが存在するEOLコンポーネントを発見した審査員は、交渉の余地のある指摘ではなく、コンプライアンス違反を発見したことになります。

‍

例：ある決済プラットフォームでは、チェックアウトのフロントエンドにAngularJS .xを使用しているが、このバージョンは2022年1月にサポート終了となっている。AngularJS新たな重大なCVEが公開された。6.3.3の規定によれば、当該組織は、まだ存在しないパッチを1か月以内に適用しなければならない。現実的な選択肢としては、緊急の移行（本番環境のチェックアウトフローにおいて30日以内に実現できることは稀である）、評価者が承認しなければならない文書化された代替対策、あるいはバックポートされたパッチを提供し、正当な是正措置の道筋を回復させる商用延長サポートが挙げられる。

‍

開発者への推奨事項：

• 6.3.2のコンポーネントインベントリは、スプレッドシートではなく、ビルドアーティファクトとして管理してください。インベントリが常に最新の状態になるよう、リリースごとにCIでSBOMを生成してください。
• 本番環境にあるすべてのフレームワークおよびランタイムのEOL（サポート終了）日を追跡し、迫りつつあるEOL日をバックログ項目ではなく、コンプライアンスの期限として扱う。
• すでにEOL（サポート終了）を迎えたコンポーネントについては、本番環境から隔離するか、移行するか、あるいは商用延長サポート契約を締結し、重大なCVEに対して30日以内のパッチ適用が可能となるようにしてください。

‍

医療保険の相互運用性と説明責任に関する法律（HIPAA）セキュリティ規則

適用対象：米国内において電子保護医療情報（ePHI）を取り扱う対象事業者および業務提携先。連邦法により義務付けられています。

‍

要件。「セキュリティ規則」では、ePHI に対するリスクおよび脆弱性について正確かつ徹底的な評価を行うこと（45 CFR 164.308(a)(1)(ii)(A)）、ならびにそれらのリスクを合理的かつ適切なレベルまで低減するのに十分なセキュリティ対策を実施することが求められています。HHSのガイダンスでは、リスク分析と脆弱性管理を基礎的な要素として位置付けており、公民権局（OCR）の2026年1月のサイバーセキュリティニュースレターでは、リスク分析においてパッチが適用されていないソフトウェアなどの脆弱性を特定し、その特定結果に基づいて積極的な是正措置を講じなければならないと明示されています。 2024年12月の規則制定案（NPRM）はさらに踏み込み、明確な脆弱性管理およびパッチ管理基準、少なくとも6ヶ月ごとの脆弱性スキャン、年1回の侵入テスト、および重大な脆弱性に対する最短15日というパッチ適用期限案を追加するものである。 2026年半ばの時点で、この規則制定案（NPRM）は最終決定に至っておらず、最終的な措置も延期されているが、OCRは現行規則の執行を積極的に行っており、その執行姿勢はすでに、リスクを文書化しながらもそれに対して適切な措置を講じていない組織を標的にしている。

‍

EOLソフトウェアが問題となる理由。HIPAAには「EOLソフトウェアの使用を禁止する」といった記述は一切ありません。同法では、安全対策が合理的かつ適切でなければならないと規定されています。情報漏洩が発生した後、ePHIにアクセスするシステムにおいて、既知のパッチ適用不能なCVEが存在するサポート終了済みのコンポーネントを稼働させている場合、それを「合理的」であると主張することは極めて困難です。OCRの調査では、リスク評価に毎年同じ脆弱性が記載されているにもかかわらず、悪用されるまで是正措置が講じられていない事例が繰り返し確認されています。こうしたパターンこそが、「故意の怠慢」との認定を招く要因となっているのです。

‍

例：ある患者向けポータルサイトが、Drupal 終了版Drupal v7）で稼働している。年次リスク分析でこの問題が指摘され、その結果は記録されたものの、移行に多額の費用がかかるため、2年間何の対応もなされなかった。その後、既知のCVEを悪用した情報漏洩が発生した。記録はされていたものの放置されていたこの指摘が、OCR（米国保健社会福祉省）の調査の焦点となり、技術的な手抜きが怠慢の証拠へと転じた。

‍

開発者への推奨事項：

• ePHIに関連するすべてのEOLコンポーネントが、是正措置計画および責任者を明記した上で、正式なリスク分析に確実に盛り込まれるようにしてください。パッチが適用されていないソフトウェアを省略したリスク分析は、OCRのガイダンスの下では、現在、明示的に不備があるとみなされます。
• 対応を完結させる：特定された各脆弱性について、実施した是正措置（パッチ適用、アップグレード、隔離、サポート延長）を記録してください。OCRの執行において、組織が特定されたリスクに対してどのような対応を行ったかが重視されるようになったためです。
• NPRMが最終決定されるのを待ってはいけません。そこに提案されている管理措置（スキャン頻度、パッチ適用スケジュール、資産インベントリ）は、規制当局が2026年時点で既に妥当なセキュリティ対策と見なしている内容を示しています。

‍

FedRAMP および NIST SP 800-53 SI-2（脆弱性の是正）

適用対象：米国連邦政府機関向けに販売されるすべてのクラウドサービス。必須。

‍

要件。FedRAMPのベースラインは、NIST SP 800-53のコントロールに基づいて構築されています。 制御項目SI-2では、組織に対し、システムの欠陥を特定・報告・是正するとともに、定義された期間内にセキュリティ関連のソフトウェア更新を適用することが求められています。FedRAMPでは、これを重大度に応じた是正期間として具体化しています。重大度が高い場合は30日、中程度の場合は90日、低い場合は180日であり、これらは毎月の「行動計画およびマイルストーン（POA&M）」プロセスおよび継続的な監視スキャンを通じて追跡されます。

‍

EOLソフトウェアが問題を引き起こす理由。セキュリティスキャンツールはCVEを検出します。深刻度の高いCVEを持つEOLコンポーネントが検出されると、30日間の期限が設定され、適用可能なパッチがないPOA&M項目が生成されます。この期限を過ぎても是正措置が講じられない場合、運用承認（ATO）がリスクにさらされることになります。 商用監査とは異なり、これは年1回のイベントではありません。スキャンは毎月、あるいはそれ以上の頻度で実行されるため、EOLソフトウェアは期限切れの検出結果を絶え間なく生み出し続けます。

‍

例：FedRAMPの認可を受けたSaaSプロバイダーが、自社のレポートサービスがExpress（サポート終了）バージョンに依存していることを発見した。 セキュリティスキャンが行われるたびにそのコンポーネントが再フラグされ、新しいCVEが報告されるたびに30日または90日のPOA&M項目が新たに作成され、第三者評価機関（3PAO）の評価者は、サポート対象外の依存関係を恒久的な脆弱性として指摘します。プロバイダーは、信頼できる移行のマイルストーン、あるいはパッチの提供を再開するベンダーによるサポートのいずれかを提示しなければなりません。

‍

開発者への推奨事項：

• FedRAMPの30日、90日、180日の期限をエンジニアリングSLAとして扱い、それらを課題管理システムに連携させることで、脆弱性に関するチケットに自動的に期限が設定されるようにしてください。
• 初期評価の前に、EOL（生産終了）部品を排除するか、またはそれらに対するサポート対象範囲を確保してください。そうすることで、その後毎月発生するPOA&M項目への対応に追われるよりも、はるかにコストを抑えることができます。
• 逸脱申請やリスク調整は、正当な理由がある場合に限り、かつ稀に行うようにしてください。評価担当者はその傾向を追跡しており、根拠のない同じ構成要素に関する逸脱申請が常態化している場合は、リスク管理が不十分であるとの判断につながります。

‍

NISTサイバーセキュリティ・フレームワーク（CSF）2.0

適用対象：大半の民間組織では任意ですが、米国連邦政府機関では義務付けられており、その請負業者に対しても広く要求されています。また、サイバー保険や取締役会への報告における事実上の基準モデルとなっています。

‍

要件について。CSF 2.0 のサブカテゴリ PR.PS-02 では、ソフトウェアは「リスクに見合った形で、保守、置換、および削除されなければならない」と規定されています。ID.RA のサブカテゴリでは、資産における脆弱性を特定、検証、および記録することが求められています。このフレームワークは成果ベースのものであり、パッチ適用期間を規定するものではありませんが、環境内のすべてのソフトウェアが、リスクに基づいて積極的に保守されるか、あるいは意図的に廃止されることが期待されています。

‍

EOLソフトウェアが問題となる理由。EOLソフトウェアは、その定義上、もはやメンテナンスが行われていません。PR.PS-02によれば、組織がそのようなソフトウェアに対してとれる正当な対応は、置き換え、削除、またはメンテナンスの再開の3つに限られます。何事もなく運用を継続することは、このフレームワークが許容しない唯一の状態です。また、このフレームワークは、商用延長サポートと最も明確に整合するものでもあります。なぜなら、ベンダーによるEOLコンポーネントへのパッチ適用は、文字通り「メンテナンスされている」状態を構成するからです。

‍

例。サイバー保険の更新に際し、CSF 2.0に準拠しようとしているある製造業者が、工場現場のアプリケーションを棚卸ししたところ、EOL（サポート終了）Vue 2 と、NodeOLNode.Nodeランタイムで構築されたスケジューリングツールを発見した。保険会社の質問票には、すべてのソフトウェアがサポート対象であり、パッチが適用されているかどうかが尋ねられている。正直に答えるには、日程を明記した移行計画かサポート契約のいずれかが必要となる。不実な回答をした場合、インシデント発生後に保険金支払いの主張が無効となる。

‍

開発者への推奨事項：

• すべてのアプリケーションを、次の3つの状態のいずれかに分類してください。「アップストリームプロジェクトによって積極的にメンテナンスされている」、「商用拡張サポートを通じてメンテナンスされている」、または「置き換え／削除の日程が設定されている」。分類されていないものはすべて、PR.PS-02のギャップとなります。
• EOL（サポート終了）およびサポート状況のデータを、CSFプロファイリングに使用されるのと同じ資産インベントリに取り込み、リスク責任者が重要度とともにソフトウェアのライフサイクル状況を確認できるようにする。
• リスクに関する決定事項を記録しておくこと。CSFは証拠に基づいて運営されています。「第3四半期の移行まではこのリスクを受け入れる」という判断と、「誰も確認しなかった」という状況との違いは、記録の有無にあります。

‍

NIST SSDF（SP 800-218、セキュアソフトウェア開発フレームワーク）

適用対象：自主的枠組み。OMB覚書M-26-05により、大統領令14028号およびOMB覚書M-22-18/M-23-16で従来義務付けられていた、米国連邦政府機関にソフトウェアを販売するベンダーに対する自己証明の義務要件が撤廃されました。各機関は、独自のリスク評価に基づき、引き続き自己証明やSBOMの提出を要求することを選択することができます。

‍

要件。SSDFは、「セキュリティを左へシフト」することに重点を置いた柔軟なフレームワークとして機能します。これは、セキュリティがソフトウェア開発プロセス全体に組み込まれることを意味します。このフレームワークでは、組織に対し、セキュアな開発方針（POプラクティス）の策定と維持、ソフトウェアの保護（PS）、十分にセキュリティ対策が施されたソフトウェアの生成（PW）、および脆弱性への対応（RV）が求められます。 プラクティスPW.4は、十分にセキュリティ対策が施されたソフトウェアの再利用を扱っており、組織に対してサードパーティ製およびオープンソースのコンポーネントを評価・監視することを求めています。RVプラクティスグループでは、リリース済みのソフトウェアにおける脆弱性を継続的に特定、評価、および是正することが求められており、これには、関連するコンポーネントが依然として修正プログラムを受け取れることが前提となっています。

‍

EOL（サポート終了）ソフトウェアが問題を引き起こす理由。セキュリティ更新プログラムの提供が終了したコンポーネントに基づいて構築された製品については、ベンダーはSSDFに準拠した脆弱性対応を保証することはできません。PW.4が求める「メンテナンスが継続されているソースからのコンポーネントの取得」およびRVが求める「継続的な是正措置」という要件は、基盤となるオープンソースプロジェクトのサポートが終了した時点で、いずれも成立しなくなります。

‍

例。連邦政府機関に製品を販売しているあるソフトウェア企業が、CISAの「セキュアソフトウェア開発宣誓書」に自主的に署名した。しかし、同社の主力製品にはjQuery .xと、Bootstrap （Bootstrap ）Bootstrap 同梱されている。法務部門は技術部門に対し、この宣誓書の記載内容が正確かどうかを問い合わせた。技術部門は、急遽是正プログラムを策定するか、あるいは依存関係ツリーと矛盾する内容を宣誓することになる。これは単なるセキュリティリスクにとどまらず、虚偽の陳述となるリスクを伴う。

‍

開発者への推奨事項：

• 採用後ではなく、採用前に、すべての新しい依存関係のサポート状況とEOL（サポート終了）時期を記録するオープンソース導入方針を策定する。
• CVEだけでなく、ライフサイクルイベント（メンテナンスモード、リポジトリのアーカイブ、EOL（サポート終了）日の発表）についても依存関係を監視してください。プロジェクトのサポート終了は、セキュリティ上の事象です。
• 連邦政府への認証申請を行う前に、依存関係のライフサイクル監査を実施し、製品に同梱されているすべてのEOLコンポーネントについて、是正措置を講じるか、サポート対象となる対応を確保してください。

‍

NIST SP 800-171 および サイバーセキュリティ成熟度モデル認証（CMMC）

適用対象：管理対象非機密情報（CUI）を取り扱う国防総省（DoD）の請負業者および連邦政府の供給業者。必須要件であり、CMMC評価は現在、国防総省の契約に段階的に導入されている。

‍

要件について。要件3.14.1（改訂版3では03.14.01に改番）では、システムの欠陥を適時に特定、報告、および是正することが求められています。評価ガイダンスでは、是正の証拠として、適用済みのパッチ、サービスパック、およびホットフィックスを具体的に挙げています。関連する要件には、脆弱性スキャンおよび是正措置に関するものがあります（3.11.2、3.11.3）。

‍

EOLソフトウェアが問題となる理由。「欠陥を適時に修正する」という要件には、ベンダーやオープンソースプロジェクトが修正の提供を停止したソフトウェアに対する例外は存在しません。CUIエンクレーブ内に既知のCVEを含むEOLコンポーネントが存在することは、3.14.1項目の恒常的な不適合となり、CMMC評価者はこれを請負業者に対して減点対象とします。また、たった1つの実践要件の不適合が、認証の失格につながり、ひいては契約資格の喪失を招く可能性があります。

‍

例：ある防衛関連サプライヤーの技術文書ポータルは、EOL（サポート終了）となったWebフレームワーク上で稼働している。CMMCレベル2の評価において、評価者は、ポータルの欠陥が適時に修正されていることを示す証拠を要求した。サプライヤーは、CVEを特定したスキャンレポートを提示することはできたが、上流側で修正が行われていないため、修正内容を示すことはできなかった。この対応は「未達成」と評価され、同社が国防総省（DoD）との契約を維持するために必要な認証が危ぶまれることとなった。

‍

開発者への推奨事項：

• 範囲を厳格に設定する：EOLソフトウェアは、可能な限りCUIの境界から完全に除外すること。境界内のすべてのものは評価の対象となるためである。
• EOLコンポーネントをスコープ内に残さなければならない場合は、代償措置を文書化し、サポート対象のパッチソースと組み合わせることで、「適時の修正」が実証可能となるようにしてください。
• パッチ適用に関する証拠（チケット、デプロイログ、適用前後のスキャン結果）は、要件ごとに整理しておいてください。CMMC評価は証拠に基づく審査であり、文書化されていない修正は、修正が行われていない場合と同じ評価となります。

‍

SECのサイバーセキュリティ開示規則

適用対象：米国の上場企業すべて。2023年12月より義務化。

‍

要件。登録企業は、重要なサイバーセキュリティインシデントについて、その重要性を判断してから4営業日以内にフォーム8-Kで開示しなければなりません。また、年次報告書（フォーム10-K）において、重要なサイバーセキュリティリスクを評価、特定、管理するためのプロセス（サイバーセキュリティリスク管理、戦略、ガバナンスに関する取締役会の監督を含む）を毎年開示しなければなりません（規則S-K第106項）。

‍

ここでEOLソフトウェアが重要となる理由。規則にはパッチ適用やEOLソフトウェアについての言及はないが、「重要性」の概念にはそれが含まれる。事業が依存しているコンポーネントに、既知でありながらパッチが適用されていない重大な脆弱性が存在すること自体が、開示を要する重要なリスクとなり得る。また、EOLが判明しているシステムに起因するインシデントは、まさに情報漏洩を証券訴訟へと発展させる事案の典型例である。なぜなら、原告側は、そのリスクが認識されていたにもかかわらず是正されず、かつ不十分な開示にとどまっていたと主張するからである。

‍

例：ある金融サービス企業が、サポート終了（EOL）Spring を使用するJavaベースのアプリケーションを通じて情報漏洩被害を受けた。インシデント対応の過程で、弁護士は、6か月前にそのフレームワークのEOL状態を指摘していた社内チケットを発見した。4日間の開示期限を守ることは今や簡単なことだが、困難なのは、文書化され、認識されていたリスクがなぜ是正されなかったのかを、8-K報告書およびその後の提出書類で説明することであり、取締役会の監督プロセスが直接的な精査の対象となっている。

‍

開発者への推奨事項：

• EOLソフトウェアに関する社内の技術記録（チケット、Slackのスレッド、リスク登録簿の記載事項など）は、情報開示の対象となり、インシデント発生後は公開された情報と照らし合わせて精査されることを理解しておく必要があります。
• セキュリティチームや法務チームに正確なライフサイクルデータを提供しましょう。EOL（サポート終了）リスクに関する正確な現状把握を行うことで、企業は項目106の開示において、リスク管理プロセスをありのままに説明できるようになります。
• 収益に直結するパスにおけるEOLコンポーネントの是正措置を優先してください。なぜなら、そこが「重要な」要素と「パッチが適用されていない」状態が重なる部分だからです。

‍

カナダ

CCSPA（重要サイバーシステム保護法、法案C-8）

適用対象：連邦政府の規制対象となる重要インフラ（通信、銀行、エネルギー、運輸）の指定事業者。義務化。法案C-8は2026年6月15日に国王の裁可を受け、CCSPAの義務は閣議決定に基づき段階的に施行される。

‍

求められる要件。指定事業者は、サイバーセキュリティプログラムを策定・実施し、サプライチェーンおよび第三者によるリスクを軽減し、定められた期限内にサイバーセキュリティインシデントを報告し、サイバーセキュリティに関する指示を遵守し、記録を保管しなければなりません。組織に対する罰金は最大1,500万カナダドルに達し、違反が継続している場合は、継続した日数に応じて個別に算定される場合があります。また、取締役や役員は、組織の法令違反を指示、承認、または黙認した場合、個人として責任を問われる可能性があります。

‍

EOLソフトウェアが問題を引き起こす理由。サプライチェーン・リスクへの対応義務は、ソフトウェア・スタックに直接及んでいます。重要なサイバーシステム内に存在する、パッチが適用されていないオープンソース・ライブラリやEOLフレームワークは、まさにプログラムが特定し軽減すべきサードパーティ・リスクの一種であり、1日あたりの罰金リスクを考えると、「知っていたのに何もしなかった」という態度は、多大なコストを招くことになります。CCSPAでは、脆弱性の定期的な評価、システムスキャン、および脆弱性が悪用される前にパッチを適用したり隔離したりするための積極的な軽減策を含むプログラムが求められています。

‍

例：連邦政府の規制対象となるエネルギー事業者の停電管理ポータルは、サポート終了（EOL）Angular で稼働している。CCSPAの対象に指定されると、当該事業者のサイバーセキュリティプログラムではサプライチェーンリスクを文書化しなければならない。評価の対象には、このサポート終了となったフロントエンドが含まれるため、事業者はリスク軽減策を示す必要がある。実際には、これには、確固たるスケジュールに基づく移行、隔離、あるいはパッチに関するSLAを伴うベンダーサポートの再開などが含まれる。

‍

開発者への推奨事項：

• 雇用主がカナダの通信、金融、エネルギー、または運輸業界で事業を展開している場合は、今すぐソフトウェアライフサイクルインベントリの整備を開始してください。指定や規制が段階的に導入されつつあり、指定後にプログラムを構築することになれば、急いで作成することになります。
• CCSPAの目的上、オープンソースの依存関係をサプライヤーとして扱う：各重要コンポーネントのメンテナンス担当者、サポート状況、およびセキュリティ修正プログラムがどのように提供されるかを記録する。
• エンジニアリングの実務にインシデント報告の準備体制（ログの保存、コンポーネントレベルの波及範囲のマッピングなど）を組み込み、報告時に影響を受けたシステムやコンポーネントを迅速に特定できるようにする。

‍

欧州連合

DORA（デジタル・オペレーショナル・レジリエンス法）

適用対象：EUの金融機関（銀行、保険会社、投資会社、決済機関、暗号資産事業者）および重要なICTサードパーティプロバイダー。義務化され、2025年1月17日より適用開始。

‍

要件。DORAのICTリスク管理フレームワークでは、金融機関に対し、信頼性が高く、十分な処理能力を備え、技術的に強靭なICTシステムを使用すること、すべてのICT資産の最新目録を維持すること（耐用年数の終了が近づいている資産の追跡を含む）、パッチ管理を実施すること、およびレガシーICTシステムを特定・文書化し、それらを段階的に廃止するか、あるいは明確に管理することを求めています。

‍

EOLソフトウェアがなぜ問題となるのか。DORAは異例なほど率直である。サポート終了済みのシステムは、業務レジリエンスにおける根本的な欠陥として扱われ、資産目録作成の義務には、EOLの追跡が具体的に想定されている。決済や取引のプロセスにおいてEOLソフトウェアを運用している金融機関は、監督当局やその監査人が確認するよう指示されている、文書化されたレジリエンス上の欠陥を抱えていることになる。

‍

例：あるEUの決済機関の取引ダッシュボードは、2023年12月にサポート終了（EOL）Vue 2動作している。DORA資産インベントリには、この事実、その重要度、および対応計画を記載しなければならない。監督当局による審査において、「計画なし」は指摘事項となる一方、「2027年に移行を予定しており、それまでの間は商用セキュリティパッチで対応する」という場合は、管理されたレガシーシステムとみなされる。

‍

開発者への推奨事項：

• ICT資産台帳に「使用終了日」と「サポート状況」を必須項目として追加し、依存関係マニフェストからこれらの情報を自動的に取り込むようにします。
• 重要または主要な機能に含まれるレガシーコンポーネントやEOLコンポーネントについては、それぞれについて、以下の3つの計画のうちいずれか1つを文書化してください。「指定日までに移行する」、「指定日までに運用を終了する」、あるいは「前述の2つのいずれかが実行されるまでパッチを適用し続ける」。
• レジリエンスに関する仮定の検証：DORAでは、デジタル運用レジリエンスのテストが求められており、脆弱性が確認されているEOLコンポーネントは、脅威を想定した侵入テストにおいて真っ先に悪用される対象となります。

‍

GDPR（一般データ保護規則）、第32条

適用対象：EUの個人データを処理するすべての組織（組織の所在地を問わず）。必須。

‍

要件について。第32条では、リスクに見合ったセキュリティレベルを確保するために「適切な技術的および組織的措置」を講じることを求めており、その際、「技術の最新動向」を明示的に考慮に入れるよう定めています。ただし、パッチの適用、実施期限、あるいは特定の技術については義務付けていません。

‍

EOLソフトウェアが問題となる理由。ここで重要なのは「最先端の技術水準」という言葉です。個人データ漏洩が発生した後、監督当局は、利用可能な技術を踏まえて、講じられていた対策が適切であったかどうかを問います。公開されているCVEがあり、利用可能なパッチがなく、サポート期間が大幅に終了しているソフトウェアを稼働させている場合、それを「最先端の技術水準」であると主張することは極めて困難であり、欧州の規制当局は、既知の未修正の脆弱性を原因とする漏洩事件を受けて、組織に対して繰り返し罰金を科しています。

‍

例：EUの顧客データを処理するマーケティングSaaSが、サポート終了（EOL）jQuery チェーンに含まれる既知のCVEを介して侵害された。 第32条に基づく分析は、当該企業が不運だったかどうかを問うものではなく、公開されているエクスプロイトが存在するサポート終了済みのコンポーネントを継続して運用することが「適切」であったかどうかを問うものです。GDPRに基づく罰金は、基本原則の違反も認められた場合、全世界の年間売上高の4％に達する可能性があり、既知の脆弱性を介した情報漏洩は、典型的な情状酌量となるパターン（過失および技術的措置の不備）です。

‍

開発者への推奨事項：

• 個人データを処理するシステムにおける脆弱性の是正を優先し、その優先順位付けの根拠を提示できるようにすること。
• コンポーネントがEOL（生産終了）となった場合は、その時点でのリスク対応方針（移行、隔離、サポート契約）を記録しておくこと。なぜなら、その時点での文書化こそが、第32条に基づく最も強力な抗弁となるからである。
• レガシーシステムにおいてデータ最小化を実践する：EOL（ライフサイクル終了）システムが扱う個人データが少なければ少ないほど、移行作業が進む間、第32条に基づくリスクは低減される。

‍

NIS2指令

適用対象：EU内の18のセクター（エネルギー、運輸、医療、デジタルインフラ、重要製品の製造、デジタルサービス事業者など）にわたる不可欠かつ重要な事業体。義務規定であり、加盟国法への組み込み期限は2024年10月であり、各加盟国ではそれぞれのスケジュールに従って施行が段階的に進められている。

‍

求められる要件。第21条(2)は、10項目の最低限のリスク管理措置を義務付けており、その中には(e)「脆弱性の対応および開示を含む、ネットワークおよび情報システムの調達、開発、保守におけるセキュリティ」や、直接のサプライヤーおよびサービスプロバイダーとの関係に及ぶ(d)サプライチェーンのセキュリティなどが含まれる。 第21条第3項では、事業者は各サプライヤーに特有の脆弱性、およびサプライヤー製品の全体的な品質と安全な開発慣行を考慮することが求められている。第23条では、インシデント報告の期限を24時間以内（早期警告）、72時間以内（通知）、1ヶ月以内（最終報告）と定めている。必須事業者に対する罰金は1,000万ユーロ、または全世界の売上高の2％に達し、NIS2では経営陣に対する個人的責任も追加されている。

‍

EOLソフトウェアが問題となる理由。第21条(2)(e)は、開発および保守における脆弱性への対応を法的義務として定めており、EOLソフトウェアとは、脆弱性への対応が構造的に終了したソフトウェアを指す。第21条(2)(d)および第21条(3)に基づくサプライチェーン対策は、この論理をオープンソースコンポーネントにも拡張している。すなわち、事業者は、自らが依存するソフトウェアの背後にあるセキュリティ対策について説明責任を負わなければならないが、上流プロジェクトが終了している場合、そのような対策は存在しない。

‍

例：ある病院グループ（重要組織）が、EOL（サポート終了）Nuxt アプリケーション上でスタッフの勤務スケジュール管理システムを運用している。 そのスタック内の既知のCVEを介してランサムウェア攻撃が発生した。24時間の報告期限を過ぎた後、国家当局による調査では、第21条に基づく措置が講じられていたかどうかが検証される。文書化された対応策がない、EOLが確定しており脆弱性が既知のシステムは、第21条(2)(e)項への違反に直結し、NIS2の下では、リスク管理措置を承認した経営陣が個人的な責任を負うことになる。

‍

開発者への推奨事項：

• オープンソースの依存関係を明示的に対象とした脆弱性対応プロセスを導入する。これには、特定（SCAスキャン）、優先度判定、是正措置のSLA、および開示対応が含まれる。
• 必須または重要なサービスを支えるシステムのSBOMを管理し、サプライチェーンに関する質問に対してデータに基づいて回答できるようにする。
• EOL（製品ライフサイクルの終了）に関する情報を、文書で経営陣に報告してください。NIS2の個人責任に関する規定により、経営陣はこれを把握しておく必要があります。正確なライフサイクルデータを経営陣に提供することも、エンジニアの職務の一環です。

‍

サイバーレジリエンス法（CRA）

適用対象：EU市場に投入される「デジタル要素を含む製品」（ハードウェアおよびソフトウェアを問わず）の製造業者、輸入業者、および販売業者。製造業者の所在地は問わない。 義務。実際に悪用された脆弱性および重大なインシデントに関する報告義務は2026年9月11日から適用され、必須要件、適合性評価、およびCEマーキングの全規定は2027年12月11日から適用されます。罰金は1,500万ユーロ、または全世界の売上高の2.5％のいずれか高い方が科されます。

‍

要件。これは、製品のライフサイクル全体にわたって製品そのものを規制するものであるため、開発者にとってこのリストの中で最も影響力の大きい法律です。附属書I第I部では、既知の悪用可能な脆弱性を含まない状態で製品を納入することが求められています。 附属書I第II部では、脆弱性の取り扱い要件が定められています。製造業者は、脆弱性およびコンポーネントを特定・文書化すること（少なくともトップレベルの依存関係を網羅した機械可読形式のSBOMの作成を含む）、無料のセキュリティアップデートを通じて遅滞なく脆弱性に対処すること、効果的かつ定期的なセキュリティテストを実施すること、および修正済みの脆弱性を公開することが求められます。これらの義務はサポート期間を通じて適用され、その期間はほとんどの場合、少なくとも5年間でなければなりません。 第14条では、実際に悪用されている脆弱性について、ENISAおよび各国のCSIRTに対し、24時間以内（早期通報）、72時間以内（完全通報）、および修正プログラムが利用可能になってから14日以内（最終報告）に報告することが義務付けられている。重要な点として、2026年9月からの報告義務は、数年前に出荷されたレガシー製品を含め、すでに市場に出回っている製品にも適用される。

‍

なぜオープンソースやEOLソフトウェアがここで極めて重要なのか。オープンソースコンポーネントを製品に組み込んで出荷する商用ベンダーは、それらのコンポーネントに含まれる脆弱性について法的責任を負います。出荷した製品内のオープンソースライブラリに、実際に悪用されている脆弱性が発見された場合、アップストリームプロジェクトが存続しているかどうかにかかわらず、報告期限が適用され、「遅滞なく」是正措置を講じる義務が課せられます。 EOL（サポート終了）フレームワークを基盤として構築された製品を出荷することは、法的に、そのアップストリームが今後一切対処することのないコンポーネントの脆弱性に対処することを約束することを意味します。CRA（サイバーセキュリティ規制法）は、「古い依存関係における無視されたCVE」を、技術的負債から、テクノロジー規制において最高額の罰金上限が設定された法的責任へと転換します。

‍

例：あるISVが、EU向けに文書管理製品を販売している。この製品には、サポート終了（EOL）Bootstrap Express 組み込まれている。2026年10月、Express 存在するCVEが実際に悪用され始めた。第14条に基づき、ベンダーは早期警告を24時間以内に提出し、完全な通知を72時間以内に提出し、修正プログラムが利用可能になってから14日以内に最終報告書を提出しなければならない。 アップストリームからの修正プログラムは提供されていません。ベンダーは、独自にバックポートしたパッチを作成するか、延長商用サポートを通じてパッチを購入するか、あるいは販売を継続している製品に対して修正プログラムが提供されない理由を規制当局に説明しなければなりません。

‍

開発者への推奨事項：

• 出荷されるすべての製品について、機械可読形式のSBOM（CycloneDXまたはSPDX）を今すぐ作成・維持してください。各製品バージョンに何が含まれているかをあらかじめ把握しておかなければ、2026年9月の24時間以内の報告期限に間に合わせることはできません。
• すべての製品ラインについて、生産終了（EOL）部品を調査し、2027年12月までにそれぞれに対処してください。具体的には、アップグレード、除去、または指定されたサポート期間中にパッチを提供できるサポート契約の締結のいずれかを行ってください。
• 製品ごとに現実的なサポート期間を定義・公表し、そのコミットメントに伴うパッチ適用コスト（サードパーティ製コンポーネントを含む）を製品計画に組み込むこと。サポート期間はもはや単なるマーケティング上の表明ではなく、法的拘束力のあるコミットメントとなっている。
• 24時間および72時間のタイムラインに基づいてシミュレーションを行った、統一された脆弱性開示ポリシーと、受付・優先度判定・報告のワークフローを確立する。

‍

イギリス

英国のGDPR

適用対象：英国の個人データを処理する組織。必須要件であり、情報コミッショナー事務所（ICO）によって施行される。

‍

必要な要件。ブレグジット後もEUのGDPRから引き継がれた英国のGDPRには、第32条に規定される「適切な技術的および組織的措置」という義務が同様に盛り込まれています。ICO（情報コミッショナー事務局）の執行実績により、その解釈は明確になっています。既知の脆弱性に対するパッチ適用を怠った場合は、適切なセキュリティ対策の不履行とみなされ、サポート終了済みまたは長期間パッチが適用されていないソフトウェアに起因する情報漏洩は、不運によるものではなく過失と見なされます。

‍

例。ICOは、英国証券投資協会（CISI）が、サポート終了（EOL）を迎えたウェブサイト用ソフトウェアを運用していたことで、第32条に違反していたことを認定した。さらに、攻撃者は、2017年からパッチが提供されていたにもかかわらず適用されなかった重大な脆弱性を悪用していた。

‍

開発者への推奨事項：

• EUのGDPRと同様の規律を適用する：資産の棚卸し、個人データを取り扱うシステムに対する優先順位付けされたパッチ適用、およびEOLコンポーネントに関するリスク判断の適時な文書化。
• レガシーシステムを迅速に移行できない場合は、そのシステムに含まれる個人データの量を削減し、隔離するとともに、その両方の証拠を保管しておくこと。
• ICOに関するガイダンスや執行通知を注視してください。これらは、実務において「適切」とは何を意味するのかを示す、継続的な判例記録としての役割を果たしています。

‍

2018年英国NIS規則

適用対象：必須サービス（水道、エネルギー、交通、医療）の事業者および関連デジタルサービスプロバイダー（クラウド、オンラインマーケットプレイス、検索）。義務的かつ法的拘束力あり。

‍

要件。事業者は、ネットワークおよび情報システムに対するリスクを管理し、インシデントの発生を防止・その影響を最小限に抑えるために、適切かつ均衡のとれた措置を講じなければならず、重大なインシデントについては72時間以内に報告しなければならない。 英国の規制当局がコンプライアンスの評価に用いるNCSCの「サイバー評価フレームワーク（CAF）」には、脆弱性の管理やシステムのサポート維持に関する目標が含まれている。実際には、パッチ適時性に対する期待値は、重要な更新プログラムを14日以内に適用するという「サイバー・エッセンシャルズ」のベンチマークと一致することが多い。

‍

EOLソフトウェアが問題を引き起こす理由。重要なサービスを妨害する事象が、パッチが適用されていないEOLシステムに起因する場合、規制当局はサービス継続性の維持義務違反を認定する可能性が高く、72時間以内の報告は、是正措置手続きの端緒となる文書となります。パッチの入手先がないソフトウェアにおいて、14日以内のパッチ適用という期待は達成不可能です。

‍

例。英国のある水道事業者のテレメトリ・ダッシュボードは、サポート終了（EOL）AngularJS 上で動作している。既知のCVEが悪用され、1日間にわたり運用状況の可視性が失われた。このインシデントは72時間以内に報告が義務付けられており、その後のCAF評価では脆弱性管理が検証される。公開されているCVEがあり、パッチ適用経路もないサポート終了コンポーネントは、複数のCAF評価項目において低い評価を受けることになる。

‍

開発者への推奨事項：

• CAFに基づいて必須サービスシステムを照合し、サポート対象外のコンポーネントをすべて特定する。CAFでは、システムがサポート対象であるか、脆弱性が適切に管理されているかが明確に検証される。
• 必須サービス環境内のすべての対象について、14日以内の重要パッチ提供という要件を満たせるパッチソース（アップストリームまたは商用）を確立する。
• エンジニアリング部門を巻き込んで、72時間の報告フローをリハーサルし、コンポーネントレベルの事実（何が脆弱だったか、いつからか、どのような対応が行われたか）を迅速に把握できるようにしておく。

‍

アジア太平洋地域

APPI（日本、個人情報保護法）

適用対象：日本国内の個人の個人情報を取り扱う組織。必須。

‍

求められる要件。「個人情報保護法（APPI）」では、事業者に、個人情報の漏洩、紛失、または毀損を防止するため、個人情報の安全管理に必要なかつ適切な措置を講じることを求めています。個人情報保護委員会のガイドラインでは、これを組織的、人的、物理的、および技術的な安全対策として具体的に定めており、技術的な安全対策には、ソフトウェアのメンテナンス、セキュリティパッチの定期的な適用、および脆弱性の監視などが含まれます。

‍

EOLソフトウェアが問題となる理由。GDPRと同様、この法令ではEOLソフトウェアについて具体的に言及されていませんが、規制当局はサポートおよびメンテナンスが行われているソフトウェアの使用を明確に求めています。サポート終了したソフトウェアの既知の脆弱性を介して個人データが漏洩することは、「必要かつ適切な」セキュリティ管理とは相容れないものであり、また（2022年の改正で導入された）情報漏洩の届出義務により、そのような事案は確実に規制当局に報告されることになります。

‍

例：ある日本のEC事業者が、アカウントポータルで使用していたJavaScriptフレームワークのサポート終了（EOL）バージョンに起因するデータ漏洩被害を受けた。PPCへの報告義務に基づき技術的保護措置の精査が行われた結果、「当該コンポーネントは3年間サポート対象外となっていた」という点が主要な調査結果となった。

‍

開発者への推奨事項：

• 技術的保護措置に関するPPCのガイダンスを運用上の基準として扱うこと。すなわち、日本国内の個人の個人データを保有するあらゆるシステムについて、定期的なパッチ適用、脆弱性の監視、およびサポート対象のソフトウェアの使用を行うこと。
• 日本市場向けのシステムについても、EUや米国のコンプライアンスに適用されているのと同じライフサイクルインベントリおよび是正措置に関するSLAの対象に含め、別途、より緩い基準を設けることは避けるべきである。
• 通知が義務化され、その後の質問も予測可能であるため、情報漏洩報告の根拠となるような形式で、安全対策に関する決定事項を文書化しておく必要があります。

‍

サイバー防衛法（日本、「ACD法」または「ACDA」）

適用対象：「経済安全保障促進法」に基づき指定された特定重要インフラ事業者、およびこれらにサービスを提供するITベンダー。義務化。2025年5月16日に制定され、段階的な実施を経て2027年までに全面施行される。

‍

その要件。ACDAは、官民連携、脅威検知のための通信データの活用、攻撃者のインフラに対する政府による無力化、および組織改革という4つの柱を中心に、日本のサイバー防衛体制を再構築する。指定プロバイダーは、サイバーセキュリティインシデントを所管当局に報告する義務を負い、この義務は2026年10月1日に発効する（正式な日程は未定）。 重要システムに影響を及ぼす脆弱性については、政府がITベンダーに通知し、所管大臣が是正措置を要請することができる。これらの要請には拘束力はないが、ベンダーは対応するために合理的な努力を払わなければならない。また、この枠組みにより、政府は事業者に対し、ゼロデイ脆弱性への対処を速やかに要請することが可能となる。

‍

EOLソフトウェアが問題となる理由。ACDAは、規制当局と重要インフラ内のソフトウェアとの間に直接的な連絡経路を確立するが、EOLソフトウェアは双方の面で機能不全に陥る。事前の通知により、重要システムの構成が導入前に規制当局に可視化されるため、サポート終了済みのフレームワークは、文書化された脆弱性としてその審査の対象となる。 是正措置の仕組みは、修正が可能であることを前提としています。大臣がEOLコンポーネントのCVEに対する是正措置を要求した場合、上流での修正は存在せず、「合理的な努力」とは、独自にパッチを作成するか、修正が提供されないことを認めることに帰着してしまいます。そして、インシデント報告の義務化により、サポート終了ソフトウェアの既知のCVEを介した侵害が、定められた期限内に当局に報告されることが保証されます。

‍

例：ある指定電力事業者が、サポート終了（.NET ）となった.NET 上で停電報告ポータルを運用している。NCOが、その.NET が実際に悪用されていることを特定し、所管大臣が当該事業者のITベンダーに対して是正措置を要請した。 上流のパッチは存在しない。ベンダーの選択肢は、緊急移行か、パッチソースを復元する商用延長サポートのいずれかである。「当該コンポーネントはサポート終了（EOL）であり、修正できない」という事実が、将来のインシデント報告に先立ち、省庁の記録に残された。

‍

開発者への推奨事項：

• 貴社のシステムが指定された日本のインフラ事業者向けにサービスを提供している場合は、今すぐすべてのフレームワークおよびランタイムを棚卸しし、2026年11月に通知および報告義務が適用される前に、EOL（サポート終了）となったコンポーネントの対応を完了させてください。
• 重要システムを構成するすべてのコンポーネントについて、アップストリーム、社内開発、商用延長サポートのいずれであるかを問わず、パッチのソースを管理し、政府からの是正要請に迅速に対応できるようにする。
• ACDAとAPPIは相互に補完的な規制として扱うべきである。APPIは個人データの漏洩を規制し、ACDAは重要サービスの停止を規制しており、日本市場のシステムで発生した1件のインシデントが、両方の規制の適用対象となり得る。

‍

SOCI法（オーストラリア、2018年重要インフラ保安法）

適用対象：オーストラリアの11のセクターにわたる重要インフラ資産の所有者および運営者。義務付けられています。

‍

要件。「SOCI法」およびその「重要インフラリスク管理プログラム（CIRMP）」の規則では、責任ある事業体に対し、重大なリスク（サイバーリスクやサプライチェーン上のリスクを含む）を特定し、それらを最小化または軽減するための管理措置を講じ、毎年取締役会の承認を得た上で報告を行うことが求められています。多くの事業体は、「ACSC Essential Eight」を採用することでサイバーフレームワークの義務を満たしています。このフレームワークのパッチ適用成熟度レベルでは、定義された短い期間内に重要なパッチを適用することが求められており、サポート終了したソフトウェアを、除去または置き換えるべきギャップとして明示的に扱っています。

‍

EOLソフトウェアが問題となる理由。EOLソフトウェアは同法において具体的に言及されてはいないが、リスク管理義務を通じて明らかに適用範囲に含まれている。すなわち、重要システムに含まれるサポート終了済みのコンポーネントは、文書化された管理措置または是正措置を必要とする重大なサイバーリスクであり、取締役会はこれに対処するプログラムについて毎年確認を行う必要がある。

‍

例：あるオーストラリアの港湾運営会社の物流アプリケーションが、サポート終了（EOL）Node.jsのバージョン上で稼働している。取締役会が署名するCIRMP年次報告書には、重要なリスクとそれに対する緩和策を記載しなければならない。このEOLランタイムについては、信頼できる緩和策（移行スケジュール、隔離、またはパッチ提供を伴うサポート延長など）が講じられているか、あるいはインシデントや監査によってその事実が明らかになった場合、その不備が指摘事項となる。

‍

開発者への推奨事項：

• パッチ適用およびライフサイクル管理の慣行を、「Essential Eight」成熟度モデルに整合させる。このモデルは、オーストラリアの規制当局や取締役会の多くが、「妥当」という概念を表す簡略表現として用いている。
• SurfaceのEOL（生産終了）に関する情報を、提案された対応策とともにCIRMPリスク登録簿に反映させる。これは、取締役会の認証により、報告されていない技術的リスクがガバナンス上の問題となるためである。
• アップグレードが真に不可能なオペレーショナル・テクノロジー関連システムについては、セグメンテーションおよび監視管理措置をリスク対策として明示的に文書化すること。

‍

グローバル基準

インターネットセキュリティセンター（CIS）コントロール v8.1

適用対象：自主的なベストプラクティス・フレームワークであり、広く採用されており、規制当局や保険会社によって参照されており、一部の契約状況においては必須となっている。

‍

要件について。「コントロール2（ソフトウェア資産の棚卸しおよび管理）」では、組織に対し、承認され、サポート対象となっているソフトウェアのみがインストールおよび実行されるよう、すべてのソフトウェアを積極的に管理することが求められています。コントロール2に基づく保護措置では、ソフトウェアがサポート対象であることを確保すること、およびサポート対象外のソフトウェアに対処することが明示的に求められています。「コントロール7（継続的な脆弱性管理）」では、脆弱性を継続的に評価・追跡し、明確な頻度で是正措置のプロセスを確立することが求められています。

‍

EOLソフトウェアが問題を引き起こす理由。CISは、この問題を率直に指摘している数少ないフレームワークの一つです。すなわち、サポート終了したソフトウェアは本質的に脆弱であるとみなされ、緩和策を講じた例外として文書化するか、あるいは削除しなければならないとされています。CISを基準としている組織（あるいは顧客や保険会社がCISを基準としている組織）は、管理されていないEOLコンポーネントが存在する場合、内部監査に不合格となります。

‍

例：中堅のSaaS企業が、エンタープライズ向けセキュリティアンケートに回答するためにCIS Controlsを採用した。Control 2によるソフトウェアインベントリ調査の結果、EOL（サポート終了）となったフレームワーク上で動作するアプリケーションが4つ見つかった。これらのアプリケーションは、それぞれ、代償的制御措置と廃止予定日を明記した文書化された例外としてリストアップするか、サポート対象の状態に移行させる必要がある。リストに載せないままにしておくと、そのコントロール要件を満たさなくなるだけでなく、さらに悪いことに、それに基づいて作成されたアンケートの回答が虚偽のものになってしまう。

‍

開発者への推奨事項：

• パッケージマニフェストおよびデプロイメントツールから「Control 2」のインベントリを自動化し、すべてのフレームワークおよびランタイムに対して「サポート終了日」フィールドを追加する。
• コントロール7において、深刻度ごとに是正措置のSLAを設定し、それに基づいて実績を測定すること。このコントロールでは、その場しのぎの対応ではなく、定期的なサイクルを持つプロセスが求められている。
• EOL対象の各コンポーネントを、管理措置の意図通り、文書化、緩和策、および有効期限の設定が必要な正式な例外として扱うこと。

‍

SOC 2 トラスト・サービス基準

適用対象：自主的な証明ですが、企業顧客が契約上この報告書を要求しているため、B2B SaaSおよびクラウドベンダーにとっては事実上必須となっています。

‍

要件。「トラスト・サービス基準」（特にCC7.1）では、新たな脆弱性の監視、定期的なスキャン、適時の是正措置、および適切に機能するパッチおよび変更管理プロセスの確立が求められています。監査人は、監査期間中に特定された脆弱性が、組織が定めたSLAの範囲内で是正されたかどうか、またそのプロセスが一貫して運用されていたかどうかを検証します。

‍

EOLソフトウェアが問題を引き起こす理由。SOC 2 Type IIレポートは数か月にわたる期間を対象としています。未修正のCVEを抱えたEOLコンポーネントは、その期間中のすべてのスキャンで検出され、是正措置が不可能なため、レポートに「例外」として記載されるか、あるいはその説明が次第に凝ったものになっていきます。企業顧客はこうした「例外」に注目します。SaaSベンダーのレポートに記載される脆弱性管理に関する例外は、セキュリティ上の問題であると同時に、営業上の問題でもあります。

‍

例：あるSaaSベンダーのタイプII監査期間は1月から6月までである。 2月、同社のビルドパイプラインで使用されているサポート終了（EOL）済みのオープンソースツール、および社内サービスで使用されているExpress 、重大度の高いCVEが公開された。ベンダー自身のポリシーでは、重大度の高い不具合は30日以内に是正されることになっている。監査人は7月にそれらのチケットを抽出して確認した。アップストリームや商用パッチがないため、120日目になってもチケットは未解決のままであり、報告書には例外事項として記載された。

‍

開発者への推奨事項：

• 実際に達成可能な是正措置のSLAを作成し、それを確実に履行すること。監査人は自社のポリシーに基づいて検証を行うため、期限を守れない壮大なポリシーよりも、控えめでも確実に守られるポリシーの方がはるかに優れている。
• 監査期間が始まる前に、対象範囲内のすべてのコンポーネントにパッチの入手先を確保しておくこと。監査期間の途中でEOL（サポート終了）ソフトウェアが発見された場合、それは数ヶ月にわたる文書化された不備となる。
• 脆弱性チケットは、監査の対象となるため、正確かつ完全な状態（特定日、深刻度、是正措置、解決の証拠）に保ってください。

‍

ISO/IEC 27001:2022

適用対象：情報セキュリティマネジメントシステムの自主的な国際認証。顧客との契約や調達要件を通じて、義務化されることが多々ある。

‍

要件。附属書Aのコントロール8.8（技術的脆弱性の管理）では、技術的脆弱性に関する情報を適時に収集し、リスクを評価し、適切な措置を講じることが求められている。コントロール8.9（構成管理）では、ハードウェアおよびソフトウェアのベースライン・テンプレートを含め、構成を確立、文書化、実施、および監視することが求められている。コントロール5.9では、情報および関連する資産のインベントリ作成が求められている。

‍

EOLソフトウェアがこれを破綻させる理由。8.8項によれば、EOLコンポーネントの既知の脆弱性に対する「適切な措置」には、提供されないパッチを待つことは含まれない。組織は、アップグレード、隔離、リスク軽減、またはサポートの回復を行う必要があり、その意思決定の経緯を示す必要がある。 8.8項によれば、EOLソフトウェアは定義上、正当化可能なセキュリティ基準の範囲外となります。なぜなら、修正不可能なCVEが蓄積し続けるコンポーネントを、いかなる強化テンプレートでも補うことはできないからです。認証監査は定期的に実施される（年次監視監査、3年ごとの再認証）ため、管理されていないEOLコンポーネントは、監査のたびに不適合事項として指摘されることになります。

‍

例。あるソフトウェアコンサルティング会社は、政府機関の顧客から要求されているISO 27001の認証を取得している。サーベイランス監査の際、監査人は脆弱性管理記録を抽出して確認したところ、顧客ポータル内のサポート終了（EOL）jQuery 、スキャナーによる検出結果が繰り返し記録されていた。これらはすべて「リスク受容」としてクローズされており、是正措置も、責任者も、完了予定日も設定されていなかった。 監査人は8.8条項に対する不適合を指摘した。評価、是正措置、または期限を定めた見直しを行わずにリスクを容認することは、「適切な措置」とはみなされないからである。

‍

開発者への推奨事項：

• 資産インベントリ（5.9）、構成ベースライン（8.9）、および脆弱性対応プロセス（8.8）を連携させ、ライフサイクルのステータスがこれら3つすべてに反映されるようにする。監査人は、統制間の継ぎ目をますます厳しく検証するようになっている。
• EOL部品のリスク受容については、期限を定め、責任者を明確にし、具体的なリスク軽減策と組み合わせ、所定の間隔で見直しを行う。
• SCAおよびEOLのスキャン結果をISMSの是正措置プロセスに直接取り込むことで、「適時」な特定と対応の証拠が自動的に蓄積されるようにする。

‍

開発者にとってこれらすべてが意味すること：統合プレイブック

20のフレームワークや規制を並べて読み解くと、そのパターンは明らかです。具体的な期限は異なります（PCI DSS 6.3.3およびFedRAMPの「高」評価では30日、英国の「Cyber Essentials」の要件では14日、CRAおよびNIS2の報告では24時間または72時間）が、その根底にある要求事項は同一であり、いずれも技術的な要件です：

‍

1. 出荷・運用している内容を把握すること。SBOMはもはや任意の要件ではありません。CRA（一般データ保護規則）では、EU域内で販売される製品に対してSBOMの作成が法的要件となっており、PCI DSS 6.3.2ではコンポーネントインベントリが、DORAではEOL（製品ライフサイクル終了）追跡機能付きのICT資産インベントリが求められています。また、CISコントロール2、ISO 27001 5.9、NIST CSFはいずれもSBOMの存在を前提としています。 CI環境において、リリースごとにCycloneDXまたはSPDX形式でSBOMを生成し、検索可能な状態で維持してください。次回のLog4Shell級のインシデントが発生した際、このリストに挙げたすべての規制当局は、数時間以内に「影響を受けているか、どこで、いつからか」という質問に回答することを求めてきます。

‍

2. EOL 日をコンプライアンスの期限とみなす。オープンソースプロジェクトで公表されたサポート終了日（EOL）は、その日を過ぎると、そのプロジェクト内の新たな CVE について、通常の手段では恒久的に修正できなくなる日付である。 すべてのランタイム、フレームワーク、主要なライブラリ（Node.js、Angular、AngularJS、Vue、Reactツール群、Express、Nuxt、Bootstrap、jQuery、Drupal .NET、Spring、およびその他のスタック）について、証明書の有効期限切れと同じくらい真剣にEOLの期限を追跡してください。期限の12ヶ月前にアラートを出し、9ヶ月前に計画を立て、EOL当日までに行動を起こしてください。

‍

3. すべてのコンポーネントに対して、以下の3つのステータスのうち、正確に1つを割り当てること。「上流で積極的にメンテナンスされている」；セキュリティパッチを提供する商用拡張サポート契約を通じてメンテナンスされている（これは、NIST CSF PR.PS-02における「メンテナンスされている」という要件を満たし、PCIの30日間の期限を遵守可能にし、FedRAMPのPOA&Mのスケジュールを維持するものである）；または、具体的な日程が確定した交換・撤去が予定されている。 これら3つのステータスのいずれにも該当しないものは、このリストに記載されているすべての監査人、評価者、規制当局が発見するよう訓練を受けている「ギャップ」となります。

‍

4. 是正措置にSLAを設定し、その遵守状況を可視化する。深刻度に応じた期限を課題管理ツールに組み込み、是正までの平均所要時間を測定し、解決の証拠を保存しておく。SOC 2、ISO 27001、CMMC、FedRAMPは、いずれも根本的には証拠の提示が求められる取り組みである。これらに合格する組織とは、通常のエンジニアリング業務の流れの中で、監査証跡が副産物として自然に生成される組織のことである。

‍

5. 既知の前提に基づいた報告期限に備える。CRAの24時間前警告（2026年9月11日より、すでに市場に出回っている製品も含む）、NIS2の24時間前インシデント警告、およびSECの4営業日という重要度判断の期限は、いずれもインシデント発生前に自社のシステムに関するコンポーネントレベルの知識が存在することを前提としています。検知、SBOMによるコンポーネントの特定、影響評価、通知案の作成という一連の流れをリハーサルしておきましょう。

‍

6. ライフサイクル上のリスクを文書で上層部に報告する。NIS2では経営陣に個人的な責任が課され、SECの規則では取締役会に開示の監督責任が求められ、オーストラリアのCIRMPでは取締役会の認証が義務付けられている。経営陣は、把握しているリスクについてのみガバナンスを行える。EOL（サポート終了）リスクに関する正直かつ最新の状況把握と、その対応策（移行、隔離、サポート延長）を盛り込んだ文書は、エンジニアリングチームが作成できる最も影響力の大きい資料の一つである。

‍

通行方向は一方通行です。 2027年12月のCRAの全面適用、加盟国全体で成熟しつつあるNIS2の施行、国防総省（DoD）の契約へのCMMCの段階的導入、国王裁可を経て段階的に施行されるカナダのCCSPA、そして提案されているHIPAAセキュリティ規則の抜本的見直し――これらすべてが、「資産の把握」「適時の是正措置」「文書化されたプロセス」という3つの要素を厳格化しています。今すぐパイプラインにライフサイクルへの意識を組み込んでおく開発者にとっては、これらの規制は単なる事務手続きとして受け止められるでしょう。そうしない開発者にとっては、緊急事態として直面することになるでしょう。

‍

HeroDevsの「Never-Ending Support (NES) 」が、EOLコンプライアンスのギャップをどのようにNever-Ending Support (NES)

NESは、AngularJS、Angular、Vue 2、Node.js、Spring、.NET、jQuery、Bootstrap、Express、Nuxt含む、あらゆる規模の組織において未解決のEOLリスクの大部分を占める、サポート終了（EOL）を迎えたオープンソースのフレームワーク、ランタイム、ライブラリのポートフォリオを網羅しています。 NESは、プライベートで安全なレジストリと、署名済みのサポート契約、公開されたCVE修正ログ、リリースノート、SBOMへの組み込みに適したリリースといった、コンプライアンス要件を満たす完全なアーティファクトセットを通じて、継続的なCVE修正を提供します。

前述の各セクションで説明された義務と照らし合わせると、NESは構造的に不可能なものを実証可能な適用範囲へと変換します：

• 修正期限が再び達成可能になります。NESは、アップストリームで今後修正が提供される見込みのないコンポーネントについて、商用パッチのソースを復元します。これにより、これらの修正期限が達成可能となり、検出事項をクローズできるようになります。
• 「維持されている」が正しい回答となります。NIST CSF 2.0 PR.PS-02 に基づき、ソフトウェアはリスクに見合った形で、維持、置換、または削除されなければなりません。EOL コンポーネントに対するベンダーによるパッチ適用は、「維持されている」という成果に該当します。 
• レガシーシステムは、管理対象システムとなります。DORAおよびNIS2は、レガシーソフトウェアそのものを禁止しているわけではなく、管理されていないレガシーソフトウェアを禁止しています。NES契約の対象となるEOLコンポーネントについて、パッチ適用に関するSLAが確約され、是正措置のログが文書化されていれば、そのレガシーソフトウェアはセキュリティが確保され、商用サポートの対象となります。 
• 製品のライフサイクルにわたるサポートの約束が持続可能になります。『サイバーレジリエンス法』に基づき、オープンソースコンポーネントを出荷するメーカーは、宣言されたサポート期間を通じて、それらの脆弱性を修正する法的責任を負います。NESは、アップストリームでのサポートが数年前に終了したフレームワークを基盤とする製品においても、サポートの約束を確かなものにするバックポートされたパッチを提供します。

移行が適切な解決策である場合、NESは移行の代わりとなるものではありません。これは、移行のスケジュールを透明なものにする仕組みです。組織は、取締役会、監査人、規制当局に対して、現実的な近代化スケジュールを文書で確約しつつ、その過程で発生するすべてのCVEを期限通りに是正し、その記録を残すことができます。

‍

AIによって発見される脆弱性の頻度は、EOLソフトウェアのリスクを倍増させている。NESを導入することによる運用上の成果として、本番環境でEOLのオープンソースソフトウェアを運用している企業は、監査人からの質問に対する回答を、不適格とみなされる開示事項から、文書化され、正当性を説明できる統制措置へと転換することができる。

最新の技術情報、リリースノート、およびCVEの修正手順については、herodevs.comおよびhttps://docs.herodevs.com/guide/getting-startedをご覧ください。

‍

‍

参考文献

1. PCIセキュリティ基準協議会、『ペイメント・カード・インダストリー・データ・セキュリティ・スタンダード（PCI DSS）』v4.0.1、要件6.3.1、6.3.2、6.3.3、および11.3.1、2024年6月。https://www.pcisecuritystandards.org/document_library/https://blog.basistheory.com/pci-dss-requirement-6
2. Risk Associates、「PCI DSS v4.0.1 が脆弱性の特定と修正に関するルールをどのように変えるか」、2026年4月。https://riskassociates.com/blogs/how-pci-dss-v4-0-1-shifts-the-rules-on-identifying-and-fixing-vulnerabilities/
3. Endor Labs（Schellman社と共同）、『PCI DSS v4におけるOSSの脆弱性への対応に関する監査人の視点』、2026年1月。https://www.endorlabs.com/learn/an-auditors-perspective-on-addressing-oss-vulnerabilities-for-pci-dss-v4
4. Angular 、「AngularJSの長期サポートを終了」、Google、2022年1月。angularjs
5. 合衆国連邦規則集、45 CFR 第164編、サブパートC（HIPAAセキュリティ規則）。https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164
6. Medcurity、「2026年HIPAAセキュリティ規則の更新：準備すべき新たな要件」（リスク分析およびパッチ未適用のソフトウェアに関するOCRの2026年1月サイバーセキュリティニュースレターの要約）、2026年6月。https://medcurity.com/hipaa-security-rule-2026-update/
7. 米国保健社会福祉省、公民権局、「電子保護医療情報（ePHI）のサイバーセキュリティ強化に向けたHIPAAセキュリティ規則の規則制定案に関する通知」。https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html
8. 『連邦官報』、電子保護医療情報のサイバーセキュリティを強化するためのHIPAAセキュリティ規則、90 FR 898、2025年1月6日。https://www.federalregister.gov/public-inspection/2024-30983/health-insurance-portability-and-accountability-act-security-rule-to-strengthen-the-cybersecurity-of
9. クリアウォーター・セキュリティ、「HIPAAセキュリティ規則の施行：2026年の現状」、2026年7月。https://clearwatersecurity.com/blog/hipaa-security-rule-enforcement-2026/
10. 米国国立標準技術研究所（NIST）、NIST SP 800-53 Rev. 5：情報システムおよび組織のためのセキュリティおよびプライバシー管理措置、管理措置 SI-2（欠陥の是正）。https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf
11. FedRAMP 継続的モニタリング・プレイブック。https://www.fedramp.gov/resources/documents/Continuous_Monitoring_Playbook.pdf
12. 米国国立標準技術研究所（NIST）、『NISTサイバーセキュリティ・フレームワーク（CSF）2.0』、NIST CSWP 29、サブカテゴリ PR.PS-02、2024年2月。https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
13. 米国行政管理予算局、各行政省庁・機関の長宛ての覚書、M-26-05、2026年1月23日。https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf
14. 米国国立標準技術研究所（NIST）、NIST SP 800-218：セキュアソフトウェア開発フレームワーク（SSDF）バージョン1.1、プラクティスPW.4およびRV.1～RV.3。https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf
15. サイバーセキュリティ・インフラセキュリティ庁（CISA）、セキュアなソフトウェア開発に関する証明書。https://www.cisa.gov/secure-software-attestation-form
16. 『連邦官報』、大統領令第14028号：「米国のサイバーセキュリティの向上」、2021年5月12日。https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
17. 米国国立標準技術研究所（NIST）、NIST SP 800-171 Rev. 3：非連邦システムおよび組織における管理対象非機密情報の保護、要件 3.14.1。https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r3.pdf
18. 米国証券取引委員会（SEC）、『サイバーセキュリティ・リスク管理、戦略、ガバナンス、およびインシデント開示』、リリース番号 33-11216；34-97989、2023年7月。https://www.sec.gov/files/rules/final/2023/33-11216.pdf
19. カナダ議会、法案C-8：サイバーセキュリティに関する法律、電気通信法の改正およびその他の法律に対する付随的改正、カナダ法令集2026年、第9章、LEGISinfo。https://www.parl.ca/legisinfo/en/bill/45-1/c-8
20. カナダ政府の公共安全省、法案C-8の王室承認によりサイバーセキュリティと重要インフラの強化を図る（2026年6月）。https://www.canada.ca/en/public-safety-canada/news/2026/06/government-of-canada-strengthens-cyber-security-and-critical-infrastructure-with-royal-assent-of-bill-c8.html
21. Borden Ladner Gervais LLP、法案C-8が可決：重要サイバーシステム保護法、2026年6月。https://www.blg.com/en/insights/2025/07/bill-c-8-revives-canadian-cyber-security-reform-what-critical-infrastructure-sectors-need-to-know
22. 欧州連合、金融セクターのデジタル・オペレーショナル・レジリエンスに関する規則（EU）2022/2554（DORA）、第5条～第15条、EUR-Lex。https://eur-lex.europa.eu/eli/reg/2022/2554/oj
23. 欧州連合、規則（EU）2016/679（一般データ保護規則）、第32条、EUR-Lex。https://eur-lex.europa.eu/eli/reg/2016/679/oj
24. 欧州連合、指令（EU）2022/2555（NIS2指令）、第21条および第23条、EUR-Lex。https://eur-lex.europa.eu/eli/dir/2022/2555/oj
25. NIS-2-Directive.com、NIS 2指令、第21条：サイバーセキュリティ・リスク管理措置（条文全文）。https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html
26. Glocert International、「NIS2 第21条のリスク管理措置の解説：10の対策すべて」、2025年12月。https://www.glocertinternational.com/resources/guides/nis2-article-21-risk-management-measures-explained/
27. 欧州連合、規則（EU）2024/2847（サイバーレジリエンス法）、第14条および附属書I、EUR-Lex。https://eur-lex.europa.eu/eli/reg/2024/2847/oj
28. 欧州委員会、『サイバーレジリエンス法：立法文書の概要』、欧州のデジタルの未来を形作る。https://digital-strategy.ec.europa.eu/en/policies/cra-summary
29. CyberResilienceAct.eu、「サイバーレジリエンス法解説：適用範囲、分類、および期限」、2026年6月。https://www.cyberresilienceact.eu/explained.html
30. キーサイト・テクノロジーズ、「EUのCRA準拠まであと1年：2026年9月11日、すべてが変わる」、2025年9月。https://www.keysight.com/blogs/en/tech/nwvs/2025/09/11/one-year-countdown-to-eu-cra-compliance-september-11-2026-changes-everything
31. Mend（Security Boulevard経由）、『EUサイバーレジリエンス法：2026年以降に向けた包括的なコンプライアンスガイド』、2026年5月。https://securityboulevard.com/2026/05/the-eu-cyber-resilience-act-a-complete-compliance-guide-for-2026-and-beyond/
32. 情報コミッショナー事務局、案件番号 INV/0158/2020。https://ico.org.uk/media2/1kip5gw2/chartered-institiute-for-securities-and-investment-reprimand.pdf
33. 情報コミッショナー事務局、『データセキュリティガイド』（英国GDPRのセキュリティ要件）。https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/
34. 英国政府、『2018年ネットワークおよび情報システム規則』（SI 2018/506）。https://www.legislation.gov.uk/uksi/2018/506/contents
35. 英国国家サイバーセキュリティセンター（NCSC）、サイバー評価フレームワーク（CAF）。https://www.ncsc.gov.uk/collection/cyber-assessment-framework
36. 英国国立サイバーセキュリティセンター（NCSC）、『Cyber Essentials：ITインフラストラクチャの要件』（14日ごとの更新要件）。https://www.ncsc.gov.uk/cyberessentials/overview
37. 個人情報保護委員会（日本）、個人情報保護法（APPI）および個人情報保護委員会ガイドライン（英語資料）。https://www.ppc.go.jp/en/legal/
38. 日本 - サイバーセキュリティに関する法律・規制 2026年版。https://iclg.com/practice-areas/cybersecurity-laws-and-regulations/japan
39. 日本の新たなサイバー防衛法：企業への影響。https://connectontech.bakermckenzie.com/japans-new-active-cyber-defense-law-impact-on-businesses/
40. オーストラリア政府、『2018年重要インフラ保安法』（重要インフラリスク管理プログラム規則を含む）。https://www.legislation.gov.au/C2018A00029/latest
41. オーストラリア・サイバーセキュリティ・センター（ACSC）の「Essential Eight」成熟度モデル（アプリケーションおよびオペレーティングシステムのパッチ適用、サポート終了ソフトウェアの削除）。https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight
42. インターネットセキュリティセンター（CIS）の「重要セキュリティ対策（Critical Security Controls）v8.1」における、対策 2（ソフトウェア資産の棚卸しと管理）および対策 7（継続的な脆弱性管理）。https://www.cisecurity.org/controls
43. AICPA、『トラスト・サービス基準』（2017年、2022年改訂重点事項付き）、基準CC7.1。https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
44. 国際標準化機構（ISO）、ISO/IEC 27001:2022「情報セキュリティマネジメントシステム」、附属書Aのコントロール5.9、8.8、8.9。https://www.iso.org/standard/27001
45. CyberResilienceAct.eu、「サイバーレジリエンス法解説：適用範囲、分類、および期限」、2026年6月。https://www.cyberresilienceact.eu/explained.html
46. endoflife.date、フレームワーク、ランタイム、データベースのサポート終了日（コミュニティが管理するリファレンス）。https://endoflife.date/
47. Node.js プロジェクト（OpenJS Foundation）、過去のリリースおよびサポート終了スケジュール。https://nodejs.org/en/about/previous-releases
48. Vue.js チーム、Vue 2 のVue 2 （2023年12月31日）。https://v2.vuejs.org/eol/