In a CI pipeline, which parts of the triggering event are attacker-controlled, and which are not?

## The question behind the question Every CI job starts by reading an event: someone pushed, someone opened a pull request, someone commented, someone pushed a tag. The payload of that event is a mixture of two very different kinds of data, and the whole of expression injection begins with failing to separate them. **Attacker-controlled (free text a person supplied):** - the commit message and the commit body - the git author name, committer name, and both email addresses (these are whatever the contributor set locally; nothing verifies them) - the branch name and the tag name - a pull request title, description, and the name of the source branch - an issue body, an issue comment, a review comment - file paths and file contents in the diff **Platform-derived (not chosen by the submitter):** - the commit hash, and any tree or blob hash - the event name and the action that fired it - the base repository and organisation identifiers, the run identifier and attempt number - the timestamp the forge recorded A useful mental test: could I make this field say `hello"; whoami; #` by typing it? If yes, it is untrusted. ## Who the attacker is, and it is rarely the obvious person The positions differ per field, and that changes how much you should care. - **An anonymous internet user** can usually set a comment body, an issue body and a pull request description on a public repository. No account relationship with you is required. - **A low-privilege contributor** chooses the branch name of the pull request they open, and the commit message and author name of every commit in it. - **A colleague with write access** chooses tag names. "Only maintainers can push tags" narrows the attacker set; it does not empty it, and it does nothing against a compromised account or a bot token. - **A compromised automation account** — a bot that opens dependency pull requests, for example — supplies branch names and commit messages that no human ever reads. ## Validation is not a boundary The most common junior mistake is deciding a field is safe because the platform restricts it. Git ref names are the classic case: the ref grammar rejects spaces, control characters and a handful of symbols, so a branch cannot be called `my branch`. It can perfectly well be called `x$(id)` or ``x`id` `` or `x';whoami;'`. The characters that matter for command construction are almost all legal. The same reasoning applies to length limits, to "it must start with a letter", and to "our contributors are all employees". None of these were designed as security controls, and none of them survive an attacker who reads the grammar. ## Merging does not sanitize Engineers often assume that once a pull request is reviewed and merged, its metadata is trusted, so a job that runs on the default branch is safe. It is not. The merged commit carries the contributor's message and author name verbatim into the default branch's history. Reviewers read the diff; almost nobody reads the author field. A job triggered by the push to the default branch reads exactly the same untrusted strings, now with production-grade credentials in scope. ## Untrusted only matters at a sink Marking a field untrusted is not the same as banning it. The payload is genuinely useful — you want the branch name in a container tag, the author in a notification, the message in a changelog. The rule is about where the value is allowed to go: - **Safe:** passed to a program as an argument or through the process environment, written to a file with a serializer, printed as data. - **Dangerous:** substituted into a command line, a script body, a JSON or YAML document, a query, an HTML report, or any other text that something later parses as syntax. So the practical output of this triage is a short list — "these fields never get concatenated into anything" — that a reviewer can hold in their head. Everything else in this area is the consequence of that list being missing. ## In an interview Answer with the split, give two or three fields on each side, and volunteer the ref-name detail — it demonstrates that you understand why platform validation reassures people wrongly. Then close on the sink: the field is not harmful until something treats it as code.