# 脆弱性バジェット ## 定義 脆弱性バジェット(Vulnerability Budget)とは、エラーバジェットモデルを**セキュリティ**ドメインに拡張した概念である。「依存コンポーネントの CVE を何日間許容できるか」を SLI/SLO/ポリシーの構造で管理する。Thomson・Laing が SREcon19 Americas で提唱した (Source: [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]])。 ### SLI/SLO/ポリシーの定義 | 要素 | 内容 | 例 | |---|---|---| | **SLI** | 実行中依存コンポーネントのパッチリリースからの経過日数 | 26 days since JVM v1.9.13 released | | **SLO** | 最大許容経過日数 (閾値) | 30 日 | | **ポリシー** | 閾値接近時にパッチを適用する | 30 日以内にパッチ適用 | SLI グラフは縦軸 = 経過日数、横軸 = 時間のバーチャートで表現される。各バーは「あるコンポーネントについて最新パッチが出てから現在まで何日経過しているか」を示す。バーが SLO 閾値を超えたらポリシーが発火してパッチを適用する。 ### Equifax 侵害との関係 (CVE-2017-5638) Apache Struts の CVE-2017-5638 に基づく Equifax 侵害のタイムライン: | 日付 | 出来事 | |---|---| | May 2016 | Apache Struts 2.5 リリース | | March 6 2017 | パッチ提供 | | March 7 2017 | 脆弱性公開(ゼロデイ警告) | | March 14 2017 | NVD 詳細公開 | | **May 13 2017** | **ハック成功** (公開から 67 日後) | | July 29 2017 | ハック発見 | 公開(March 7)からハック成功(May 13)まで **67 日**。SLO = 30 日のポリシーがあれば April 7 にパッチ適用が完了し、侵害は防げた。スライドの主張: **「30 days SLO would have worked for Equifax」** (Source: p.33, [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]])。 ### Pivotal による実証 大規模 SaaS テナント向けプラットフォームの SRE チームが Nov 2018-Mar 2019 の 6 ヶ月間、Ubuntu OS の rebuild & repave に 30 日 SLO を適用した実測グラフを公開した。定期的なパッチ適用で鋸波パターン(パッチ適用時に年齢がゼロにリセット)を維持し、年末年始の休暇期間を除いて SLO を守った。グラフはチームが「配信した価値を組織に対して可視化・証明する」ツールとして機能した。(Source: p.35, [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]]) ## 横断的知見 - **エラーバジェットモデルの構造的普遍性を初めて明示的に示した事例**: 可用性のエラーバジェット(SRE Book/Google)は SLI=エラー率・SLO=可用性目標の形を取るが、Thomson・Laing は「SLI = ユーザー価値の計測値 / SLO = 閾値 / ポリシー = アクション」が任意ドメインに適用できる汎用モデルであることを明示した。SRE Book には「エラーバジェット以外への SLI/SLO 拡張」の事例は存在しないため、横断的知見として重要である (Source: [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]])。 - **CVE の「数」を減らそうとする素朴な指標は、脆弱性バジェットが SLI として採用する「経過日数」設計そのものによって回避される**: [[Isobel Redelmeier]](『SLO サービスレベル目標』17章コラム「CVE の重要性」)は、CVE 件数を減らすことを目標にすると、実際に脆弱性を減らす代わりに脆弱性を探さなくなるという逆インセンティブが生じると警告した。Thomson・Laing の脆弱性バジェットは、そもそも CVE の「件数」ではなく「パッチリリースからの経過日数」を SLI に採用しているため、件数を隠す動機そのものが構造的に発生しない。Redelmeier の警告は、脆弱性バジェットが暗黙に回避していた指標ゲーミングのリスクを、CVE カウントという対抗設計と対比させることで明示化する (Source: [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]])。 ## 未解決の問い - SLI を「すべての依存コンポーネントの経過日数」とした場合、コンポーネントが多数ある場合の集約方法(最大値・平均・ワースト n% など)は何が適切か。 - CVE の重大度(CVSS スコア)によって SLO 閾値を変えるべきか(重大な CVE は 7 日、中程度は 30 日など)。 - rebuild & repave(イミュータブルインフラ)を前提とした脆弱性バジェットは、インプレース更新型インフラに適用できるか。 - 依存管理ツール(Dependabot など)が自動でパッチ PR を作成する場合、脆弱性バジェットの SLI をどの時点で「修正済み」とカウントするか(PR マージ時 vs デプロイ完了時)。 ## 関連 - 概念: [[エラーバジェット]] / [[フィーチャーフレッシュネス]] / [[SLI-SLO段階的導入]] / [[設定ミス脆弱性]] - エンティティ: [[Jim Thomson]] / [[David Laing]] / [[Pivotal Software]] / [[Isobel Redelmeier]] - ソース: [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]] - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]] (SLI/SLO/ポリシー定義・Equifax タイムライン・Pivotal 実測グラフ) - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]] (CVE カウントの指標ゲーミング警告、Isobel Redelmeier のコラム)