A deployment workflow is a privileged application.

Why is a deployment workflow part of the security boundary?#

A deployment workflow is part of the security boundary because it can translate repository events and executable code into changes to production. The relevant question is not only where a secret is stored. Ask whose input can influence a job, which code the job runs, which identity it receives, and which resources that identity can change. A build step with access to production authority is a privileged program even when its workflow file looks like ordinary configuration.

Create a job-level map rather than a repository-wide label such as trusted pipeline. Include contribution checks, artifact creation, release approval and deployment as separate steps. Record the event source, runner environment, executable dependencies, token permissions, target environment and outputs of each step. A repository may contain both untrusted contribution work and privileged release work. Reviewing those paths separately reveals where a file, artifact, cache entry or workflow input crosses from one authority level to another.

Separate untrusted contribution processing from privileged execution#

GitHub's secure-use guidance warns about privileged workflows that check out untrusted pull-request code, including relevant pull_request_target and workflow_run patterns. It also advises minimum token permissions and careful handling of artifacts from other workflows. The practical lesson is to examine the executable input, not just the event name: a release job that runs contributor-controlled code can expose its authority even if a previous validation job completed successfully.

For a proposed separation model, contribution jobs receive only the permissions required to inspect and test their inputs. A privileged job selects a reviewed revision and independently checks that the artifact belongs to that revision and expected workflow. It should not execute arbitrary scripts recovered from an untrusted artifact. Shared caches need the same scrutiny because they can become implicit inputs to later builds. Document any exception, its owner and the reason deployment authority is necessary; convenience alone is not an adequate explanation of the boundary.

Prefer short-lived workload identity with narrow trust conditions#

GitHub Actions can use OpenID Connect to present workflow identity claims to a supporting cloud provider, which validates its trust conditions before issuing short-lived cloud access. This can avoid duplicating long-lived cloud credentials as repository secrets. OIDC is an identity exchange, not a permission policy by itself. The accepted claims and resulting cloud role determine which workflow may obtain which authority.

Review the provider-supported subject, audience and relevant workflow or environment conditions. Compare those conditions with the actual release path, including reusable workflows and environment selection. An unintended repository or event should not obtain the production role. A permitted job should receive only its required resource operations. Reduced token lifetime and restricted role permissions solve different problems: an overprivileged token can still cause harm before it expires. Use a separate deployment identity for unrelated environments where their resources and approval requirements differ.

Compare credential models without confusing lifetime and authority#

Choose a credential model around the operations the job must perform and the identity controls the receiving service actually supports. Federation is often a useful direction, but a migration can leave other sensitive identities untouched: a release signing key, package registry credential or recovery account may still need a distinct lifecycle. A secret manager centralizes handling only when consumers and administrators use it with appropriate permissions and operational discipline.

The following table is a proposed review aid. For every credential, record an owner, consumer, destination, granted operations, expiry or replacement mechanism, and emergency revocation path. Do not collect the credential value into that inventory. A readable authority map should allow a reviewer to decide what a job could do without possessing the means to do it. Separate routine replacement from exposure response so a calendar-based rotation task does not delay containment of a suspected leak.

Review dependencies, runners and outputs as executable authority#

GitHub recommends pinning third-party actions to full commit identifiers and reviewing their source. Its guidance also notes that automatic secret redaction is not guaranteed, particularly when values are transformed. A stable dependency reference prevents an unnoticed version move; it does not establish that the selected code is safe. A masked log similarly does not establish that a secret never entered a process, artifact or unexpected destination.

Review what each execution step can read and write, including files, network services and shared runner state. Identify which caches or artifacts may outlive the job and who can retrieve them. Use synthetic markers, not production tokens, when validating log and artifact handling. Exercise both normal output and error paths: a failed command may print configuration that a successful command keeps quiet. A proposed runner review should also explain isolation between trust levels and how a compromised or contaminated environment is retired rather than merely reused after a successful cleanup message.

