説明が可能なプロダクトセキュリティについての一考察 / 開発者向けブログ・イベント

初めまして、GMO インターネットグループクラウドセキュリティ領域のエキスパートで、GMO Flatt Security 株式会社の齋藤です。この記事は GMOインターネットグループ Advent Calendar 2025 10日目の記事です。

この記事では、プロダクトを提供する組織が向き合うべき「セキュリティとは何か」について、“なぜやるのか”という観点をもとに、説明可能なプロダクトセキュリティのあり方について一考察を書いていきます。

また、主な想定読者は「一人目セキュリティエンジニア」「兼任でのセキュリティ組織の立ち上げを検討している方」「プロダクトを提供する組織でセキュリティを何から始めるか考えている方」としております。

筆者の考察

「プロダクトを提供する組織におけるセキュリティとは何なのか」。筆者は今年度、クラウドやプロダクトのセキュリティについて登壇や発信をする中で、この問いに向き合う機会がありました。

セキュリティ実務をする者として真っ先に思い浮かぶのは、技術的実装や運用プロセスの整理、セキュリティポリシーの策定、認証取得といった取り組みです。これらは確かに重要であり、組織の成熟度を高める上で不可欠です。しかし、それらはあくまで「何をするか」という手段の話であって、「なぜセキュリティ施策をするのか」 という目的への考察には至っていませんでした。

では、プロダクトを提供する組織におけるセキュリティの本質的な目的とは何でしょうか。

極論では、「ステークホルダーに発生する損失を全てなくすこと」が目的になりますが、現実的にこれを遂行するのは技術やコストといった点で難しいです。その中で現実的な落とし所として「全てのステークホルダーに対して、”信頼”・”価値”・”事業”・”コスト”・”社会的責任/倫理”の各側面で生じ得る損失を、組織として許容可能な範囲にコントロールすること」に集約されると考えます。

本稿における「許容可能な範囲にコントロール」とは、組織が定めたリスク受容度（Acceptable Risk）に基づき、インシデントが発生した際に生じ得る損失について、「その規模と影響が受容基準に整合している」「発生可能性と影響を把握し説明可能な状態にある」といった観点で管理できている状態、またはその水準に到達するための活動を指します。なお、本稿で扱うリスク受容は ALARP（As Low As Reasonably Practicable）原則を前提に、”ゼロリスクではなく合理的に低減し続ける” という考え方に基づいています。

この記事では、この筆者の論をベースに目的や手段の関係やどのように進めていくかを整理していきます。

前提: ステークホルダーと損失の分解

この記事の議論を正しく受け取ってもらうために、まず前提となる 2 つの視点を共有します。 1 つは、プロダクトを提供する組織にとってのステークホルダーは誰か、もう 1 つは、“信頼・価値・事業・コスト・社会的責任/倫理”という損失をどのように捉えるかです。

1. ステークホルダーは誰か

セキュリティは特定の組織や担当者だけの問題ではなく、プロダクトを取り巻く多様なステークホルダー全員に影響します。これらを組織の外部と内部に分け、それぞれの属性を整理します。

組織外のステークホルダー:

組織外のステークホルダーは、プロダクトを「利用する側」「評価する側」「社会的に許容する側」として、組織の意思決定や安全性の結果を直接的に受け取る立場です。彼らの要求や期待水準は多層的かつ相互に異なり、プロダクトの安全性が揺らいだ際には、後述する各側面での損失が発生し、信頼の失墜やサービスそのものの乗り換え、社会的批判など事業組織としての影響が発生します。

属性	概要
個人顧客顧客企業社員	・プロダクトを実際に利用し、価値を享受する層。・価値の享受を受けるということは、その分多くの情報や機微情報をプロダクトに預けているという状況にある。・安全性・信頼性・体験品質の低下は購買や利用といった行動に直撃する。
顧客企業（調達・購買・CIO/CISO）	・プロダクトを業務基盤として採用する主体の層。・個人顧客同様にプロダクトを実際に利用し、価値を享受する層でもあり、観点として重複する箇所もある。・個人顧客に比べより可用性、法令順守、運用負荷などに関する要求が強い。・業務上・事業上の機微情報を取り扱う可能性があるので、信用等を気にし利用に際して評価を行う。
規制当局・社会	・プロダクトが社会的に適切に振る舞っているかを判断し、許容範囲の基準（プライバシー、消費者保護、公共性、倫理）を定める存在。・違反等があった場合は業務停止や事業そのものの存続ができなくなることも。

