iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Reduce GitHub Actions supply-chain risk with three controls: pin every action to its full commit SHA, give each job only the GITHUB_TOKEN permissions it needs, and use OIDC with restrictive cloud-side trust instead of storing long-lived cloud credentials in GitHub secrets. These controls address different risks: a SHA fixes which code runs, token permissions limit what workflow code can do in GitHub, and OIDC trust policy governs what cloud identity a workflow can obtain.
What do these GitHub Actions controls protect?
Treat every action in a job as code running within that job’s environment: it can interact with the data and credentials available to it. A pinned action can still contain malicious or vulnerable code; least-privilege permissions limit the authority available to that code, while OIDC trust conditions restrict which workflows may obtain cloud credentials. None of the three controls replaces the others.
GitHub identifies untrusted pull-request content, exposed secrets, and unreviewed third-party actions as material workflow risks. Review what each action does, especially how it handles repository content, tokens, and secrets. GitHub’s secure use reference describes these risks and recommends pinning actions to full-length commit SHAs.
Recommended Free Tools
How do I pin GitHub Actions to a commit SHA?
In each action’s uses: reference, use the action’s upstream repository path followed by @ and the full commit SHA—not a version tag or branch name. GitHub states: “Pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release.” See GitHub’s secure use reference.
#1 Best Overall
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Find and verify the SHA
- Open the action’s upstream repository and identify the commit corresponding to the release you intend to use. Confirm the commit belongs to that repository; do not copy a SHA from an unrelated fork or an unverified source.
- Review the action’s source and release changes for behavior that could affect your repository, tokens, or secrets. A SHA establishes which code runs, not whether that code is safe.
- Replace the action’s tag or branch reference with the full commit SHA. Review composite actions and reusable workflows in the same way: any referenced dependency can affect what executes.
- Keep the pinned SHA maintained. Use Dependabot or an equivalent update-review process to surface new versions, then review proposed SHA changes rather than accepting them as automatically safe.
A tag is easier for people to read and update, but it is movable: a publisher with control of the repository can change or delete it. A full SHA fixes the referenced revision. Neither option removes the need to assess whether the action’s code is trustworthy.
How do I restrict GITHUB_TOKEN permissions?
Set permissions deliberately at the workflow or job level, starting with the minimum needed. GitHub identifies read-only access to repository contents as a good default. If one job needs additional authority, grant it there rather than giving every job broad permissions. See GitHub’s guide to using GITHUB_TOKEN.
Rank #2
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
Example: read-only workflow and a job that requests an OIDC token
This example keeps repository access read-only by default and adds id-token: write only to the deployment job. The latter permits that job to request an OIDC token; it does not itself grant permission to change cloud resources.
name: Build and deploy
on: [push]
permissions:
contents: read
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Build
run: echo "Build here"
deploy:
runs-on: ubuntu-latest
permissions:
contents: read
id-token: write
steps:
- name: Deploy
run: echo "Configure the cloud provider's OIDC login and deploy here"Replace the illustrative commands with your build and deployment steps, and configure the cloud provider’s OIDC login and trust policy before relying on the deployment job. The sample does not install or pin an action; pin any actions you add to full commit SHAs.
Rank #3
- POWERFUL SECURITY KEY: The Security Key NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key NFC via USB-A and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Check each job’s actual needs
- List the GitHub resources each job reads or changes, then grant only the corresponding token access.
- Keep permission changes local to the job that needs them when practical. Workflow-level permissions apply more broadly; job-level permissions let you make grants more specific.
- Do not assume an action lacks token access because you did not pass
GITHUB_TOKENas an action input. GitHub notes that an action can access the token throughgithub.token; permissions on the job still matter. - Review token permissions whenever you add an action or change a job’s purpose. A trusted action with unnecessary authority still increases the impact of a mistake or compromise.
For the permission model and token behavior, consult GitHub’s GITHUB_TOKEN authentication guide and GITHUB_TOKEN overview.
How do I use OIDC with GitHub Actions?
OIDC lets a workflow request a GitHub-issued JSON Web Token (JWT) and present it to a cloud provider in exchange for a provider-issued access token. This avoids keeping long-lived cloud credentials in GitHub secrets, but it is secure only when the provider’s trust configuration restricts which GitHub identities can obtain credentials.
Rank #4
- Security Key : Protect your online accounts against unauthorized access by using FIDO2 and U2F authentication with T110. It's the world's most protective security key that works with windows, Mac OS, Linux as well as Chrome, Firefox, Edge and many other major browsers.
- Certified with the new FIDO2 standard, T110 provides the benefit of fast login and strong protection against phishing, account takeover as well as many other online attactks.
- Works with : Bank of America, Github, Google, Microsoft, DUO, Twitter, Facebook, Dropbox, Apple, ebay, BINANCE, mor and more.
- Fits USB-A port : Insert the T110 security key into the USB-A port of each service and log in conveniently with one touch
- For the driver download and user guide, please visit TrustKey Solutions Home support page.
- In the workflow or job that needs cloud access, grant
id-token: write. Keep that permission off unrelated jobs. - Configure the cloud provider to trust GitHub as the token issuer, use the expected audience, and require claim conditions that limit eligible repositories and workflows. GitHub says the provider’s trust configuration must include at least one condition so untrusted repositories cannot obtain tokens.
- Configure the provider to issue an access token with only the cloud role permissions required for the task. The cloud provider—not the GitHub permission—determines what the exchanged credential can do.
- Where appropriate, require a protected GitHub environment for deployments. Use environment protection rules such as limiting eligible branches or tags, or requiring controlled access to environment secrets.
- Test the exchange and verify that an ineligible repository or workflow cannot obtain the cloud role. Review the provider’s resulting role permissions as well as its identity conditions.
GitHub’s OIDC cloud-provider configuration guide covers provider setup, and its OpenID Connect reference explains the token and claims.
Do not confuse token permission with cloud authority
id-token: write authorizes requesting and using the OIDC token. It does not grant the workflow write access to cloud resources by itself. Cloud-side trust policy decides whether the token’s claims satisfy the conditions, and the provider’s role configuration determines the resulting access. Broad trust conditions or an over-permissioned role can therefore undermine OIDC’s benefits.
Best Value
- Ultra-Compact FIDO2 Security Key - Plug-and-stay or carry on a keychain. This USB-A hardware security key offers portable, always-on protection for desktop and mobile use. (Item Size: 0.75 X 0.74 IN x 0.25 IN)
- USB-A Hardware Key for All Devices - Works with USB-A ports on PC, Mac, Android, and other laptop/notebook device. Enables secure, cross-platform login with FIDO2.0 passkey support.
- FIDO Certified Security Key - Meets FIDO and FIDO2 standards. Works with Google, Microsoft, GitHub, Dropbox, and more. Please check service compatibility before purchase.
- Passwordless Login with Passkey - Supports passkey login via WebAuthn and CTAP2. Enjoy password-free sign-ins where supported. Not all websites or services currently support passkeys.
- Advanced Multi-Factor Authentication - Offers 200 FIDO2 passkey slots and 50 OATH-TOTP slots. Strong, flexible 2FA/MFA support across various apps and authentication platforms.
Match the subject claim to the repository’s current format
Check GitHub’s current OIDC reference before editing provider trust. GitHub documents an immutable subject-claim format for repositories created after July 15, 2026, and for repositories that opted in; repository renames and transfers after that date also move to the immutable format. A provider policy written for another subject format may stop matching. Confirm the subject claim actually emitted for the repository and make the provider’s condition match it.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Which approach should I choose?
| Decision | Option | Security effect | Maintenance or configuration trade-off |
|---|---|---|---|
| Action reference | Version tag | Readable, but mutable; the referenced code can change if the tag moves. | Convenient to update, but does not provide an immutable release reference. GitHub secure use reference. |
| Action reference | Full commit SHA | Immutable reference to the selected revision; does not prove the code is trustworthy. | Requires a process to review and update pinned commits. GitHub secure use reference. |
| Token scope | Workflow-level permissions | Applies the workflow’s grant across its jobs unless a job has a more specific permission set. | Simpler to manage, but can grant more jobs authority than necessary. GitHub GITHUB_TOKEN guide. |
| Token scope | Job-level permissions | Lets you limit grants to the jobs that need them. | Requires identifying and maintaining each job’s needs. GitHub GITHUB_TOKEN guide. |
| Cloud authentication | Long-lived cloud credentials in GitHub secrets | Credentials can provide cloud access if exposed to workflow code. | Requires storage, rotation, and exposure controls. GitHub OIDC guide. |
| Cloud authentication | OIDC exchange | Avoids storing long-lived cloud credentials in GitHub secrets; cloud-side claims and role permissions govern access. | Requires correct issuer, audience, subject or other claim conditions, and a narrowly scoped cloud role. GitHub OIDC reference. |
What should you review before merging a workflow change?
- Every action uses a full upstream commit SHA, and SHA updates receive human review.
- Action source and release changes have been checked for how they handle repository data, tokens, and secrets.
- The workflow starts with minimal token access, and any broader permission is limited to the job that needs it.
- Untrusted pull-request content cannot reach secrets or privileged deployment paths without appropriate controls.
- OIDC is enabled only for jobs that need it; the provider checks restrictive identity claims and grants a narrowly scoped role.
- Any deployment environment has appropriate protection rules, and the trust policy matches the repository’s current subject claim format.
For repository-wide controls over which actions workflows can use, review GitHub’s repository Actions settings documentation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
