設計・開発・テストにおけるセキュリティの実践と考え方を知ろう

本日のアジェンダ全体像や背景の把握 1 章セキュリティインシデントの実例と影響 / 2 章 Shift-Left アプローチとその全体像設計・開発・テスト・運用における実践 3 章設計フェーズのセキュリティ統合 / 4 章実装フェーズのセキュリティ実践 / 5 章 CI/CD パイプラインのセキュリティ / 6 章運用時のセキュリティ管理組織や指標、説明 7 章プロダクトセキュリティ組織ってなんで必要なの？/ 8 章セキュリティメトリクスと KPI / 9 章セキュリティ投資の ROI 評価実践 10 章 CTF で脆弱性を見つけよう (事後課題) セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 3

4.

5.

6.

講義にあたっての講師の 3 つの考え 1. 組織や人、技術やソリューション、使えるものを全て使う: プロダクトはスケールし、日々変化をする。できる限り属人性を排除し、使えるものを全て使う。技術的なこだわりも大事であるが、調整能力や説明能力、対話力、すべてが必要である。 2. 標準やフレームワークの活用など公の知識をまずは理解し落とし込む: オリジナルのセキュリティ施策やルールより、まずは集合値たる標準やフレームワークをすることで、業界で直面する"多くの課題"を解決することができる。これらフレームワークに則りながら OSS や製品、独自の指針に合わせたツールの作成を行いプロダクトとその利用者の安心と安全に寄与する。 3. スペシャリスト + リーダーシップを持ったモデレーター: 全員がセキュリティを意識する過程で、その専門家・調整者としてセキュリティエンジニアがいるのが望ましい。リーダーであってもいいが、調整者として振る舞うことで、俗に言う "ゲートキーパー" とならないセキュリティ部門を構築することができる。セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 6

7.

8.

9.

10.

11.

講義タイトル B2 との関連クラウドプラットフォーム運用フェーズの B1 監視入門実装詳細デジタルアイデンティティ認証設計の具体 B3 とパスキー実装 Kubernetes クラウドネイインフラセキュ B4 ティブリティ実装脅威モデリング B5 攻撃者視点の開発の実践 API セキュリティアーキテ設計パターンの B6 クチャ応用関連セクションセクション 6（運用）セクション 3（設計）/ セクション 4（実装）セクション 5（CI/CD）セクション 1,3,5（インシデント・設計・CI/CD）セクション 3,4（設計・実装）セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 11

12.

13.

なぜセキュリティインシデントの理解が必要かインシデントが発生することで発生するプロダクトにおける課題プロダクトへの影響サービス停止による数億円規模の損失になる可能性も最悪サービス終了の可能性新規機能の開発の停止ブランドイメージの毀損株価への影響顧客離反率採用コストの上昇、優秀人材の獲得困難逆に稀に優秀人材がやってくる人も...?(必殺仕事人的な人 / N = 1 程度の話) セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 13

14.

ビジネス機会損失と財務インパクト - 経済的損失機会損失顧客の入札資格喪失交渉力の低下 GDPR 違反による制裁の可能性個人情報保護法違反による信頼の失墜財務的損失インシデント対応平均コスト: 3.86 億円（IBM Security 調査）集団訴訟リスクサイバー保険料の上昇新機能開発停止による競争力低下セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 14

15.

16.

決済セキュリティインシデントの実例 Target 社データ侵害事例（2013 年）万件のカード情報流出 7,000 万件の個人情報漏洩総損失: 2.5 億ドル以上原因: POS 端末マルウェア、カード情報の不適切な保存 4,000 国内 EC サイト事例（2019-2023 年）複数の EC サイトでカード情報漏洩 SQL インジェクションによる攻撃平均被害額: 1 件あたり 3.2 億円加盟店契約解除のリスクセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 16

17.

18.

Work: 気になったインシデントについて学びを得ようみんなで話をして直近にあったインシデントの報告書や初動対応を読んでみましょう。自分自身が開発者の場合、どのような学びがあるか一人一つ出していきましょう。視点 - セキュリティの原理原則技術的トピック組織的トピックビジネス的トピック https://piyolog.hatenadiary.jp/ 参考にすると良いもののどれか https://www.jnsa.org/result/incidentdamage/202402.html セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 18

19.

20.

なぜインシデント事例から学ぶのか - 実践的学習アプローチ他社のインシデントは明日の自社の課題を理解準拠すべき基準や業界標準などの違反を理解することで、既知のリスクを回避攻撃パターンの事前把握により、同様の脆弱性を開発段階で回避実際の被害額を知ることで、セキュリティ投資の正当性を理解「自分たちは大丈夫」という正常性バイアスの打破プロダクト開発への直接的な教訓 s 事例 → サポート機能の設計時に HAR ファイル取扱いを考慮 GitHub Copilot 事例 → AI 利用時の機密情報管理ポリシー策定国内事例 → サプライチェーンを含めた脆弱性管理の必要性決済情報の保持要件事例 → センシティブ情報の取り扱いに関する関心 Okta コンプライアンス要件の把握などセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 20

21.

セキュリティの 3 つの基本原則 - 実践的なアプローチの核となる考え方 1. 想定と準備: 侵害される前提での設計インシデント事例が示す「完璧な防御は不可能」という現実被害を最小化する設計（ブラストラディウスの縮小） 2. 多層防御: 単一障害点の排除事例: MFA 迂回後も被害拡大を防ぐ仕組みの必要性各レイヤーでの独立した防御メカニズム Okta 3. 最小権限: 必要最小限のアクセス権付与サポートエンジニアの過剰な権限が被害を拡大ゼロトラストアーキテクチャの実践的適用セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 21

22.

学んだ重要ポイントのまとめ誰のためのセキュリティなのか？: プロダクトが提供する価値を享受するステークホルダーのためにする。第 1 章から得られた重要な洞察大手企業でも深刻な被害が発生サプライチェーン攻撃が増加傾向直接的損失は氷山の一角信頼失墜が最大の長期的影響隠蔽は不可能かつ高リスク誤った情報を発出することで発生する顧客からの信頼失墜次のステップ: Shift-Left アプローチの実践へセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 22

23.

24.

25.

ウォーターフォール型開発のフェーズと場面典型的なフェーズ: 要件定義 → 全体的な要求事項の明確化 2. 設計 → システムアーキテクチャと UI/UX 設計 3. 実装 → コーディングと単体テスト 4. テスト → 統合・システム・受入テスト 5. デプロイ・保守 → 本番環境への展開と運用 1. 適用場面: 規制が厳しい業界（金融、医療、政府）要件が明確で変更が少ないプロジェクト大規模で複雑なシステム開発セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 25

26.

従来のウォーターフォール型開発でのセキュリティ従来の手法におけるセキュリティ対応と課題: 後工程でのセキュリティ対応: セキュリティテストは開発完了後のテスト工程で実施発見の遅延: あと工程で実施することで脆弱性の発見が開発サイクルの終盤に集中修正コストの増大: 設計に起因する問題の修正には大規模な手戻りが発生リリース遅延: セキュリティ問題の修正がプロジェクト全体のスケジュールに影響結果として: セキュリティ対策が「後付け」になりがち根本的な設計変更が困難ネガティブな要素でセキュリティチームと開発チームの軋轢が生まれてしまうセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 26

27.

28.

アジャイル開発の特性 - 2 開発サイクル: スプリント: 1-4 週間の短期開発サイクルデイリースタンドアップ: 日次の進捗共有スプリントレビュー: 成果物のデモと検証レトロスペクティブ: 継続的改善の実施主要な役割: プロダクトオーナー: ビジネス価値の最大化スクラムマスター: プロセスの促進とサポート開発チーム: 自己組織化された実装チームセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 28

29.

従来のアジャイル型開発でのセキュリティ典型的な問題点: スプリント優先: 機能開発が優先され、セキュリティが後回しに技術的負債の蓄積: 「後でセキュリティ対策」が積み重なるセキュリティレビューの省略: 短いイテレーションでセキュリティレビューが不十分ドキュメント不足: セキュリティ要件や脅威モデルの文書化が疎かによくある誤解: 「アジャイルだからセキュリティは柔軟に対応」→ 実際は場当たり的になる「継続的デリバリーで修正も早い」→ 本番環境での脆弱性露出リスクも存在するセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 29

30.

Shift-Left アプローチとは従来: 開発完了後にセキュリティテスト問題発見時の修正コストが高いウォーターフォールにおける"テスト"などでセキュリティを考えると発生する課題 Boehm のコスト曲線によるコスト増加リリース遅延のリスク Shift-Left: 設計・開発段階からセキュリティを組み込み早期発見・早期修正アジャイルやウォーターフォール問わずに、各フェーズにセキュリティを取り入れる継続的なセキュリティ改善や SSDLC 的思考の導入開発ライフサイクルの早期段階でセキュリティを統合するアプローチ DevSecOps セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 30

31.

コスト効果の実証データの例設計段階での修正は本番環境の 1/100 のコスト (Boehm のコスト曲線、ベームの法則などでも言われる内容) Shift-Left の効果 $100K 修正コストの段階的増加 ✓ 設計段階での修正は実装段階の1/10 ✓ 設計段階での修正は本番環境の1/100 コスト⽐率 1:10:100 ）DSU（トスコ正修設計:実装:本番 $10K $1K $100,000 $10,000 $1,000 設計段階実装段階本番環境セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 31

32.

Shift-Left - 4 つの柱包括的なセキュリティ統合アプローチセキュリティ・バイ・デザイン: 設計段階での脅威モデリング開発者ベース底上げ: セキュアコーディング教育継続的セキュリティテスト: SAST や DAST の CI/CD 統合フィードバックループ: 運用からの学習と改善セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 32

33.

34.

35.

36.

37.

開発プロセス統合の実践各開発フェーズでのセキュリティ活動計画・要件定義: 脅威モデリング、セキュリティ要件定義設計: セキュアアーキテクチャレビュー、データフロー分析実装: セキュアコーディング教育、静的解析ツール(SAST)、レビューテスト・デプロイ: 動的セキュリティテスト、検証自動化セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 37

38.

Work: SSDLC 実装における組織的課題をいかに解決するか？開発現場に SSDLC を適用させるためには多くの課題が存在します。これら課題をいかに対策/アプローチをしていくべきか、みんなで考えてみましょう。課題スキルギャップ , セキュリティ知識不足プロセス変更抵抗 , 既存ワークフロー変更ツール疲れ , 過剰なアラート・ノイズ責任の曖昧さ , Dev vs Sec, 責任分界点投資対効果 , ROI 証明の困難視点施策はトップダウンが良いのか？それともボトムアップ/並走するのがいいのか？やらないという選択肢ややるための利点をいかに説明するのか？セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 38

39.

実装における組織的課題技術導入以上に重要な"人"・"プロセス"・"文化の変革" SSDLC 課題カテゴリ具体的な障壁対策アプローチスキルギャッセキュリティ知識段階的教育プログラム、ペアプログラミング、自動プ不足化やツールの導入プロセス変更既存ワークフロー小さな成功体験の積み重ね、段階的導入抵抗変更過剰なアラート・ツール疲れノイズチューニング、優先度付け、統合ダッシュボード Dev vs Sec 責任分 RACI マトリックス、クロスファンクショナルチー責任の曖昧さ界点ム投資対効果 ROI 証明の困難メトリクス可視化、段階的な成果測定セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 39

40.

ウォーターフォール型でのセキュリティ統合包括的な事前計画によるリスク管理フェーズセキュリティ活動成果物要件定義セキュリティ要件抽出セキュリティ要件書基本設計脅威モデリング脅威分析文書詳細設計セキュアコーディング標準設計仕様書実装コードレビュー・SAST セキュアコードテストペネトレーションテストテスト報告書メリット: 包括的計画、明確なゲート、詳細文書化セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 40

41.

42.

43.

44.

45.

46.

ツールエコシステムの構築効果的な Shift-Left を支える自動化ツール群静的解析 (SAST): SonarQube, Semgrep 依存関係管理: OWASP Dependency-Track、GitHub Dependabot シークレット管理: GitSecrets, TruffleHog, GitLeaks 動的解析: OWASP ZAP, Burp Suite CI/CD 統合と継続的セキュリティテスト LLM ツールの活用: Claude Code, Devin, Codex, Takumi セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 46

47.

48.

49.

50.

51.

成功指標とメトリクス Shift-Left 導入の効果を測定する重要指標脆弱性修正時間（MTTR）セキュリティ問題の早期発見率手動診断などで検出された本番運用中のプロダクトにおける脆弱性検出の減少率全ての工程での重大脆弱性の減少数セキュリティ対応コストの削減開発効率の向上一方で、メトリクスを取るが完璧を求めない、取得の精度は求めすぎないと言うのも頭の片隅に置いておくと良いでしょう。 → 組織における合理性の中で、可能な範囲で効果測定を行う。指標についての詳細は各フェーズでお話しします。セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 51

52.

53.

設計段階でのセキュリティ統合の重要性システム全体のセキュリティレベルを決定する重要な段階セキュリティ要件の明文化既知のセキュリティリスクの洗い出し脅威モデリングの体系的実施セキュアアーキテクチャパターンの適用包括的な設計レビュー修正コストは、設計段階で行うことで、実装段階の 1/10 になる。セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 53

54.

55.

設計段階でセキュリティの欠陥を見つける方法 - OWASP ASVS OWASP ASVS （Application Security Verification Standard）v5.0 とはアプリケーションのセキュリティ要件と検証基準の業界標準（2024 年 5 月リリース）約 350 のセキュリティ要件を 17 カテゴリで体系化 3 つのレベルで段階的なセキュリティ成熟度を定義検証観点だがこの観点を要件や設計段階から取り入れることで、セキュリティ品質を高めることができるセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 55

56.

OWASP ASVS におけるレベルと目的検証レベル（ASVS 5.0）レベル目的・対象 Level 既知の脆弱性の排除 1 Level 一般的な攻撃への耐 2 性確保 Level 高度な攻撃者への防 3 御検証方法ペンテスト（ブラックボックス）ペンテスト＋監査（グレーボックス）包括的検証（ホワイトボックス）適用例社内ツール、情報提供サイト EC サイト、SaaS サービス金融、医療、政府系システム https://github.com/owasp-ja/asvs-ja/ セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 56

https://github.com/owasp-ja/asvs-ja/

57.

ゼロトラストアーキテクチャ的実装の例現代的なセキュリティアーキテクチャの核となる概念重要な 4 つの観点: ネットワーク位置に関係なく信頼しない 2. Always Verify: すべてのリクエストを検証 3. Least Privilege: 最小権限の原則を適用 4. Assume Breach: 侵害を前提とした設計 1. Never Trust: 技術実装: マイクロセグメンテーション、適応的アクセス制御詳しい話は https://learn.microsoft.com/en-us/azure/well-architected/security/principles セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 57

https://learn.microsoft.com/en-us/azure/well-architected/security/principles

58.

59.

データ分類と保護レベル設計データ分類フレームワーク分類暗号化インターネット/通信 TLS 1.2+ Internal Confidential Restricted アクセス制御監査レベル制限なし基本ログ AES-256 従業員のみ全アクセス記録 AES-256+HSM Need-to-know 包括的監査証跡 E2E 暗号化役員承認リアルタイム監視設計への反映分類に応じたアーキテクチャコンポーネントの選択セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 59

60.

設計時の脅威モデリングと原則設計時にセキュリティリスクや脅威を洗い出すのは、一見属人性が高いように見えるが、そうではない。特定の観点をもとに確認をしていくことにより、設計段階からこれらを洗い出すことができる。 https://www.threatmodelingmanifesto.org/ セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 60

https://www.threatmodelingmanifesto.org/

61.

https://www.threatmodelingmanifesto.org/

62.

設計段階でセキュリティの欠陥を見つける方法 - 脅威モデリング異なる手法の特徴と適用場面手法適用場面強み学習コスト STRIDE 一般的な Web アプリ体系的、初心者向け低 PASTA エンタープライズビジネス影響重視高 LINDDUN プライバシー重視 GDPR 対応に最適中 OCTAVE 組織レベル運用リスク包括高推奨: STRIDE から開始し、組織の成熟度に応じて他手法を導入セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 62

63.

64.

65.

66.

セキュリティアーキテクチャレビューの実践レビューフェーズ概念設計: 脅威モデルとセキュリティ要件の整合性論理アーキテクチャ: セキュリティコンポーネントの配置物理設計: インフラストラクチャセキュリティ実装準備: 運用セキュリティの考慮や Well-Architected FW などを参考にできる限り開発の邪魔にならない程度にレビューをする。 memo: 安全性と開発者体験のトレードオフにならないように意識する / 誰のためのセキュリティか？を意識する OWASP ASVS セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 66

67.

設計フェーズまとめ - セキュリティ統合設計の重要ポイント体系的なアプローチ脅威モデリングによる客観的リスク評価セキュリティ担当者が開発チームに入り複数人でレビュー要件として明文化されたセキュリティ仕様 Design Docs などのフレームワーク利用実証されたアーキテクチャパターンの活用継続的な改善定期的な設計レビューの実施フィードバックループの確立組織のセキュリティ成熟度向上セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 67

68.

69.

70.

71.

72.

設計フェーズまとめ - セキュリティ統合設計の成功要因 1. 体系的アプローチでの明文化開発手法に適応した統合リスクベースの優先順位 Design Docs 2. 実践的な実施完璧より継続を重視インクリメンタルな改善自動化の積極活用 3. 組織的な取り組みセキュリティチャンピオン育成パターンライブラリ構築メトリクスによる改善次のステップ: 設計を基にした実装フェーズでのセキュリティ実践セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 72

