東京海上日動におけるセキュアな開発プロセスの取り組み NIKKEI Tech Talk #35 2025.07.24 

自己紹介 2 

自己紹介 3 宮島 拓也（みやじま たくや） 東京海上日動システムズ株式会社 ITサービス本部 ITサービス管理部 サイバーセキュリティチーム セキュリティスペシャリスト 経歴 2017年 東京海上日動システムズ新卒入社 • 営業管理系の社内業務アプリの開発・運用 • レガシーシステムメイン、ちょっとSalesforce 2018年 SaaSエンジニアへ転向（部署異動） • Microsoft365、Salesforceの開発・運用 • スマホでの業務実現のため、Intuneなどを設計したり 2022年 突然セキュリティに目覚め、セキュリティ基盤担当へ（部署異動） • セキュリティ共通システムの開発・運用 • 脆弱性管理システムやSIEMなど 2024年 セキュリティ管理担当へ（部署異動） • セキュリティ改善プロジェクトの計画・推進 • 各システムのセキュリティ評価 • 各開発プロジェクトのセキュリティ設計支援 • インシデントレスポンス 

東京海上日動システムズについて 4 

東京海上日動システムズの概要 5 サイバーセキュリティチームの概要 2012年に発足 2025年現在で約30名の専任部隊 東京海上日動とあんしん生命のセキュリティの戦略立案やポリシー策定、インシデントハ ンドリングや日々のモニタリングを行う 東京海上グループのIT・デジタル戦略を担う システム会社 Business Established Number of Employees 東京海上グループのIT・デジタル戦略を担う システム会社 東京海上グループの情報システムの 企画・提案・設計・開発・保守・運用・ システム活用支援 1983年9月 2004年10月 東京海上火災、日動 火災のシステムグループ３社が合併して 東京海上日動システムズ（株）が発足 1,736名（2025年4月現在） 平均年齢は38歳 

システム・案件の規模 6 システム 約700 サーバ 約7,000 開発案件 約4,000/年 業務端末 約50,000 

なぜ開発プロセス？ 7 

なぜ開発プロセス？ 8 NIKKEI Tech Talk #35 「Webプロダクトの多層防御」というテーマでなぜ開発プロセスを？ プロセスこそが、防御技術に実効性を与えるものだから 開発プロセス ルール通りにやりますね。 書いてないってことはいらないのか。 FW WAF ハードニング Proxy EDR・EPP リリース前診断 パッチ適用 etc... ただ声を張り上げても 全員には伝わらない 

なぜ開発プロセス？ 9 NIKKEI Tech Talk #35 「Webプロダクトの多層防御」というテーマでなぜ開発プロセスを？ プロセスこそが、防御技術に実効性を与えるものだから 開発プロセス なるほど。やります。 FW WAF ハードニング Proxy EDR・EPP リリース前診断 パッチ適用 etc... ...をやってください。 システムにセキュリティを実装するのはセキュリティ担当ではない。だからこそプロセス化が必要。 

東京海上日動の開発プロセスに おけるセキュリティ ～これまで～ 10 

東京海上日動の開発プロセスにおけるセキュリティ ～これまで～ 11 開発プロセスにおけるセキュリティ品質の取組の歴史 ～2010 セキュリティ専門人材はまだおらず、リリース前に開発者がDASTツールでスキャン。 2011 セキュリティ専門人材が誕生。定期的な脆弱性診断プロセスが開始。 公開Webアプリ用のセキュリティ要件とチェックリストが誕生。まだまだセキュリティ担当の関わりは薄い。 2021 散在するチェックリストを束ね、セキュリティチェックリストが誕生。セキュリティ担当が第三者評価するように。 開発者はセキュリティを自然と意識しはじめ、セキュリティ担当への相談も急増。 黎明期 安定期 リリース前にも手動診断を行うように。他にも多くのチェックリストが作られる。 要件定義 設計 開発 テスト リリース 運用 企画 チェックリスト中間評価 チェックリスト最終評価 手動診断（定期） DASTツール&手動診断 ～ 