組織内のステークホルダー:

組織内のステークホルダーは、プロダクトを「作る側」「支える側」「統制する側」として、セキュリティを実装し維持する主体です。組織内部といっても役割は明確に分かれ、価値を生む、リスクとガバナンスを支援する、統制の妥当性を検証するという三層構造によって成り立ちます。これらの関係性が曖昧になると、責任の所在がぼやけ、セキュリティ施策が持続せず、インシデント発生時の対応も破綻しやすくなります。組織内のステークホルダーの役割と境界を明確にすることは、プロダクトセキュリティの基盤そのものです。

属性	気にする観点
経営層	信頼、ブランド、事業継続性、コストなど全側面の最終的責任を負う。
実行組織（開発・運用・PdM・営業など）	プロダクト価値を実際に生み出すライン。安全で持続可能な開発・運用体制が必要。
内部専門組織（セキュリティ、法務、リスク管理）	リスク評価、ガバナンス、標準化、仕組み化などを通じて 1 線を支援する役割。
監査（内部監査、監査役、外部監査）	統制が適切に働いているかを独立した立場からチェックする。

外部・内部で整理したこれらのステークホルダーは、それぞれが異なる期待・要求・制約を持っており、プロダクトの安全性が揺らいだときに受ける影響もまったく異なります。そして重要なのは、どのステークホルダーにとってもセキュリティは“付加価値”ではなく、“失ってはならない前提条件”として働いているという点です。

どれか 1 つでも満たせなくなれば、信頼・価値・事業の継続・コスト・社会的責任といった領域で大きな損失を引き起こす可能性があります。

2. 想定される損失

次に、セキュリティが防ぐべき「損失」を、信頼・価値・事業・コスト・社会的責任/倫理の 5 つに整理します。これら損失（リスク）は、金銭的に換算できるものも存在しますが、ブランドイメージの毀損や信頼の低下、人的疲労、組織的疲労など金銭的に換算しにくい損失も存在します。

プロダクトセキュリティの議論では、「どのような対策をするか」よりも先に、“何を失う可能性があるのか” を正しく把握することが本質です。損失が可視化されなければ、対策の優先順位も、必要な投資量も、どこまで手当てすべきかも合理的に判断できません。

ここでは、ステークホルダーが直面し得る損失を 5 種類に分類し、それぞれの性質を整理します。

損失(リスク)の種類	損失の例
信頼の失墜	・信頼やブランドという無形資産の損失・心理的負荷による人的損失
顧客価値の低下	・インシデントの調査や復旧により本来提供できるはずだった価値の提供停止・サービスの停止によるユーザー体験の劣化
事業価値/事業成長の低下	インシデント発生によって即座に発生するわけではないが、起因して発生する損失として以下のものが考えられます。・事業継続性の喪失・業務停止によって発生する継続損失・生産性／イノベーション損失（開発停止・改修遅延・内部疲弊）
コストの発生	・復旧や調査・補償・代替手段構築上記以外に発生する実費的損失
社会的責任の追求/倫理違反	・プライバシー・規制違反・罰則・説明責任・社会的外部性（公共への悪影響）

これらの損失は、単独で発生することもあれば、連鎖的に広がることもあります。特に「信頼」と「価値」の損失は、可視化されにくい一方で事業への影響が大きく、発覚した時点では取り返しのつかない状態になっていることが多い領域です。したがってセキュリティの第一歩は、これらの損失を組織としてどこまで許容できるか（＝許容可能なリスクの境界）を明確にすることにあります。

目的となる「各側面において損失を出さない」とは

ここまで整理したとおり、極論では「ステークホルダーに発生する損失を全てなくすこと」が目的になりますが、現実的にはプロダクトセキュリティは「信頼・価値・事業・コスト・社会的責任／倫理」という 5 つの損失を、組織として許容可能なレベルに抑えることに重点をおくことになると考えます。

