Give each pipeline its own scoped service identity, store its token in your CI secret store, set the narrowest permissions the scan needs, rotate on a schedule, and log its use. Never use a person's personal token for automation, because it leaves when they do.
What goes wrong
Scanner tokens are often created in a hurry by one developer, pasted into a variable and forgotten. The token has the creator's full access, never expires, and is shared across dozens of pipelines. When that person leaves or the token leaks, nobody knows where it is used.
Principles
GitHub's guidance on workflow tokens recommends granting the least required access, set per workflow or per job, and warns that an action can read the token even when it is not passed explicitly. GitHub's app guidance advises selecting minimum permissions and never using personal access tokens for app authentication. OWASP's logging guidance lists adding and assigning tokens among events to record. Together these give a clear pattern.
Setup steps
- Create a dedicated service account in the AppSec tool, named for the purpose, with an owner recorded.
- Assign the narrowest role. A scan upload token needs to submit results, not edit policy or read every project. See RBAC roles to ask for.
- Scope it to projects or repos, not the whole tenant, where the tool allows.
- Store it as a CI secret, at the narrowest level: repository or environment, not organisation wide unless needed.
- Limit exposure in pipelines. Do not echo it, do not pass it to untrusted pull requests from forks, and pin third party actions to a commit.
- Set an expiry or rotation date, and record it in your register.
- Alert on use from unexpected places or at unusual volume.
Comparison of credential types
| Type | Strength | Risk |
|---|---|---|
| Personal token | Quick | Tied to a person, broad, often never expires |
| Shared team token | Simple | No attribution, hard to rotate |
| Per pipeline service token | Clear owner, scoped | More to manage |
| Short lived federated credential | No stored secret | Needs tool and CI support |
Ask your vendor whether it supports short lived or federated credentials for CI. If it does, prefer that over a stored secret.
Test it in the pilot
- Create a token with the narrowest role. Confirm a scan still uploads.
- Try to use it to change a policy. It should fail.
- Revoke it and check that the next pipeline run fails clearly instead of passing silently. See fail open or fail closed.
- Find its creation, use and revocation in the audit log.
Try it yourself
The pull request gate demo shows a scan result feeding a merge decision. Think about which identity delivers that result in your pipeline and what it is allowed to do.
Click through it at your own pace, or open it full screen.
Safeguard offers a CLI for CI use and policy gates, and a free scan is at gold.safeguard.sh/scan.
Quick check
Can one token serve all pipelines?
It can, but it makes attribution and rotation hard. Per pipeline or per team tokens are easier to trace and revoke.
Should tokens be available to pull requests from forks?
Generally no. Untrusted code could read them. Use separate, restricted workflows for forks.
Sources
- GitHub Docs: Automatic token authentication
- GitHub Docs: recommended practices for creating a GitHub App
- OWASP Logging Cheat Sheet
Last reviewed: 19 October 2026.
