ライブラリ脆弱性アップデート方針の策定ガイド - 国内外の公的基準から導く重要度別 SLA 設計

「ライブラリの脆弱性が見つかったら何日以内に対応すべきか」。この問いに対して、単一の権威ある基準は存在しません。NIST は「組織が定義した期間内」と言い、ISO 27001 は「適切かつ適時に」と述べ、日本の政府統一基準は「速やかに」と求めます。

しかし、具体的な日数を明示する基準も確かに存在します。

基準	主な修正期限
CISA BOD 19-02	Critical 15 暦日 / High 30 暦日
FedRAMP	Critical/High 30 日 / Moderate 90 日 / Low 180 日
PCI DSS	Critical 30 日
英国 SS-033	Critical 7 日（条件付き） / High 14 日 / Medium・Low 45 日
豪州 ASD	exploit 確認時 48 時間 / その他 2 週間
IPA	暫定 0〜3 日 / 恒久 7 日（最優先ランク）

これらを組み合わせることで、根拠のある SLA を設計できます。

本記事では、国内外の主要ガイドラインを一次情報ベースで横断調査し、一般的な企業が採用できる統合 SLA を提示します。

そもそも「重要度」とは何か: CVSS の位置づけ

重要度別の SLA を設計する前提として、CVSS（Common Vulnerability Scoring System）の分類を整理しておきます。

重要度ラベル	CVSS v3.1 スコア	対応の方向性
Critical（緊急）	9.0〜10.0	最優先。外部からの攻撃が容易で、致命的な影響
High（重要）	7.0〜8.9	迅速な対応が必要。影響は深刻だが攻撃条件がやや複雑
Medium（警告）	4.0〜6.9	定期的な更新サイクル内での対応を推奨
Low（注意）	0.1〜3.9	計画的なメンテナンスでの対応

ただし、CVSS は「深刻度（severity）」であって「リスク（risk）」そのものではありません。CVSS スコアが Medium でも、実際に悪用が確認されていれば対応優先度は Critical 相当に跳ね上がります。このため、後述する SLA 設計では以下の追加軸を必ず考慮します。

悪用可能性: 実際の悪用（in-the-wild exploit）や KEV カタログ掲載の有無
資産の露出: インターネット公開か、内部システムか
緩和策の有無: WAF やネットワーク分離による暫定対処が可能か

具体的な日数を明示する 3 つのグローバル基準

世界中の数多くのフレームワークの中で、重要度に紐づく具体的な修正期限を法的拘束力をもって規定しているのは、実はごく少数です。

CISA Binding Operational Directives（米国）

CISA は 2 つの指令を通じて、最も厳格な修正期限を定めています。

BOD 19-02（2019 年）は、インターネット公開の連邦システムに対して Critical を 15 暦日以内、High を 30 暦日以内 に修正することを義務付けます。

BOD 22-01（2021 年）は、CVSS スコアではなく 実際に悪用されている脆弱性（KEV カタログ掲載） に着目し、個別に期限を設定します。2021 年以降に採番された CVE は 2 週間以内、それ以前の CVE は 6 ヶ月以内 の修正が求められます。CISA の分析によれば、悪用される CVE の 42% は公開当日に悪用が開始され、75% は 28 日以内に悪用されています。

FedRAMP（米国）

FedRAMP は NIST SP 800-53 の「組織が定義する期間」を具体化した、現時点で最も包括的な重要度別タイムラインを提供しています。

重要度	修正期限
Critical / High	30 日
Moderate	90 日
Low	180 日

この 30 / 90 / 180 日の枠組みは、規制対象外の民間企業でも事実上の業界標準として広く参照されています。

PCI DSS v4.0.1（国際）

PCI DSS v4.0.1（2024 年 6 月）の要件 6.3.3 は、Critical なセキュリティパッチを 30 日以内に適用 することを義務付けます。High 以下は「組織が定義したリスク基準に従い、速やかに適用」とされ、具体的な日数は各組織の判断に委ねられています。

注目すべきは、v4.0 では High にも 30 日を求める議論がありましたが、v4.0.1 で Critical のみに絞られた点です。これは、組織にリスクベースの判断余地を残す意図的な設計変更です。

フレームワーク型基準: 日数は明示しないが「仕組み」を要求

多くの主要基準は、具体的な日数を規定する代わりに、組織が自ら SLA を定義し運用するプロセスを求めています。