Fictional worked example: separate validation from release#

Consider the fictional service Northline Inventory. Its staging delivery process currently lets a contribution test job and a deployment job use the same runner group and a shared cloud credential. The authorized review uses a disposable repository, synthetic package contents and a cloud sandbox. The team first writes an authority map: contribution tests compile contributed code; release preparation selects a reviewed revision; deployment updates a named staging service. These are three different inputs and purposes, not one universally trusted pipeline.

The proposed redesign gives contribution tests no deployment identity and a separate runner boundary. A release job records the reviewed revision and artifact digest, then requests a short-lived role accepted only for the designated repository and staging environment. Deployment validates that selected artifact metadata before use. In the sandbox, an ordinary contribution cannot obtain the release role, a valid staging release can update only the staging resource, and a production target is denied. These fictional acceptance tests verify named boundaries without demonstrating a method for compromising a real runner.

Fictional worked example: rehearse exposure and replacement#

Northline also has a test package-publishing secret that cannot yet use federation. The team deliberately treats a disposable version as exposed during the exercise. Its incident worksheet names the registry owner, affected test repository, permitted publishing scope and revocation procedure. The owner revokes the dummy credential, verifies that its previously permitted operation is rejected, provisions a replacement with the same narrow scope, and checks a legitimate staging publish. The workflow records identifiers and outcomes, never the values themselves.

The exercise then makes the routine delivery job unavailable. Recovery must still be possible through an independently approved owner path; otherwise the team would need the compromised pipeline to replace its own credential. A sanitized review records how existing artifacts were inspected, which runner state was discarded, and how normal release work resumed. The lesson is specific: ownership and verification made this fictional recovery understandable. It is not evidence that Northline, or any real organization, has achieved complete pipeline security.

Plan creation, replacement, revocation and expiry before exposure#

OWASP's secrets-management guidance distinguishes creation, rotation, revocation and expiration. Removing a visible value from a repository or log does not make an issued credential unusable. Suspected exposure needs an owner-led decision about revocation or replacement, consumers, affected resources and recovery. The objective is to verify that the old authority is no longer usable, not simply to make the evidence disappear from one interface.

Document how a secret reaches its consumer, where it may be retained and how a consumer learns of replacement. Rotation can fail operationally when a forgotten worker or external integration still uses the old value. Test the transition with dummy identities and observe the receiving system's decisions. Protect retained incident evidence through a restricted channel, and avoid copying secrets into tickets as a coordination shortcut. Distinguish machine credentials from user-password policy; this pipeline guide does not recommend indiscriminate periodic password changes for people.

Verification checklist, tradeoffs and next steps#

Start with the deployment path that has the largest consequence, not every repository at once. Review one job's input, execution and identity from event to final resource change. Then test the rejected path as well as the permitted deployment. Keep the findings bounded: an OIDC denial verifies that particular trust condition, while a successful staging deployment verifies a particular role and operation. Neither result establishes that all dependencies, administrators or recovery accounts are appropriately controlled.

Stronger boundaries can increase runner cost, release latency and maintenance work. Pinning requires deliberate updates; federation requires understanding provider claims; isolated runner groups require reliable provisioning. Make those tradeoffs visible and assign ownership instead of reverting to a shared credential whenever work becomes inconvenient. The next useful deliverable is a job authority map, an exception register and a rehearsed recovery procedure. Revisit them after workflow, dependency or environment changes rather than assuming a one-time review stays current.

• List triggers, executable inputs, job identities and permitted target resources.
• Keep untrusted contribution execution separate from privileged release work.
• Validate the accepted federation claims against positive and negative test cases.
• Review action source and full commit pins through a controlled update process.
• Inspect logs, artifacts and shared state with synthetic markers, including failures.
• Record secret owners and consumers without copying credential values.
• Rehearse old-credential denial and legitimate recovery outside the failed pipeline.