現代のプロダクトやそれらを提供する組織は複雑化し、依存するサービスやコンポーネントなどが増加し続けています。そのため、どれだけ対策を講じても、潜在的なセキュリティリスクや未知の脆弱性、人為的ミスなどの可能性を全て排除することは難しいです。したがって、セキュリティの本質は「発生可能な損失（リスク）を合理的に低減し、発生した場合でも致命的な被害に至らないようダメージをコントロールすること」にあります。

ダメージコントロールは、軍事や自動車、医療分野、格闘技など、特定の”損害”が発生する分野において、その損害を悪化させないための処置のことで継続的に行動や事象の悪化をさせないことを目的にします。本稿では、発生する損害をいかに最小化するかの意味でこの語を用いています。

この「ダメージのコントロール」は次の 3 つの観点に分解できます。

発生の蓋然性や必然性を下げる: 設計、実装、運用プロセスの中で、脆弱性や攻撃につながる設定ミスをあらかじめ発見するなどし、事故や攻撃の蓋然性や必然性を現実的に低減する。
影響範囲を限定する: 権限分離、データ分離といった形で、発生時における侵害範囲を限定しながら、監査証跡の確保や攻撃の観測を行い、リスクの早期検知をし初動対応を可能にする
再発生の蓋然性と必然性を下げるインシデントについての原因追及に関する説明可能性の確保: インシデントが起きた際に、何が起き、なぜそうなり、どう対処したかをステークホルダーに対して説明可能な状態を維持し再発防止策の策定と実施を可能にする。

特に 3 点目の説明可能性は、企業・組織における信頼の失墜を最小化し、合理的な説明と、それまでの対策などについて真摯に対応することで少なからずではありますが信頼の回復に直結します。技術的に完全であること以上に、「状況を把握し、判断し、説明できる組織であるか」が問われるためです。

手段の大枠: リスクベースのセキュリティ対策

プロダクトのセキュリティを考え実装する際に、最初にやりがちな行動として、「対策」や「手法」から議論を始めてしまうことです。もちろんこれらは大事であり、喫緊の課題や直視すべきリスクを見つける上で重要な取り組みです。ただ、目的との紐づきが曖昧なままに取り組みや施策を積み上げると”やっている気がするだけ“の散発的な対策になり最終的に明確な対策が施せません。

ではどこから考えるべきか。結論としては明確で、先の各側面において損失を出さないという観点で話した「リスク」をベースにセキュリティ施策を考えるのが良いと考えます。

施策を考える際の起点は以下の 5 つです。

事業組織としての重要資産（クラウンジュエル）を特定する
組織の提供するプロダクトにおけるステークホルダーと損失（リスク）の構造を理解する
発生しうる損失（リスク）を評価する
「どこまでの損失なら許容できるか」を決める（＝リスク受容度）
対応方針を選択して決める

この章では、これらについて深掘りしていきます。

1. 事業組織としての重要資産を特定する

まず着手すべきは「何が侵害されると致命的なのか」を特定することです。これがいわゆる重要資産（Crown Jewels とも呼ばれるもの）であり、プロダクトの存在意義そのものと言ってよい領域です。

重要資産は組織や事業モデルによって異なりますが、典型的には以下が含まれます。

個人情報、決済情報、医療データなど機微性の高いデータ
顧客企業の業務データ、SaaS 内の蓄積ログ
認証・認可の基盤（ID 管理、鍵管理、トークン発行など）
インフラのルート権限や KMS のマスターキー
プロダクトの価値を形成するアルゴリズム・内部ロジック
外部と接続する API・連携基盤

個人情報、決済情報、医療データなど機微性の高いデータが漏洩した際の想定損害賠償額については、2018 年に JNSA がまとめた、情報セキュリティインシデントに関する調査報告書が参考になります。

これらは侵害された場合に、前述の全ての損失を瞬間的に引き起こす可能性があります。

したがって、以下のようなことが言えます。

重要資産を守るために、どこに投資し、どのリスクを許容し、どの対策が必須なのかが決まる。

重要資産の不明確な組織は対策が散発的になり、セキュリティ部門が守るべき資産を把握しきれない状態になってしまいます。

2. プロダクトにおけるステークホルダーと損失（リスク）の構造を理解