NIST SP 800-53 Rev 5 / SP 800-40r4

NIST SP 800-53 の SI-2（Flaw Remediation）は、セキュリティ更新を「組織が定義した期間内」に適用することを要求します。よく引用される「30 / 90 / 180 日」は NIST 自身の推奨ではなく、FedRAMP が NIST の空欄を埋めたものです。

SP 800-40r4（2022 年）は、パッチ管理を「予防保守（Preventive Maintenance）」と位置づけ、ソフトウェアとファームウェアを広くスコープに含む資産影響把握と、リスクベースの優先順位付けを求めています。

ISO/IEC 27001:2022 / 27002:2022

ISO 27002:2022 の管理策 8.8（既知の脆弱性の管理）は、「適切かつ適時な行動」を求めますが、数値的な期限は一切規定していません。ISMS 認証で問われるのは、機能するプロセスが存在するかどうかです。一部の審査員が推奨する「Critical は 48 時間」といった数字は、規格本文に根拠がありません。

SOC 2（AICPA Trust Services Criteria）

SOC 2 の CC7.1 は、脆弱性スキャンを「定期的に」実施し、是正を「適時に」行うことを求めます。原則ベースのフレームワークであるため、監査では組織が定めたポリシーと実際の運用記録の一貫性が評価されます。

CIS Controls v8.1

CIS Controls は重要度による分類を行わず、月次以上 のパッチ適用頻度を一律のベースラインとして提示しています。

日本国内のガイドライン: 「迅速に」の具体化

日本のサイバーセキュリティフレームワークは、米国のような強制力のある数値期限を持たず、プロセスの確立と「速やかな対処」 を求める構造が特徴です。

NISC 統一基準（令和 7 年度版）

政府機関等のサイバーセキュリティ対策のための統一基準は、国の行政機関に対して義務的に適用されます。脆弱性対応については「影響度と緊急度に応じて、パッチ適用までの時間をできるだけ短くする」と記載されていますが、具体的な日数は規定されていません。

デジタル庁の CRSA（常時リスク診断・対処）システムは、公開から 30 日以上未修正の脆弱性 を「長期未解消」としてフラグを立てますが、これは運用上のモニタリング指標であり、義務的な SLA ではありません。

IPA の脆弱性対応リスク評価手法（2024 年）

IPA が公表する「脆弱性対応におけるリスク評価手法のまとめ ver1.1」は、日本国内で最も実務に近い期限目安を提示しています。

ランク	暫定対処	恒久対処
S（最優先）	即日〜3 日以内	7 日以内
A（重要）	30 日以内	45 日以内
B（通常）	定期メンテナンス	定期メンテナンス
C（低優先）	対処しない	対処しない（受容）

「暫定 → 恒久」の二段階設計は、パッチ適用に時間がかかる場合でも暫定緩和（WAF ルール追加、設定変更等）で攻撃面を縮小する運用を可能にします。

JPCERT/CC の 45 日調整期間

情報セキュリティ早期警戒パートナーシップガイドライン（2024 年版）では、JPCERT/CC が製品開発者へ最初に連絡を試みた日から 45 日後 を公表日の目安としています。

金融庁サイバーセキュリティガイドライン（2024 年）

金融分野におけるサイバーセキュリティに関するガイドラインは、金融機関に対して「システムの重要度、リスク、脆弱性の重要度に基づいてパッチ適用期限を設定する」ことを実質的に義務付けています。ただし、その期限が何日であるべきかは規定していません。

ガイドライン横断比較表

ガイドライン	Critical	High	Medium	Low	拘束力
CISA BOD 19-02	15 日	30 日	—	—	連邦機関に義務
CISA BOD 22-01（KEV）	個別期限（2 週間 / 旧 CVE は 6 ヶ月）	同左	同左	同左	連邦機関に義務
FedRAMP Rev5	30 日（High と同一）	30 日	90 日（Moderate）	180 日	CSP に義務
PCI DSS v4.0.1	30 日	組織定義	組織定義	組織定義	カード情報取扱組織に義務
CIS Controls v8.1	30 日（一律）	30 日	30 日	30 日	任意
NIST SP 800-53	組織定義	組織定義	組織定義	組織定義	連邦システムに義務
ISO 27001/27002	規定なし	規定なし	規定なし	規定なし	認証取得時
SOC 2	規定なし	規定なし	規定なし	規定なし	監査報告時
英国 SS-033	7 日（条件付き、条件外は 14 日）	14 日	45 日	45 日	対象組織に義務
豪州 ASD/ACSC	48 時間（exploit 時）	2 週間	2 週間	2 週間	推奨
NISC 統一基準	「速やかに」	「速やかに」	—	—	政府機関に義務
IPA（2024）	S: 暫定 0〜3 日 / 本格 7 日	A: 暫定 30 日 / 本格 45 日	定期メンテ	受容可	参考
FSA ガイドライン	組織が期限を設定	同左	同左	—	実質義務（金融機関）

