An open-source infrastructure repository runs terraform plan in CI for every pull request, including pull requests from forks, and the plan job has access to cloud credentials so it can refresh real resources. What is the main risk, and the fix?
Select an answer to reveal the explanation.
Short Explanation
Here's the sneaky part: a plan runs the code in the pull request, and on a fork, that code was written by a stranger. Providers, data sources and external programs execute during plan, so a hostile change can quietly ship your credentials out. Keep credentials away from untrusted fork jobs and plan those only after a maintainer reviews them.
Full Explanation
terraform plan is not a passive read. It initializes the providers and modules named in the configuration, evaluates data sources, and can execute external programs, so whoever controls the configuration controls code running with the job's credentials. A pull request from a fork lets an outside contributor change that configuration, for example adding a data source or provider that sends environment variables to an attacker. Credentialed plans should run only for trusted branches, or after a maintainer has reviewed the change and explicitly approved a run, and fork jobs should run with no secrets, limited to formatting and validation. Treating plans as read-only ignores that arbitrary code executes during planning, and comment permissions do not affect credential theft. Plans do not apply changes, so locking state targets the wrong threat. Giving forks a long-lived key, even read-only, hands every contributor a credential to exfiltrate, and read access to state or resources may itself expose secrets. Exam caveat: CI triggers that run fork code in the base repository's privileged context are a known way to leak secrets. Operational check: open a test pull request from a fork and confirm the job runs without any cloud credentials or secrets in its environment.