73.

74.

実装フェーズのセキュリティ重要性学習目標: に対応したセキュアコーディング自動化ツール（SAST、SCA）の効果的活用依存関係のセキュリティリスク管理シークレット管理の実装 OWASP Top 10 本講義の構成: 基礎編: セキュアコーディングの原則 2. 脆弱性理解編: OWASP Top 10 の詳細解説 3. 外部認証編: OIDC/OAuth/SAML の実装 4. 品質保証編: テストと静的解析 5. 自動化編: CI/CD パイプライン統合 1. セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 74

75.

76.

セキュアコーディングの基本原則 5 つの基本原則: 最小権限の原則 - 必要最小限の権限のみ付与 2. 多層防御 - 複数のセキュリティ層を実装 3. フェイルセキュア - エラー時も安全側に倒す 4. 入力検証 - すべての入力を信頼しない 5. 出力エンコーディング - コンテキストに応じた適切な処理 1. 実装の心構え: セキュリティは後付けではなく設計段階から考慮「動けばいい」ではなく「安全に動く」を目指すチーム全体でセキュリティ意識を共有セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 76

77.

[beta]

入力検証の階層的アプローチ - 検証の 3 階層
// Layer 1: 型・形式検証
const schemaValidation = z.object({
email: z.string().email(),
age: z.number().int().min(0).max(150),
});
// Layer 2: ビジネスルール検証
const businessValidation = (data) => {
if (data.age < 18 && data.parentConsent !== true) {
throw new Error("Parent consent required");
}
};
// Layer 3: セキュリティ制約検証
const securityValidation = (data) => {
if (containsSQLKeywords(data.email)) {
throw new SecurityError("Potential injection detected");
}
};

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

77

78.

79.

（認可の不備） OWASP Top 10 - A01: Broken Access Control アクセス制御の不備による権限昇格やデータ漏洩のリスク主な脆弱性パターン: IDOR (Insecure Direct Object References) 権限昇格 CORS 設定ミスパストラバーサルセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 79

80.

81.

82.

83.

[beta]

複雑な IDOR - 階層的リソースでの攻撃
間接参照の脆弱性:
GET /org/123/project/456/doc/789

脆弱: 組織メンバーチェックのみ
セキュア: 全階層での所属確認
// 必須: 全階層での関連性検証
const doc = await db.documents.findOne({
id: docId,
projectId: projectId,
organizationId: orgId, // 全ての関連を確認
});

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

83

84.

[beta]

アクセス制御マトリックス

役割ベースのアクセス制御（RBAC）:
役割 ユーザー管理
注文管理
レポート
Admin CRUD 全て
CRUD+返金
作成・閲覧・出力
User
自分のみ閲覧・更新 自分のみ CRUD 権限なし
Guest 権限なし
公開情報のみ 権限なし
// シンプルな権限チェック
const canAccess = (role, resource, action, context) => {
const permissions = getPermissions(role, resource);
return permissions.includes(action) && checkOwnership(context);
};

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

84

85.

86.

[beta]

OWASP Top 10 - A02: Cryptographic Failures

対策

// scryptを使用した強力なハッシュ化
async hashPassword(password: string): Promise<string> {
const salt = randomBytes(32);
const hash = await scrypt(password, salt, 64, {
N: 16384, r: 8, p: 1 // CPU/Memory cost parameters
});
return Buffer.concat([salt, hash]).toString('base64');
}

重要な原則:

適切なハッシュ関数の選択（scrypt, bcrypt, Argon2）
ソルトの使用
タイミング攻撃対策

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

86

87.

88.

[beta]

OWASP Top 10 - A03: Injection

カテゴリの代表的脆弱性

// 危険な実装
const query = `SELECT * FROM users WHERE email = '${email}'`;
// セキュアな実装
const query = "SELECT id, username, email FROM users WHERE email = ?";
const result = await this.db.query(query, [email]);

対策のポイント:

パラメータ化クエリの使用
入力値検証と無害化
最小権限でのデータベースアクセス

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

88

89.

90.

A03: 高度な SQL インジェクション攻撃パターン攻撃の種類: 攻撃タイプ手法影響検出難易度 Union-based UNION 句でデータ結合データ大量窃取低 Blind SQLi Boolean/Time-based 推測データ推測・遅延中 Second-Order 遅延実行検出回避高 Stacked Queries 複数クエリ実行データ改竄・削除中対策: 全ての動的クエリでパラメータ化を徹底セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 90

91.

92.

A03: その他のインジェクション攻撃 LDAP インジェクション: 攻撃: *)(uid=*))(|(uid=* でフィルター破壊対策: ldap-escape ライブラリでエスケープ XML インジェクション (XXE): 攻撃: 外部エンティティでファイル読み取り対策: DTD 処理無効化、XML パーサー設定テンプレートインジェクション (SSTI): 攻撃: {{7*7}} でコード実行対策: プリコンパイルテンプレート使用セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 92

93.

94.

[beta]

A03: Injection

対策のベストプラクティス

レイヤー
実装
効果
入力検証 スキーマ検証・型チェック
攻撃の 90%を防御
クエリ安全化 ORM やプリペアドステートメント SQLi 完全防御
権限制限 最小権限・読取専用接続
被害を最小化
監視・検知 異常パターン検知・ログ分析
早期発見・対応
// 最小限の実装例
const secureQuery = await db
.where({ id: userId }) // 自動パラメータ化
.select(["id", "name"]) // 必要カラムのみ
.first();

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

94

95.

OWASP Top 10 - A04: Race Condition による競合状態の脆弱性並行処理における同期不備が引き起こす重大なセキュリティリスク Race Condition とは: 複数のスレッド/プロセスが同時に共有リソースにアクセス実行タイミングによって異なる結果が生じる金銭やポイントの二重引き出し・不正増殖が可能影響: 金銭的損失（二重送金、残高不正操作）データの不整合権限昇格ビジネスロジックの破壊セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 95

96.

[beta]

Race Condition

攻撃例: ポイント送金処理の脆弱性

// 危険: 並行処理で残高が不正になる
async function transferPoints(fromUserId, toUserId, amount) {
// 1. 送金元の残高確認
const sender = await getUser(fromUserId);
if (sender.points < amount) {
throw new Error("残高不足");
}
// 2. ポイント減算（この間に別のリクエストが入る可能性）
sender.points -= amount;
await updateUser(sender);
// 3. 受取側のポイント加算
const receiver = await getUser(toUserId);
receiver.points += amount;
await updateUser(receiver);
}

攻撃シナリオ: 100 ポイントしかないのに、同時に 2 つの 50 ポイント送金が成功
セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

96

97.

[beta]

Race Condition

対策: データベースレベルのトランザクション制御

async function secureTransferPoints(fromUserId, toUserId, amount) {
return await db.transaction(async (trx) => {
// 1. 行レベルロックで送金元を取得
const sender = await trx("users")
.where("id", fromUserId)
.forUpdate() // 排他ロック
.first();
if (sender.points < amount) {
throw new Error("残高不足");
}
// 2. アトミックな更新
await trx("users").where("id", fromUserId).decrement("points", amount);
await trx("users").where("id", toUserId).increment("points", amount);
// 3. 監査ログ
await trx("transaction_logs").insert({
from_user: fromUserId,
to_user: toUserId,
amount,
timestamp: Date.now(),
});
});
}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

97

98.

[beta]

Race Condition

対策: 楽観的ロック（Optimistic Locking）

interface User {
id: string;
points: number;
version: number; // バージョンカラム
}
async function optimisticTransfer(fromUserId: string, amount: number) {
const MAX_RETRIES = 3;
let retries = 0;
while (retries < MAX_RETRIES) {
const user = await getUser(fromUserId);
if (user.points < amount) {
throw new Error("残高不足");
}
// バージョン番号を条件に更新
const result = await db.query(
`UPDATE users SET points = points - ?, version = version + 1
WHERE id = ? AND version = ?`,
[amount, fromUserId, user.version]
);
if (result.affectedRows === 1) {
return; // 成功
}
retries++;
await sleep(Math.random() * 100); // ランダム待機
}
throw new Error("競合が解決できません");
}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

98

99.

[beta]

Race Condition

対策: 分散ロック（Redis 使用）

const Redis = require("ioredis");
const Redlock = require("redlock");
class SecureWallet {
constructor() {
this.redis = new Redis();
this.redlock = new Redlock([this.redis], {
retryDelay: 200,
retryCount: 3,
});
}
async transferWithDistributedLock(fromUserId, toUserId, amount) {
const lockKey = `lock:transfer:${fromUserId}`;
const ttl = 10000; // 10秒のTTL
// 分散ロックの取得
const lock = await this.redlock.acquire([lockKey], ttl);

}

}

try {
// ロック取得後に安全に処理
await this.performTransfer(fromUserId, toUserId, amount);
} finally {
// 必ずロックを解放
await lock.release();
}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

99

100.

[beta]

Race Condition

テストの実装 - 並行実行による脆弱性検証

describe("Race Condition Security Tests", () => {
it("should prevent double spending with concurrent requests", async () => {
const userId = "user123";
await setUserPoints(userId, 100); // 初期残高100
// 50ポイントの送金を10回同時実行
const promises = Array(10)
.fill(null)
.map(() => transferPoints(userId, "recipient", 50));
const results = await Promise.allSettled(promises);
// 成功は2回まで（100÷50=2）
const successful = results.filter((r) => r.status === "fulfilled");
expect(successful.length).toBeLessThanOrEqual(2);
// 最終残高は0以上
const finalBalance = await getUserPoints(userId);
expect(finalBalance).toBeGreaterThanOrEqual(0);
});

});

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

100

101.

Race Condition 防御のベストプラクティスパフォーマンス対策手法実装方法適用場面影響 DB トランザクシ BEGIN/COMMIT/ROLLBACK RDBMS 環境中ョン悲観的ロック SELECT FOR UPDATE 高競合環境高楽観的ロックバージョンカラム低競合環境低マイクロサービ分散ロック Redis/Zookeeper 中スイベントソーシンイベント順序保証監査要件あり低グセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 101

102.

103.

（型混乱）脆弱性 Type Confusion 動的な型変換や不適切な型検証による深刻なセキュリティリスク Type Confusion とは: 期待される型と異なる型のデータを処理させる攻撃 JSON パースやインターフェース型変換での脆弱性権限昇格やビジネスロジックの破壊が可能主な攻撃パターン: 数値/文字列の混乱（"0" vs 0）配列/オブジェクトの混乱 null/undefined/空文字の処理インターフェース型アサーションの悪用 JSON セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 103

104.

[beta]

Type Confusion

攻撃例: Go の API 実装

脆弱な実装 - 動的な構造体フィールド:

// 危険: interface{}を使用した動的な型処理
type UserRequest struct {
ID
interface{} `json:"id"`
// 型が不定
IsAdmin interface{} `json:"isAdmin"` // bool想定だが...
Discount interface{} `json:"discount"`
}
func processUser(req UserRequest) {
// 型アサーションが失敗する可能性
userID := req.ID.(string) // パニックの可能性
// 危険な型変換
if req.IsAdmin == "true" || req.IsAdmin == true || req.IsAdmin == 1 {
grantAdminAccess() // 意図しない権限昇格
}
// 数値の型混乱
discount := req.Discount.(float64) // "100"が来たらパニック
}

攻撃ペイロード: {"id": ["admin"], "isAdmin": 1, "discount": "100"}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

104

105.

[beta]

Type Confusion

対策: 厳密な型定義とバリデーション

type SecureUserRequest struct {
ID
string `json:"id" binding:"required,uuid"`
IsAdmin bool
`json:"isAdmin"`
Discount float64 `json:"discount" binding:"min=0,max=100"`
}
// カスタムUnmarshalJSON実装で型を強制
func (s *SecureUserRequest) UnmarshalJSON(data []byte) error {
type Alias SecureUserRequest
aux := &struct {
ID
json.RawMessage `json:"id"`
IsAdmin json.RawMessage `json:"isAdmin"`
Discount json.RawMessage `json:"discount"`
*Alias
}{
Alias: (*Alias)(s),
}
if err := json.Unmarshal(data, &aux); err != nil {
return err
}
// 厳密な型チェック
var id string
if err := json.Unmarshal(aux.ID, &id); err != nil {
return fmt.Errorf("id must be string: %w", err)
}
s.ID = id
return nil
}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

105

106.

[beta]

Type Confusion:

脆弱なパターン:

配列とオブジェクトの混乱

// 危険: 単一値と配列の両方を受け入れる
type FlexibleRequest struct {
UserIDs interface{} `json:"user_ids"` // string or []string
}
func processUsers(req FlexibleRequest) {
// 型によって処理が変わる - 危険！
switch v := req.UserIDs.(type) {
case string:
processUser(v)
case []interface{}:
for _, id := range v {
processUser(id.(string)) // パニックの可能性
}
}
}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

106

107.

[beta]

Type Confusion:

セキュアな実装:

配列とオブジェクトの混乱

type StrictRequest struct {
UserIDs []string `json:"user_ids" binding:"required,dive,uuid"`
}
// 単一値も配列として処理
func (s *StrictRequest) UnmarshalJSON(data []byte) error {
var single string
if err := json.Unmarshal(data, &single); err == nil {
s.UserIDs = []string{single}
return nil
}
var array []string
if err := json.Unmarshal(data, &array); err != nil {
return fmt.Errorf("user_ids must be string or []string")
}
s.UserIDs = array
return nil
}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

107

108.

Type Confusion: 数値型の混乱による金額操作価格計算での型混乱攻撃: // 脆弱: interface{}での金額処理 type PaymentRequest struct { Amount interface{} `json:"amount"` Quantity interface{} `json:"quantity"` } func calculateTotal(req PaymentRequest) float64 { // 文字列 "0.01" × 文字列 "1000" = ??? amount := toFloat64(req.Amount) // 型変換の実装次第 quantity := toFloat64(req.Quantity) } // 攻撃例: amount="0.01e3" (指数表記) = 10 // 攻撃例: amount=999999999999999999999 (オーバーフロー) return amount * quantity セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 108

109.

[beta]

Type Confusion:

数値型の混乱による金額操作

セキュアな実装:
type SecurePaymentRequest struct {
Amount
int64 `json:"amount" binding:"required,min=1,max=1000000"`
Quantity int32 `json:"quantity" binding:"required,min=1,max=100"`
}

// 円単位

func calculateSecureTotal(req SecurePaymentRequest) int64 {
// オーバーフローチェック
if req.Amount > math.MaxInt64/int64(req.Quantity) {
panic("integer overflow detected")
}
return req.Amount * int64(req.Quantity)
}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

109

110.

[beta]

Type Confusion

テストの実装 - 型混乱攻撃のテストケース

func TestTypeConfusionVulnerabilities(t *testing.T) {
tests := []struct {
name
string
payload string
expect string
}{
{
name:
"String as Number",
payload: `{"id": "123", "amount": "999999"}`,
expect: "type_error",
},
{
name:
"Array as String",
payload: `{"id": ["admin", "user"], "role": "admin"}`,
expect: "type_error",
},
{
name:
"Boolean as Number",
payload: `{"isAdmin": 1, "verified": "true"}`,
expect: "type_error",
},
{
name:
"Exponential Notation",
payload: `{"amount": "1e10", "price": 1.0e308}`,
expect: "validation_error",
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
err := processRequest([]byte(tt.payload))
assert.Error(t, err)
assert.Contains(t, err.Error(), tt.expect)
})
}
}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

110

111.

Type Confusion 防御のベストプラクティス実装ガイドライン: 対策実装方法効果厳密な型定義 interface{}を避ける型安全性確保カスタム Unmarshal 独自の検証ロジック完全な制御バリデーションタグ binding/validate タグ自動検証数値範囲チェック min/max 制約オーバーフロー防止ホワイトリスト検証許可値のみ受入想定外入力排除セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 111

112.

113.

114.

115.

SAML 2.0 の役割と特徴側面内容用途エンタープライズ SSO、B2B 連携プロトコル XML 署名による認証アサーション主な利用者企業、政府機関、金融機関利点: 成熟した標準（2005 年〜） / 豊富なエンタープライズ機能 / 詳細な属性マッピング / フェデレーション対応セキュリティ課題: XML 署名の複雑性による実装ミス / 署名ラッピング攻撃 / アサーション再生攻撃 / メタデータの改ざんセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 115

116.

OAuth 2.0 の役割と特徴側面内容用途 API 認可、リソースアクセス委譲プロトコルトークンベースの認可主な利用者モバイルアプリ、Web API、SaaS の利用者利点: シンプルな実装/ 細かい権限制御（スコープ）/ RESTful API との親和性/ モバイル対応セキュリティ課題: 認証ではなく認可のみ / トークン漏洩リスク / リダイレクト URI の検証不備 / PKCE 未実装による攻撃セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 116

117.

OpenID Connect (OIDC) - 現代的な認証レイヤー側面内容用途認証 + 認可、モダン SSO プロトコル JWT 形式の ID トークン主な利用者モダン SaaS、クラウドサービス利点: OAuth 2.0 の上に構築された標準化 / JSON ベースでシンプル / モバイル・SPA フレンドリー /豊富なクレーム情報セキュリティ課題: 脆弱性（メールクレームの誤用）/ ID トークンの不適切な検証/ nonce パラメータの欠如/ Discovery の改ざん nOAuth Endpoint セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 117

118.

外部 ID 連携の比較マトリックス要件 SAML 2.0 OAuth 2.0 OIDC エンタープライズ SSO ◎ 最適 △ 不適 ○ 可能 API 認可 △ 不適 ◎ 最適 ◎ 最適モバイルアプリ × 困難 ○ 可能 ◎ 最適実装の容易さ × 複雑 ○ 中程度 ○ 中程度技術的安定性 ◎ 高い ○ 中程度 ○ 中程度属性情報の豊富さ ◎ 詳細 △ 限定的 ○ 柔軟セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 118

119.

[beta]

\
SaaS

における外部 ID 実装のベストプラクティス

class SecureIdentityProvider {
async validateExternalAuth(protocol: "SAML" | "OIDC", token: any) {
// 1. プロトコル固有の検証
if (protocol === "OIDC") {
await this.verifyJWT(token);
await this.validateNonce(token.nonce);
await this.checkEmailVerified(token);
} else if (protocol === "SAML") {
await this.verifyXMLSignature(token);
await this.validateNotBefore(token);
await this.checkAudienceRestriction(token);
}
// 2. 共通のセキュリティチェック
await this.preventReplayAttack(token);
await this.validateIssuer(token);
await this.enforceExpirationTime(token);

}

}

// 3. アカウントリンキング
return this.secureAccountLinking(token);

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

119

120.

121.

Pre-Account Hijack Pre-Account Hijack とは攻撃の概要被害者がアカウントを作成する前に攻撃者が準備を行うアカウント作成後、攻撃者が簡単にアクセス可能な状態を作るメールアドレスのみで攻撃可能（パスワード不要）研究結果（USENIX Security 2022）の人気サービスを調査 35 以上のサービスが脆弱一部は完全に検出不可能な攻撃 75 影響アカウント完全乗っ取り/ 個人情報の窃取/ 金銭的被害セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 121

122.

https://www.usenix.org/conference/usenixsecurity22/presentation/sudhodanan

123.

124.

125.

126.

nOAuth 脆弱性の理解と対策 Microsoft EntraID OAuth nOAuth 攻撃シナリオ実装における認証迂回の問題攻撃者が EntraID でアカウントのメールアドレスを被害者のメールアドレスと同じものに変更アプリケーションがメールアドレスを一意の識別子として使用している場合、アカウント乗っ取りが発生メールクレームは変更可能（mutable）で未検証（unverified）という特性を悪用セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 126

127.

nOAuth 脆弱性の対策実装 - 脆弱な例 // 脆弱: メールアドレスで認証（nOAuth脆弱性） async handleOAuthCallback(idToken: any) { const email = idToken.email; // 変更可能で未検証 const user = await findUserByEmail(email); if (user) { return createSession(user); // アカウント乗っ取りリスク } } セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 127

128.

[beta]

nOAuth

脆弱性の対策実装 - 対策例

// セキュア: subクレームで認証 + メール検証
async handleOAuthCallback(idToken: any) {
const sub = idToken.sub; // 不変の一意識別子
const email = idToken.email;
const emailVerified = idToken.email_verified;
if (!emailVerified) {
throw new Error("Email not verified");
}
const user = await findUserBySub(sub);
return createSession(user);
}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

128

129.

130.

131.

高度な認証脆弱性の検出課題 - 従来のセキュリティツールの限界脆弱性タイプ課題 OWASP Top 10 パターンベースで検出可能 Pre-Account Hijack ビジネスロジックに依存 nOAuth 脆弱性認証フロー全体の理解が必要 SAML 実装の欠陥複雑な XML 処理の検証困難なぜ検出が困難なのか: コンテキスト依存: アプリケーション固有のロジック理解が必要時系列的な攻撃: 複数ステップにまたがる攻撃シナリオ設定と実装の組み合わせ: コードだけでなく設定も含めた評価が必要セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 131

132.

133.

LLM を活用した高度な脆弱性検出 - 認証フロー分析のアプローチ Prompt を用意し、検出をさせる以下の認証実装を分析し、高度な脆弱性を検出してください： 1. Pre-Account Hijack攻撃の可能性 - メール未検証でのアカウント作成 - フェデレーション認証の誤用 - セッション固定攻撃 2. nOAuth脆弱性 - emailクレームによる認証 - email_verifiedの未確認 - mutableな属性への依存 3. SAML実装の問題 - 署名検証の不備 - Assertion再利用攻撃 - XML署名ラッピングセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 133

134.

Claude Code を活用したセキュリティレビュー実装例 # Claude Codeを使用した認証実装の高度なセキュリティレビューの模擬 $ claude-code Claude> 以下の認証実装をレビューして、Pre-Account Hijack、nOAuth、 SAML関連の脆弱性を特定してください。特に注目すべき点: 1. メールアドレスの検証プロセス 2. フェデレーション認証の実装 3. セッション管理 4. アカウントリンキングのロジックコードベース: ./src/auth/ Claude> 認証実装を分析しました。以下の潜在的な脆弱性を発見しました： Critical: Pre-Account Hijack脆弱性 - /src/auth/signup.ts:45 - メール未検証でのOAuth連携が可能 - 攻撃者が被害者のメールで事前にOAuthアカウントを作成可能 High: nOAuth脆弱性 - /src/auth/oauth-handler.ts:78 - emailクレームで認証している - email_verifiedフラグの確認が欠如修正案を生成しますか？ [Y/n] セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 134

135.

[beta]

Claude Code

による自動修正提案の例

// Claude Codeが提案する修正実装
async handleOAuthCallback(idToken: any) {
// 脆弱: emailで認証
// const user = await findUserByEmail(idToken.email);
// セキュア: subクレームとemail検証
if (!idToken.email_verified) {
throw new UnverifiedEmailError();
}
const user = await findUserByProviderSub(
idToken.iss, // Identity Provider
idToken.sub
// 不変の識別子
);

}

// アカウントリンキングの安全な実装
if (!user && idToken.email_verified) {
await this.secureAccountLinking(idToken);
}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

135

136.

脆弱性発見の解析と改善行動既知の脆弱パターンとビジネスロジック/コンテキストを有する実装の脆弱性検出実装推奨事項: 基礎層: SAST/DAST で OWASP Top 10 をカバー 2. 高度層: LLM で複雑な認証・認可フローを分析 3. 継続的改善: 検出結果をフィードバックしてモデルを改善 1. セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 136

137.

138.

OWASP ASVS による検証基準 Application Security Verification Standard v5.0 レベル別セキュリティ要件: の活用低保証レベル（基本的な脆弱性の排除） Level 2: 標準的なセキュリティ保証（一般的な攻撃への耐性） Level 3: 高度なセキュリティ保証（高度な攻撃者への耐性） Level 1: 重要な検証領域: 認証 V3: セッション管理 V4: アクセス制御 V5: 検証、サニタイズ、エンコーディング V2: セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 138

139.

[beta]

包括的入力検証フレームワーク - TypeScript における Zod の例
全ての入力に対する体系的検証
const userSchema = z.object({
username: z
.string()
.min(3)
.max(20)
.regex(/^[a-zA-Z0-9_]+$/),
email: z.string().email().max(100),
password: z
.string()
.min(12)
.regex(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&])/),
});

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

