クイズの説明
Month 4「セキュリティパイプラインを確立しよう」の卒業クイズです。DevSecOps、脅威モデリング、SAST/DAST/SCA、シークレット管理、ID管理、セキュリティメトリクスの全領域から出題します。
合格ライン: 80%（10問中8問正解）
問題
Q1. DevSecOpsの基本原則（Step 1）
DevSecOpsの3つの柱として正しい組み合わせはどれですか？
- A. コスト、品質、速度
- B. 文化（Culture）、自動化（Automation）、計測（Measurement）
- C. 予防、検知、対応
- D. 設計、実装、テスト
答えを見る
正解: B
DevSecOpsの3つの柱は、Culture（文化: セキュリティは全員の責任）、Automation（自動化: SAST/DAST/SCAのパイプライン統合）、Measurement（計測: MTTR、カバレッジ率等のメトリクス）です。この3つが揃わないとDevSecOpsは機能しません。文化なき自動化はツールの押し付けになり、計測なき改善は方向性を見失います。
Q2. 脅威モデリング（Step 1）
STRIDEモデルの「E（Elevation of Privilege）」に該当する攻撃として最も適切なものはどれですか？
- A. 攻撃者がDDoS攻撃でサービスを停止させる
- B. 一般ユーザーがURLパラメータを変更して管理者APIにアクセスする
- C. 攻撃者がHTTPSの通信を傍受して内容を読む
- D. ユーザーが「その操作はしていない」と否認する
答えを見る
正解: B
Elevation of Privilege（権限昇格）は、攻撃者が本来持っていない権限を不正に取得する攻撃です。一般ユーザーがURLパラメータを変更して管理者APIにアクセスする行為は、権限昇格の典型例（BFLA: Broken Function Level Authorization）です。A（DDoS）はDenial of Service、C（通信傍受）はInformation Disclosure、D（否認）はRepudiationに該当します。
Q3. SASTとDASTの使い分け（Step 2）
セキュリティテストピラミッドにおいて、SASTをPR作成時に、DASTをステージングデプロイ後に配置する理由として最も適切なものはどれですか？
- A. SASTの方がDASTより検出精度が高いため、先に実行する
- B. SASTは高速でフィードバックが早く開発者体験を損なわないが、DASTは実行中のアプリが必要で時間もかかるため後工程に配置する
- C. SASTは無料だがDASTは有料のため、コスト効率の観点で後工程にする
- D. SASTとDASTは同じ脆弱性を検出するため、二重チェックの意味で異なるタイミングに配置する
答えを見る
正解: B
セキュリティテストピラミッドでは「軽量で高速なテストを手前に、重量で網羅的なテストを後ろに」配置します。SASTはソースコードの解析のみで数分で完了し、PRのフィードバックとして適切です。DASTは実行中のアプリケーションに対してリクエストを送信するため、デプロイ済みの環境が必要で実行に数十分かかります。両者は補完関係にあり、SASTはコードレベルの問題（SQLインジェクション等）を、DASTはランタイムの問題（CORS設定ミス等）を検出します。同じ脆弱性を検出するわけではありません。
Q4. SBOMの活用（Step 2）
組織がSBOM（Software Bill of Materials）を生成・管理することの最も重要な利点はどれですか？
- A. アプリケーションのビルド時間を短縮できる
- B. ライセンスコストを削減できる
- C. 新しいCVEが公開された際に、影響を受けるシステムとバージョンを数分で特定できる
- D. 開発者が使用できるライブラリを制限できる
答えを見る
正解: C
SBOMの最も重要な利点は、新しい脆弱性（CVE）が公開された際に、SBOMを検索するだけで影響を受けるシステム・コンポーネント・バージョンを数分で特定できることです。Log4Shellのような緊急性の高い脆弱性が発見された場合、SBOMがなければ各チームに確認依頼を出して数日かけて影響調査する必要があります。SBOMにより、脆弱性対応のMTTD（検出時間）を劇的に短縮できます。
Q5. 動的シークレット（Step 3）
HashiCorp Vaultの動的シークレット（Database Secret Engine）で生成されるPostgreSQL認証情報の特徴として正しいものはどれですか？
- A. 一度生成された認証情報は永続的に有効で、手動で失効させる必要がある
- B. TTL（Time to Live）が設定されており、期限が切れると自動的にデータベースユーザーが削除される
- C. 生成される認証情報はすべてのアプリケーションで共有される
- D. 動的シークレットは読み取り専用で、データの書き込みには使用できない
答えを見る
正解: B
Vaultの動的シークレットで生成されるデータベース認証情報は、設定されたTTL（例: 1時間）後に自動的に失効します。具体的には、VaultがPostgreSQLに対して一時的なユーザーを作成し、TTL経過後にそのユーザーを自動的に削除（REVOKE）します。各アプリケーションインスタンスには固有の認証情報が発行されるため（Cは誤り）、「どのインスタンスが漏洩したか」の追跡も容易です。また、ロールの設定次第で読み書き両方の権限を付与可能です（Dは誤り）。
Q6. ゼロスタンディング権限（Step 3）
ゼロスタンディング権限環境で、深夜の重大障害発生時に承認者全員が不在の場合に使用する手順は何ですか？
- A. 障害が収まるまで待つ
- B. ブレイクグラス（Break Glass）手順で一時的な特権アクセスを取得し、事後レビューを実施する
- C. 開発者が自分のローカル環境でデータベースに直接アクセスする
- D. セキュリティポリシーを一時的に無効化する
答えを見る
正解: B
ブレイクグラス（Break Glass）手順は、ゼロスタンディング権限環境における緊急時のアクセス手段です。通常のJIT承認フローの承認者が不在の場合に、自動承認でアクセスを取得できます。ただし、(1) 使用時に全件アラートが発報される、(2) 24時間以内に事後レビューを実施する、(3) 不正使用は懲戒対象とする、という統制が設けられています。ゼロスタンディング権限を導入する際は、必ずブレイクグラス手順をセットで設計する必要があります。
Q7. OAuth 2.0 フロー（Step 4）
SPAからバックエンドAPIにアクセスする際に、Implicit Grant Flowではなく Authorization Code Flow with PKCEが推奨される理由として最も適切なものはどれですか？
- A. PKCEの方が実装が簡単だから
- B. Implicit GrantではアクセストークンがURLフラグメントに含まれ、ブラウザ履歴やRefererヘッダーで漏洩するリスクがあるから
- C. Implicit Grantではリフレッシュトークンが取得できるが、PKCEでは取得できないから
- D. PKCEの方が認証速度が速いから
答えを見る
正解: B
Implicit Grant Flowでは、アクセストークンがURLフラグメント（#access_token=xxx）として直接ブラウザに返されます。これはブラウザの履歴に残り、HTTPのRefererヘッダーで外部サイトに漏洩する可能性があります。Authorization Code Flow with PKCEでは、まず認可コードが返され、次にバックチャネルでコードをトークンに交換します。PKCEのcode_verifier/code_challengeにより、認可コードが横取りされてもトークンの取得を防止できます。なお、Cは逆で、Implicit Grantではリフレッシュトークンは取得できません。
Q8. マルチテナント認可（Step 4）
BtoB SaaSにおいて、テナント間のデータ漏洩を防ぐための「多層防御」として最も適切な組み合わせはどれですか？
- A. ファイアウォール + VPN + IPフィルタリング
- B. API Gatewayでのテナント検証 + OPAポリシー + PostgreSQL Row Level Security
- C. フロントエンドでのUI非表示 + APIのレート制限
- D. すべてのデータを暗号化 + ログの出力
答えを見る
正解: B
多層防御によるテナント分離は、複数のレイヤーでテナントIDの検証を行うことで、1つのレイヤーに不備があっても他のレイヤーでデータ漏洩を防ぐアプローチです。(1) API GatewayでJWTのtenant_idクレームを検証、(2) OPA（認可エンジン）でテナントIDとロールに基づくポリシーチェック、(3) PostgreSQL RLS（Row Level Security）でデータベースレベルでのフィルタリング。C（UI非表示）はフロントエンドのみの制御であり、APIを直接叩けばバイパスされます。D（暗号化）はテナント分離の手段としては不十分です。
Q9. セキュリティメトリクス（Step 5）
以下のセキュリティメトリクスデータから読み取れる最も重要な問題点はどれですか？
| 月 | 新規検出 | 修正完了 | オープン | MTTR(Critical) |
|---|---|---|---|---|
| 1月 | 62 | 45 | 180 | 72h |
| 2月 | 55 | 58 | 177 | 48h |
| 3月 | 48 | 52 | 173 | 36h |
- A. MTTRが改善しているので問題はない
- B. オープン脆弱性が173件も残っており、修正速度は改善しているが蓄積された「負債」の解消にはまだ時間がかかる
- C. 新規検出数が減っているため、SASTのルールが古くなっている可能性がある
- D. 修正完了数が毎月ばらついているため、チームの生産性に問題がある
答えを見る
正解: B
データを見ると、(1) MTTRは72h→48h→36hと改善中、(2) 新規検出は減少中（62→55→48）、(3) 修正完了は新規検出を上回っている月がある（2月: 58 > 55、3月: 52 > 48）、(4) しかしオープン脆弱性は173件と高水準。修正速度の改善（MTTR短縮）と修正量の増加（修正 > 新規）は良い兆候ですが、過去に蓄積された173件の「負債」の解消にはまだ時間がかかります。現在のペースでは完全解消に約3年必要です。「負債解消スプリント」のような集中対応が必要かもしれません。
Q10. DevSecOps成熟度モデル（Step 5）
以下の組織の状態を読み、DevSecOps成熟度レベルとして最も適切なものはどれですか？
SASTとSCAがCI/CDパイプラインに統合されており、CriticalとHigh脆弱性はPRマージをブロックする。DASTは月1回手動で実行。シークレットスキャンは全リポジトリに導入済み。ただし、セキュリティメトリクスのダッシュボードは未構築で、MTTRのSLA目標も未設定。
- A. L2（Managed）— 基本的なツール導入、手動レビュー中心
- B. L3（Defined）— セキュリティがCI/CDに統合、ポリシーが定義されている
- C. L4（Measured）— メトリクスで計測、継続的改善サイクル
- D. L5（Optimized）— AI/ML活用、自動修復
答えを見る
正解: B
この組織はSAST/SCAがCI/CDに統合され、ゲートポリシー（Critical/Highでブロック）が運用されています。シークレットスキャンも全リポジトリに展開済みです。これはL3（Defined: セキュリティがCI/CDに統合され、ポリシーが定義されている）の特徴に該当します。ただし、ダッシュボードが未構築でMTTRのSLA目標が未設定であるため、L4（Measured: メトリクスで計測し継続的に改善）には到達していません。DASTが手動実行である点はL3の範囲内ですが、L4を目指すにはDASTの自動化とメトリクス計測が必要です。
結果
合格（8問以上正解）
Month 4「セキュリティパイプラインを確立しよう」を修了しました。DevSecOpsの基本原則から、SAST/DAST/SCA、シークレット管理、ID管理、セキュリティメトリクスまで、エンタープライズレベルのセキュリティパイプライン設計の知識を習得しました。
あなたが身につけたスキル：
- 脅威モデリングに基づくセキュリティ要件の体系的な定義
- SAST/DAST/SCAをCI/CDパイプラインに統合した自動化セキュリティテスト
- HashiCorp Vault等を活用したシークレット管理基盤の設計
- ゼロトラスト原則に基づくID管理基盤の構築
- セキュリティメトリクスの定義と成熟度モデルによる継続的改善
不合格（7問以下正解）
全体を復習しましょう。特に間違えた問題に対応するStepを重点的に見直してください：
- Q1-Q2: Step 1（DevSecOps基本原則、脅威モデリング）
- Q3-Q4: Step 2（SAST/DAST/SCA、SBOM）
- Q5-Q6: Step 3（シークレット管理、ゼロスタンディング権限）
- Q7-Q8: Step 4（OAuth 2.0、マルチテナント認可）
- Q9-Q10: Step 5（セキュリティメトリクス、成熟度モデル）
推定所要時間: 30分