東京海上日動の開発プロセスにおけるセキュリティ ～これまで～ 12 開発プロセスにおけるセキュリティ品質の取組の歴史 ～2010 セキュリティ専門人材はまだおらず、リリース前に開発者がDASTツールでスキャン。 2011 セキュリティ専門人材が誕生。定期的な脆弱性診断プロセスが開始。 公開Webアプリ用のセキュリティ要件とチェックリストが誕生。まだまだセキュリティ担当の関わりは薄い。 2021 散在するチェックリストを束ね、セキュリティチェックリストが誕生。セキュリティ担当が第三者評価するように。 開発者はセキュリティを自然と意識しはじめ、セキュリティ担当への相談も急増。 黎明期 安定期 リリース前にも手動診断を行うように。他にも多くのチェックリストが作られる。 要件定義 設計 開発 テスト リリース 運用 企画 チェックリスト中間評価 チェックリスト最終評価 手動診断（定期） DASTツール&手動診断 ～ めでたしめでたし ・・・では終わらなかった 

東京海上日動の開発プロセスにおけるセキュリティ ～これまで～ 13 時が経つにつれ、課題が続出 多すぎるチェック項目 一般的なWebアプリでチェック項目は 150以上。 それら全てが要回答・要評価。 双方への過負荷 現場は案件ごとにチェックリスト作成。 セキュリティ担当は限られた情報で評 価。 双方工数極大。 頭打ちな実効性 YESって回答だけど、本当にできて いるの？ でも信じるしかない。 もはや国語の問題と化す要件 項目数を減らそうとした結果、Excel のセルに入りきらない要件文。 難解すぎて現場は誤答・誤判断頻 発。 要件定義 設計 開発 テスト リリース 運用 企画 チェックリスト中間評価 チェックリスト最終評価 手動診断（定期） DASTツール&手動診断 遅すぎる脆弱性発見 リリース直前の脆弱性発見により、 手戻り発生。 診断手配のリードタイム テンポよく開発したい。すぐリリースし たい。でも診断見積が、契約手続 きが、、、 

東京海上日動の開発プロセスに おけるセキュリティ ～これから～ 14 

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 15 セキュリティとは、ビジネスを最大限支援するためのものでなくてはならない。それはシステム開発においても同じ。 「辛い・遅い・コスパが悪い」プロセスは見直す必要がある。 私たちが目指したい未来 ✓ 低実効性・高負荷なチェックリスト評価型統制からの脱却 ✓ 脆弱性は早期にみつけて素早く潰す。シフトレフト 

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 16 ✓ 低実効性・高負荷なチェックリスト評価型統制からの脱却 に向けた３つのチャレンジ Before After チェックリストの位置づけ 全項目をセキュリティ担当が評価するもの 開発者が活用できるリファレンス兼セルフリス ク評価ツール チェックリストの内容 項目数を気にして、難解長大な記述 項目数が増えてでも、シンプル明快に リスクと対策を誰もが理解できるように LLMによる高度化も見据えて セキュリティ評価手法 セキュリティチェックリスト中心の評価 チェックリスト評価はリスクベースで絞りつつ SAST/DASTやポスチャマネジメントでの 診断や設定チェック中心の実態評価 要件定義 設計 開発 テスト リリース 運用 企画 セルフチェック （チェックリスト） SASTツール診断 ・早期是正 各診断結果評価 手動診断（定期） ポスチャマネジメント ツール診断 ・早期是正 伴走支援 手動診断 &DASTツール 