統合 SLA 設計: 実務で使えるポリシーの構築

上記のガイドラインを統合し、一般的な企業が採用できる SLA を提示します。英国 SS-033 の 7 / 14 / 45 日、豪州 ASD の 48 時間、IPA の暫定→恒久モデルを外形基準とし、NIST / SOC 2 / ISMS が求める「リスクベース・継続監視・記録」の要件を満たす設計です。

重要度（CVSS）	トリアージ開始	暫定対処（緩和）	恒久対処（パッチ適用）	備考
Critical（9.0〜10.0）	当日	48 時間以内	7 日以内（上限 14 日）	インターネット面・exploit 確認時は最短で
High（7.0〜8.9）	1 営業日以内	必要に応じ実施	14 日以内	攻撃容易・露出大なら Critical 格上げ
Medium（4.0〜6.9）	5 営業日以内	必要に応じ実施	45 日以内	変更管理プロセス内で実施
Low（0.1〜3.9）	定例トリアージ	原則不要	定例更新 / 受容時は 3 ヶ月以内に再判定	四半期で棚卸し

暫定対処と恒久対処の二段階設計

IPA のモデルに倣い、対応を「暫定」と「恒久」の 2 フェーズに分けることが実務上のポイントです。

暫定対処: パッチ適用が間に合わない場合でも、WAF のカスタムルール追加、該当機能の一時停止、ネットワーク分離などで攻撃面を縮小する
恒久対処: ライブラリのアップデート、パッチ適用、または代替ライブラリへの移行

flowchart TD
    A[脆弱性検知] --> B[影響確認・トリアージ]
    B --> C{Critical / KEV / exploit?}
    C -- Yes --> D[暫定緩和 48h 以内]
    D --> E[恒久対処 7 日以内]
    E --> F[検証・再スキャン]
    F --> G[記録・クローズ]
    C -- No --> H{High?}
    H -- Yes --> I[14 日以内にパッチ適用]
    I --> F
    H -- No --> J[定例更新に組込み]
    J --> F
    B --> K{例外 - 受容?}
    K -- Yes --> L[リスク受容承認]
    L --> M[代替統制 + 3 ヶ月以内再レビュー]
    M --> J

ISMS / SOC 2 監査への整合

ISMS と SOC 2 は表現が異なりますが、脆弱性管理で問われるポイントは実質的に共通しています。

監査で問われること	ISMS（ISO 27001）	SOC 2（TSC）
検知できるか	管理策 8.8: 技術的脆弱性管理	CC7.1: 脆弱性への感受性の識別
優先順位付けできるか	リスクアセスメントプロセス	リスクベースの是正
期限内に是正できるか	PDCA サイクルの運用実績	「適時」の客観的証跡
例外が統制されているか	残留リスクの受容と見直し	例外の文書化と承認
証跡が残るか	内部監査記録	観察期間中の運用記録

SOC 2 の「timely」を客観化するには、重要度別 SLA を文書化し、期限遵守率を KPI としてトラッキングする必要があります。SOC 2 Type II では 3〜12 ヶ月の観察期間中、すべてのパッチが期限内に適用されたことを証明する必要があるため、1 件でも大幅な遅延があれば「例外（Exception）」としてレポートに記載されるリスクがあります。

監査に耐える運用ポリシーには、最低限以下の要素が必要です。

文書化されたプロセス: 情報源、トリアージ基準、重要度別 SLA、変更管理との接続、例外管理（承認者・期限・代替統制）
定期性・継続性: 依存関係の継続監視（SCA）、外部資産は月次以上、内部資産は四半期以上のスキャン
証跡: 検知 → 判定 → 緩和 → 適用 → 検証 → クローズの記録、期限遵守率、例外レビュー記録

運用自動化のベストプラクティス

SCA ツールの三層運用