139

140.

141.

[beta]

単体テストにおけるセキュリティ検証
describe("Authentication Security Tests", () => {
it("should reject SQL injection attempts", async () => {
const maliciousInput = "user_input_test' OR '1'='1";
await expect(authService.login(maliciousInput, "pass")).rejects.toThrow(
"Invalid credentials"
);
});
it("should enforce rate limiting", async () => {
for (let i = 0; i < 6; i++) {
await authService.login("user", "wrong");
}
await expect(authService.login("user", "pass")).rejects.toThrow(
"Too many attempts"
);
});
});

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

141

142.

143.

144.

145.

146.

147.

静的解析ツール（SAST）の活用既知の脆弱な実装を動的な検査に先んじて検出して修正をするために SAST を用いる。ツールタイプ強みコスト SonarQube OSS/商用包括的分析 CE 無料 Semgrep OSS/商用高速・低偽陽性 OSS 無料 CodeQL 商用高精度検出 Public repo 無料 Checkmarx 商用エンタープライズ要見積導入戦略: 無料版から開始して、手動による脆弱性の把握や CI/CD 統合による自動化を行う。セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 147

148.

品質ゲートの実装と管理品質ゲート条件の設定: 品質ゲートは以下の条件で自動的にデプロイメントを制御します：セキュリティホットスポット許容閾値: ゼロ（1 件でも検出されれば不可）対応: デプロイメントを即座にブロック理由: 潜在的な脆弱性を本番環境に持ち込まないクリティカル脆弱性許容閾値: ゼロ（完全排除が必須）対応: デプロイメントを即座にブロック理由: 重大なセキュリティリスクの完全除去セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 148

149.

品質ゲートの実装と管理コードカバレッジ必要閾値: 80%以上対応: 閾値未満の場合は警告を表示理由: テスト不足による品質リスクの可視化 OWASP ASVS 準拠レベル必要レベル: レベル 2 以上対応: 未達成の場合はレビュー必須理由: 標準的なセキュリティ保証レベルの維持段階的な品質向上: 基本的なセキュリティチェック Phase 2: ASVS Level 1 準拠（基本的な脆弱性の排除） Phase 3: ASVS Level 2 以上の達成（標準的な保証レベル） Phase 1: セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 149

150.

151.

品質ゲートの運用指針 Phase 1: 警告のみ Phase 2: 開発環境 Phase 3: ステージング Phase 4: 本番環境 ⚠ 🚧 🔒 🛡 学習期間試験導⼊本格運⽤準備完全適⽤期間: 2-4週間期間: 4-6週間問題を検出してログ記録開発者への通知のみ • ビルドは継続 • 誤検知の調整期間開発ブランチでブロックパイプラインで強制 • 例外処理プロセス確⽴ • チーム内フィードバック期間: 2-4週間リリース候補でブロック本番相当の検証 • 緊急対応⼿順の確⽴ • パフォーマンス影響測定継続的運⽤本番デプロイでブロックゼロトレランス適⽤ • ⾃動修正の導⼊ • 継続的改善サイクル • • • • • • CI • • 例外処理プロセス: リスク評価と文書化期限付き例外承認代替対策の実装セキュリティ・キャンプ全国大会 2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 151

152.

153.

依存関係セキュリティ管理(Software Composition Analysis) 深刻度対応期限アクション Critical 1 日即座修正 High 7日次スプリント修正 Medium 30 日便利な時修正 Low 90 日文書化して受容自動化の実装: パッチレベル更新の自動適用脆弱性スキャンの継続実行 SBOM（Software Bill of Materials）生成セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 153

154.

シークレット管理の実装 - git-secret と trufflehog 1 機密情報の漏洩防止と検出システムの構築 1. git-secret による暗号化管理: # git-secretの初期化とユーザー追加 git secret init git secret tell [email protected] # GPG鍵を持つユーザーを追加 # 機密ファイルの管理 git secret add .env git secret add config/database.yml git secret hide # ファイルを暗号化 # チーム開発での運用 git secret reveal # 復号化（GPG鍵が必要） git secret whoknows # アクセス権限を持つユーザー一覧セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 154

155.

シークレット管理の実装 - git-secret と trufflehog - 2 2. trufflehog によるシークレット検出: # リポジトリ全体のスキャン trufflehog filesystem . --json --no-update # Git履歴を含めたスキャン（過去のコミットも検査） trufflehog git file://. --since-commit HEAD~100 # CI/CDパイプラインでの自動検出 trufflehog github --org=myorg --repo=myrepo セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 155

156.

[beta]

シークレット検出パターンと設定 - trufflehog の検出パターン例
# .trufflehog.yml - カスタム検出ルール
detectors:
- name: custom_api_key
regex:
pattern: 'api[_-]?key["\s]*[:=]["\s]*([a-zA-Z0-9]{32,})'
keywords:
- api_key
- apikey
- name: database_connection
regex:
pattern: "postgres://([^:]+):([^@]+)@"
keywords:
- postgres
- mysql
- mongodb
exclude_paths:
- node_modules/
- vendor/
- "*.min.js"
- test/fixtures/

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

156

157.

158.

Pre-commit フックによる漏洩防止 - 自動検出による事前防止策 # .pre-commit-config.yaml repos: - repo: https://github.com/trufflesecurity/trufflehog rev: v3.63.0 hooks: - id: trufflehog name: TruffleHog Secret Scanner entry: trufflehog filesystem . args: ["--no-update", "--fail"] - repo: https://github.com/Yelp/detect-secrets rev: v1.4.0 hooks: - id: detect-secrets args: ["--baseline", ".secrets.baseline"] セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 158

159.

Pre-commit フックによる漏洩防止 - 自動検出による事前防止策 # pre-commitのセットアップ pip install pre-commit pre-commit install # ベースラインの作成（既存の誤検知を記録） detect-secrets scan > .secrets.baseline detect-secrets audit .secrets.baseline セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 159

160.

