In indirect poisoned pipeline execution, which repo files are executable inputs that reviewers read as config?

### The question a reviewer never asks For every file in a diff, there is one security-relevant question: **does the build execute this, or only read it?** Most engineers assume that only files with a source extension are executable, and that everything else is settings. In a modern repository that assumption is wrong for a large fraction of the tree, and indirect poisoned pipeline execution lives entirely in the gap. ### The categories of executable input **1. Build definitions that are actually programs.** In several major ecosystems the build file is written in a general-purpose or near-general-purpose language: a JVM build script in a Kotlin or Groovy DSL, a Makefile, a Python packaging script, an MSBuild target file. These are configuration-shaped and Turing-complete. Anyone who can edit one can run arbitrary code at build time, and in a monorepo the build file often sits outside whatever paths the team thinks of as sensitive. **2. Task-runner files behind a one-word entrypoint.** Pipelines are usually written to invoke a single verb — run the build, run the CI task — and the repository decides what that verb means. If the CI entrypoint of a Rails application is `bundle exec rake ci`, then the task-runner file is the pipeline, functionally, and it has none of the pipeline definition's protection. Adding a task, or changing what the existing `ci` task depends on, is a code change disguised as project plumbing. **3. Quality-gate configuration that loads plugins.** Lint and test configuration files frequently declare plugins or extensions that the runner then loads from the repository or from a resolved package. The linter's job is to run over the whole tree with whatever plugins it was told to load, so a plugin declaration is a request to execute code. It is a particularly comfortable hiding place because the diff reads as an improvement to the team's own standards. **4. Dependency-manager lifecycle hooks.** Restore and install phases run hooks in most ecosystems. In a .NET line-of-business repository, a shared build-properties file picked up automatically by every project can register a target that runs during package restore. The executable input is then two layers away from anything a reviewer of the feature would look at, and it fires on a phase — restore — that nobody thinks of as running repository code. It also fires early, often before any test or scan step the team believes is protecting them. **5. Code generation and vendored generated files.** A generator invoked during the build is code. A checked-in generated file that a later step compiles is code with the additional advantage that nobody reads generated diffs. ### Why this variant beats good review Three things stack up. The change is small, so it looks like housekeeping. The file lives in a directory the feature reviewer has no context for, so the reviewer defers. And the semantics are indirect: reading `<Target Name="..." AfterTargets="Restore">` or a new entry in a plugin list does not visibly say *this runs a shell command*, so even a careful reader has to know the ecosystem's execution model to see it. The attacker position that fits this best is not an anonymous outsider — it is a contributor who legitimately has commit rights and whose changes are expected. On an internal HR portal repository, that contributor's payload runs on a runner that can reach employee personal data; on a line-of-business repository it runs with the restore-time credential and a checkout of source that is itself the asset. ### Controls that actually apply - **Inventory the executable inputs.** Write down, per repository, which files the build parses, loads or hooks. If the team cannot produce that list, they cannot review these changes on purpose. - **Path-scoped required review.** Make changes under those paths require approval from a named owner, independent of the feature reviewer. This is the control that maps directly onto the attack, and it is worth its friction cost precisely because the file set is small. - **Do not let unreviewed refs reach a credentialed job.** Even a perfectly hidden payload is worth much less in a job with a read-only token, no secrets, and an ephemeral runner. Preventing execution entirely is hard; making execution worthless is achievable. - **Split the pipeline.** Build arbitrary branches unprivileged; do privileged work in a job that only trusted refs and an approval can reach. - **Detection as a backstop.** Alert on the first appearance of a build-affecting file in a repository that never had one, on network egress from a build job, and on credential use from an unexpected ref. These are detective controls and they arrive after execution — useful, but never the primary defence. ### The test to carry into a review For each file in the diff: is this parsed by an interpreter, loaded as a plugin, or run as a hook during the build? If yes, review it as code — regardless of its extension.