A deployment token appears as *** in your build log. The deployment succeeds. That tells you the job could use the token and the log concealed that occurrence of its value. It says nothing about where else the running code could send it. GitHub's secure-use guidance, reviewed September 18, 2026, also warns that automatic redaction is not guaranteed when secret values are transformed.
For a small team reviewing its release pipeline, the useful starting point is the credential that can change production. Find the job that receives it, then work backward through the code and inputs that job trusts. A list of enabled security settings cannot answer that question on its own.
Start with the job that can deploy
Consider a hypothetical application whose release job installs packages, runs tests, and deploys to a cloud account. A long-lived cloud credential is available throughout that job. The team reviews application changes carefully, but has never written down why package installation needs deployment access.
The review should produce a record like this. These are example observations, not findings from a Sythe customer:
| Question | Example answer | Decision to make |
|---|---|---|
| What receives the credential? | The release job, through its environment | Can access begin later, after the build? |
| What can it change? | Every application in the production account | Can permissions be limited to this application? |
| What code runs with it? | Installation scripts and a deployment action | Which of those actually needs it? |
| What permits the job to start? | A merge into the release branch | Who can change that branch or its workflow? |
| How is access revoked? | Someone replaces a stored cloud key | Who owns that operation if a release is compromised? |
The table makes an otherwise vague instruction, “review CI security,” small enough to complete. An engineer can inspect the workflow and cloud policy together, document the answers, and assign changes against specific permissions.
Do this for one real deployment before applying a template across every repository. Repositories with the same workflow filename may use different credentials or deploy into different accounts.
Separate the build from production authority
In this example, the package installation step has no business reason to possess the cloud credential. Move deployment into a separate job and give that job only the access required to release the application. This is a design recommendation for the example, not a claim that splitting jobs automatically makes a pipeline safe.
The artifact crossing between those jobs still needs scrutiny. Record which run produced it and why that run is trusted to supply production code. A privileged job that deploys an arbitrary artifact has preserved the same underlying problem through a different route.
GitHub specifically cautions against checking out untrusted code in privileged workflows, including unsafe uses of pull_request_target and workflow_run. A familiar trigger name is insufficient evidence that a workflow is safe.
Repository access is another credential boundary. GitHub recommends minimum permissions for GITHUB_TOKEN. A reasonable starting point for a job that only reads source is:
# Starting point for a job that only needs to read repository contents.
# Check the requirements of the actual steps before adopting it.
permissions:
contents: read
That setting controls the GitHub token. It does not narrow a separate cloud credential supplied to the same job. Review each independently.
Short-lived credentials still need a narrow trust policy
Where the cloud provider supports it, OpenID Connect can let a workflow obtain temporary access without storing a long-lived cloud secret. GitHub's OIDC reference, reviewed September 18, 2026, explains the claims available to the receiving provider and the id-token: write permission used to request a token. That permission alone does not grant cloud access; the provider's trust policy determines what identity it accepts.
For the example application, write down the intended rule before configuring it: this repository's approved production deployment may assume this application's deployment role. Then compare that rule with the actual claims and policy. Avoid copying a subject string from an old tutorial without checking what your workflow now issues.
Test the refusal as well as the successful release. In a controlled environment, a workflow outside the permitted conditions should fail to obtain that role. Keep the policy and test result together so the next engineer can understand why the restriction exists.
A pinned action still needs review
GitHub recommends pinning third-party actions to full commit SHAs. A movable tag can change which code runs without a corresponding workflow edit. Pinning makes that change explicit, but does not establish that the pinned code is safe.
Review an action update according to the job's authority. An action running beside production credentials deserves more scrutiny than a formatting check. If the team cannot explain what that action does with the job's access, remove unnecessary permissions before treating the update as routine.
Choose the repository that deploys your most sensitive application. Trace its deployment credential, reduce one unnecessary grant, and verify that the next legitimate release still works. Keep the denied-access test alongside it. Those results give the next review something concrete to challenge.