Q1. DevSecOpsの「Shift Left」とは何を意味するか?
A. セキュリティテストをリリース後に行うこと B. セキュリティを開発ライフサイクルの早い段階に組み込むこと C. セキュリティチームを開発チームの左隣に配置すること D. 左から右へのデプロイパイプラインを構築すること
答えを見る
正解: B
Shift Leftとは、セキュリティテストを開発ライフサイクルの早い段階(左側)に移すことを意味します。従来はリリース直前にセキュリティレビューを行っていましたが、この時点での修正は高コストです。要件定義→設計→実装→テスト→リリースの流れの中で、できるだけ早い段階でセキュリティチェックを行うことで、修正コストを1/100に削減できるとされています。
Q2. SASTとDASTの違いとして正しいのはどれか?
A. SASTは実行中のアプリケーションをテストし、DASTはソースコードを解析する B. SASTはソースコードを静的に解析し、DASTは実行中のアプリケーションを動的にテストする C. SASTはオープンソースの脆弱性を検出し、DASTはライセンス違反を検出する D. SASTとDASTは同じ手法の別名である
答えを見る
正解: B
- SAST(Static Application Security Testing): ソースコードやバイトコードを実行せずに解析し、脆弱性を検出します。SQLインジェクション、XSS、バッファオーバーフロー等を早期に発見できます。ツール例: Semgrep, SonarQube, CodeQL
- DAST(Dynamic Application Security Testing): 実行中のアプリケーションにHTTPリクエストを送信して、レスポンスから脆弱性を検出します。ランタイムの設定ミスや認証の不備を発見できます。ツール例: OWASP ZAP, Burp Suite
両者は補完関係にあり、どちらか一方だけでは十分ではありません。
Q3. SCA(Software Composition Analysis)の主な目的はどれか?
A. ソースコードの静的解析 B. コンテナイメージの脆弱性スキャン C. オープンソース依存関係の脆弱性とライセンスの検出 D. ネットワークトラフィックの分析
答えを見る
正解: C
SCA(Software Composition Analysis)は、プロジェクトが使用するオープンソースライブラリとその依存関係の脆弱性を検出するツールです。具体的には以下を行います。
- 既知の脆弱性(CVE)の検出: NVD、GitHub Advisory等の脆弱性データベースと照合
- 推移的依存関係の分析: 直接依存だけでなく、間接的な依存関係も含めてチェック
- ライセンスコンプライアンス: GPL等のコピーレフトライセンスの検出
- SBOM生成: ソフトウェアの構成要素の一覧化
ツール例: Snyk, npm audit, FOSSA
Q4. コンテナセキュリティのベストプラクティスとして正しくないのはどれか?
A. Distrolessベースイメージを使用する B. rootユーザーでコンテナを実行する C. マルチステージビルドでビルドツールを最終イメージから除外する D. イメージにCosignで署名し、デプロイ時に検証する
答えを見る
正解: B
コンテナをrootユーザーで実行することは、セキュリティ上のリスクです。コンテナからの脱出(container escape)に成功した場合、ホスト上でroot権限を取得できる可能性があります。ベストプラクティスは以下の通りです。
- 非rootユーザーで実行:
USER nonroot:nonroot - Distrolessイメージ: 不要なパッケージを排除して攻撃面を最小化(A)
- マルチステージビルド: ビルドツールを最終イメージに含めない(C)
- イメージ署名: Cosign/Notaryで署名し、改ざんを防止(D)
- 読み取り専用ファイルシステム:
readOnlyRootFilesystem: true
Q5. Policy as Code(OPA/Rego)の主な利点はどれか?
A. インフラのプロビジョニングを自動化する B. セキュリティポリシーをコードとして管理し、CI/CDで自動的に適用する C. アプリケーションのパフォーマンステストを行う D. データベースのマイグレーションを管理する
答えを見る
正解: B
Policy as Codeは、セキュリティポリシーやコンプライアンス要件をコード(Rego言語等)として記述し、CI/CDパイプラインで自動的に適用する手法です。利点は以下の通りです。
- バージョン管理: ポリシーの変更履歴を追跡可能
- 自動適用: Terraform planの検証、K8sのAdmission Controlで自動ブロック
- 一貫性: 全チーム・全環境で同じポリシーを適用
- テスト可能: ポリシー自体のユニットテストが可能
- 監査対応: ポリシーの変更理由を記録
ツール: OPA(Open Policy Agent)、Sentinel(HashiCorp)、Kyverno(K8s)
Q6. SBOM(Software Bill of Materials)の説明として正しいのはどれか?
A. ソフトウェアのビルド手順を記載したドキュメント B. ソフトウェアに含まれる全コンポーネント(依存関係含む)の一覧 C. ソフトウェアのテスト結果レポート D. ソフトウェアのデプロイメント設計書
答えを見る
正解: B
SBOM(Software Bill of Materials)は、ソフトウェアに含まれる全コンポーネントの一覧です。製造業のBOM(部品表)の概念をソフトウェアに適用したものです。以下の情報を含みます。
- コンポーネント名とバージョン
- ライセンス情報
- サプライヤー情報
- 依存関係の階層構造
主な形式: SPDX、CycloneDX ツール: Syft、Anchore、Trivy
2021年の米国大統領令(EO 14028)により、米国政府への納入ソフトウェアにはSBOMの提供が義務化されました。
Q7. Kubernetes Pod Security Standards の「Restricted」レベルで要求されるのはどれか?
A. 特権コンテナの許可 B. HostPathボリュームの使用 C. 非rootユーザーでの実行と権限昇格の禁止 D. ホストネットワークの使用
答えを見る
正解: C
Pod Security Standardsの3レベル:
- Privileged: 制限なし(開発環境向け)
- Baseline: 基本的な制限(特権コンテナ禁止、HostPath禁止)
- Restricted: 最も厳格。以下を要求:
- runAsNonRoot: true(非rootユーザーでの実行)
- allowPrivilegeEscalation: false(権限昇格の禁止)
- capabilities.drop: [ALL](全ケーパビリティの削除)
- readOnlyRootFilesystem: true(読み取り専用FS推奨)
- seccompProfile.type: RuntimeDefault
A, B, DはいずれもRestricted レベルで禁止されている設定です。
Q8. Checkovの主な用途として正しいのはどれか?
A. ソースコードの静的解析(SAST) B. コンテナランタイムの監視 C. IaC(Terraform/CloudFormation等)のセキュリティスキャン D. ネットワークの脆弱性スキャン
答えを見る
正解: C
Checkovは、Infrastructure as Code(IaC)のセキュリティスキャンツールです。以下のフレームワークに対応しています。
- Terraform
- CloudFormation
- Kubernetes YAML
- Dockerfile
- ARM Templates
- Serverless Framework
チェック内容の例:
- S3バケットのパブリックアクセス設定
- セキュリティグループの過剰な開放
- RDSの暗号化設定
- IAMポリシーのワイルドカード
- VPCフローログの有効化
Bridgecrew社(現Palo Alto Networks)が開発しており、1000以上の組み込みチェックルールと、Pythonによるカスタムポリシーの記述が可能です。
合格基準
- 合格スコア: 80%(8問中7問以上正解)
- 不合格の場合は、Step 3の各レッスンを復習してください
推定読了時間: 15分