Day 110 方法9：責めない事後検証 The Blameless Security Post‑Mortem

サイバー判断力によるヒューマン・ハードニング

» 2026/02/15

[シリーズ構造] 柱D｜脅威の現実

脆弱性はなくならない。だから問うべきは「誰がやった？」ではなく、 「なぜ、このミスが効く構造になっていた？」責めない事後検証は、人を守るためではなく、 判断が潰れない組織をつくるための設計である。

▶ シリーズ概要： シリーズ全体マップ：人間のしなやかさ ― サイバー判断力のために

▶ 柱E｜脅威の現実 関連記事：

• Day 59 | 攻撃者をステークホルダーとしてデザインする
• Day 60 | セキュリティトレーニングが失敗する理由
• Day 61 | 経験の科学
• Day 61 | すべてを変えた数字
• Day 63 | AIが攻撃者になる時
• Day 63 | 攻撃を学ぶことの倫理
• Day 65 | 理論から実践へ
• Day 66 | 手法 1: レッドチェア・テクニック
• Day 67 | 手法2: ユースケースの隣に、アビューズケースを置く
• Day 68 | 手法3 : STRIDE
• Day 105 | 手法4：セキュリティ・チャンピオン・ネットワーク
• Day 106 | 手法5: ハンズオン攻撃トレーニング
• Day 107 | 手法 6: セキュリティのガードレールを「デフォルト」にする
• Day 108 | 手法7：セキュア設計・チェックリスト
• Day 109 | 手法8：セキュリティ設計レビュー・テンプレート
• Day 110 | 方法9：責めない事後検証

方法9：責めない事後検証

このやり方は、Site Reliability Engineering（SRE）から来ている。Google が広めた文化で、SREの書籍でも「事後検証（ポストモーテム）の考え方」として、きちんと整理されている。もともとは障害対応のための文化だ。でも今回は、それをセキュリティの脆弱性対応に引き寄せて使う。

理由は、難しくない。運用事故を減らせる組織は、だいたいセキュリティ事故も減らせるから。

どれだけ設計を整えても、脆弱性は出る。システムは複雑で、人間は人間で、攻撃者は、こちらの想定より少し先を行く。

だから、欠陥が見つかったときに立てる問いは、「誰がやった？」ではない。

問いは、これだ。

「なぜ、このミスが"効いてしまう状態"になっていたんだろう？」

「責めない」とは、何をしないことで、何をすることか

責めない事後検証は、個人やチームをかばうための仕組みじゃない。前提にしているのは、たった一つ。

「当事者は、その時点で得られた情報の中で、善意で合理的に動いていた。」

これは甘さではない。事実を引き出すための、かなり現実的な設計だ。

セキュリティの世界では、脆弱性が見つかると、つい"事件現場"のように扱ってしまうことがある。すると、エンジニアはいつの間にか"容疑者"になる。罰の気配が漂った瞬間、人はこう動く。

• 情報を削る
• タイムラインを丸める
• 不確実な点をぼかす
• 恥ずかしい判断を消す

そして皮肉なことに、その「消された部分」こそが、再発防止の核心だったりする。

「責めない」は、責任を曖昧にすることじゃない。責任の矢印を、人ではなく、仕組みに向け直すという意味だ。

人は簡単には直せない。でも、仕組みとプロセスは直せる。

責めない事後検証の進め方

1）何が起きたか

まずは事実を、淡々と残す。誰が読んでも、同じ情景が浮かぶレベルで。ここで必要なのは「物語」じゃない。ヒーローも、悪者も、いらない。必要なのはタイムラインだ。

• 脆弱性の内容
• どうやって見つかったか
• 想定された影響と、実際の影響

評価や感想は、あとでいい。

2）なぜ起きたか

いちばん熱が入りやすいところ。だからこそ、刺さない。見るのは、人のミスそのものじゃない。

• どんな前提が置かれていたか
• どのプロセスが拾えなかったか
• どんなガードレールが無かったか
• その場に、どんな情報や文脈が足りなかったか

