午前I問題
ソースコードリポジトリにAPIキーやパスワードなどの認証情報（シークレット）を平文でハードコーディングすることのリスクを軽減する対策として、最も適切なものはどれか。
ア）リポジトリをプライベート設定にすれば、シークレットを直接コードに記述してもよい
イ）シークレットはコードから分離し、シークレット管理サービスや環境変数経由で注入する
ウ）シークレットをBase64エンコードしてからコードに埋め込めば、暗号化と同等の安全性が得られる
エ）コミット履歴をgit rebaseで書き換えられるため、シークレットが漏洩しても後から削除すれば問題ない
午前I の解答・解説を見る
正解： イ）シークレットはコードから分離し、シークレット管理サービスや環境変数経由で注入する
解説：
- ア）不正解。プライベートリポジトリであっても、権限を持つ第三者への共有・アクセストークンの流出・誤ってパブリックに変更した場合など漏洩経路は存在する。プライベート設定はハードコーディングのリスクを消さない。
- イ）正解。HashiCorp VaultやAWS Secrets Manager等のシークレット管理サービスにシークレットを保管し、実行時に環境変数やアプリケーションから動的に取得することで、ソースコード自体にはシークレットを含めない設計が最も適切。
- ウ）不正解。Base64エンコードは可逆変換に過ぎず暗号化ではない。誰でもデコードでき、安全性の向上には全く寄与しない。
- エ）不正解。一度リモートリポジトリにpushされたシークレットは、他者がクローン・フォーク・キャッシュしている可能性があり、履歴を書き換えても漏洩の事実は消えない。漏洩したシークレットは無効化（ローテーション）が必須。
午前II問題
CI/CDパイプラインにおけるSAST（静的解析）とシークレットスキャンの組み込みに関する記述のうち、最も適切なものはどれか。
ア）シークレットスキャンはビルド成果物（バイナリ）のみを対象とし、ソースコードのコミット差分は対象外である
イ）SASTはコンパイル済みバイナリを実行してファジングを行うことで脆弱性を検出する手法である
ウ）プルリクエスト作成時にシークレットスキャンを実行し、検出時にマージをブロックすることで、シークレットのメインブランチへの混入を未然に防止できる
エ）シークレットスキャンで機密情報が検出された場合、当該コミットを削除するだけでよく、検出された認証情報自体のローテーションは不要である
午前II の解答・解説を見る
正解： ウ）
解説：
- ア）不正解。シークレットスキャンツール（例：gitleaks、TruffleHog）はコミット差分やリポジトリ全履歴を正規表現・エントロピー解析で走査するのが主目的であり、バイナリのみを対象とするものではない。
- イ）不正解。設問の記述はファジングを用いたDAST寄りの動的テストの説明であり、SASTはソースコード・中間コードを実行せず静的に解析する手法である。
- ウ）正解。プルリクエスト（マージリクエスト）のタイミングでシークレットスキャンをCIジョブとして実行し、検出時にステータスチェック失敗としてマージを強制的にブロックする運用は、メインブランチへのシークレット混入を防ぐ効果的なシフトレフト施策である。
- エ）不正解。コミット削除やhistory書き換えを行っても、既にpush・共有された時点でシークレットは漏洩したとみなすべきであり、当該認証情報の失効・再発行（ローテーション）が必須の対応となる。
午後問題
Webサービスを提供するC社では、GitHubとGitHub Actionsを用いてCI/CDパイプラインを構築している。ある朝、セキュリティ監視ベンダーから「公開リポジトリのコミット履歴内にAWSアクセスキーが平文で含まれている」という通報を受けた。
調査の結果、次の事実が判明した。
- 半年前、開発者がローカルでの動作確認用に
.envファイルへAWSアクセスキーを記述し、誤ってgit add .でステージングしてコミット・pushしてしまっていた - リポジトリは元々プライベートだったが、3か月前にOSS公開の方針転換でパブリックリポジトリに変更されていた
- CIパイプラインにはシークレットスキャンツールが導入されておらず、コミット内容のチェックは行われていなかった
- 該当のAWSアクセスキーには、S3バケットへのフルアクセス権限が付与されたままだった
設問1
C社が直ちに実施すべき初動対応を、優先度の高い順に2つ挙げよ。
設問1の解答・解説を見る
正解例：
- 漏洩したAWSアクセスキーを即座に無効化（削除・失効）し、新しいキーを再発行する
- AWS CloudTrail等の証跡ログを確認し、当該キーによる不正アクセス・不正操作（S3バケットからのデータ持ち出し等）の有無を調査する
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 漏洩キーの無効化・再発行に言及 | 「キーの失効」「ローテーション」「無効化」 | 6点 |
| 影響調査（ログ確認）に言及 | 「CloudTrail」「アクセスログ」「不正利用の有無確認」 | 6点 |
| 優先順位（まず失効、次に調査）の妥当な説明 | 被害拡大の即時停止を最優先とする論理 | 3点 |
コミット履歴からのシークレット削除（git filter-repo等）は再発防止・後始末の一環ではあるが、既に公開された情報である以上、キーの失効が完了するまでは削除だけでは無意味である点に触れられていればさらに加点対象とする。
設問2
C社は再発防止策として、CI/CDパイプラインへの技術的対策を導入することにした。導入すべき対策を2つ挙げ、それぞれの効果を述べよ。
設問2の解答・解説を見る
正解例：
-
プレコミットフック・CIパイプラインへのシークレットスキャンツール導入 gitleaksやTruffleHogなどのツールをpre-commitフックおよびGitHub Actionsのワークフローに組み込み、コミット・プルリクエスト時に高エントロピー文字列やAPIキーのパターンを自動検出してpush・マージをブロックする。
-
シークレット管理サービスの利用とIAM権限の最小化 AWS Secrets ManagerやGitHub Actions Secretsを用いてシークレットをコードから分離し、実行時に注入する。また、付与するIAMロールの権限をS3フルアクセスではなく必要最小限（該当バケットへの読み取りのみ等）に制限し、万一漏洩した場合の被害範囲を限定する（最小権限の原則）。
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| シークレットスキャンの自動化に言及 | 「pre-commitフック」「CI組み込み」「マージブロック」 | 6点 |
| シークレット管理サービス・環境分離に言及 | 「Secrets Manager」「コードからの分離」 | 5点 |
| 最小権限の原則に言及 | 「IAM権限の最小化」「被害範囲の限定」 | 4点 |
「二度と.envをコミットしない」のような属人的な運用ルールのみの回答は、技術的対策として不十分であり部分点に留める。
重要キーワード
| 用語 | 説明 |
|---|---|
| CI/CDパイプラインセキュリティ | ビルド・テスト・デプロイを自動化するCI/CDパイプラインに、セキュリティ検査を組み込む考え方 |
| シークレットスキャン | ソースコードやコミット履歴からAPIキー・パスワード等の機密情報を検出するツール・手法 |
| 監査ログ | システムやクラウドサービスへのアクセス・操作を記録するログ。インシデント調査の証跡として利用 |
| 最小権限の原則 | アカウントやサービスに付与する権限を、業務上必要な最小限に限定するセキュリティ設計原則 |
| キーローテーション | 認証情報（APIキー・パスワード等）を定期的、または漏洩時に速やかに失効・再発行すること |
| プレコミットフック | ローカルでのコミット実行前に自動チェックを走らせるGitの仕組み。シークレット混入の防止に活用される |
まとめ
- 午前I視点： シークレットのハードコーディングはBase64エンコードや履歴書き換えでは解決せず、コードからの分離・シークレット管理サービスの利用が根本対策である。
- 午前II視点： シークレットスキャンはプルリクエスト・コミット時にCIへ組み込み、検出時にマージをブロックする運用が実効性を持つ。SASTとの役割の違いも整理しておく。
- 午後視点： シークレット漏洩インシデントでは、まずキーの即時失効と影響調査を優先し、再発防止として自動スキャンの導入と最小権限設計を組み合わせるのが定石。