外部 PR を処理する CI の秘密
A 社は，OSS として公開しているリポジトリで CI を運用している。CI は，外部の開発者がフォークから送ったプルリクエスト（PR）に対しても自動的に起動し，PR のコードをビルドしてテストを実行する。テストの一部が外部の API を利用するので，CI のジョブには，その API のアクセストークンをシークレットとして環境変数で渡している。このとき想定すべき脅威への対策として，最も適切なものはどれか。
- ア外部の開発者からの PR のビルドとテストは，シークレットを読み取れず特権もない隔離された環境で実行し，シークレットを使うテストは保守担当者がコードを確認した後に実行する。
- イCI のログでシークレットの値が自動的にマスクされるように設定し，ジョブの出力からアクセストークンが読み取られないようにする。
- ウCI の定義ファイルを変更する PR は自動的に拒否し，それ以外の PR はこれまでどおり自動でビルドとテストを実行する。
- エPR を送る外部の開発者に多要素認証の設定を義務付け，アカウントの乗っ取りによる不正な PR を防ぐ。
正解と解説を見る
正解 ア
この問題の基礎知識
- CI（継続的インテグレーション）は，変更のたびにビルドとテストを自動実行する仕組みであり，ビルドスクリプト，テストコード，依存パッケージの設定などもリポジトリの内容として実行される。
- フォークからのプルリクエストのコードは信頼できない者が書いた可能性があり，そのコードを実行する環境で読み取れるシークレットは窃取され得る。
- ログのマスクは表示される値を伏せるだけで，コードが値を読み取って外部に送信することは防げない。多要素認証はアカウントの乗っ取りを防ぐが，正規のアカウントをもつ悪意のある者は防げない。
ア外部の開発者からの PR のビルドとテストは，シークレットを読み取れず特権もない隔離された環境で実行し，シークレットを使うテストは保守担当者がコードを確認した後に実行する。正解
PR のビルドスクリプトやテストコードは送った者が自由に書けるので，シークレットを渡した環境で実行すると窃取され得る。外部からの PR の CI はシークレットを読めない隔離環境で実行するか，書込み権限を持つ保守担当者の承認まで実行を遅らせる。
イCI のログでシークレットの値が自動的にマスクされるように設定し，ジョブの出力からアクセストークンが読み取られないようにする。
マスクはログに表示される値を伏せるだけである。PR のコードが環境変数からトークンを読み取り，攻撃者のサーバに送信したり，変換してから出力したりすれば防げない。
ウCI の定義ファイルを変更する PR は自動的に拒否し，それ以外の PR はこれまでどおり自動でビルドとテストを実行する。
定義ファイルを変えなくても，CI が実行するビルドスクリプト，テストコード，依存パッケージの設定などを PR で書き換えれば，任意のコードをシークレットにアクセスできる状態で実行できる。
エPR を送る外部の開発者に多要素認証の設定を義務付け，アカウントの乗っ取りによる不正な PR を防ぐ。
多要素認証はアカウントの乗っ取りを防ぐが，悪意のある者が自分のアカウントを正規に作成し，フォークから PR を送ることは防げない。想定すべきなのは信頼できない者が書いたコードの実行である。
検証用の出典出典照合済み
NIST SP 800-204D Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines ／ GitHub Docs: Securely using pull_request_target ／ GitHub Docs: Secure use reference（Using secrets）照合の根拠（4 件）
- ア（正解）: 外部からの PR の CI はシークレットを読めない隔離環境で実行するか，書込み権限を持つ保守担当者の承認まで遅らせる
run CI workflows in sandboxed environments without access to the network, any privileged access, or the ability to read secrets or b) have built-in protection that incorporates a delay in CI workflow runs until they are approved by a maintainer with write access.
NIST SP 800-204D · Section 3.2 PULL-PUSH-REQ-3（新しいタブで開きます） - ウ（誤り）・エ（誤り）: CI 定義を変えなくてもビルドスクリプトやテスト，依存関係を書き換えればシークレット付きで実行される。攻撃者はフォークから PR を開くだけでよく，アカウントの乗っ取りは要らない
An attacker only needs to open a pull request from a fork whose `Makefile` (or build script, test command, dependency, or configuration file) contains malicious commands. Those commands then run with the base repository's secrets and token.
GitHub Docs: Securely using pull_request_target · Understanding the risk（新しいタブで開きます） - イ（誤り）: 値を変換すればログの自動マスクは機能しないので，マスクだけでは窃取を防げない
Because there are multiple ways a secret value can be transformed, automatic redaction is not guaranteed.
GitHub Docs: Secure use reference · Using secrets（新しいタブで開きます） - ア（正解）: 想定すべき脅威は，悪意のある者が PR を送って CI/CD のシークレットを盗むこと
The repository owner may have improperly configured the repository, allowing malicious actors to submit pull requests with the intention of stealing secrets configured within a CI/CD pipeline.
NIST SP 800-204D · Section 3.1（新しいタブで開きます）
イの「攻撃者のサーバへの送信」はマスクがログの表示だけに作用することから論理的に排除される。