「入力チェック漏れ」で止めない。大事なのは、なぜその判断が、その場では合理的に見えてしまったのか。ここを掘れると、再発防止が具体になる。

3）どう変えるか

見えた要因ごとに、次を決める。

• プロセスを直す
• トレーニングを補う
• ツール化・自動化する
• チェックリストを足す
• 悪用ケース（abuse case）を更新する
• ガードレールを置く

これは修理じゃない。組織のアップデートだ。最近のインシデント対応は、「全部終わってから学ぶ」より、気づいた時点で混ぜ込んでいく方向に寄っている。学びは、鮮度が高いほど効く。

4）学びを共有する

学びが閉じると、事故は場所を変えて再演される。

共有先は、当事者だけじゃない。

• 全エンジニア
• Security Champions
• 必要に応じてリーダー層
• オンボーディングや研修
• 社内の攻撃者プレイブック

脆弱性が秘密のままだと、次の脆弱性は、ただのリピートになる。

文化の切り替え

• 旧：誰のミスか
• 新：なぜ成立したか
• 旧：隠す
• 新：予防のために見せる
• 旧：静かに直す
• 新：仕組みごと直して、共有する

この切り替えができている組織は、もう十分に成熟している。

しかも、それは競争力になる。攻撃者より早く学べる組織が、結局強い。

そして今、攻撃者目線（アドバーサリアル思考）は、設計や開発の中に入り始めている。

次の問いは、ここだ。

「これを、組織を壊さずに、どう広げていく？」

------

[Series Structure] Pillar D | Threat Reality

Vulnerabilities will happen. The real question is not "Who caused it?" but "Why did the system allow this mistake to matter?" A blameless security post-mortem is not about being soft. It is about designing organizations where judgment survives pressure.

▶ Series overview: Series Map - Human Flexibility for Cyber Judgment

▶ Other posts in Pillar E (Pillar D | Threat Reality):

• Day 59 | Design with Attacker as Stakeholder
• Day 60 | Why Security Training Fails
• Day 61 | The Science of Experience
• Day 62 | The Numbers That Changed Everything
• Day 63 | When AI Becomes the Attacker
• Day 64 | The Ethics of Learning to Attack
• Day 65 | From Theory to Practice
• Day 66 | Method 1 :The Red Chair Technique
• Day 67 | Method 2: Abuse Cases Alongside Use Cases
• Day 68 | Method 3: STRIDE
• Day 105 | Method 4: Security Champions Network
• Day 106 | Method 5: Hands-On Attack Training
• Day 107 | Method 6: Security Guardrails as Defaults
• Day 108 | Method 7: The Secure Design Checklist
• Day 109 | Method 8: The Security Design Review Template
• Day 110 | Method 9: The Blameless Security Post‑Mortem

The Blameless Security Post‑Mortem

This practice comes from the Site Reliability Engineering (SRE) movement, popularized by Google and captured in the SRE book's chapter on postmortem culture. It was born in the world of outages but the underlying idea translates cleanly to security vulnerabilities: the same learning culture that prevents operational failures also prevents security failures.

Even with everything we've done so far, vulnerabilities will still happen.

Because systems are complex.
Because humans are human.
Because attackers evolve.

So when we find a flaw, the question is not: "Who messed up?"
The question is: "What allowed this to matter?"

Google puts it bluntly: a blameless postmortem focuses on contributing causes without indicting individuals or teams and assumes people acted with good intentions using the information they had at the time. That's not "soft." That's how you get the truth.