High Medium Low High Medium Low YES NO High Medium Low 東京海上日動の開発プロセスにおけるセキュリティ～これから～ 17 After チェックリストの位置づけ 開発者が活用できるリファレンス兼セルフリスク 評価ツール リスクベースで本当に必要なところにパワーをかけ、診断結果の実態評価と開発者セルフチェックをメインとしたGuardrail型な“これから” 評価対象システム 外部からの攻撃の受けやすさ 攻 撃 成 功 時 の 影 響 度 評価対象項目 項 目 の 重 要 度 （ 危 険 度 ） × 開発者セルフチェック + セキュリティ担当も評価 開発者セルフチェック 開発者セルフチェック + セキュリティ担当も評価 開発者セルフチェック 開発者セルフチェック （診断結果は セキュリティ担当が 評価） 診断で確認可能な項目か ＝ ⚫ リスクベースで注力するセキュリティ担当 ⚫ 裁量と責任の両方を得て、各種診断というガードレールの内側で開発スピードを出せる開発者 ⚫ セキュリティに適正なリソースとスケジュールをかける開発プロジェクト 

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 18 After チェックリストの内容 項目数が増えてでも、シンプル明快に リスクと対策を誰もが理解できるように LLMによる高度化も見据えて シンプル明快を命題に、一問一答を原則に。 セルフチェックメインにするからこそ、「なぜ（リスク）」と「代替策（NOのときどうする）」を丁寧に解説。 人間が読み間違えない内容であれば、LLMにも取り込みやすいはず＝LLMによる高度化も目指せるようになるはず。 前提条件 目的 確認項目 満たせない場合の代替策 認証機能がある場合 辞書攻撃や総当たり攻 撃による不正アクセス脅 威の低減 パスワードは×種×桁以上とする ■■■■■する 認証機能がある場合 パスワード使いまわしの抑 制による不正アクセスの 低減 パスワード変更時、過去×回以内に設定履歴の あるパスワードは拒否する ■■■■■する 認証機能がある場合 辞書攻撃や総当たり攻 撃による不正アクセス脅 威の低減 連続×回の認証エラー時にアカウントロックする ■■■■■する ・ ・ ・ ユーザーのパスワードは以下をすべて満たすこと ①パスワードは×種×桁以上とする ②パスワード変更時、過去×回以内に設定履歴のあるパ スワードは拒否する ③連続×回の認証エラー時にアカウントロックする ④パスワード設定時、〇〇〇なパスワードは拒否する ⑤パスワードの使いまわしはしないようユーザーに周知する ただし、①～③が満たせない場合は、■■■■■とするこ とで代替策としてもよい また、④、⑤が満たせない場合は、 ■■■■■もしくは ▲▲▲とすることで代替策としてもよい 分解 

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 19 After セキュリティ評価手法 SAST/DASTやポスチャマネジメントでの 診断や設定チェック中心の実態評価 SASTとDAST、ポスチャマネジメントで発見さ れた脆弱性は修正済み。再診断で潰し込みも 確実。 未修正項目は代替策としてこの設定が～ 未修正項目についてだけ確認させてほしい。 代替策に加えて例えばIP制限って～ ～真に必要な数回のやりとりを経て～ 診断で致命的なものはでてないし、 未修正も判断根拠十分。承認！ 検出ベースだから話もスムーズだったな、 次工程にもすぐ移れるぞ！ アウトプット ：品質根拠のあるセキュリティチェック結果 評価の根拠 ：診断結果と設定値 疲労感 ：必要最小限。納得感もある 

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 20 ✓ 脆弱性は早期にみつけて素早く潰す。シフトレフト に向けた２つのチャレンジ Before After セキュリティ担当の関与 相談が来たら対応。QA型 高難度案件は、要件定義・設計段階から 伴走支援 脆弱性診断の方法 リリース直前にDAST(ツール＋手動)のみ SAST＋DASTの2段構え 要件定義 設計 開発 テスト リリース 運用 企画 セルフチェック （チェックリスト） SASTツール診断 ・早期是正 各診断結果評価 手動診断（定期） ポスチャマネジメント ツール診断 ・早期是正 伴走支援 手動診断 &DASTツール 

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 21 After セキュリティ担当の関与 高難度案件は、要件定義・設計段階から 伴走支援 高難度案件・重要案件にプロジェクトチームの一員として深く入り、脆弱性をそもそも作りこませないことにパワーをかける“伴走支援” とあるアジャイル開発で伴走支援を試行してみた例。 結果として、Day8で検出された脆弱性は非常に軽微かつ数も少なく、手戻りは発生しなかった。 Day1 Day2 ～ Day7 Day8 Day9 Day10 開発チーム スプリントプランニング 設計 開発 テスト 脆弱性修正 レトロスペクティブ セキュリティ担当 システム理解 要件理解 セキュリティレビュー計画・ テスト計画 セキュリティ設計レビュー セキュアコーディングレビュー SAST / DAST ⇒ 修正支援 ブラックボックステスト （全機能DAST） 脆弱性修正支援 

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 22 After 脆弱性診断の手法 SAST＋DASTの2段構え SASTで見つけられる脆弱性をDASTまで残存させないことで、開発後期の脆弱性発見＝大きな手戻りの可能性を減らす 書いたコードでこう検出された、という経験の繰り返しが現場のセキュアコーディングスキル向上に寄与 開発 テスト 資源開発するたびに自動SASTツール診断＆すぐ是正 SASTでしか検出できない脆弱性 DASTでしか検出できない脆弱性 両方で検出できる脆弱性 リリース ツール＆手動診断 

まとめ 23 

まとめ 24 ⚫ 多層防御技術に実効性を持たせるのは、開発プロセスである ⚫ ただし、レガシーなチェックリスト統制では、かかる負担に対して効果が見合わない ⚫ 全てが高速化する今の世の中、シフトレフトなプロセスへと改善することが急務 ⚫ プロセス上のGatewayは最小限に、可能な限りGuardrail型へ 

ありがとうございました