How would you govern which third-party GitHub Actions the repositories in your organization may run?

## Why this is a governance question at all When a workflow step references someone else's action, that code runs on your runner, in your job, with the job's `GITHUB_TOKEN` and any secrets the step can see. There is no sandbox between it and the rest of the job. A popular action is therefore a dependency with unusually direct blast radius, and the compromise pattern is well understood: an attacker gains control of an action's repository, moves a version tag to malicious code, and every workflow referencing that tag picks it up on its next run. ## The organization-level policy GitHub exposes an Actions policy at organization level (and above it, at enterprise level) with escalating tiers: 1. **Disable Actions** entirely for the organization's repositories. 2. **Allow all actions and reusable workflows** — the permissive default. 3. **Allow only actions and reusable workflows from this organization or enterprise** — everything third-party is blocked, which forces vendoring. 4. **Allow those plus selected others**, with checkboxes for actions created by GitHub and for actions from Marketplace verified creators, plus a free-text allow-list. The allow-list accepts patterns: a specific version of a specific action, all versions of one action, or every action from one owner. Enterprise policy constrains what organizations may choose, and an individual repository cannot re-enable something the organization has blocked — the hierarchy only tightens as it descends. Tier 4 is where most large organizations land. Tier 3 sounds appealing but means every trivial helper must be forked into the organization and maintained there, which shifts the burden rather than removing it. ## Pinning to a commit SHA Policy decides *which* actions may run; pinning decides *which code* runs under that name. Referencing an action by a moveable tag means trusting the maintainer's account and GitHub's tag semantics forever. Referencing a full commit SHA means the bytes you reviewed are the bytes that execute. The cost is real: pinned SHAs do not receive fixes on their own, so pinning is only responsible when paired with an automated update flow that opens pull requests to advance the pins. That is the trade to state explicitly — pinning without maintenance converts a supply-chain risk into a stale-dependency risk. ## Complementary levers - **Default `GITHUB_TOKEN` permissions.** Setting the organization default to read-only means an action that wants to write must be given that ability in the workflow, where a reviewer sees it. This is the cheapest high-leverage control on this list. - **Fork pull-request approval.** Requiring approval before workflows run for outside contributors' pull requests prevents drive-by execution on your runners, and matters more if you use self-hosted runners. - **Reviewing `.github/workflows/`.** Treat that directory as privileged code: require ownership review on it so adding a new third-party action is a decision someone signed off on. - **Vendoring the critical few.** For the handful of actions in your deployment path, forking into the organization gives you control of the code and pairs naturally with an organization-only or allow-list policy. ## Rolling it out without a revolt Start by measuring: inventory which actions are actually referenced across repositories and at which versions. Publish the policy tier you intend, with a migration window and a fast path for adding an action to the allow-list — if approval takes a week, teams will route around you. Turn the policy on in audit-minded stages, starting with the repositories that deploy to production, and pair every restriction with the automation that keeps pins current so the strictness does not decay into a backlog. ## What an interviewer is listening for Not a list of menu items. They want to hear that you know a third-party action is arbitrary code with your credentials; that the platform gives you a tiered allow-list you can set once at organization level and cannot be loosened below; that pinning to a SHA is the control that survives a maintainer compromise; that read-only default token permissions limit what a bad action can do even when it runs; and that the whole programme collapses if there is no maintained path to update pins and add approved actions quickly.