Reviewing Buildkite for security
For Security and compliance reviewers, who will never write a pipeline
This path exists because reviewing a CI system and operating one are different jobs, and most CI documentation is written for the second.
You will not be asked to write a pipeline. The material covers where secrets should live and why, what `allowed-plugins` guarantees and what it does not, what possession of an agent token actually permits, and which questions the audit log can and cannot answer.
Two things are worth carrying into any review:
**A queue boundary is a secrets boundary.** The strongest form of "this job cannot reach that credential" is that the machine it ran on never had it.
**Fork builds on a public pipeline run untrusted code on your agents.** If the organisation has public pipelines, that configuration is one of the most consequential decisions in the estate.
Modules, in order
Keeping credentials out of pipelines, and constraining what a job is allowed to load.
Who can change what, who did change what, and the risks that arrive from outside the organisation.