Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Secure a GitHub Actions pipeline by limiting workflow permissions and secret access first, then add pull-request checks for workflow code and dependency changes. Pin third-party actions to full commit SHAs, keep untrusted pull-request code away from privileged workflows, and use short-lived cloud credentials and artifact attestations where they fit. These controls reduce specific risks; none proves a pipeline or its output is safe.
Start by reducing workflow authority
Every action that runs in a job is part of that job’s trusted computing base: it may be able to use the job’s token and any credentials exposed to it. Begin by declaring GITHUB_TOKEN permissions explicitly at the workflow or job level. GitHub describes read-only access to repository contents as a good default; grant additional permissions only to the jobs that need them. See GitHub’s secure use reference.
Keep secrets out of workflow files, which are often reviewed and copied as code. Store sensitive values as GitHub secrets and pass each secret only to the job or action that requires it. Review logs and command output for accidental disclosure. For deployment credentials with greater impact, use environment protection rules so a reviewer can approve access before the job proceeds; see Using secrets in GitHub Actions.
Protect the workflow supply chain
Pin third-party actions to full commit SHAs
Use a full-length commit SHA when referencing a third-party action. GitHub states that pinning an action to a full-length commit SHA is currently the only way to use it as an immutable release. A tag is easier to read and update, but its target can change or be deleted. Verify that the SHA belongs to the intended action repository, and review the action’s source and how it handles repository files, environment variables, and credentials.
#1 Best Overall
Review changes to workflow files
Consider using CODEOWNERS rules for .github/workflows so changes to CI controls receive review from people responsible for security. Review action updates and relevant advisories as part of normal maintenance. A pinned action avoids a moving reference, but it does not make that revision trustworthy by itself.
Add pull-request checks for workflow and dependency risks
Scan workflow configuration
GitHub recommends code scanning and OpenSSF Scorecards for identifying workflow security risks. Scorecards can flag practices such as risky script-injection patterns, broad token permissions, and actions that are not pinned. Use findings to inspect and fix the underlying workflow; a clean scan is not proof that no vulnerabilities exist. GitHub’s workflow security guidance describes security-hardening practices, while the code scanning documentation covers code scanning.
Rank #2
Review dependency changes
Add Dependency Review to pull requests that change dependencies. It can surface vulnerable packages introduced by a proposed change; configure it as a required status check if you want findings covered by its policy to block merging. Confirm that the repository has the necessary feature eligibility and settings before treating the check as a merge gate. See About dependency review.
Decide what each check inspects, when it runs, and whether it advises or enforces. Also account for language and repository coverage, plan eligibility, false positives, update cadence, and who owns exceptions. A required check only enforces the policy it is configured to apply; it does not establish that all code or workflow behavior is safe.
Recommended Free Tools
Keep untrusted pull-request code out of privileged workflows
Pull requests from forks or other untrusted contributors are a distinct trust boundary. GitHub warns against using pull_request_target to check out, build, or run untrusted pull-request code when secrets or a privileged GITHUB_TOKEN are available. Avoid this trigger if the workflow does not need its privileged context. Be cautious with other privileged triggers as well, and treat artifacts produced after processing untrusted contributions as untrusted input.
Keep release and deployment steps behind explicit trust boundaries and review. Separate validation of outside contributions from jobs that can publish releases, access protected environments, or use powerful credentials. See GitHub’s secure use reference and securely using pull_request_target.
Rank #4
Use short-lived cloud credentials where supported
For a supported cloud provider, configure OpenID Connect (OIDC) so a workflow exchanges an identity token with the provider instead of relying on long-lived cloud credentials stored as repository secrets. Restrict the provider’s trust policy to the repository and, where supported, the specific workflow, branch, environment, or other identity claims allowed to assume the role. Exact claims and provider support vary and can change, so check current GitHub and provider documentation before configuring the policy. GitHub explains the setup in About security hardening with OpenID Connect.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use attestations to establish release provenance
For binaries or packages that consumers can verify, artifact attestations can associate an artifact with its repository, workflow, commit, triggering event, and related build context. That provenance helps consumers evaluate where an artifact came from and how it was produced. It does not guarantee that the source or artifact is secure; consumers still need to assess the source and set their own acceptance policy. See Using artifact attestations.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteQuick 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.