前章で述べたとおり、セキュリティの目的はステークホルダーに対して発生し得る損失を許容範囲に収めることです。したがって、まずは「誰にどんな損失が起き得るのか」を構造的に整理します。

どのステークホルダーに
どの損失（信頼・価値・事業・コスト・社会的責任）が
どの程度の深刻度で降りかかるのか

これが可視化されれば、対策の方向性と強度、優先順位は自然に決まります。

3. 発生しうる損失（リスク）を評価する

では、そのリスクは実際に起こりうるのかについて、プロダクトとして提供されるソフトウェアの領域ではどのように評価すべきでしょうか。

例えば、OWASP SAMM（Software Assurance Maturity Model）のようなフレームワークが成熟度と置かれている環境の評価の道標となります。SAMM は Governance・Design・Implementation・Verification・Operations の 5 つのビジネス機能で構成され、各領域における成熟度を段階的に高めていくモデルです。SAMM の成熟度の評価を各種プロダクトやソフトウェア毎に行うことで、現状のリスクや脅威が可視化され、改善の指針を組織全体に示すことができます。

ビジネス機能	概要
Governance （ガバナンス）	この項目は組織がソフトウェア開発活動全体をどのように管理するかに関わるプロセスと活動に焦点を当てています。評価対象としては、開発に関与する部門横断的なグループに影響を与える懸念事項や、組織レベルで確立されたビジネスプロセスが定義されているかなどがあります。
Design （設計）	この項目は開発プロジェクトにおいて組織が目標を定義し、ソフトウェアを開発する方法に関するプロセスと活動に焦点を当てます。評価対象としては、要件収集、高レベルのアーキテクチャ仕様策定、詳細設計などがあります。
Implementation （実装）	この項目は組織がソフトウェアコンポーネントとそれに関連する欠陥を構築および展開する方法に関連するプロセスとアクティビティに焦点を当てます。評価対象としては、対象となるソフトウェアの実装におけるセキュリティ施策の対応状況やビルドや提供に関する観点などがあります。
Verification （検証）	この項目は組織がソフトウェア開発全体を通じて生成される成果物をどのようにチェックおよびテストするかに関するプロセスと活動に焦点を当てています。評価対象としては、テストなどの品質保証、コードのレビューおよび評価活動などがあります。
Operations （運用）	この項目はアプリケーションとその関連データの運用期間全体を通じて、機密性、整合性、可用性を維持するために必要な活動を評価します。

4. 「どこまでの損失なら許容できるか」を決める

セキュリティについて重要な観点として、”どこまで守れば十分なのか“を決めることですが、組織によってはこの議論が後回しになってしまう可能性があります。極論「全ての損失を許容しない」というのも 1 つではあるのですが、以下の観点を鑑みると現実的には「最強のセキュリティ」を実装するのは難しいでしょう。

インシデントがあった際の事業への影響度
顧客が求める要求水準
規制要件
同業他社との兼ね合いと優位性
組織の文化や開発スピードへの影響
人や時間、金銭的なコスト

そこで、考えるべきこととして許容度を設定するということです。許容度の決定は、重要資産と損失構造が明確になっていなければ不可能です。例えば、代替可能な手段が存在しており、同業他社プロダクトへの乗り換えが容易な場合、顧客の機微情報やサービスの停止というのは事業の継続ができなくなる、またはサービスそのものが採算が取れなくなります。

ここまで決まって初めて、手段の優先順位が合理的に並びます。

事業組織にとってのセキュリティは、前提として社会的責任や消費者保護の観点があります。その上で有限である経営資源をどのようにセキュリティ施策に適用していくかを判断する必要があり、”無限に強くする“という必要はありません。

“無限に強くする”の正確性に関する補足: 無限の資産があるのであれば無限に強くする活動になるが、有限な経営資源をいかに活用をするかという活動が、セキュリティ対策です。

その際に考慮すべき点として「どの損失を、どの程度まで経営上受容や許容をするか（Risk Appetite と Risk Tolerance）」というものがあります。これらを先に決めなければ、対策の強度・投資額・優先順位が確定できないわけです。

実務では、次の 4 点を定義します。

1. 対象となる損失の単位

信頼／価値／事業／コスト／社会的責任の各分類ごとに、何を損失と見なすか
例：PII の保護、社会的責任、価値の提供と稼働率、顧客解約率、ブランド毀損、行政処分の有無など

