3.1. Governing Actions and Workflows at Scale
💡 First Principle: Every uses: line in every workflow is an invitation for someone else's code to execute inside your organization with your token — so governance at scale means deciding, centrally, which invitations are allowed and which automation everyone should be building from in the first place.
Why care: this is where a single compromised third-party action becomes an organization-wide incident rather than one repository's bad day. It's also where maintenance cost compounds — an org with no shared automation strategy writes the same deploy pipeline forty times and patches it forty times. Governance has a carrot (make the blessed path the easy path) and a stick (policy that blocks everything else), and mature organizations use both.
The two mechanisms map cleanly: templates and reusable workflows are the carrot, distributing known-good automation; Actions permissions policies are the stick, restricting what may run at all. Both are configurable at enterprise, organization, and repository level, with the outer scope constraining what inner scopes may choose.
⚠️ Common Misconception: "The policy setting Allow actions created by GitHub also covers verified Marketplace publishers." It does not. Those are two distinct checkboxes — GitHub-authored actions, and Marketplace actions from verified creators — and anything outside both requires an explicit allowlist entry. Expect at least one question that hinges on treating them as separate tiers.
