LEARN. PRACTICE. GROW.Concept and mechanism
A pipeline executes code and may access sensitive systems. Treat external contributions, pull request titles, and received artifacts as untrusted inputs until appropriately assessed. Do not place code from an unknown contribution in a privileged job merely to make testing convenient. In GitHub, pull_request_target and workflow_run need particular care when combined with checkout of untrusted code. Keep permissions minimal per job and review third-party actions. Pinning an action to a full commit stabilizes the revision used without establishing that the revision is safe. A cache may also carry untrusted content and should never contain secrets.
Guided application
In a fictional exercise, a pull request test does not need the credential allowing production deployment. Separate execution from promotion and provide access only to the authorized context. Masking reduces accidental log exposure without preventing a malicious job from using a credential. Self-hosted runners need suitable isolation, cleanup, and network boundaries; environment approval does not turn the machine into an isolated environment. OIDC permits obtaining temporary cloud credentials after validating workflow identity and trust conditions. If it fails, compare issuer, audience, subject, and authorized context without broadening trust to any repository. Formats and capabilities vary: confirm current documentation and configuration rather than copy an old subject as a universal rule.
Masked credentials remain usable by code receiving them.
Common pitfalls
Masking as authorization; SHA as safe code; private runner as isolation; wildcard to fix OIDC.
Related topics: Integration and delivery · Jobs and dependencies · Artifacts and evidence
Grant access through trust context and verify identity before promotion.
Reference: Untrusted workflow inputs least privilege and runner isolation · CI/CD practices 2026-09; scoped GitHub Actions GitLab Jenkins and Azure DevOps Services documentation