クイズの説明
Step 1「セキュリティ要件を体系化しよう」の理解度を確認します。DevSecOps、脅威モデリング、セキュリティ要件定義、コンプライアンスマッピングについて問います。
合格ライン: 80%（5問中4問正解）
問題
Q1. DevSecOpsの基本原則
DevSecOpsにおける「Shift Left」の考え方として最も適切なものはどれですか？
- A. セキュリティチームの人数を増やし、より多くのレビューを実施する
- B. セキュリティテストを開発ライフサイクルの早い段階に組み込み、問題を早期に検出する
- C. セキュリティ専用の環境を本番環境の左隣に配置する
- D. セキュリティツールのライセンスコストを開発部門の予算に移管する
答えを見る
正解: B
Shift Leftとは、セキュリティテストや検証をSDLC（ソフトウェア開発ライフサイクル）の早い段階（左側 = 上流工程）に移動させることです。要件定義や設計の段階で脅威モデリングを行い、実装段階でSASTを実行し、テスト段階でDASTを実施することで、リリース直前のゲートレビューに依存しない継続的なセキュリティ検証を実現します。リリース後に発見される脆弱性の修正コストは、設計段階の20倍以上とされており、Shift Leftの経済的メリットは非常に大きいです。
Q2. STRIDE脅威モデル
以下のセキュリティ上の問題は、STRIDEモデルのどのカテゴリに該当しますか？
攻撃者がAPIリクエストのパラメータを改ざんし、他のユーザーの注文金額を0円に変更した。
- A. Spoofing（なりすまし）
- B. Tampering（改ざん）
- C. Information Disclosure（情報漏洩）
- D. Elevation of Privilege（権限昇格）
答えを見る
正解: B
APIリクエストのパラメータを改ざんして金額を変更する行為は、Tampering（改ざん）に該当します。Spoofing（A）は他者になりすます行為、Information Disclosure（C）は情報の不正な閲覧、Elevation of Privilege（D）は権限を不正に取得する行為です。この事例では、データの完全性が損なわれており、対策としてはサーバーサイドでの金額再計算、デジタル署名、入力検証の強化が必要です。
Q3. セキュリティ要件の品質
以下のセキュリティ要件のうち、「受け入れ基準」として最も適切なものはどれですか？
- A. 「セキュリティを強化する」
- B. 「パスワードは十分に強いものにする」
- C. 「未認証のAPIリクエストに対してHTTP 401ステータスコードを返し、レスポンスボディにエラーメッセージを含める」
- D. 「セキュリティ対策を適切に実施する」
答えを見る
正解: C
受け入れ基準は「テスト可能」で「客観的に判定可能」である必要があります。Cは「未認証リクエスト → HTTP 401 + エラーメッセージ」という具体的な入力と期待される出力が明記されており、自動テストで検証できます。A「セキュリティを強化する」、B「十分に強い」、D「適切に実施する」はすべて曖昧で、何をもって達成とするかが判定できません。「テストできない要件は要件ではない」という原則を常に意識しましょう。
Q4. DREADリスクスコアリング
DREADモデルにおいて、以下の脆弱性のリスクスコアを計算してください。
| 評価軸 | スコア |
|---|---|
| Damage（被害の大きさ） | 9 |
| Reproducibility（再現性） | 8 |
| Exploitability（攻撃容易性） | 7 |
| Affected Users（影響範囲） | 10 |
| Discoverability（発見容易性） | 6 |
このリスクスコアと対応方針として最も適切なものはどれですか？
- A. スコア7.0 — High: 次スプリントで対応
- B. スコア8.0 — Critical: 即時対応必須
- C. スコア6.0 — Medium: 計画的に対応
- D. スコア9.0 — Critical: 即時対応必須
答えを見る
正解: B
DREADスコア = (9 + 8 + 7 + 10 + 6) / 5 = 40 / 5 = 8.0。スコア8.0以上はCriticalに分類され、即時対応が必要です。被害が大きく（9）、再現性が高く（8）、影響範囲が全ユーザー（10）であるため、この脆弱性は最優先で対処すべきです。DREADスコアは脅威の優先順位付けに有効ですが、組織のコンテキスト（ビジネスクリティカル度、既存の防御策等）も考慮した上で最終的な対応方針を決定します。
Q5. コンプライアンスマッピング
Compliance as Codeの目的として最も適切なものはどれですか？
- A. コンプライアンス要件をコードで定義し、自動的に準拠状況を検証することで、監査対応を日常業務に統合する
- B. 監査法人の代わりにAIが監査を実施できるようにする
- C. コンプライアンス違反を自動的に隠蔽し、監査をパスしやすくする
- D. セキュリティエンジニアの代わりにプログラマーがコンプライアンスを管理する
答えを見る
正解: A
Compliance as Codeは、OPA（Open Policy Agent）やcheckov等のツールを使ってコンプライアンス要件をコード（ポリシー）として定義し、CI/CDパイプラインで自動的に準拠状況をチェックするアプローチです。これにより、年1回の監査のためにドキュメントを慌てて整備するのではなく、日々の開発がそのまま監査証跡となります。監査法人を置き換えるもの（B）ではなく、監査時に「自動テストの結果」を証拠として提示できるようにするものです。
結果
合格（4問以上正解）
Step 1の内容をよく理解しています。DevSecOpsの基本原則、脅威モデリング、セキュリティ要件定義、コンプライアンスマッピングの知識を身につけました。次のStep 2「SAST/DAST/SCAを統合しよう」に進みましょう。定義した要件を自動で検証するパイプラインを構築します。
不合格（3問以下正解）
Step 1の内容を復習しましょう。特に以下のポイントを重点的に確認してください：
- Shift Left — セキュリティを開発の早い段階に組み込む意義
- STRIDE — 6カテゴリの脅威分類と具体例
- 要件の品質 — テスト可能で客観的に判定できる受け入れ基準
- Compliance as Code — ポリシーのコード化と自動チェック
推定所要時間: 15分