脆弱性管理の自動化は、以下の 3 つのレイヤーで設計するのが効果的です。

継続監視レイヤー: Dependabot / Renovate / Snyk 等による依存関係の常時モニタリング
定例更新レイヤー: 月次〜四半期でのバッチ的なライブラリ更新
緊急対応レイヤー: Critical / KEV 対象の脆弱性に対する SLA ベースの即時対応

Dependabot / Renovate の戦略的設定

自動更新ツールを「通知をオンにするだけ」で運用するとアラート疲弊を招きます。

セキュリティ更新と機能更新を分離する: セキュリティ修正は優先パイプラインで処理し、パッチバージョン（z-stream）はテスト通過後に自動マージ
クールダウン期間を設ける: 新バージョンリリース直後はサプライチェーン攻撃の可能性を考慮し 3〜7 日の待機期間を置く。ただし、既知の脆弱性修正パッチはバイパス
EPSS と到達可能性を活用する: CVSS だけでなく、EPSS（Exploit Prediction Scoring System）や関数レベルの到達可能性分析（Reachable Vulnerability）でアラートを絞り込む

パッチ適用できない場合の例外管理

レガシーシステムや互換性の問題で期限内にアップデートできないケースは必ず発生します。放置ではなく、以下のプロセスを文書化することが SOC 2 / PCI DSS の監査で必須となります。

例外申請: アップデートできない技術的・ビジネス的理由の明確化
代替統制（Compensating Controls）: WAF のカスタムシグネチャ、ネットワーク分離、IPS 強化などの緩和策
期限付きリスク受容: セキュリティ責任者の承認、3 ヶ月以内の再レビュー義務

グローバルと日本の差異: ポリシー設計時の注意点

「数値を明示する」文化と「プロセスを求める」文化

最も本質的な差異は、米国・英国・豪州が重要度別の具体的な日数を規定する傾向にあるのに対し、日本は「組織が自ら期限を設定し、迅速に対処すること」を求める点です。

日本の FSA ガイドラインが「パッチ適用期限をシステムの重要度・リスク・脆弱性の重要度に基づいて設定する」ことを求めつつ、その数字を規定しないのは、この文化的差異の典型例です。

脆弱性情報のエコシステム

グローバルでは CVE / NVD が中心ですが、日本では JVN（Japan Vulnerability Notes）を通じた JPCERT/CC と IPA の調整・公開プロセスも重要な情報源です。JVN での公表後も更新が行われるため、企業の運用ポリシーには「公表後の追従・再トリアージ」の頻度も組み込む必要があります。

インシデント化した場合の報告タイムライン

脆弱性アップデートの遅延が情報漏えいに発展した場合、各法域で異なる報告義務が生じます。

法域	報告期限	根拠
日本	概ね 3〜5 日以内	個人情報保護委員会の報告ガイダンス
EU	72 時間以内	GDPR 第 33 条
米国（SEC）	4 営業日以内	SEC サイバーインシデント開示規則

Critical / High の SLA を短めに設計し、例外統制と証跡を整備しておくことは、インシデント発生時の「説明責任コスト」を大幅に下げます。

まとめ

ライブラリ脆弱性のアップデート方針を策定する際に押さえるべきポイントを整理します。

具体的な日数を規定する基準は少数: CISA BOD 19-02（15 / 30 日）、FedRAMP（30 / 90 / 180 日）、PCI DSS（30 日）、英国 SS-033（7 / 14 / 45 日）が主要なアンカーポイント
大多数の基準は「組織が SLA を定義し、運用すること」を要求: NIST、ISO 27001、SOC 2、日本の政府統一基準はすべてこの構造
CVSS だけでは不十分: 悪用可能性（KEV / EPSS）、資産の露出、緩和策の有無を掛け合わせたリスクベースの優先順位付けがトレンド
暫定 → 恒久の二段階設計が実務的: IPA のモデルに倣い、暫定緩和で攻撃面を即座に縮小しつつ、恒久対処を計画的に進める
例外管理と証跡が監査の鍵: SOC 2 / ISMS 両方で、SLA の文書化・期限遵守率のトラッキング・例外の統制が問われる

「何日以内に対応すべきか」に唯一の正解はありませんが、国内外のガイドラインを横断的に参照することで、根拠があり、監査に耐え、実務で運用可能な SLA を設計できます。

以上、ライブラリ脆弱性アップデート方針の策定ガイドについて、現場からお送りしました。