2. しきい値（受容と許容の境界）

事業上受容できる範囲と許容できない範囲を決定し、インシデント対応の指標とする

3. 意思決定権限の明確化

誰が受容を決め、誰が承認し、誰が説明責任を負うのか
受容は経営判断であり、実務者が「勝手に受容」せず、レポートラインを通して報告をする

4. 想定とレビューの頻度

月次：運用 KPI、四半期：経営レビュー、年次：リスク再評価としきい値の見直し
ALARP の原則を明示（合理的に下げられるなら下げる／過剰投資はしない）

この 4 点が定義されて初めて優先順位が明確になります。これらは経営層にも明確に意識をしてもらう必要があるのですが、本題からずれる関係上この記事では詳細については触れません。

サイバーセキュリティ経営ガイドライン Ver 3.0 を参考にしてみてください。https://www.meti.go.jp/policy/netsecurity/downloadfiles/guide_v3.0.pdf

結果として、重要資産周辺に経営資源が集中し、“散らばったセキュリティ施策”が消えます。

この許容度に基づいて、次に具体的な対応方針を選択していきましょう。

5. 対応方針を選択し決定する

最後に各種リスク評価や許容度をもとに対応の方針や優先度を定めていきます。その際に、先に現状の評価に用いた OWASP SAMM を活用しましょう。SAMM は各領域がソフトウェアのライフサイクルとも合致しており、具体の手段に関しては組織に委ねられているものの、どのような施策を取るべきかについて明確な指針を提示できます。

ビジネス機能	主な取り組み内容
Governance （ガバナンス）	・セキュリティ戦略の策定・ポリシーの整備・エンジニア教育の実施・重要資産の特定と優先度の策定 → セキュリティを推進するための土台を築き、組織全体の方向性を決定づける
Design （設計）	・脅威モデリングによるリスク分析・セキュリティ要件の明文化・多層防御を前提としたアーキテクチャ設計 → 設計段階でセキュリティを組み込むことで後工程での手戻りを削減
Implementation （実装）	・セキュアコーディングガイドラインの策定・CI/CD へのセキュリティチェック統合・依存ライブラリの脆弱性管理・シークレット管理の実装 → 開発プロセスの中にセキュリティを自然に埋め込む
Verification （検証）	・脆弱性診断（SAST/DAST）・ペネトレーションテスト →「守れているつもり」から「守れていることを検証済み」の状態へ移行
Operations （運用）	・インシデント対応手順の整備・ログ取得・脅威検知の仕組み構築・パッチ管理・アクセス権限の定期的な棚卸し → インシデント発生時の説明可能性と迅速な対応を支える

これらの施策は一度にすべて実装するものではありません。SAMM の成熟度モデルに従い、まず組織の現状を評価した上で、各プラクティスの成熟度を段階的に高めていく必要があります。重要なのは、自組織のリスク受容度と重要資産に基づいて優先順位を決め、持続可能なペースで改善を積み重ねていくことです。

「何」を守るために「どのような」施策を練っていくのかを穴埋め的に施策を練り、実装していくのがリスクベースのセキュリティの第一歩になると思います。

詳しい実装などについては、こちらのドキュメントをご覧ください。

設計・開発・テストにおけるセキュリティの実践と考え方を知ろう by @a-zara-n
設計・開発・テストにおけるセキュリティの実践と考え方を知ろう – 広島ミニキャンプ by @a-zara-n

まとめ

プロダクトセキュリティは、技術的課題という側面とともに、組織としての姿勢と能力が問われる経営課題でもあります。セキュリティ施策は数多くありますが「何をするか」の前に「なぜやるのか」を明確にし、その理由を組織内外へ説明できる状態にするということが、今回の登壇を通して私が伝えたかったことです。組織ごとに目指すセキュリティのあり方というのは多くありますが、組織が持つべき姿勢は、「全ての利害関係者の損害を可能な限り最小限に抑え、いざという時に何が発生したのかを説明できること」だと考えます。
この記事が、一人目セキュリティエンジニアや、これからセキュリティ組織の立ち上げを検討している方々にとって、「どこから始めるか」「何を優先すべきか」を考える際の一助となれば幸いです。