What a Blameless Post‑Mortem Actually Is (and isn't)

A postmortem is a written record of an incident: what happened, what it impacted, how it was mitigated, root causes, and the follow‑ups that prevent recurrence.

But in security, there's a trap: we can treat vulnerability like a crime scene and the engineer like the suspect.

That's not just unfair, it's strategically dumb.

Because if people expect punishment, they'll filter what they share. They'll sanitize timelines. They'll downplay uncertainty. They'll skip the embarrassing details. And those "embarrassing details" are usually the exact details that explain why the system failed.

Blameless doesn't mean anybody is accountable. It means we hold systems and processes accountable because those are the only things we can reliably improve at scale. Google even says the quiet part out loud: you can't "fix" people, but you can fix systems and processes that support people making the right decisions in complex environments.

How to Run a Blameless Security Post‑Mortem

1) What happened

Capture the facts so cleanly that someone who wasn't there can still see the shape of the failure.

Include:

• What the vulnerability was
• How it was discovered (internal testing, external report, customer, bug bounty, production signal, etc.)
• Potential or actual impact (data exposure, privilege escalation, lateral movement, integrity loss, availability risk)

Write it as a timeline, not a story. Stories have heroes and villains. Timelines have evidence.

2) Why it happened

This is the sharp edge--without the shame.

Ask:

• Which assumption failed?
• Which process step didn't catch it?
• Which guardrail was missing?
• Was knowledge or context missing at the point of decision?

This is the part where teams are tempted to stop at the obvious ("we missed validation," "we forgot a check," "we didn't threat model it"). Don't stop there. The goal is not to identify who made a mistake, but why the system made that mistake possible--and sometimes likely.

If you want a north star: investigate the systematic reasons an individual or team had incomplete or incorrect information. That's where prevention lives.

3) How we prevent recurrence

For each contributing factor, identify:

• Process upgrades
• Training gaps
• Tooling / automation
• Checklist additions
• Abuse case library updates
• New guardrails

This is not remediation.
This is evolution.

A fix patches today's hole. A postmortem hardens the organization against the next hole.

This mindset also aligns with modern incident response guidance that emphasizes integrating lessons learned into ongoing risk management, not treating "lessons learned" as a ceremonial final step.

4) Lessons shared

Security learning that stays local dies local.

Share:

• With all engineers, not just the impacted team
• With the Security Champions network (the people embedded in teams who help scale security knowledge and practice)
• With leadership when it changes risk posture or priorities
• Into onboarding/training when the lesson is foundational
• Into your internal attacker playbook as a real example

A vulnerability that remains a secret is a vulnerability that will happen again.

Google's SRE guidance also stresses that the value of a postmortem scales with how widely it's shared--and that a thoughtful, honest postmortem can help restore trust after an incident.

The culture shift (this is the real work)

Old culture → blame "Who made this mistake?"

New culture → learning "What allowed this mistake to cause harm?"

Old culture → concealment

New culture → transparency for prevention (because fear kills signal)

Old culture → "fix it quietly"
New culture → "fix the system loudly"

This shift is a sign of maturity.

It's also a competitive advantage. Because organizations that can learn faster than attackers evolve win.

And now that adversarial thinking is embedded into how we design and build, we need to answer a new question:

How do we roll this out without breaking the organization?

References　出典・参照文献

Google Cloud. (2017, November 28). Google's tips on how to hold a fearless shared postmortem. https://cloud.google.com/blog/products/gcp/fearless-shared-postmortems-cre-life-lessons

Google SRE. (n.d.). Postmortem Culture: Learning from Failure (Blameless postmortem for system resilience). https://sre.google/sre-book/postmortem-culture/

National Institute of Standards and Technology. (2025). Incident response recommendations and considerations for cybersecurity risk management: A CSF 2.0 community profile (NIST Special Publication 800-61r3). https://doi.org/10.6028/NIST.SP.800-61r3

OWASP Foundation. (n.d.). Security Champions (OWASP Security Culture Project). https://owasp.org/www-project-security-culture/v10/4-Security_Champions/

OWASP Foundation. (n.d.). OWASP Security Champions Guide Project. https://owasp.org/www-project-security-champions-guidebook/

OWASP Foundation. (n.d.). OWASP Security Champions Guide. https://securitychampions.owasp.org/