シークレット漏洩時の対応手順インシデント対応プロトコル: 即座の無効化 2. 影響範囲の特定 3. 新しいクレデンシャルの生成 4. 監査ログとアラート 5. Git 履歴のクリーニング（必要に応じて） 1. 対応優先度: 即座): AWS/GCP 認証情報、本番 DB 接続文字列 High (1 時間以内): API キー、OAuth トークン Medium (24 時間以内): 開発環境の認証情報 Critical ( セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 160

161.

シークレット管理のベストプラクティス組織的な管理体制: 対策レベル実装内容効果予防 git-secret による暗号化平文保存を防止検出 trufflehog の定期スキャン早期発見ブロック pre-commit フックコミット前に阻止監視 CI/CD での継続的スキャン継続的な保護対応インシデント対応手順迅速な無効化セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 161

162.

シークレット管理のベストプラクティスシークレットローテーション戦略: # シークレットの定期更新ポリシーローテーション方針: APIキー: 更新頻度: 90日自動化: 有効通知: 7日前にアラートデータベースパスワード: 更新頻度: 180日承認要否: 必要実行時間帯: メンテナンスウィンドウ内 JWT署名鍵: 更新頻度: 365日並行稼働期間: 7日 # 新旧キーの同時有効化切替方式: グレースフル切替セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 162

163.

CI/CD でのセキュリティ統合 # .github/workflows/security.yml name: Security Pipeline on: [push, pull_request] jobs: secret-scanning: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 with: fetch-depth: 0 # 全履歴を取得 - name: TruffleHog OSS uses: trufflesecurity/trufflehog@main with: path: ./ base: ${{ github.event.repository.default_branch }} - name: Git-secret check run: | git secret whoknows # アクセス権限の確認 git secret reveal --force # CI環境での復号化 - name: SAST Scan run: semgrep --config=auto --error - name: Dependency Check run: | npm audit --audit-level=high trivy fs --security-checks vuln . セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 163

164.

コードレビューでのセキュリティ観点効果的なセキュリティレビューの実践レビューチェックリスト: 認証・認可: 認証チェックの実装確認、権限検証の適切性入力・出力処理: 入力検証の実装、出力エンコーディングの適用機密情報管理: ハードコード化の回避、ログ出力での機密情報マスクセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 164

165.

実装フェーズまとめセキュアな実装の重要ポイント体系的アプローチ: を基軸とした対策実装自動化ツールによる継続的品質向上包括的な依存関係・シークレット管理 OWASP Top 10 持続可能性の確保: パイプラインへの統合チーム全体でのセキュリティ意識共有 CI/CD 次のステップ: CI/CD パイプライン内での本格的なセキュリティ統合セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 165

166.

167.

CI/CD セキュリティの重要性パイプライン全体にセキュリティを統合した自動化システム学習目標: セキュリティを組み込んだ CI/CD パイプライン設計 SAST、DAST、コンテナスキャンの統合セキュリティ基準に基づいた品質ゲート実装 4 つの段階: コードセキュリティ: 静的解析、シークレット検出 2. ビルドセキュリティ: 依存関係・コンテナスキャン 3. テストセキュリティ: 動的解析、ペネトレーションテスト 4. デプロイセキュリティ: インフラ検証、運用時保護 1. セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 167

168.

169.

170.

SLSA とは何かソフトウェアサプライチェーンの完全性を保証するセキュリティフレームワーク SLSA の目的: 改ざん防止: ビルドプロセス全体での不正な変更を防止完全性の向上: ソフトウェアアーティファクトの信頼性確保パッケージとインフラの保護: エンドツーエンドのセキュリティ主要な構成要素: （ソース）: コードの起源と完全性 2. Build（ビルド）: 再現可能で検証可能なビルドプロセス 3. Provenance（来歴）: ビルドの詳細な証跡 4. Verification（検証）: アーティファクトの真正性確認 1. Source セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 170

171.

SLSA が解決する脅威サプライチェーン攻撃の実例と対策実際の攻撃事例: インシデント例手法 SLSA での対策 SolarWinds ビルドシステム侵害 L3: ビルド環境の隔離 Codecov CI/CD への不正アクセス L2: 署名付き来歴 npm event-stream 依存関係への悪意コード注入 L1: 来歴の追跡 XcodeGhost 開発ツールの改ざん L3: 検証可能なビルドセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 171

172.

SLSA レベルの概要段階的なセキュリティ成熟度モデルレベ名称主要要件保護対象ル L0 No Guarantees なし保護なし L1 Provenance Exists 来歴の生成・配布プロセスミス Hosted Build 専用インフラ・署名付き来 L2 ビルド後の改ざん Platform 歴ビルド中の改ざん・内部脅 L3 Hardened Builds ビルド隔離・秘密鍵保護威セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 172

173.

174.

175.

SLSA Build L0: 保証なし - 2 典型的な使用例: # 開発者のローカル環境でのビルド npm run build docker build -t myapp:dev . # 手動デプロイ scp dist/* user@server:/var/www/ リスク: 完全に信頼できない、監査証跡なしセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 175

176.

177.

SLSA Build L1: 来歴の存在 - 2 実装アーキテクチャ: # 隔離されたビルド環境の例 build-isolation: runner: type: ephemeral # 使い捨てランナー isolation: container network: restricted secrets: type: hardware-security-module rotation: automatic attestation: type: in-toto storage: immutable-ledger セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 177

178.

[beta]

来歴（Provenance）の構造 - in-toto 形式の例
https://github.com/in-toto/attestation
{

"_type": "https://in-toto.io/Statement/v0.1",
"subject": [
{
"name": "my-app",
"digest": { "sha256": "abc123..." }
}
],
"predicateType": "https://slsa.dev/provenance/v0.2",
"predicate": {
"builder": {
"id": "https://github.com/owner/repo/.github/workflows/build.yml"
},
"buildType": "https://github.com/slsa-framework/slsa-github-generator",
"invocation": {
"configSource": {
"uri": "git+https://github.com/owner/repo@refs/heads/main",
"digest": { "sha1": "def456..." }
}
},
"materials": [
{
"uri": "git+https://github.com/owner/repo",
"digest": { "sha1": "def456..." }
}
]
}

セキュリティ・キャンプ全国大会
2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025
}

178

https://github.com/in-toto/attestation

179.

SLSA Build L1: 来歴の存在 - 3 実装例（GitHub Actions）: name: Build with SLSA L1 on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Build run: make build - name: Generate Provenance uses: slsa-framework/[email protected] with: subject-name: ${{ github.event.repository.name }} subject-digest: ${{ steps.build.outputs.digest }} セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 179

180.

181.

SLSA Build L2: GitHub Actions ホスト型ビルドプラットフォーム - 1 での実装: jobs: slsa-build: permissions: id-token: write # OIDC トークン生成に必要 contents: read attestations: write steps: - name: Build and Generate SLSA Provenance uses: slsa-framework/[email protected] with: # 署名付き来歴を自動生成 upload-assets: true メリット: ビルド後の改ざん検出、コンプライアンス対応セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 181

182.

183.

184.

185.

SLSA 検証の実装 - アーティファクトの信頼性確認 cosign による検証例: https://github.com/sigstore/cosign # 1. 署名付きアーティファクトのダウンロード curl -LO https://github.com/org/repo/releases/app.tar.gz curl -LO https://github.com/org/repo/releases/app.tar.gz.sig # 2. SLSA 来歴の検証 cosign verify-attestation \ --type slsaprovenance \ --certificate-identity https://github.com/org/repo/.github/workflows/release.yml@refs/tags/v1.0.0 \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ app.tar.gz # 3. 来歴内容の確認 cosign verify-attestation app.tar.gz | jq '.payload' | base64 -d | jq '.predicate' # 4. ポリシーベースの検証 opa eval -d slsa-policy.rego -i provenance.json "data.slsa.allow" セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 185

https://github.com/sigstore/cosign

186.

SLSA と他のフレームワークの統合 - 1 包括的なセキュリティエコシステム統合マップ: フレームワーク統合ポイント相乗効果 SBOM (SPDX/CycloneDX) 依存関係の透明性完全なサプライチェーン可視化 Sigstore 署名・検証インフラキーレス署名の実現 OpenSSF Scorecard プロジェクト評価リスクベースの信頼性判断 in-toto エンドツーエンド検証包括的な改ざん防止セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 186

187.

SLSA と他のフレームワークの統合 - 2 実装例: - name: Generate SBOM and SLSA run: | syft . -o spdx-json > sbom.spdx.json slsa-provenance generate --artifact app.tar.gz --sbom sbom.spdx.json セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 187

188.

SLSA 採用の ROI - 1 投資対効果の定量化コスト削減効果の例: 項目 L1 L2 L3 実装コスト 10 万円 100 万円 500 万円インシデント削減率 20% 50% 80% 平均被害額/件 5000 万円 5000 万円 5000 万円年間期待削減額 1000 万円 2500 万円 4000 万円 ROI 100 倍 25 倍 8倍セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 188

189.

190.

191.

192.

193.

ブランチ保護ルールの設定の Branch Protection Rules による強制的なセキュリティ統制基本的な保護設定: GitHub # .github/branch-protection.yml (設定例) protection_rules: - name: main # PRレビュー必須化 required_reviews: required_approving_review_count: 2 dismiss_stale_reviews: true require_code_owner_reviews: true # ステータスチェック必須化 required_status_checks: strict: true # ブランチを最新に保つ contexts: - "security/sast" - "security/secrets" - "test/unit" セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 193

194.

ブランチ保護ルールの詳細設定高度な保護機能: 設定項目目的推奨値 Require a pull request 直接 push を防止必須コードレビュー強制 2 人以上 Require approvals コード変更時の再レビュー有効 Dismiss stale reviews 有効 Require review from CODEOWNERS 重要コードの保護 Require status checks CI/CD の成功を必須化有効 Include administrators 管理者も例外なし有効コミット署名の強制有効 Require signed commits マージコミット禁止プロジェクト次第 Require linear history セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 194

195.

CODEOWNERS による自動レビュアー割当重要なコードへの変更を適切なチームが必ずレビュー CODEOWNERS ファイル例: # .github/CODEOWNERS # デフォルトオーナー * @security-team # セキュリティ関連ファイル /security/ @security-team @lead-developer /.github/workflows/security-*.yml @security-team @devops-team # 認証・認可 /src/auth/ @identity-team @security-team /src/middleware/auth* @identity-team # データベース・機密情報 /migrations/ @database-team @security-team /config/database.yml @database-team @security-team *.env* @security-team セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 195

196.

コミット署名（GPG/SSH）の実装コミットの真正性を暗号学的に保証 GPG 署名の設定: # GPGキーの生成 gpg --full-generate-key # GitにGPGキーを設定 git config --global user.signingkey <KEY_ID> git config --global commit.gpgsign true # 署名付きコミット git commit -S -m "feat: セキュアな機能追加" SSH 署名の設定（GitHub 推奨）: # SSH署名を有効化 git config --global gpg.format ssh git config --global user.signingkey ~/.ssh/id_ed25519.pub # 署名の検証 git log --show-signature セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 196

197.

[beta]

署名コミットの強制と Verified 表示
での署名検証と Vigilant mode
組織レベルでの強制:
GitHub

1. Organization Settings → Code security and analysis

を有効化
3. Vigilant mode で未署名を警告表示
2. Require commit signing

署名状態の確認:

# ローカルでの署名確認
git verify-commit HEAD
# CI/CDでの自動検証
- name: Verify Commit Signatures
run: |
git log --format='%H %G?' -n 10 | while read commit status; do
if [ "$status" != "G" ]; then
echo "Error: Unsigned commit $commit"
exit 1
fi
done

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

197

198.

[beta]

GitHub Actions
CI/CD

での保護ルール実装

レベルでのセキュリティチェック自動化

name: Branch Protection Enforcement
on:
pull_request:
branches: [main, develop]
jobs:
security-checks:
runs-on: ubuntu-latest
steps:
- name: Check Commit Signatures
run: |
# 全コミットの署名確認
for commit in $(git rev-list ${{ github.event.pull_request.base.sha }}..${{ github.event.pull_request.head.sha }}); do
if ! git verify-commit $commit 2>/dev/null; then
echo "::error::Unsigned commit detected: $commit"
exit 1
fi
done
- name: Enforce Security Scan
run: |
# SAST/シークレットスキャンの実行
npm audit --audit-level=moderate
trufflehog git file://. --only-verified

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

198

199.

プルリクエストテンプレートによる品質確保セキュリティレビューの標準化 .github/pull_request_template.md: ## 変更内容  ## セキュリティチェックリスト - [ ] 機密情報が含まれていないことを確認 [ ] 入力検証が適切に実装されている [ ] 認証・認可が正しく実装されている [ ] セキュリティテストが追加/更新されている [ ] 依存関係に脆弱性がないことを確認 [ ] OWASP Top 10 を考慮した実装 ## セキュリティ影響 - [ ] この変更にセキュリティ上の影響はない [ ] セキュリティレビューが必要（@security-team） ## テスト - [ ] ユニットテスト追加/更新 [ ] セキュリティテスト実施セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 199

200.

マージ戦略とセキュリティ安全なマージ方法の選択推奨マージ戦略: 戦略メリットセキュリティ観点履歴がクリーン機密情報の誤混入を防ぐ Squash and merge 線形履歴変更の追跡が容易 Rebase and merge Create a merge commit 完全な履歴保持監査証跡として有効設定例（GitHub API）: gh api repos/:owner/:repo --method PATCH \ --field allow_squash_merge=true \ --field allow_merge_commit=false \ --field allow_rebase_merge=true \ --field delete_branch_on_merge=true セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 200

201.

GitHub Ruleset { } の新機能：より柔軟で強力な保護ルール設定例: "name": "Security Ruleset", "target": "branch", "enforcement": "active", "conditions": { "ref_name": { "include": ["refs/heads/main", "refs/heads/release/*"], "exclude": [] } }, "rules": [ { "type": "required_signatures" }, { "type": "required_status_checks", "parameters": { "required_status_checks": [ { "context": "security-scan" }, { "context": "code-review" } ] } } ] セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 201

202.

203.

204.

205.

インフラのコード化 - Infrastructure as Code クラウド化が進む中でインフラを何かしらの言語で記述し、管理する IaC というものが出てきました。IaC の登場で、インフラの管理や再利用性が高ま流ようになったのは事実です。このような中で、IaC の登場でもう一つの利点が出てきました。それがコードベースで設定値を確認することができるというものです。セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 205

206.

207.

208.

209.

セキュリティテスト自動化 - 包括的テスト戦略の実装テストタイプツール対象認証・認可ロジックソースコード実行タイミング Unit Security Jest + Custom コミット時 SAST Semgrep などコミット時/ビルド時 API Security Postman/Newman REST/GraphQL API ビルド時 DAST OWASP ZAP バックエンドビルド時 / デプロイ前 E2E Security Playwright フロントエンドデプロイ前 LLM を用いた CodeReview Claude Code / A などソースコードデプロイ前 Load + Security K6 + Extensions 負荷テストとセキュリティ週次セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 209

210.

セキュリティメトリクスの収集セキュリティに関してもメトリクスを取得して、改善や根本的なボトルネック、発生箇所、組織課題などの改善に活かすことが重要です。取得すべきメトリクスは多く存在しますが、おおよそ自動化されたセキュリティを導入している場合は、CI/CD のパイプラインおよびその周辺にその情報が集約されているでしょう。セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 210

211.

CI/CD の導入する際のセキュリティ成熟度をモデル化すると組織のセキュリティ CI/CD の導入における成熟度をモデル化するとレベル特徴自動化率主な活動 Level 1 初期 0-20% 手動セキュリティチェック(簡単なツール利用などを行う) Level 2 管理 21-40% 基本的なツール導入(CI に Semgrep などを導入する) Level 3 定義 41-60% 標準プロセス確立(修正をするための定義や指標を設定) Level 4 統合 61-80% 包括的自動化 Level 5 最適化 81-100% 継続的改善成熟度向上ロードマップ: 段階的な能力向上計画セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 211

212.

CI/CD セキュリティ BP - 効果的な実装のための重要原則設計原則: 早期段階でのセキュリティ統合自動化優先: 手動プロセスの最小化継続的フィードバック: 迅速な問題修正 Shift-Left: 運用原則: 段階的導入: リスクを最小化した段階的展開チーム協働: 開発・運用・セキュリティの連携強化技術原則: ツール統合: エコシステム全体での一貫性スケーラビリティ: 組織成長に対応した設計セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 212

213.

214.

シークレット管理の課題なぜシークレット管理が重要なのかよくあるインシデント: への認証情報誤コミット: 年間 10 万件以上平均発見時間: コミット後 20 秒で悪用開始被害額: 平均500 万円〜数億円 GitHub 管理の課題: 開発者の意識不足とヒューマンエラー複数環境での異なるシークレット管理ローテーション作業の複雑さ監査証跡の不足セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 214

215.

216.

シークレット管理の 4 層防御 git-secret, TruffleHog, 多層防御アプローチ: その他ツールを活用した包括的管理予防（Prevention）: git-secret による暗号化 2. 検出（Detection）: TruffleHog によるスキャン 3. 管理（Management）: Vault/Secrets Manager 統合 4. 監視（Monitoring）: 継続的スキャンとアラート 1. セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 216

217.

git-secret による暗号化実装開発チームでのシークレット共有を安全に行う初期セットアップ: # リポジトリでgit-secretを初期化 git secret init # チームメンバーのGPGキーを追加 git secret tell [email protected] git secret tell [email protected] # .gitignoreに暗号化対象ファイルを追加 echo ".env" >> .gitignore echo "config/secrets.yml" >> .gitignore セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 217

218.

git-secret でのファイル暗号化暗号化プロセス: # 暗号化対象ファイルを登録 git secret add .env git secret add config/secrets.yml # ファイルを暗号化（.env.secret が生成される） git secret hide # 暗号化されたファイルをコミット git add .env.secret config/secrets.yml.secret git commit -m "Add encrypted secrets" 復号化: # チームメンバーが復号化 git secret reveal セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 218

219.

TruffleHog によるシークレット検出高精度な検出と検証機能を持つスキャンツール基本的なスキャン: # リポジトリ全体をスキャン trufflehog git file://./myrepo --json # 検証済みシークレットのみ表示 trufflehog git file://./myrepo --only-verified # 特定のブランチをスキャン trufflehog git file://./myrepo --branch=develop セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 219

220.

[beta]

TruffleHog

によるシークレット検出

出力例:
{

}

"detector": "AWS",
"verified": true,
"raw": "AKIA...",
"file": "config/aws.yml",
"line": 15

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

220

221.

CI/CD パイプラインへの統合 name: Secret Scanning on: [push, pull_request] jobs: trufflehog: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 with: fetch-depth: 0 # 全履歴を取得 - name: TruffleHog Scan uses: trufflesecurity/trufflehog@main with: path: ./ base: ${{ github.event.repository.default_branch }} head: HEAD extra_args: --only-verified --json セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 221

222.

Pre-commit フックでの防御コミット前の自動チェック実装 .pre-commit-config.yaml: repos: - repo: https://github.com/Yelp/detect-secrets rev: v1.4.0 hooks: - id: detect-secrets args: ["--baseline", ".secrets.baseline"] - repo: https://github.com/trufflesecurity/trufflehog rev: v3.63.0 hooks: - id: trufflehog entry: trufflehog git file://. pass_filenames: false セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 222

223.

224.

[beta]

GitLab

でのシークレット検出設定

.gitlab-ci.yml:
secret_detection:
stage: test
image:
name: trufflesecurity/trufflehog:latest
entrypoint: [""]
script:
- trufflehog filesystem . --json > secrets-report.json
- |
if [ -s secrets-report.json ]; then
echo "Secrets detected!"
cat secrets-report.json
exit 1
fi
artifacts:
reports:
secret_detection: secrets-report.json
when: always
セキュリティ・キャンプ全国大会
2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

224

225.

226.

ツール選定のポイントオープンソース・商用・クラウドサービスの特徴と使い分け選定基準: 組織規模: スタートアップ vs エンタープライズ予算: 無料 OSS vs 商用ライセンス統合要件: CI/CD、IDE、クラウドプロバイダー検出精度: 誤検知率とカバレッジのバランスセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 226

227.

[beta]

シークレットローテーション自動化 - 定期的なシークレット更新の実装
AWS Secrets Manager

での自動ローテーション:

import boto3
from datetime import datetime, timedelta
def rotate_secret(secret_name):
client = boto3.client('secretsmanager')
# 新しいシークレットを生成
new_secret = generate_new_secret()
# シークレットを更新
client.update_secret(
SecretId=secret_name,
SecretString=new_secret
)
# アプリケーションに通知
notify_applications(secret_name)
return f"Rotated {secret_name} at {datetime.now()}"

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

227

228.

インシデント対応プロセス - シークレット漏洩時の対応手順即座の対応（15 分以内）: 漏洩したシークレットの無効化 2. 新しいシークレットの生成 3. 影響範囲の特定 1. 調査と改善（24 時間以内）: # 漏洩経路の特定 git log -p -S "LEAKED_SECRET" # 影響を受けたコミットの修正 git filter-branch --force --index-filter \ 'git rm --cached --ignore-unmatch path/to/file' \ --prune-empty --tag-name-filter cat -- --all セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 228

229.

https://canarytokens.org/

230.

231.

CI/CD セキュリティまとめ包括的なパイプラインセキュリティの実現重要な成果: 自動化されたセキュリティ検証プロセス品質ゲートによる客観的品質管理継続的改善サイクルの確立ビジネス価値: 開発速度とセキュリティ品質の両立リスク削減による事業継続性向上次のステップ: 運用環境でのリアルタイムセキュリティ管理セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 231

232.

233.

234.

なぜ運用セキュリティが重要なのか - 2 運用フェーズ特有の課題: 時間 365 日の継続的な監視必要性変更管理とセキュリティのバランスパフォーマンスとセキュリティのトレードオフ新たな脆弱性への迅速な対応 24 学習目標: ランタイム保護技術の実装と運用包括的監視システムの構築効果的な脆弱性管理プロセスインシデント対応能力の向上ソリューションはどのようなものなのかをざっくり知るセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 234

235.

236.

ランタイム保護の多層構造境界防御層 WAF 防御防御 • SQLi • XSS DDoS Protection CDN Security API Gateway • Rate Limiting • IP Filtering • Edge Protection • Bot Management • Auth/AuthZ • Throttling IAST App Firewall Service Mesh • L7 Protection • 挙動分析 • mTLS • Policy NDR CWPP HIDS • Network • • Cloud • Container アプリケーション保護層 RASP 防御⾃⼰保護 • Runtime • • • 動的テスト脆弱性検出実⾏インフラ保護層 EDR 検知⾃動対応 • Endpoint • 監視異常検知データ保護層 DLP 漏洩防⽌機密情報保護 • Data • CASB • Cloud Access • Shadow IT 対策保護監視暗号化 • TLS/SSL • Data-at-Rest • Host IDS • FIM DAM 監視制御 • DB • Access 統合監視: SIEM / SOAR / SOC による⼀元管理セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 236

237.

ランタイム保護の多層構造 - 詳細防御層の統合による包括的セキュリティ各層の役割と連携: 境界防御層: WAF、DDoS Protection、CDN Security アプリケーション保護層: RASP、IAST、API Gateway インフラ保護層: EDR、NDR、CWPP データ保護層: DLP、CASB、暗号化セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 237

238.

（）の実装 WAF Web Application Firewall トラフィックフローインターネット保護 CDN/DDoS ユーザー/攻撃者アプリ WAF 第⼀防御層 Web アプリケーション保護保護対象ブロックルール設定 WAF コアルールセット (CRS) カスタムルール対策: 機械学習ベース検知業務特化ルール: OWASP Top 10 インジェクション検知 • XSS攻撃ブロック • パストラバーサル防御異常検知: エンドポイント保護 • レート制限 (100req/min) • 地理的アクセス制御 • ボット対策 • ファイルアップロード検証 • カスタムヘッダー検証 • SQL 対策 • セッション攻撃防御 • XXE/SSRF 検知モード • ホワイトリストパラノイアレベル: 2/4 (バランス型) 監視ログモード偽陽性分析 • ベースライン作成期間: 2週間 Stage 2: 部分適⽤低リスクルール有効化ホワイトリスト調整 • カナリアテスト期間: 2週間 • グローバル: 1000req/min 単位: 100req/min • IP • API: 50req/min/user • • しきい値設定信頼IPリスト: 内部システム、CDN ログイン: 5attempts/5min 検索: 20req/min 対策 DDoS 異常スコア: 5以上でブロック段階的導⼊戦略 Stage 1: 制限設定: ⾏動分析ベースライン • 異常トラフィックパターン • ゼロデイ攻撃検知 • 偽陽性の⾃動学習 • リアルタイム脅威分析 • スコアリングシステム • API • RCE (Remote Code Execution) レート制限⾃動スケーリング、IP⼀時ブロックパフォーマンスメトリクス Stage 3: 検知精度: 完全保護真陽性率: 98.5% • 偽陽性率: 0.8% • 検知漏れ: <0.1% • 全ルール有効化ブロックモード • 継続的チューニング継続運⽤ • • • • • • パフォーマンス: レイテンシ増加: <5ms • スループット: 10Gbps • CPU使⽤率: 15-20% • 運⽤指標: ブロック数: 15K/⽇⾃動対応率: 95% • MTTR: 15分 • • 重要KPI: セキュリティインシデント削減率 87% | ROI: 320% 運⽤のベストプラクティス WAF ✓ 定期的なルール更新（週次） ✓ 偽陽性の継続的チューニング ✓ セキュリティベンダーとの脅威情報共有 ✓ インシデント後の事後分析 ✓ 開発チームとの連携強化 ✓ 災害時のバイパス⼿順整備セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 238

239.

（）の実装 - 詳細 WAF Web Application Firewall WAF の本質的な役割と限界: ネットワーク境界防御: アプリケーション前面でのフィルタリング既知攻撃のブロック: シグネチャベースのパターンマッチング一時的な対策: アプリケーション修正までの時間稼ぎコンプライアンス要件: PCI DSS 等の規制対応 ※ WAF は「万能な防御」ではなく、アプリケーションのセキュアコーディングが大前提セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 239

240.

241.

WAF の活用現実的な WAF 活用戦略: リスクベースアプローチ: 全てを防ぐのではなく、重要な攻撃を優先アプリケーション理解: ビジネスロジックに基づくルール設定継続的改善: ログ分析とルール最適化のサイクルインシデントレスポンス: WAF ログをセキュリティ監視に活用セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 241

242.

243.

効果的なログ管理戦略ログソースアプリケーション • • アクセスログエラーログシステムカーネルサービスログ • OS/ • セキュリティ • • 認証/認可監査ログインフラ • • ネットワークロードバランサーデータベース • • クエリログスローログコンテナ/K8s ログコレクターストレージ Fluentd / Fluent Bit ホットストレージ主要機能 Elasticsearch • ダッシュボードウォーム/コールド • メトリクス可視化 • ログ収集・集約 • フィルタリング • パース・変換 • エンリッチメント • バッファリング • ルーティング • • 分析・可視化直近7⽇間⾼速検索対応 Grafana ⽇〜1年圧縮保存 •7 • • HTTP/HTTPS • TCP/UDP • gRPC • Email • Slack/Teams • PagerDuty アラートルールエラー率閾値 • 異常パターン • セキュリティイベント • SIEM • Syslog フォーマット通知チャネル Kibana オブジェクトストレージプロトコルアラート⾃動対応 Splunk / ELK アーカイブ • • • Glacier / Cold Storage 年以上 • コンプライアンス対応 •1 相関分析脅威検出インシデント調査スケーリングサービス再起動ブロック • • • IP • JSON • Apache/Nginx • Syslog RFC • Pod/Container • イベントログ保持ポリシー保持期間: • • • • • リアルタイム: 7⽇間（Elasticsearch）短期: 30⽇間（標準ストレージ）中期: 90⽇間（低頻度アクセス）⻑期: 1年間（アーカイブ）アーカイブ: 7年間（Glacier Deep Archive）パフォーマンス要件: • • 検索レスポンス: <1秒（直近7⽇）データ取得: <5分（30⽇以内）コンプライアンス: 年間必要最⼩限監査ログ年間 • PCI-DSS: 1 • GDPR: • :7 容量管理: • • • ⽇次: 500GB 圧縮率: 10:1 年間: 約18TB セキュリティ & コンプライアンスアクセス制御: 監査要件: データ保護: モニタリング: ✓ RBAC（役割ベースアクセス制御） ✓ 最⼩権限の原則 ✓ 監査ログの分離 ✓ 保存時暗号化（AES-256） ✓ 転送時暗号化（TLS 1.3） ✓ PII⾃動マスキング ✓ 定期的なバックアップ ✓ ログの完全性保証 ✓ タイムスタンプ同期（NTP） ✓ 改ざん防⽌（ハッシュチェーン） ✓ ログ収集率: 99.9% ✓ 異常検知: リアルタイム ✓ インシデント対応: 15分以内 ✓ 定期レビュー: ⽉次セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 243

244.

245.

246.

ログ分析と脅威検知 - 2 実践的な実装: ルールベースで基本的な脅威をカバー 2. 統計的手法で異常を検出 3. 段階的に機械学習を導入 4. 成熟後に UEBA を検討 1. 詳しい話は B1 の「クラウドプラットフォーム監視入門」をご覧ください。 https://github.com/m-mizutani/seccamp-2025-b1 セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 246

https://github.com/m-mizutani/seccamp-2025-b1

247.

248.

SIEM 統合アーキテクチャインフラストラクチャアプリケーションファイアウォール • ネットワーク機器 • サーバー/OS • 仮想化基盤 • セキュリティツールアプリクラウドサービス脅威インテリジェンス • Web • WAF/IPS • AWS CloudTrail • Threat Feed • API • EDR/EPP • Azure Monitor • IOC • • GCP Logging • • SaaS • OSINT データベース • ミドルウェア • 脆弱性スキャナ監査ログ • DLP 情報脆弱性DB ログ収集・正規化層 Syslog API/Webhook Agent (Beats/Fluentd) SIEM データ処理ダッシュボードリアルタイム監視 • KPIトラッキング • 傾向分析 • コンプライアンス • レポート⽣成処理能⼒: 100,000 EPS 機械学習ルールエンジン • パターンマッチング • 統計分析 • 時系列分析 • 異常検知 • アラート管理優先度付け • エスカレーション • 通知配信 • SLA追跡 • False Positive管理 • ストレージ: 10TB/⽇ STIX/TAXII コアエンジン相関分析パース・正規化 • エンリッチメント • フィルタリング • 圧縮・最適化 • インデックス作成 • • Cloud Native ストレージ⽇) • UEBA • Hot (7 • • Warm (30 • • Cold (90 ⾏動分析予測分析 • クラスタリング • ⾃動学習調査・分析ドリルダウン分析 • フォレンジック • 影響範囲特定 • タイムライン再構築 • IOC抽出 • 検知遅延: < 5秒⽇) ⽇) • Archive (365⽇+) • 圧縮率: 10:1 連携 SOAR ⾃動レスポンス • プレイブック実⾏ • チケット作成 • 隔離・ブロック • 証拠保全 • 可⽤性: 99.95% 保持期間: 365⽇セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 248

249.

SIEM データソースの統合戦略データソースログ形式収集方法 EPS 想定保持期間 WAF/CDN JSON REST API 5,000 90 日アプリケーション構造化ログ Fluentd 20,000 30 日インフラ Syslog UDP/TCP 10,000 60 日クラウド CloudTrail S3 Pull 15,000 365 日エンドポイント CEF Agent 8,000 45 日正規化の重要性: 共通イベントフォーマット（CEF/LEEF）への変換タイムゾーン統一とタイムスタンプ精度ユーザー ID とアセット情報のエンリッチメントセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 249

250.

SIEM 統合による包括的監視 - Use Case 実装主要な検知 Use Case: 検知ロジック誤検知率対応時間ブルートフォース攻撃 5 回/5 分の失敗 2% 自動ブロック権限昇格異常な権限変更パターン 5% 15 分以内調査データ漏洩大量データ転送 + 異常時刻 8% 即座隔離 APT 活動多段階・長期潜伏型 15% 詳細フォレンジックチューニング指標: Use Case 比: > 10:1 目標 MTTD（Mean Time To Detect）: < 30 分調査効率化: 80%の自動エンリッチメント Signal-to-Noise セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 250

251.

252.

SOAR 自動化の現実と課題検知 1. 2. アラート • EDR 検知 • 脅威インテリジェンス • ユーザー報告 • • 3. 重要度判定 • 影響範囲特定 • 優先度設定 • 担当者アサイン • SIEM 5. システム復元サービス再開 • 監視強化 • 正常性確認 • 調査ログ収集 • エンリッチメント • 相関分析 • IOC 抽出 • 復旧 6. トリアージ • 根絶 4. マルウェア削除 • 脆弱性修正 • パッチ適⽤ • 設定変更封じ込めネットワーク隔離アカウント無効化 • プロセス停⽌ • ファイアウォール更新 • • 主要プレイブックタイプマルウェア対応 • フィッシング対応ランサムウェア • トロイの⽊⾺ • ワーム検知時間) 対応時間) MTTD ( MTTR ( 3 28 分⽬標: 5分以内対応分⽬標: 30分以内データ漏洩対応 DDoS メール分析 • URL検証 • ユーザー通知 • • ⾃動化メトリクストラフィック分析 • レート制限 • CDN切替 • • • ⾃動化率誤検知率⽬標: 80%以上⽬標: 5%以下 78% 影響調査証拠保全規制対応 2.3% セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 252

253.

SOAR 自動化の現実と課題 - 詳細 Security Orchestration & Automated Response 自動化の適用範囲: 情報収集とエンリッチメント: 自動化推奨低リスク対応（通知、チケット作成）: 自動化推奨中リスク対応（隔離、設定変更）: 半自動化高リスク対応（削除、停止）: 人的承認必須セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 253

254.

SOAR 導入の段階的アプローチ危険な⾃動化の例必要な⼈的介⼊ポイントスケーラビリティ問題 ⚠ 本番システムの⾃動停⽌ビジネス影響売上損失、顧客離反インシデントの最終判断 👤 Critical 承認権限セキュリティマネージャーインシデント量と処理能⼒ ⚠ 重要アカウントの⾃動無効化リスク管理者ロックアウト、復旧困難 👤 ビジネス影響評価判断者ビジネスオーナープロダクトマネージャー ⚠ ネットワーク全体の⾃動遮断 👤 例外処理の承認 : : CISO/ : : 影響: 全サービス停⽌、緊急対応不可インシデント処理能⼒ / 課題: 限界点インシデント急増への対応限界 • パフォーマンス劣化 • リソース管理の複雑化 • 承認フロー: 2段階承認プロセスリスクベースの⾃動化戦略⾃動化レベルマトリクスアクション種別完全⾃動化半⾃動化⼿動対応 ✓ 推奨ログ収集・分析 ✓ 推奨アドレスブロック IP ✓ 推奨アカウント無効化 ✓ 必須本番システム停⽌低リスク承認後実⾏中リスク⾼リスク重⼤リスク ※ リスクレベルが⾼いほど⼈的介⼊が必要セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 254

255.

SOAR 導入の段階的アプローチ - 詳細リスクを抑えた実装戦略実装フェーズと期待効果: フェーズ自動化内容リスク効果 ROI Phase 1 情報収集低作業時間 50%削減 6 ヶ月 Phase 2 通知・チケット低対応時間 30%短縮 9 ヶ月 Phase 3 隔離・ブロック中 MTTR 40%改善 12 ヶ月 Phase 4 自律対応高人的介入 70%削減 18 ヶ月セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 255

256.

257.

インシデント対応プロセス 1. 準備 (Preparation) • PSIRT体制構築 • 対応⼿順・ツール整備改善 4. 事後対応検知 MTTD: 検知時間 2. 検知と分析継続的改善 Lessons Learned • RCA作成 • 再発防⽌策振り返り • アラート検知 • 影響範囲特定対応 MTTR: 復旧時間 3. 封じ込め・根絶・復旧 • 被害拡⼤防⽌ • 原因除去 • サービス復旧重要指標: 深刻度 P1: Critical P2: High P3: Medium P4: Low • MTTD (Mean Time To Detect): 平均検知時間 - インシデント発⽣から検知までの時間 • MTTR (Mean Time To Recover): 平均復旧時間 - 検知から完全復旧までの時間セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 257

258.

インシデント対応プロセス - 詳細フェーズ別の重要活動: 準備: 体制構築、手順策定、訓練実施 2. 検知・分析: アラート評価、影響範囲特定 3. 封じ込め・根絶: 被害拡大防止、原因除去 4. 復旧: システム復旧、監視強化 5. 事後分析: 教訓抽出、改善実施 1. セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 258

259.

260.

脆弱性管理ライフサイクル修正期限 SLA Critical 1営業⽇ High 7営業⽇ Medium 30営業⽇ Low 90営業⽇ 1. 発⾒スキャン・報告 6. 報告 2. 評価⽂書化・共有リスク分析 5. 検証 3. 優先順位付け修正確認重要度判定 4. 修正主要メトリクスパッチ適⽤平均修正時間(MTTR): Critical=6時間, High=3⽇ | 修正率: 99%+ | 誤検知率: <1% セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 260

261.

脆弱性管理ライフサイクル - 詳細体系的な脆弱性対応プロセス SLA 基準と達成目標: 深刻度対応期限 SLA 目標現実的な達成率 Critical 24 時間 99% 85-90% High 7日 95% 80-85% Medium 30 日 90% 75-80% Low 90 日 80% 70-75% セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 261

262.

実務的な脆弱性トリアージ発⾒ソース⾃動スキャン評価基準: 悪⽤可能性ビジネス影響度露出レベル Critical 顧客データ漏洩 Critical インターネット公開公開エクスプロイト存在 Trivy, Snyk, GitHub Security バグバウンティ HackerOne, Bugcrowd セキュリティ研究即座に悪⽤可能信頼失墜・法的責任 High サービス可⽤性乗数: ×1.5 認証後のみ High （概念実証）存在 PoC 技術的に実証済みダウンタイム・売上損失 Medium 内部システム乗数: ×0.8 CVE, NVD, Vendor Advisories 実装には専⾨知識必要 Pentesting, Code Review 内部ネットワーク Medium 理論的のみ内部監査乗数: ×0.5 業務効率低下優先順位計算ロジック最終スコア = 悪⽤可能性 × ビジネス影響度 × 露出レベル乗数 (Critical=3, High=2, Medium=1) × (Critical=3, High=2, Medium=1) × (Internet=1.5, Auth=0.8, Internal=0.5) 計算例: 公開Webサイト SQLi 3 × 3 × 1.5 = 13.5 (Critical) 内部API XSS 2 × 2 × 0.5 = 2.0 (Medium) 認証後情報漏洩内部ツール設定ミス 1 × 2 × 0.8 = 1.6 (Low) 1 × 1 × 0.5 = 0.5 (Info) 対応時間SLA Critical ( スコア 9+) 初期対応: 1時間以内修正期限: 24時間以内エスカレーション: 即座 High ( スコア 4-8) 初期対応: 4時間以内修正期限: 7⽇以内エスカレーション: 24時間 Medium ( スコア 2-3) 初期対応: 2営業⽇以内修正期限: 30⽇以内エスカレーション: 1週間 Low ( スコア 0-1) 初期対応: 1週間以内修正期限: 90⽇以内エスカレーション: なしセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 262

263.

実務的な脆弱性トリアージ - 詳細効率的な優先順位付けプロセス優先順位決定要因: 基本スコア: 技術的深刻度悪用可能性: Exploit 公開状況、攻撃容易性, ソフトウェアでの利用ビジネス影響: データ重要度、サービスクリティカリティ露出レベル: インターネット公開、アクセス可能範囲 CVSS セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 263

264.

脆弱性修正の実務的障壁現場で直面する課題と対処法障壁発生率対策依存関係の競合 35% 代替コントロール、WAF ルール本番環境への影響 25% カナリアデプロイ、段階展開リソース不足 20% 自動修正、優先順位調整ビジネス優先度 15% リスク可視化、経営層エスカレーション 5% リファクタリング計画技術的負債実践的アプローチ: リスクベース対応（ビジネス影響 × 悪用可能性）補償コントロール（即時修正不可時の代替策）継続的改善（技術的負債の計画的解消）セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 264

265.

パッチ管理の自動化 1. 検証環境 (Dev/Test) 即座に適⽤ ✓ ⾃動パッチ適⽤ ✓ ユニットテスト実⾏ ✓ 統合テスト実⾏ 2. 成功ステージング環境 3. 時間観察 24-48 検証OK ⚡ パフォーマンステスト ⚡ 負荷テスト ⚡ セキュリティスキャンカナリアリリース本番環境の5-10% 📊 メトリクス監視 📊 エラー率チェック 📊 ユーザー影響評価問題なし緊急ロールバック 5. 監視と検証問題検出時の対応継続的モニタリング ⚠ 即座に前バージョン復元 ⚠ インシデント記録 ⚠ 根本原因分析 ✅ パフォーマンス確認 ✅ セキュリティ確認 ✅ ユーザー影響確認 4. 完了本番全体展開段階的ロールアウト 🚀 Blue-Greenデプロイ 🚀 リアルタイム監視 🚀 ロールバック準備標準的なタイムライン即座 → 24時間 High: 24時間 → 7⽇ ※ ビジネスクリティカルなシステムは優先度を1段階上げて対応 Critical: ⽇ → 30⽇ Medium: 7 Low: 次回メンテナンスセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 265

266.

267.

https://github.com/kyohmizu/seccamp2025-B4

268.

コンテナランタイムセキュリティ環境での実行時保護コンテナ特有の脅威: Kubernetes イメージの脆弱性ランタイムでの権限昇格コンテナエスケープ横方向の移動保護メカニズム: （予防） Runtime Security（検知・防御） Network Policy（隔離） Security Scanning（継続的評価） Admission Controller セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 268

269.

（） CNAPP Cloud Native Application Protection Platform 統合セキュリティアプローチ: レイヤー保護技術主要機能開発 SAST/SCA コード・依存関係スキャンビルドイメージスキャン脆弱性・設定チェックデプロイ CSPM クラウド設定管理ランタイム CWPP ワークロード保護クラウド責任共有モデル: 以上は利用者責任 PaaS: アプリケーション層は利用者責任 SaaS: データとアクセス管理は利用者責任 IaaS: OS セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 269

270.

271.

272.

投資対効果（ROI）の測定の構成要素セキュリティ投資による定量的な価値創出: 監査コストの削減自動化による人件費の削減(時間単価 * 時間) 発生時の被害額 / 機会損失額 / 訴訟対応費用コンプライアンス要件における非準拠による制裁効果インシデント予防効果運用自動化による効率化コンプライアンス対応の価値セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 272

273.

成熟度評価と改善計画 - 運用セキュリティ成熟度モデルレベル特徴達成指標次への要件 Level 1 反応的対応基本的な監視プロセス文書化 Level 2 予防的対応脆弱性管理自動化導入 Level 3 プロアクティブ脅威ハンティング ML/AI 活用 Level 4 最適化予測的防御継続的改善 Level 5 改善改善優先順位: 1. 基本的な可視性の確保 → 2. インシデント対応能力 → 3. 自動化による効率化 → 4. 高度な分析能力 →5. 予測的防御セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 273

274.

運用セキュリティまとめ重要な成功要因: 多層防御: WAF、RASP、EDR の統合運用自動化: SIEM/SOAR による効率化（ただし段階的に）脆弱性管理: リスクベースの優先順位付け可視性: 包括的なログ管理と分析測定と改善: KPI に基づく継続的最適化ビジネス価値: インシデント被害の最小化コンプライアンス要件の充足運用効率の向上顧客信頼の維持セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 274

275.

276.

なぜプロダクトセキュリティ部門が必要なのか - 1 現代のソフトウェア開発における脆弱性対応の必要性ビジネスリスクの現実: 平均的なデータ侵害コスト: 4.5 億円（IBM Security Report 2024）脆弱性発見から悪用までの期間: 平均 7 日年間発見される新規 CVE: 25,000 件以上規制要件の強化: 指令（72 時間以内の報告義務）米国: CISA 脆弱性開示要件日本: 経済安全保障推進法 EU: NIS2 セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 276

277.

278.

プロダクトセキュリティ部門とは何か Product Security Incident Response Team (PSIRT) PSIRT の定義: 製品セキュリティ対応の専門チーム製品・サービスのセキュリティ脆弱性対応専門チーム外部研究者からの報告受付と評価迅速かつ適切なインシデント対応ステークホルダーとの継続的連携主要な責任範囲: 脆弱性の受付・トリアージ・評価修正計画の策定と実行管理セキュリティアドバイザリの作成・公開外部セキュリティコミュニティとの協働セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 278

279.

CSIRT と PSIRT の違い - 組織のセキュリティ体制における役割分担側面 PSIRT CSIRT 対象製品・サービスの脆弱性組織の IT インフラ活動時期開発〜運用全フェーズ主に運用フェーズ主な脅威ソフトウェア脆弱性サイバー攻撃・侵害対応範囲全顧客への影響自組織への影響連携先開発チーム・顧客 IT 運用・SOC 成果物パッチ・アドバイザリインシデント対応協力関係: インシデント情報の共有 / 脅威インテリジェンスの活用 / 対応プロセスの標準化セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 279

280.

281.

282.

PSIRT 人材要件と役割分担専門性の異なる役割の効果的な組み合わせ必要な専門性とスキルセット役割責任範囲必要スキル PSIRT マネージャーチーム運営・経営層報告プロジェクト管理・リスク評価セキュリティアナリスト脆弱性分析・技術調査 CVSS 評価・脅威モデリング脆弱性診断士自社診断内製化担当脆弱性診断セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 282

283.

PSIRT 専門担当者の役割組織横断的な連携を支える専門職役割責任範囲必要スキル開発連携担当修正計画・技術支援開発知識・調整能力広報担当アドバイザリ作成・顧客対応技術文書作成・危機管理広報法務連携担当規制対応・契約管理法規制知識・リスク管理拡張チーム: インシデントコーディネーター脅威インテリジェンスアナリスト自動化エンジニアセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 283

284.

PSIRT 成熟度モデル - 能力評価と向上計画レベル特徴主な活動次レベルへの要件 Level 1: Initial アドホック対応手動・個別対応プロセス文書化 Level 2: Managed 基本プロセス標準化開始全製品への適用 Level 3: Defined 標準プロセス一貫した対応メトリクス導入 Level 4: Measured 定量管理 KPI 駆動自動化推進 Level 5: Optimized 継続的改善 AI/ML 活用業界リーダーセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 284

285.

286.

脆弱性報告受付プロセスの例報告受付チャネルメールバグバウンティ GitHub Security [email protected] HackerOne/Bugcrowd Security Advisory 暗号化対応時間365⽇受付⾃動受付確認 • PGP • 24 • • • • 報奨⾦プログラム研究者認証済みトリアージ⽀援直接連絡営業・サポート経由 • 既存顧客からの報告 • 内部発⾒ • パートナー連携報告機能⾃動割当調整済み開⽰ • Private • CVE • 統合受付システム全チャネルからの報告を⼀元管理 1. • • 初期対応プロセス（24時間以内） 2. 初期分類受付確認⾃動返信メール送信チケット番号発⾏ • • 脆弱性種別特定影響コンポーネント特定 3. 緊急度判定初期評価優先度レベル割当（P0-P4） • CVSS • 優先度レベルと対応時間 P0: Critical 即座対応認証迂回本番環境影響対応時間以内 • RCE/ • • :1 P1: High • • • 24時間以内データ漏洩権限昇格対応: 1営業⽇ P2: Medium P3-P4: Low ⽇以内 7 • XSS/CSRF • • :1 限定的影響対応週間 • • • 30⽇以内情報開⽰ベストプラクティス対応: 次リリースセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 286

287.

脆弱性報告窓口の段階的展開戦略組織の成熟度に応じた報告窓口の設計段階的アプローチ: フェーズ窓口タイプ特徴 Phase 1 基本メール窓口メールなどを security.txt などで明示する Phase 2 専用ポータル Web フォーム・自動受付 Phase 3 社内バグバウンティ従業員インセンティブセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 287

288.

脆弱性報告窓口の発展フェーズ高度な報告プログラムの構築フェーズ窓口タイプ特徴 Phase 4 限定参加型プログラム招待制・NDA 締結 Phase 5 公開バグバウンティグローバル研究者各フェーズの成功指標: 受付から初回応答までの時間誤検知率の低下重要脆弱性の発見数セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 288

289.

初期対応とトリアージ効率的な脆弱性評価プロセス 24 時間以内の初期対応フロー: graph LR A[報告受付] --> B[自動確認送信] B --> C[初期分類] C --> D{緊急度判定} D -->|P0: Critical| E[即座エスカレーション] D -->|P1: High| F[24時間以内対応] D -->|P2: Medium| G[72時間以内対応] D -->|P3-4: Low| H[通常プロセス] セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 289

290.

291.

292.

社内バグバウンティプログラムをする際の要件要素詳細参加者全従業員対象報奨金任意のインセンティブを設定(非懲罰的な報酬) 特別報酬月間 MVP・年間表彰制度報告プラットフォーム社内専用システム成功のポイント: 経営層の支援とアナウンス明確な報奨金体系非懲罰的な文化醸成教育プログラムとの連携実装と発見の追跡性セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 292

293.

社内バグバウンティプログラムをした際の例対象者開発者 QA 報奨⾦体系営業/CS 特別報奨 Critical High Medium Low ¥50,000 ¥30,000 ¥10,000 ¥5,000 XSS, SSRF CSRF, RCE, SQLi データ漏洩全従業員が参加可能（開発者⾃⾝の脆弱性は対象外）認証バイパス情報漏洩(低) 設定ミス情報開⽰プログラムの利点 1 セキュリティ⽂化の醸成 3 社員のスキル向上全社的なセキュリティ意識向上セキュリティ知識の実践的習得 🏆 年間最優秀発⾒者特別ボーナス 👥 チーム表彰部⾨単位評価課題と対策 2 早期の脆弱性発⾒ 4 コスト効率的開発段階での問題検出外部プログラムより低コスト利益相反 → 開発者⾃⾝が作った脆弱性は報奨対象外時間確保 → 業務時間の20%をセキュリティ活動に充当可能スキル不⾜ → 定期的なセキュリティトレーニング提供導⼊フェーズ Phase 1: 準備（1-2ヶ⽉）ポリシー策定報奨⾦予算確保 • プラットフォーム構築 • 社内告知準備 Phase 2: パイロット（3ヶ⽉）限定部⾨で開始トレーニング実施 • プロセス改善 • 効果測定 Phase 3: 全社展開（6ヶ⽉〜）全部⾨への拡⼤定期的な啓発活動 • 成果の可視化 • 継続的改善 Phase 4: 成熟（継続）⾃動化推進外部連携検討 • ベストプラクティス共有 • ROI最適化 • • • • • • • • セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 293

294.

限定参加型バグバウンティをする際の要件要素詳細参加者選定 CVE 実績・専門分野・NDA 締結可否規模 20-50 名の厳選研究者報奨金 Critical: 10-30 万円 / High: 5-10 万円特別報酬初回発見ボーナス・連続発見報奨プラットフォーム HackerOne Private / Bugcrowd メリット: 高品質な報告（誤検知率 15%以下） / 情報管理の容易さ / 長期的な信頼関係構築 / 公開前の重要脆弱性発見セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 294

295.

限定参加型バグバウンティの例 Phase 1: 選定基準: 研究者選定 Phase 2: 準備プロセス: 実績: 5件以上 • 専⾨分野: Web/Mobile/IoT • 過去の報告品質 • NDA締結可能性 • 地理的分散を考慮オンボーディング継続管理: ・規約締結 • テスト環境アクセス提供 • レポートテンプレート配布 • 連絡体制確⽴ • 初回オリエンテーション • CVE • • 期間: 2-3週間報奨⾦体系 Critical 報奨⾦範囲 10-30万円 High 5-10 Medium 2-5 Low 0.5-2 特別ボーナス +50% 条件初回発⾒万円 +30% 詳細PoC 万円 +20% 修正案提⽰万円なし基本報告プログラム管理⽉次レビューミーティングパフォーマンス評価 • フィードバック収集 • スコープ更新 • 関係維持 • NDA ⽬標⼈数: 20-50名深刻度 Phase 3: 運⽤モード: 継続品質メトリクス: 誤検知率: 15%以下（公開型: 25%）重複報告: 5%以下 • 平均重要度: 3.2/5.0 成功指標とメリット期待効果: 年間発⾒数: 120件発⾒: 15件 • • • • Critical • ROI: 350% 運⽤メリット: リスク軽減: • • • • 情報管理が容易⻑期的関係構築 • ⾼品質な報告 • コントロールされた公開公開前発⾒: 95% 悪⽤防⽌ • レピュテーション保護 • 規制対応セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 295

296.

公開バグバウンティプログラムの例セキュリティ研究者バグバウンティプラットフォーム参加者プロファイル実施企業スコープ定義主要プラットフォームホワイトハッカーセキュリティ専⾨家⼤学研究者フリーランス • セキュリティ企業 • HackerOne • • • 300K+ Bugcrowd 研究者 2800+ 企業 ✓ 対象システム明確化 ✓ 除外項⽬の明⽰ ✓ テスト環境提供 ✓ 法的保護（Safe Harbor） ✓ 報奨⾦テーブル Synack 研究者 1000+ 企業精鋭研究者エンタープライズ 200K+ 1500 プラットフォーム機能動機トリアージ⽀援⾃動重複検出初期検証評価レポート品質管理管理 • • • CVSS • • SLA ⾦銭的報酬スキル向上・学習 • 評価・名声 • 社会貢献 • • 対応体制研究者管理 • • • • • レピュテーションシステムスキルマッチング⽀払い処理コミュニケーション法的サポート専任配置時間初期対応エンジニア連携 • 修正プロセス確⽴ • 情報公開準備 • PSIRT • 24 • 報奨⾦フロー標準プロセスフロー 1. 発⾒・報告脆弱性発⾒作成プラットフォーム経由で報告 • • POC • 2. 24h • • • • トリアージ初期確認重複チェック深刻度評価優先順位付け 3. 48h 検証・再現技術検証影響範囲確認計算開発チーム連携 • • • CVSS • 4. 7d • • • • 修正実装パッチ開発テスト実施デプロイ準備回避策提供 5. 30d 報奨・公開報奨⾦⽀払い登録アドバイザリ公開研究者クレジット • • CVE • • 成功指標とベンチマーク発⾒指標⽉間報告数: 150-200件有効報告率: 35-40% 発⾒: 2-3件/⽉新規研究者: 20-30名/⽉ • • • Critical • 対応指標 • • • • 初回応答: <24時間 (95%) トリアージ: <48時間 (90%) 修正時間: <30⽇ (80%) 研究者満⾜度: 4.5/5.0 平均報奨⾦最⾼報奨⾦年間予算財務指標万円万円万円 • : 5-10 • : 100-500 • : 3000-5000 • ROI: 300-500% 品質指標 • • • • 誤検知率: <20% 重複報告: 15-20% レポート品質: 4.0/5.0 再発率: <5% セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 296

297.

298.

バグバウンティ ROI 分析 - 1 投資対効果の定量評価コスト削減効果: 項目金額/影響データ侵害回避平均 4.5 億円/件ダウンタイム防止 1,000 万円/時間機会損失規制違反回避最大売上 4%の制裁金 GDPR などの法令による制裁金ブランド価値保護株価 10-30%下落防止過去の事例を参考セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 298

299.

バグバウンティ ROI 分析 - 2 発見効率比較: プログラム年間発見数 Critical 誤検知率社内 45 件 5件 40% 限定参加 120 件 15 件 15% 公開 280 件 35 件 25% データ侵害 / ダウンタイム / 規制違反 / ブランドなどの保護を目的とした脆弱性について、発生する影響を元に ROI は計算する。セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 299

300.

301.

セキュリティテスト手法の比較バグバウンティ脆弱性診断ペネトレーションテストレッドチーム 🎯 🔍 ⚔ 🎭 継続的な脆弱性発⾒網羅的な既知脆弱性検出実際の攻撃シミュレーション組織防御能⼒の総合評価特徴: 常時実施 • クラウドソーシング型 • 成果報酬制 • 多様な視点特徴: 特徴: 特徴: • • • 定期実施（年1-4回） • ツールベース中⼼ • 標準化された⼿法 • コンプライアンス準拠 • 24/365 適⽤場⾯: 適⽤場⾯: 公開Webサービス • モバイルアプリ定期セキュリティ評価 • 監査要件対応 • ベースライン確⽴ • 適⽤場⾯: 新システムリリース前 • M&A前評価 • 重要システム検証能⼒評価訓練 • 成熟度評価 • • SOC • IR ⽐較マトリクス深度 vs 網羅性実施タイムライン(⼀例) 0 レッドチームペンテスト⻑期間（1-3ヶ⽉）攻撃模擬 • 物理/ソーシャル含む • ステルス性重視 • APT 適⽤場⾯: • • API/SDK → 短期集中（1-4週間） • 実攻撃⼿法使⽤ • 侵⼊可能性実証 • ⼿動テスト中⼼ヶ⽉ 3 ヶ⽉ 6 ヶ⽉ 9 ヶ⽉ 12 バグバウンティ（継続）度深脆弱性診断バグバウンティペンテスト脆弱性診断レッドチーム網羅性 → セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 301

302.

303.

脆弱性テスト手法の比較実施頻度とコスト効果 (システム規模によるものの) 項目脆弱性診断ペネトレーションテスト頻度四半期〜半期年 1-2 回成果物脆弱性一覧・リスク評価侵入経路・改善提案コスト 200-1000 万円 500-2000 万円使い分け: 脆弱性診断: コンプライアンス要件・定期健診ペンテスト: 重要システム・新機能リリース前セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 303

304.

レッドチーム演習レッドチーム標的組織環境攻撃者シミュレーション⽬標: クラウンジュエル到達 • ⻑期潜伏実証 • データ持ち出し • 攻撃防御側（通常業務）内部ネットワーク DMZ インターネットブルーチームサーバー Web AD 制約: 破壊⾏為禁⽌ • 業務影響最⼩化 • 倫理的ガイドライン • 法的コンプライアンス • App 初期侵⼊フィッシング • ⽔飲み場攻撃 • 物理侵⼊ • サプライチェーン • ゼロデイ持続化バックドア設置 • Webシェル • サービス登録 • スケジュール • レジストリ • • 通知: 事前通知なし（理想）限定的通知 • 経営層のみ認知 • 演習後に開⽰ • 機密 • 評価指標横展開データ窃取検知能⼒経由 • Pass-the-Hash • HTTPS • RDP/SSH • DNS tunneling • WMI/PsExec • • • 認証情報窃取 • トークン偽装検知能⼒インシデント対応速度 • 封じ込め効果 • SOC 防御 DB 攻撃戦術（MITRE ATT&CK準拠） • 評価対象: • • • • • クラウド転送物理メディア • ステガノグラフィ対応能⼒初期侵⼊検知: 2時間以内横展開検知: 24時間以内データ流出検知: 48時間以内検知率: 70%以上が⽬標誤検知率: 5%以下検知平均時間対応平均時間封じ込め成功率影響範囲特定精度復旧時間時間以内 • MTTD ( ): 6 • MTTR ( ): 24 • : 85% • : 90% • : 72 典型的な演習タイムライン（8週間） Week 1 Week 2 偵察 Week 3 初期侵⼊・確⽴ Week 4 Week 5 横展開・⽬標達成 Week 6 Week 7 Week 8 報告・改善セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 304

305.

306.

セキュリティテストの統合戦略 - 成熟度に応じた段階的アプローチ Level 1: 基礎段階 Level 2: リアクティブ対応実施内容: 四半期毎の脆弱性診断 • 年2回のペンテスト • 部分的な⾃動化 • 開発チーム連携 • ツール: ツール: 基本的なスキャナー実施内容: • Nessus • SonarQube • Checkmarx/Veracode 基本的な脆弱性発⾒ • コンプライアンス充⾜ • リスク可視化開始 • 投資/年: 万円成果: 200-700 次のステップ: 定期的な診断実施 • 内製化の検討 • プロセス⽂書化 • 成果: 早期脆弱性発⾒ • 修正時間短縮 • 開発プロセス改善万円 700-1500 次のステップ: 継続的テスト導⼊ • バグバウンティ検討 • セキュリティチーム設⽴ • カスタムツール開発脅威検知 • ⾃動修正システム • • AI/ML 組織全体の耐性向上インシデント予防 • 業界リーダーシップ • 投資/年: ツール: 成果: ゼロデイ発⾒ • 継続的改善 • セキュリティ⽂化確⽴ • 投資/年: 全⼿法の統合運⽤年次レッドチーム演習 • 脅威モデリング⾃動化 • セキュリティR&D • 統合 • HackerOne/Bugcrowd 予測的・⾰新的 • • DAST/SAST/IAST • Burp Suite Pro • • 万円投資/年: 2000-5000 次のステップ: レッドチーム導⼊ • AI/ML活⽤ • グローバル展開 • 先進段階実施内容: 継続的脆弱性管理 • 定期ペンテスト • バグバウンティ運⽤ • DevSecOps実践 • • OWASP ZAP 成果: Level 4: 継続的・プロアクティブツール: 統合スキャナー • CI/CD 成熟段階 Level 3: 定期的・計画的対応実施内容: 年1回の脆弱性診断 • ⼿動テスト中⼼ • 外部委託 • 事後対応型 • • 発展段階万円〜1億円+ 5000 継続的改善: 新脅威への即座対応セキュリティ研究貢献 • エコシステム構築 • • セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 306

307.

セキュリティテスト投資戦略成熟度別投資ロードマップ成熟度テスト構成年間投資期待効果基礎脆弱性診断（四半期） 800 万円基本的脆弱性除去発展＋ペンテスト（年 2 回） 2000 万円実践的リスク低減成熟＋公開バグバウンティ 5000 万円継続的改善先進＋レッドチーム 1 億円包括的体制強化セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 307

308.

309.

310.

セキュリティアドバイザリ作成 - 透明性のあるセキュリティ情報公開 # Security Advisory: CVE-2024-XXXXX ## エグゼクティブサマリー - 影響を受ける製品とバージョンリスクレベルと推奨アクション修正版の入手方法 ## 技術的詳細 - CVSS スコア: 8.5 (High) 攻撃ベクトル: ネットワーク経由必要な権限: なし影響範囲: 機密性/完全性 ## 対策方法 1. 即座のアップデート（v2.5.1 以降） 2. ワークアラウンド（一時対策） 3. 検出方法（IoC） ## タイムライン - 発見日・報告者クレジット修正完了日・公開日セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 310

311.

312.

ステークホルダー対応詳細組織内外の緊密な連携体制ステークホルダー関心事項コミュニケーション方法営業・CS 顧客影響・FAQ 顧客向け資料・Q&A 法務・広報規制・レピュテーションリスク評価・声明文案外部ステークホルダー対応: 顧客: 段階的情報開示（embargo 期間考慮）研究者: 協調的脆弱性開示（CVD）規制当局: コンプライアンス報告メディア: 統一メッセージングセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 312

313.

314.

315.

316.

317.

PSIRT まとめ効果的な Product Security Incident Response Team の構築ビジネス価値: 顧客信頼の維持・向上（NPS +20 ポイント）規制リスクの低減（制裁金回避）競争優位性の確立（セキュリティ = 差別化要因）ブランド価値の保護（企業価値の 10-30%）セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 317

318.

PSIRT 実装ロードマップの例段階的な成熟度向上ステップ実装スケジュール: 基本体制構築（3 ヶ月） 2. プロセス標準化（6 ヶ月） 3. ツール導入・自動化（9 ヶ月） 4. バグバウンティ開始（12 ヶ月） 5. 継続的最適化（継続） 1. 次のステップ: ROI 測定による投資判断の最適化セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 318

319.

320.

なぜセキュリティメトリクスが必要かセキュリティ活動の見える化と改善の実現現状の課題: セキュリティ投資の効果が不明確改善活動の優先順位が曖昧経営層への報告が定性的メトリクス導入の効果: データに基づく意思決定明確な目標設定と進捗管理投資対効果の定量評価継続的な改善サイクル確立セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 320

321.

322.

323.

KGI - 経営層が見るべき「ゴール指標」の例ビジネス⽬標達成の測定指標 - 経営層向け戦略的指標ビジネスインパクト指標セキュリティコスト削減コンプライアンス指標顧客信頼度規制遵守率年間インシデントコストセキュリティ関連NPS ISO/GDPR/PCI-DSS +72 98% ⽬標: 50%削減業界平均: +45 必須: 100% -45% 監査スコア外部監査評価 A+ 改善率: +15% リスク管理指標リスクエクスポージャーセキュリティ成熟度年間予想損失額 (EAL) ¥2.1 億 OWASP SAMM 重⼤インシデント発⽣率スコア⽉間Critical件数 Level 2.8 前年⽐: -35% 0.3 件業界平均: 1.2件⽬標: Level 3.0 戦略的成果指標市場競争⼒ビジネス継続性 12 99.99% セキュリティ認証数業界トップ3 投資効率可⽤性 (SLA) セキュリティROI ダウンタイム: 52分/年投資回収: 11ヶ⽉ 312% ブランド価値評判スコア 85/100 前年⽐: +12pt 測定頻度: 四半期ごと | レポート先: 取締役会・経営会議 | 責任者: CISO/CTO セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 323

324.

325.

KPI - 管理層が追跡する「パフォーマンス指標」の例プロセスパフォーマンスの測定 - 管理層向け運⽤指標脆弱性管理 KPI MTTR (Critical) インシデント対応 KPI 脆弱性検出率 MTTR (High) 24h 7d ⽬標: <48h 前⽉: 36h 改善率: 33% MTTD 92% ⽬標: <7d 前⽉: 10d 達成率: 100% 15min ⾃動検出: 78% ⼿動検出: 14% ⽬標: >90% 2.5h ⽬標: <30min ⾃動検知: 85% 誤検知率: 8% ペンテスト四半期) ポリシー準拠率 4.2/5.0 • • • ⾃動化率: 65% チケット解決: 94% エスカレーション: 12% コンプライアンス KPI コードレビュー品質 100% ⾃動週次 • SAST: 100% ( ) • DAST: 85% ( ) • : 100% ( 87% ⽬標: <4h 封じ込め率: 95% 再発率: 3% プロセス効率 KPI セキュリティテスト実施率対応効率 MTTC セキュリティ項⽬: 95% 平均レビュー時間: 2.5h 発⾒⽋陥数: 3.2/PR 監査指摘対応率 96% • • • パスワード: 98% アクセス制御: 95% データ暗号化: 94% 100% 内内 • Critical: 100% (24h ) • High: 100% (7d ) • Medium: 95% (30d ) 内チームパフォーマンス KPI トレーニング完了率セキュリティチャンピオン必須研修: 100% 専⾨研修: 78% 資格取得: 45% カバー率: 80% 活動率: 92% 満⾜度: 4.5/5 89% 24 名改善提案数⾃動化進捗採⽤率: 68% 実装率: 85% 効果測定: 92% テスト: 85% デプロイ: 78% 監視: 56% 件⽉ 156 / 73% 測定頻度: ⽉次 | レポート先: 部⾨⻑会議・セキュリティ委員会 | 責任者: セキュリティマネージャーセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 325

326.

327.

KDI - 現場が監視する「診断指標」の例⽇常運⽤データの収集 - 現場向け詳細データスキャン実⾏メトリクス SAST 実⾏実⾏依存関係コンテナログ収集イベントアラート回/⽇成功率: 94.5% 平均: 45min チェック/⽇脆弱性: 247 更新: 89 イメージ/⽇リスク: 34 修正: 28 /⽇源: 324 ⽋損: 0.1% 件/時警告: 892 エラー: 124 / Critical: 3 High: 21 DAST 3,245 124 回/⽇成功率: 99.2% 平均: 4.2min ログ分析メトリクス 8,921 456 12.4TB 2.3M アクティビティメトリクスコードコミットデプロイメントセキュアレビュー: 100% ⾃動チェック: 100% 拒否率: 3.2% 修正時間: 1.2h 本番: 12 ステージング: 45 開発: 67 ロールバック: 2 892/ ⽇ 124/ 89% 件⽇精度ルール: 456 更新: 12/⽇構成管理メトリクスパッチ適⽤⽇相関 147 構成変更システム緊急: 12 (100%) 重要: 45 (98%) 中程度: 89 (92%) 平均適⽤: 2.3⽇コンプライアンス件⽇ 234 456 / • • • • CIS: 94% 承認済み: 432 (94.7%) 未承認: 24 (5.3%) ⾃動修正: 18 ドリフト検出: 8 • • • • 合格項⽬: 234/249 重要違反: 2 ⾃動修復: 89% 監査対応: 100% リアルタイム運⽤メトリクス呼び出しネットワークユーザー活動ファイル整合性証明書認証失敗: 124 レート制限: 45 異常検知: 8 検知: 0 異常トラフィック: 3 ブロック: 892IP ログイン失敗: 234 権限昇格: 12 異常⾏動: 5 監視: 12,456 変更: 234 違反: 2 期限切れ: 0 30⽇内: 12 ⾃動更新: 95% API 分 234K/ 12.4Gbps DDoS 45.6K 99.98% 個 456 測定頻度: リアルタイム〜⽇次 | データ保存: 90⽇間 | 可視化: Grafana/Kibana ⾃動収集率: 98% | API連携: 24システム | アラート設定: 892ルールセキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 327

328.

329.

Step 2: SMART 良いメトリクスの作り方 - SMART 原則原則: （具体的）: 測定対象が明確 Measurable（測定可能）: 数値化が可能 Achievable（達成可能）: 現実的な目標設定 Relevant（関連性）: ビジネス目標との関連性 Time-bound（期限）: 測定期間の明確化 Specific 例: "Critical 脆弱性の MTTR を 7 日以内にする" ✓ 全ての要件を満たす良いメトリクス再掲: メトリクスを取るが完璧を求めない、取得の精度は求めすぎないと言うのも頭の片隅に置いておくと良いでしょう。 → 組織における合理性の中で、可能な範囲で効果測定を行う。セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 329

330.

331.

https://owaspsamm.org/about/

332.

333.

SAMM v2 の 5 つの評価領域包括的なセキュリティ実践の構造化ガバナンス（Governance）戦略とメトリクス: セキュリティ戦略の策定と測定ポリシーとコンプライアンス: 規制要件の管理教育とガイダンス: セキュリティトレーニングの実施設計（Design）脅威評価: 脅威モデリングの実施セキュリティ要件: 要件定義と管理セキュアアーキテクチャ: 設計パターンの適用セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 333

334.

SAMM v2 評価領域（続き）実装（Implementation）セキュアビルド: ビルド環境の保護セキュアデプロイ: デプロイメントの自動化欠陥管理: 脆弱性の追跡と修正検証（Verification）アーキテクチャ評価: 設計レビューの実施要件テスト: セキュリティ要件の検証セキュリティテスト: SAST/DAST/IAST の活用運用（Operations）インシデント管理: 対応と復旧プロセス環境管理: 構成管理の徹底運用管理: 継続的な監視と保護セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 334

335.

成熟度レベルの段階的向上レベル状態特徴期待される成果 Level 0 未実施セキュリティ活動なしベースライン確立アドホックな活動 Level 1 初期実施基本的な実践基本的なリスク削減限定的な範囲標準化された活動 Level 2 効率化効率的な実践一貫性のある保護定期的な実施最適化された活動 Level 3 包括的包括的な実践先進的なセキュリティ継続的改善セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 335

336.

337.

338.

339.

Step 4: メトリクスの自動収集を実現するや JIRA などのセキュリティの自動化やデータの保存先から必要なデータを BigQuery などの Dataware House に結果を出力する。 DH への保存、自動収集の例 GitHub で実行された SAST の結果起票された脆弱性の進捗と解決状況公開された脆弱性の解決情報出力された脆弱性のトレンドコンプライアンスの準拠状況カバレッジ GitHub Action セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 339

340.

Step 5: ダッシュボードで可視化 . Looker Studio や QuickSight を用いた可視化を行う経営層ダッシュボード総合リスクスコア財務インパクト 78 ¥2.1億コンプライアンス 95% 潜在リスク額削減: ¥1.5億前⽉⽐: -5pt 業界平均: 72 インシデントトレンド（6ヶ⽉） ✓ ✓ 審査中 ISO27001: GDPR: PCI-DSS: ROI: 312% 改善率: 28% 管理層ダッシュボード脆弱性ステータス 3 18 67 234 チームパフォーマンスインシデント対応時間: ⾃動化率: カバレッジ: Critical High Medium Low MTTR: Critical 24h | High 7d 監査準備状況 2.5h (80%) 73% 準備率 90% 92% ✓ 完了: 92% | ⚠ 進⾏中: 6% | ✗ 未着⼿: 2% セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 340

341.

342.

343.

重要メトリクス 1: MTTR/MTTD の計測 - SQL -- MTTR（Mean Time To Remediate）計算 WITH vulnerability_metrics AS ( SELECT severity, AVG(EXTRACT(EPOCH FROM (resolved_at - detected_at))/3600) as mttr_hours, COUNT(*) as total_vulns, COUNT(CASE WHEN resolved_at IS NOT NULL THEN 1 END) as resolved_vulns FROM vulnerabilities WHERE detected_at >= NOW() - INTERVAL '30 days' GROUP BY severity ) SELECT severity, ROUND(mttr_hours, 2) as mttr_hours, ROUND(resolved_vulns::numeric / total_vulns * 100, 2) as resolution_rate FROM vulnerability_metrics ORDER BY CASE severity WHEN 'Critical' THEN 1 WHEN 'High' THEN 2 WHEN 'Medium' THEN 3 WHEN 'Low' THEN 4 END; セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 343

344.

[beta]

重要メトリクス 2: セキュリティスコアの算出
複数指標を統合した総合評価

class SecurityScoreCalculator:
def calculate_security_score(self, metrics):
weights = {
'vulnerability_score': 0.3,
'compliance_score': 0.2,
'incident_score': 0.2,
'patch_score': 0.15,
'training_score': 0.15
}
scores = {
'vulnerability_score': self.calc_vuln_score(metrics),
'compliance_score': self.calc_compliance_score(metrics),
'incident_score': self.calc_incident_score(metrics),
'patch_score': self.calc_patch_score(metrics),
'training_score': self.calc_training_score(metrics)
}
total_score = sum(scores[k] * weights[k] for k in scores)
return round(total_score, 2)

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

344

345.

Step 6: 業界標準と比較するもちろんセキュリティ投資や施策をかけれるなら多めにかけることに越したことはない。ただし、営利企業である以上、どこかで打ち止めを行ったり、必要最小限の投資に抑えて、必要な機能開発やメンバーへの還元などに適用すべきだ。その際に、業界における複数社の公開情報などを用いて施策の比較や投資金額の妥当性を図ることも大事である。セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 345

346.

347.

Step 7: PDCA サイクルで継続改善計画) - 1週間実⾏) - 4週間 Plan ( 活動: A P Act Check • • • • • セキュリティ施策実装ツール導⼊・設定プロセス改善実施チーム教育実施⾃動化推進改善) - 1週間活動: D 活動: 評価) - 1週間 Act ( Plan 継続的改善 C ⽬標設定リスク評価実施施策優先順位決定リソース配分計画タイムライン策定 • KPI • • • • Do ( • • • • • 改善点特定ベストプラクティス⽂書化プロセス標準化次サイクル計画⽴案ナレッジ共有 Check ( 活動: メトリクス収集達成度分析効果測定実施ギャップ分析レポート作成 • • KPI • • • Do セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 347

348.

349.

Step 7: PDCA サイクルで継続改善 - 詳細測定 → 分析 → 改善の繰り返し改善サイクルの例: フェーズ活動期間 Plan KPI 目標設定、施策計画 1 週間 Do セキュリティ施策の実装 4 週間 Check メトリクス収集・分析 1 週間 Act 改善点特定、次サイクル計画 1 週間セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 349

350.

351.

352.

メトリクスまとめ - 明日から始められることスモールスタートで成功体験を積む今すぐ始められる 3 つのアクション: まず 1 つの KPI から始める例: Critical 脆弱性の MTTR 測定 Excel で週次集計からスタート月次レポートを作成する経営層向けに 1 ページサマリーグラフで傾向を可視化改善目標を設定する現状値から 10%改善を目指す 3 ヶ月後に振り返り実施重要: 完璧を求めず、継続することが最も大切セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 352

353.

354.

355.

なぜセキュリティ ROI 評価が必要なのか - 2 ROI 評価の価値: 投資効果の可視化による予算確保リスクベースの優先順位付けビジネス言語での価値説明継続的な改善サイクルの実現学習目標: FAIR モデルによるリスク定量化手法/ 実践的な ROI 計算と分析/ 経営層向けプレゼンテーション技法/ 投資ポートフォリオ管理セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 355

356.

357.

358.

359.

360.

361.

FAIR モデルの基本構造 Factor Analysis of Information Risk - 主要コンポーネント: 1. Loss Event Frequency 国際標準リスク定量化フレームワーク（損失事象頻度）（脅威事象頻度）: 攻撃の発生回数 Vulnerability（脆弱性）: 攻撃成功確率 Threat Event Frequency 2. Loss Magnitude （損失規模）（一次損失）: 直接的な被害 Secondary Loss（二次損失）: 間接的な影響 Primary Loss 計算式: リスク = 頻度 × 影響度セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 361

362.

FAIR モデル実践例: SQL インジェクション WS 実際の EC サイトにおけるリスク定量化ケーススタディシナリオ設定: 中規模 EC サイト（年商 50 億円、会員数 100 万人） SQL インジェクション攻撃による顧客データ漏洩リスク出してもらいたいもの頻度分析セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 362

363.

FAIR 1. モデル実践例: SQL インジェクション - 1 頻度分析（Loss Event Frequency）脅威事象頻度: 年間 10 回の攻撃試行（業界データより）脆弱性（成功率）: 30%（セキュリティ対策実施済みだが完全ではない）損失事象発生頻度: 10 回 × 30% = 年間 3 回セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 363

364.

FAIR モデル実践例: SQL インジェクション - 2 損失規模分析（Loss Magnitude）一次損失（Primary Loss）- 直接的な被害: 2. システム復旧費用: 500 万円インシデント調査・対応: 300 万円業務停止による機会損失: 200 万円小計: 1,000 万円二次損失（Secondary Loss）- 間接的な影響: 規制当局への罰金（個人情報保護法）: 1,000 万円顧客離反による売上減少: 2,000 万円ブランド価値毀損・風評被害: 500 万円集団訴訟費用: 300 万円小計: 3,800 万円セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 364

365.

FAIR 3. モデル実践例: SQL インジェクション - 3 リスク計算件あたりの総損失: 4,800 万円年間期待損失: 3 回 × 4,800 万円 = 1 億 4,400 万円最悪シナリオ: 全顧客データ漏洩で 2 億 4,000 万円信頼区間（70%）: 1 億円〜2 億 1,600 万円 1 セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 365

366.

367.

セキュリティ ROI 計算フレームワーク基本計算式: ROI = (投資効果 - 投資コスト) / 投資コスト × 100 投資効果の構成要素: リスク軽減: 期待損失の削減額効率向上: 自動化による工数削減機会創出: ビジネス成長への貢献ブランド価値: 信頼性向上の金銭価値投資コストの内訳: 初期投資: ライセンス、実装、移行運用コスト: 保守、更新、人件費機会費用: 他の投資機会の喪失セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 367

368.

セキュリティ ROI 計算フレームワーク投資コスト投資効果初期投資 • • ライセンス・導⼊費⽤システム構築・移⾏ • • 保守・メンテナンス⼈件費・トレーニング • • 他投資機会の喪失リソース配分の変更運⽤コスト機会費⽤計算と分析 ROI リスク軽減 • • 期待損失の削減インシデント回避 • • ⾃動化による⼯数削減プロセス最適化 • • 競争優位性の確⽴ブランド価値向上効率向上時系列分析リスク調整投資回収期間累積推移・計算 • • ROI • NPV IRR ビジネス価値総投資コスト基本計算式投資効果 - 投資コスト) / 投資コスト) × 100 ROI (%) = (( • • • 確率加重分析感度分析シナリオ分析評価基準総投資効果 ROI > 300%: 優秀 | 200-300%: 良好 | 100-200%: 普通 | < 100%: 改善要継続的な効果測定とKPIダッシュボード財務指標 ROI: 投資収益率効率性指標年次推移累積期間・⾃動化率削減処理能⼒向上エラー率減少 • ROI • ROI • Payback • NPV IRR 計画運⽤指標 • • MTTR • • 実⾏評価リスク指標セキュリティ指標 • • • • 改善脆弱性密度インシデント頻度検知精度コンプライアンス価値指標 • • • • ビジネス指標顧客満⾜度市場評価競争優位性ブランド価値継続的改善サイクル重要ポイント: • • • ⽉次でのKPI追跡と四半期レビューベンチマークとの⽐較による相対評価予実分析による継続的な改善セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 368

369.

例: SAST 導入の ROI 詳細分析 - 3 年間の総合的な費用対効果分析初年度分析: コスト項目金額（万円）効果項目金額（万円）ライセンス費用 600 バグ削減効果 800 導入・構築費用 200 インシデント予防 3,000 トレーニング費用 100 生産性向上 500 運用費用 300 品質改善 300 合計コスト 1,200 合計効果 4,600 初年度 ROI: (4,600 - 1,200) / 1,200 × 100 = 283% セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 369

370.

例: SAST 導入の ROI 詳細分析 - 3 年間の総合的な費用対効果分析年目分析（年間）: コスト項目金額（万円）効果項目金額（万円）ライセンス費用 600 バグ削減効果 1,200 運用費用（効率化） 200 インシデント予防 3,500 生産性向上 800 品質改善 500 合計コスト 800 合計効果 6,000 2-3 年目 ROI: (6,000 - 800) / 800 × 100 = 650% 2-3 セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 370

371.

例: SAST 導入の ROI 詳細分析 - 3 年間の総合的な費用対効果分析 3 年間総括: 総コスト: 2,800 万円総効果: 16,600 万円純効果: 13,800 万円 3 年間 ROI: 493% 回収期間: 4.2 ヶ月内部収益率（IRR）: 215% セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 371

372.

373.

投資優先順位の決定フレームワーク - 1 つの評価軸による戦略的投資判断評価軸と重み付け: 評価軸重要度評価ポイント ROI（投資対効果） 30% 投資額に対するリターンの大きさリスク削減効果 25% 重大インシデントの防止能力回収期間 20% 投資額回収までの速さコンプライアンス 15% 法規制要件への対応度戦略的価値 10% ビジネス成長への貢献度 5 セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 373

374.

投資優先順位の決定フレームワーク - 2 優先度スコアリングの仕組み: 1. 各項目を 0-1 の範囲で正規化以上で満点回収期間: 6 ヶ月以内で満点リスク削減: 年間 1 億円以上で満点 ROI: 300% 2. 重み付け合計でスコア算出各評価軸のスコア × 重要度を合計最終スコアは 0〜1 の範囲セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 374

375.

376.

投資優先順位の決定フレームワーク - 4 実例: SAST 導入の評価スコア 0.94（0.30×0.94=0.28）リスク削減: 4,600 万円 → スコア 0.46（0.25×0.46=0.12）回収期間: 4.2 ヶ月 → スコア 1.00（0.20×1.00=0.20）コンプライアンス: 高 → スコア 0.80（0.15×0.80=0.12）戦略的価値: 中 → スコア 0.60（0.10×0.60=0.06）総合スコア: 0.78 → 年内実行推奨 ROI: 283% → セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 376

377.

378.

エグゼクティブサマリーの構成 - 1 ページで伝える投資価値セキュリティ投資提案書 - エグゼクティブサマリー ## 投資提案 **投資額:** 年間 1,200 万円（初年度 1,500 万円） **期待効果:** 年間 4,600 万円の価値創出 **ROI:** 283%（業界平均 150%を大幅に上回る） **回収期間:** 4.2 ヶ月 ## ビジネスインパクト **リスク削減:** 年間 1.4 億円の潜在損失を回避 **効率向上:** 開発生産性 20%向上（2,000 万円相当） **競争優位:** セキュリティ品質による差別化 **規制対応:** コンプライアンス要件 100%充足 ## 実装計画 # - Phase 1（1-2 ヶ月）: ツール選定と環境構築 Phase 2（3-4 ヶ月）: 段階的展開 Phase 3（5 ヶ月〜）: 全面運用と最適化 ## リスクと対策 - 技術的リスク: 低（実績豊富なソリューション）組織的リスク: 中（変更管理プログラムで対応）セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 378

379.

経営層向けプレゼンテーション戦略 - 1 ストーリーテリングによる説得力向上効果的なプレゼンテーション構成: スライド内容時間キーメッセージ 1. 現状認識競合他社のインシデント事例 2 分「明日は我が身」 2. リスク評価自社の潜在リスク（金額） 2 分「年間 10 億円のリスク」 3. 解決策投資提案の概要 3 分「投資対効果 3 倍」 4. 成功事例同業他社の成功例 2 分「実証済みの効果」 5. 実行計画段階的導入計画 2 分「リスクを抑えた展開」 6. 意思決定承認要請 1 分「今すぐ行動が必要」セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 379

380.

381.

ビジネス言語への変換テクニック技術的表現脆弱性対策性能改善自動化監視強化認証強化悪い例良い例「SQL インジェクション対策が必要」「顧客データ漏洩リスク（4.5 億円）を 99%削減」「レスポンスタイムを改善」「顧客満足度 10%向上、売上 2%増加見込み」「開発サイクル 50%短縮、年間 3,000 万円のコスト削「CI/CD パイプライン構築」減」「SIEM を導入」「インシデント検知時間を 48 時間 →30 分に短縮」「多要素認証を実装」「アカウント侵害を 95%防止、規制要件充足」セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 381

382.

383.

384.

385.

[beta]

投資効果の継続的モニタリング
class SecurityROIDashboard:
def __init__(self):
self.metrics = {}
def calculate_monthly_roi(self):
query = """
WITH investment_metrics AS (
SELECT
DATE_TRUNC('month', date) as month,
investment_type,
SUM(cost) as total_cost,
SUM(prevented_loss) as loss_prevented,
SUM(efficiency_gain) as productivity_gain,
COUNT(DISTINCT incident_prevented) as incidents_avoided
FROM security_investments
WHERE date >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY DATE_TRUNC('month', date), investment_type
)
SELECT
month,
investment_type,
total_cost,
loss_prevented + productivity_gain as total_benefit,
ROUND(((loss_prevented + productivity_gain - total_cost) /
NULLIF(total_cost, 0)) * 100, 2) as roi_percentage,
incidents_avoided
FROM investment_metrics
ORDER BY month DESC, roi_percentage DESC
"""
return self.execute_query(query)
def generate_executive_report(self):
return {
'ytd_roi': self.calculate_ytd_roi(),
'top_performing_investments': self.get_top_investments(),
'risk_reduction_trend': self.analyze_risk_trend(),
'forecast': self.predict_next_quarter(),
'recommendations': self.generate_recommendations()
}

セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025

385

386.

投資タイムラインと段階的実装 - 詳細長期的な投資計画 5 年間のロードマップ例: 年次フォーカス領域主要投資期待 ROI Year 1 基礎構築 SAST、WAF、基本監視 150% Year 2 検知強化 SIEM、SOC、SOAR 200% Year 3 高度化 AI/ML、脅威ハンティング 250% Year 4 統合ゼロトラスト、SASE 300% Year 5 最適化自動化、予測的防御 350% セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 386

387.

コスト・ベネフィット分析マトリクス - 詳細投資判断の可視化 4 象限分析: 低コスト・高効果（優先実施） Major Projects: 高コスト・高効果（計画的実施） Fill Ins: 低コスト・低効果（余力で実施） Question Marks: 高コスト・低効果（再検討） Quick Wins: セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 387

388.

セキュリティ投資の成熟度評価 - 1 組織の投資最適化レベル成熟度特徴投資アプローチ ROI Level 1: 反応的インシデント対応中心場当たり的 <50% Level 2: 準備的基本的な防御年次計画 50-100% Level 3: 予防的リスクベースポートフォリオ管理 100-200% Level 4: 最適化データ駆動継続的最適化 200-300% Level 5: 革新的ビジネス統合戦略的投資 >300% セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 388

389.

390.

391.

392.

セキュリティ ROI 評価まとめ重要な成功要因: リスクの定量化: FAIR モデルによる客観的評価 ROI 計算: 包括的な費用対効果分析優先順位付け: データ駆動の投資判断コミュニケーション: ビジネス言語での価値説明継続的改善: KPI による効果測定と最適化ビジネス価値の実現: 投資判断の透明性と説得力（予算承認率 80%向上）リスク削減と効率化（年間 ROI 200-300%）競争優位性の確立（セキュリティ = ビジネスイネーブラー）経営層の信頼獲得（戦略的パートナーシップ）次のステップ: 自社のリスク定量化（FAIR モデル適用）/投資ポートフォリオ設計 / KPI ダッシュボード構築 / 経営層への提案実施セキュリティ投資は『コスト』ではなく『戦略的投資』(損失回避のための投資) セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 392

393.

394.

事後課題にします(後でアナウンスします) 本講義内で解説をした脆弱性や設計のミスを題材に CTF 問題を提供します Flag の取得 + WriteUp の提出を考えています LLM やツールを使って脆弱性を発見することは推奨しますできる限り効率的に実施してください！修了後に URL とドライブ URL を提供するのでぜひ！ ※ 期間中は講義に集中してください！セキュリティ・キャンプ全国大会2025 - B2: 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう © 2025 394

395.

設計・開発・テストにおけるセキュリティの実践と考え方を知ろう

a_zara_n

関連スライド

AWS Dev Day 2023 E-2: Amazon S3・Amazon Cognito・AWS Lambdaのアンチパターンで学ぶセキュリティ・バイ・デザイン

コンテキストを読み解き進めるモダンWebセキュリティ入門 - 公開資料

え、私のFlagまるみえ!? クラウド問題やインフラにおける題設計ミスにみるクラウドセキュリティ(入門) - 魔女のお茶会 #7 おふらいん! (2025冬)

クラウドから落とされた汚れた贈り物

MCP Security introduction

Serverless ApplicationとSecurity 開発者だからこそしってほしいAmazon S3

各ページのテキスト

設計・開発・テストにおけるセキュリティの実践と考え方を知ろう

a_zara_n

関連スライド

AWS Dev Day 2023 E-2: Amazon S3・Amazon Cognito・AWS Lambdaのアンチパターンで学ぶセキュリティ・バイ・デザイン

コンテキストを読み解き進める モダンWebセキュリティ入門 - 公開資料

え、私のFlagまるみえ!? クラウド問題やインフラにおける題設計ミスにみるクラウドセキュリティ(入門) - 魔女のお茶会 #7 おふらいん! (2025冬)

クラウドから落とされた汚れた贈り物

MCP Security introduction

Serverless ApplicationとSecurity 開発者だからこそしってほしいAmazon S3

各ページのテキスト

コンテキストを読み解き進めるモダンWebセキュリティ入門 - 公開資料