Memory hook: Give the job a narrow identity, then verify what it produced.
Must remember
Configuration variables are readable configuration, not secret storage. Secrets can be scoped at organization, repository and environment levels under access policies. Environment protections can gate deployment access. Check precedence and availability rather than assuming a secret exists in every fork, reusable workflow or environment context.
GITHUB_TOKEN is an automatically issued job token with a limited lifecycle and configurable permissions. Set only required scopes; an omitted scope in an explicit permissions map is not automatically granted broadly. A personal access token has a different owner/lifecycle and should be used only when justified. Secret masking reduces accidental display but is not a guarantee against transformations or intentional exfiltration.
OIDC federation lets a job exchange an identity token for temporary cloud credentials. id-token: write permits requesting that token; it does not itself grant cloud-resource permissions. The cloud trust policy must constrain issuer, audience and claims to approved repository/workflow/environment contexts. A broadly trusted subject can undo the benefit of removing a long-lived secret.
Treat issue titles, branch names, PR text and artifacts from untrusted runs as data. Avoid inserting them directly into run scripts; use validated inputs and safe argument/environment handling. Review third-party actions, pin full commit SHAs where appropriate and maintain approved updates. Permissions, provenance and runner isolation complement version pinning.
Artifact attestations establish supported build provenance and integrity claims. Verify expected repository/workflow/identity and digest before deployment, not merely that some signature exists. An attestation does not prove code is vulnerability-free or business-correct. Use required reviewers, protected environments and a tested rollback for consequential deployment.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Cloud deployment without permanent cloud keys | OIDC with narrow cloud trust and role permissions. |
| Verify where an artifact came from | Attestation verification against expected identity and digest. |
| Untrusted PR title needed by a script | Pass as validated data with safe shell handling. |
Traps
- id-token: write does not authorize arbitrary cloud operations.
- Signed provenance is not proof of vulnerability-free code.
Active recall
1. Variable versus secret?
Ordinary configuration versus protected sensitive value with scoped availability.
2. Why limit GITHUB_TOKEN permissions?
Compromised steps should have the smallest possible repository impact.
3. What does OIDC trust validate?
The token issuer/audience and permitted workload identity claims.
4. Why pin an action SHA?
To identify the exact source revision being executed.
5. What should artifact verification compare?
Expected producer/workflow identity and the exact artifact digest/provenance.