GitHub Workflow

Design workflows as executable security boundaries, not only automation YAML.

A workflow decides when code runs, whose code/data is trusted, what credentials exist, where execution happens, and what later workflows may consume. Treat those decisions as part of the implementation.

Start with the trust map

Before editing YAML, identify:

• trigger and initiating actor;
• whether the event can be influenced by forks, external contributors, issue/comment text, branch names, tags, artifacts, or other workflows;
• which repository/ref is checked out and whether that code is trusted at execution time;
• effective GITHUB_TOKEN permissions and any additional credentials;
• environment secrets, approvals, deployment targets, and OIDC identities;
• runner type and what network/filesystem state it can reach;
• caches, artifacts, outputs, and reusable workflows crossing into later jobs or runs.

Do not infer trust from where a workflow file lives. Trust follows the event, ref, data, credentials, and execution path.