当安全从 “附属 KPI” 跃升为业务韧性的硬指标，度量与可观测性就不再是选做题。云安全联盟（CSA）大中华区发布的《DevSecOps 六大支柱》终章 ——“测量、监控、报告和行动”（Pillar 6），为从事信息安全和信息技术管理和业务职能的人员提供了一套 “可视、可衡、可改” 的闭环方法论。
本文原文地址：https://mp.weixin.qq.com/s/0iUhV2DU69D_wh59L5Lu7A
なぜ Pillar 6 に注目するのか？#
投入の検証：量的な証明がなければ、安全の ROI を証明することはできず、ビジネスと同調することもできません。
統一された言語：統一された指標体系を用いて、開発、運用、安全、管理層を同じ「ダッシュボード」に引き寄せます。
改善の推進：監視 ➜ 可視化レポート ➜ 正確な行動を実現し、「発見 — 修正 — 振り返り」のパイプラインを構築します。
“一図で理解する” Pillar 6 フレームワーク#
- 測定は統一された指標プールを使用して「安全健康度」を定量化します；
- 監視はこれらの指標をログ、指標、トレース、ユーザー体験の 4 つのデータパイプラインに接続し、リアルタイムの「デジタルツイン」を形成します；
- レポートは「可視化 - 焦点 - 反復 - 協力」の 4 つの原則に従って、監視データを管理層と現場が理解できる洞察に変換します；
- 最後に、行動はレポートに基づく改善タスクを自動的に開発、運用、安全ツールチェーンに割り当て、閉ループを実現します。
このように、測定 → 可観測 → 意思決定 → 閉ループの順序で、DevSecOps の抽象的な目標を具体的で実行可能な日常のワークフローに分解し、安全を「見える化」し「迅速に動かす」ことができます。
12 のコア指標#
| 次元 | 指標の例 | 価値 |
|---|---|---|
| 脆弱性 | MTTI、MTTR、未解決燃焼率、開発速度の割合 | 「問題の蓄積」を「リスク曲線」に変換 |
| アーキテクチャの安全性 | 制御再利用率、深層防御スコア、安全モデル採用率、脅威 - リスクマッピング | 「設計は安全である」という実現度を定量化 |
| インシデント応答 | MTTD、MTTC、MTTRN、後審結案率 | 「アラート→回復」が振り返り可能で最適化できることを保証 |
正式に「コア指標」を列挙する前に、経営者からよく尋ねられる質問に答えます：なぜ 12 項目なのか、それ以上でもそれ以下でもないのか？
Pillar 6 は DevSecOps の全ライフサイクルを「脆弱性管理 — 安全アーキテクチャ — インシデント応答」の 3 つの主幹に分解し、それぞれの主幹からビジネスに最も説明力があり、自動化収集が容易な 4 つの測定ポイントを選択します。これにより、左移動の安全（設計 - コーディング段階の脆弱性の露出）、体系的な安全（深層防御とモデルの実現）、右移動の安全（アラートの閉ループと回復の弾力性）の 3 つの次元をカバーしつつ、指標の過負荷による測定体系の実現困難を避けることができます。
[!TIP]
最初に試点ラインで 1–2 個の「北極星指標」を適用することをお勧めします。例えば、MTTI + MTTR または MTTD + MTTRN を使用して、2–3 回の反復スプリントでデータ収集とダッシュボードの可視化を検証します。指標データが安定したら、残りの 8–10 項目を徐々に補完します。この過程で、出所、基準、閾値を必ず記録し、横断的なチームがベンチマーク比較を行えるようにし、「同じ指標で異なる解釈」によるコミュニケーションコストを避けます。
成熟度自己診断：Alpha → Beta → Charlie#
| チーム象限 | 現状の画像 | 次の最適なステップ |
|---|---|---|
| Alpha | 指標の欠如、パッチの遅延、イベントの蓄積 | 最小指標セットの構築 + 週次スキャン |
| Beta | 指標が散発的、プロセスが分断 | 自動化コントロール + クロスファンクショナルダッシュボード |
| Charlie | 指標の閉ループ、意思決定のデータ化 | 精緻なコスト - 利益 & 文化の定着 |
実践において、この Alpha → Beta → Charlie の 3 段階の成熟度は「レベルアップ」の線形プロセスではなく、むしろ組織の安全文化とエンジニアリング能力をリアルタイムで映し出す鏡のようなものです。正しいアプローチは、まずコア指標を使用して健康診断を行い、自分がどの象限にいるかを特定することです。その後、Pillar 6 が提供する指標プールと改善マニュアルを参照し、次の段階で補完すべき短所を明確にします。この「測定 — ギャップ分析 — 反復」の閉ループは、高得点を追求するあまりツールを盲目的に導入したり、プロセスを積み上げたりするジレンマを避けることができます。
注意すべきは、多くのチームが Beta → Charlie の移行段階で「クロスファンクショナルな協力のボトルネック」に直面することです —— 技術的負債は減少しましたが、組織の協力のボトルネックが顕在化します。Pillar 6 の経験は示しています：MTTI、MTTR などのハード指標が安定しているにもかかわらず、安全を前進させることが難しい場合、しばしば安全の測定結果がパフォーマンスや予算配分に組み込まれていないためです。この時、4 つのレポート原則（可視化、焦点、反復、協力）を OKR や四半期の振り返りに組み込み、データでリソースとインセンティブを駆動することで、真の突破口を開くことができます。
最後に、現在が Alpha、Beta、Charlie のいずれであっても、「可観測性優先」の心構えを保つべきです：すべての欠陥、すべてのアラート、すべての改善をデータポイントとして蓄積します。チームが同じ指標を使用して「安全の価値の物語」を語ることができるとき、成熟度曲線は自然に上昇し、安全の ROI もより容易に定量化され、上層部の賛同を得ることができるでしょう —— これが Pillar 6 があなたに達成してほしい長期的な目標です。
5 ステップの実行ロードマップ#
第一歩は、チームに 3–5 個のビジネス SLA に最も密接に関連する「北極星指標」（例：MTTI、MTTR、MTTD など）を設定し、安全を抽象的な概念から測定可能で整合性のある共通の目標に変えることです。開発、運用、安全、管理層が同じダッシュボードで同じ数字を見るとき、今後の投資と協力に方向性が生まれます。
第二歩は、単一の製品ラインまたはゴールドパイプラインで概念検証（PoC）を行います。最小限の範囲内でデータ収集、ダッシュボードの可視化、およびアラートの連携の完全な閉ループを検証し、「安全の可観測性が実際に納品の信頼性を向上させることができる」ことを最速で証明し、拡張のための組織の信頼とリソースを獲得します。
第三歩は、PoC が通過した後、垂直拡張段階に入ります。「脆弱性 → 安全アーキテクチャ → インシデント応答」の 3 つの主幹に沿って、12 のコア指標を徐々に補完し、ログ、指標、トレース、UX データをすべて統一された可観測プラットフォームに接続します。これにより、左移動から右移動の全リンクの閉ループが形成され、複数のツールの分断によるデータの孤島を避けることができます。
第四歩は、データ通路が安定した後に横展開を開始します。統一された指標の基準、閾値、およびボードテンプレートをより多くの開発 / 運用チームにコピーし、異なる機能が同じ言語を使用してリスクと改善を議論できるようにします。この取り組みは、レポートの「先に垂直に深化し、次に多くのプロジェクトを横展開する」というリズムに対応し、成功体験を迅速にスケール化し、繰り返し同じことをする渦に陥ることを防ぎます。
最後のステップは、継続的なフィードバックと文化の定着です。月次または四半期ごとの「測定 — レポート — 行動」のサイクルを通じて、指標結果を OKR、パフォーマンス、予算決定に組み込みます。リソースの傾斜とインセンティブの配分がデータによって駆動されるとき、DevSecOps の測定は試点ツールから組織の習慣にアップグレードされ、レポートが提唱する「安全の可観測性を用いて企業レベルのリスクを管理する」という長期的な目標を実現します。