Recommended Free Tools
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
Secure GitHub in layers: protect every maintainer identity with phishing-resistant multifactor authentication, limit who and what can write to repositories, review dependencies and workflow changes before merging, minimize CI credentials, and maintain a tested response plan. This matters because a stolen maintainer session can alter source code, release artifacts, or the build process without exploiting a vulnerability in the application itself.
The controls below reflect GitHub documentation available on October 13, 2026. Names, plan requirements, and settings can change, so confirm availability in your current GitHub.com organization, Enterprise Cloud, Enterprise Server, or personal-account configuration.
Understand the attack surface before changing settings
A GitHub compromise is not limited to someone pushing an obviously malicious file. An attacker who obtains a maintainer account, personal access token, SSH key, installed-app authorization, or workflow credential may be able to change branch protections, modify a release workflow, insert a dependency, rewrite documentation that users trust, or publish a tampered artifact. Treat account security as part of software supply-chain security, not as a separate IT task.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →There are four connected trust boundaries:
- Identity: people, sessions, passkeys, security keys, SSH keys, tokens, and authorized applications.
- Repository authority: organization roles, team membership, outside collaborators, branch rules, and installed GitHub Apps.
- Code and dependencies: pull requests, package updates, generated files, release assets, and secrets accidentally committed to history.
- Automation: workflow files, third-party Actions, runners, job tokens, cloud credentials, and code downloaded during a job.
Defend each boundary independently. A strong password cannot compensate for a workflow that gives every pull request write access, and a locked-down branch cannot undo a cloud key that was exposed in a build log.
#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.
1. Harden every GitHub account first
Require multifactor authentication
Turn on two-factor authentication (2FA) for every personal account with access to an organization or repository. Organization owners can require members and outside collaborators to use 2FA; communicate a setup deadline and verify the organization’s plan and managed-user restrictions before enforcing it.
When phishing resistance is the priority, prefer a WebAuthn credential: a passkey stored by a platform authenticator or a FIDO2 security key. GitHub’s account guidance states, “The most secure option is a WebAuthn credential.” That is GitHub’s recommendation in the context of account protection, not a universal ranking for every authentication system. WebAuthn credentials are scoped to GitHub’s legitimate domain, so a credential created for an impersonating site cannot normally be used there.
| Method | Phishing resistance | Recovery and backup | GitHub setup considerations |
|---|---|---|---|
| Passkey (WebAuthn) | High; the credential is bound to the legitimate website | Back up through the platform’s supported synchronisation or register additional devices; retain recovery codes | Can be used as a primary sign-in method when supported by the account; verify current browser and device compatibility |
| Hardware security key (WebAuthn) | High; the private key remains on the physical device | Register at least two keys and store one securely as a spare; retain recovery codes | GitHub’s security-key instructions require TOTP or SMS 2FA to be configured before adding a security key as a second factor |
| TOTP authenticator code | Better than a password alone, but codes can be phished in real time | Keep the authenticator’s approved backup and GitHub recovery codes in separate secure locations | Useful as a fallback and, according to GitHub’s setup instructions, a prerequisite for adding a security key as 2FA |
| SMS code | Weakest of these choices because phone-number takeover and real-time phishing remain possible | Depends on continued control of the phone number; keep recovery codes | Use only when stronger methods are unavailable, then add a passkey or security key |
Register more than one WebAuthn credential. A lost phone, damaged key, or replaced laptop should not force an emergency account-recovery process. Download GitHub recovery codes when 2FA is enabled, store them offline or in an approved password manager, and regenerate them if you believe they were exposed. Test that a spare credential and the recovery process work before an incident.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteRemove credentials and authorizations you no longer need
Audit active sessions, SSH keys, deploy keys, personal access tokens, OAuth authorizations, and installed GitHub Apps. Remove anything that is stale, duplicated, owned by a departed person, or broader than its current purpose. Review these records after role changes, laptop loss, contractor offboarding, and suspected phishing.
If an SSH private key is stored on disk, protect it with a strong passphrase and an agent that does not expose the key unnecessarily. A hardware-backed SSH key can keep the private key inaccessible to ordinary software. Never place a personal SSH key or a broad personal access token in a workflow merely because it is convenient; use a narrowly scoped machine identity instead.
Protect organization owners and recovery paths
Keep the number of organization owners small, documented, and reviewed. Give routine maintainers the lowest role that lets them work. Ensure at least two trusted administrators can perform recovery, but do not use shared accounts. Record who controls billing, identity-provider integration, repository administration, and emergency credential rotation. A recovery plan that depends on one person’s unavailable phone is not a recovery plan.
2. Close unnecessary repository write paths
Review people, teams, collaborators, and applications
List organization members, team grants, direct repository permissions, outside collaborators, bot accounts, and installed applications. Remove access that is no longer required and reduce broad administrator or maintain permissions to a narrower role. Check inherited team access as well as direct grants; a person may retain write access through a team after their direct permission is removed.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Rank #2
- 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.
For each GitHub App or OAuth application, identify the repositories it can reach, the permissions it requests, and its owner. Revoke applications that are unused or no longer trusted. Treat an application with repository-write permission as another maintainer identity: it needs an owner, an expiry or review date, and a documented reason for every permission.
Protect important branches with rulesets
Use repository rulesets or branch protection for the branches that feed releases and production deployments. Require pull requests instead of direct pushes, require approvals from appropriate reviewers, and require status checks that include tests and security scans. Prevent force pushes and branch deletion where the workflow requires an immutable history. Require review from code owners for sensitive directories such as workflow files, release scripts, authentication code, and infrastructure definitions.
These controls reduce the damage a compromised account can do: the attacker may obtain a valid session, but cannot silently place a change on a protected branch without satisfying the independent review and check requirements. Review bypass permissions, administrator exemptions, and temporary rules; an exception that nobody audits becomes the normal write path.
Apply consistent organization controls
Where your plan supports organization-wide security configurations, use them to establish a baseline across repositories. Then handle documented exceptions individually. New repositories should inherit protection before their first production commit, rather than relying on a maintainer to remember several settings.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
3. Find secrets and vulnerable source code
Enable secret scanning and push protection
Enable secret scanning for repositories that contain source, configuration, infrastructure, or documentation. It can identify supported credentials already present in repository history. Enable push protection where available so supported secrets are blocked before they are pushed. Decide who may approve a bypass, record the reason, and review bypasses; a developer who chooses “allow” to unblock a build may have just published a live credential.
When a secret is detected, revoke or rotate it first. Removing the string from the latest file, rewriting history, or deleting the branch does not invalidate a token that an attacker already copied. After rotation, inspect commit history, pull requests, Actions logs, deployment systems, and provider audit logs to determine whether the credential was used.
Run code scanning and act on findings
Configure CodeQL code scanning or a supported third-party scanner for the languages and build paths you use. Review findings, triage false positives, and assign owners; a green scan means only that the configured analysis found no matching patterns, not that the code is safe. Include workflow files and infrastructure definitions in the scan coverage where supported.
Rank #3
- 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.
GitHub’s repository-security quickstart describes Code Security features for public repositories and for private repositories owned by organizations with eligible Team or Enterprise products. Availability differs by plan and installation, so check the current entitlement before designing a mandatory control around it.
4. Review dependencies before they enter the default branch
Use dependency visibility and pull-request checks
Enable the dependency graph so GitHub can identify declared packages and their versions. Add dependency review to pull requests that change manifests or lockfiles. The review highlights known vulnerabilities, license or policy differences, and dependency changes introduced by the pull request before merge. Require its check on protected branches when the repository’s build permits it.
Use Dependabot for alerts and updates
Enable Dependabot alerts and security updates where available. Dependabot uses dependency data and entries in the GitHub Advisory Database to identify potential vulnerabilities and can propose a targeted update. GitHub also documents malware alerts for dependencies. Treat every proposed update as a code change: inspect the package, maintainer, version range, transitive changes, release notes, and test results before merging.
An alert is evidence of a known advisory, not proof that an unflagged package is benign. A package can be compromised before an advisory exists, can be typosquatted, or can contain malicious behavior that a vulnerability database does not classify. For high-impact dependencies, pin versions, review provenance where available, and use reproducible builds or attestations appropriate to your release process.
5. Harden GitHub Actions and other CI automation
Set the minimum GITHUB_TOKEN permissions
GitHub creates a repository-scoped, job-lived GITHUB_TOKEN for workflows. If a malicious command runs during the job, it can use every permission granted to that token until the job ends. Set a restrictive default and add only the permissions a specific job requires:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutepermissions:
contents: read
jobs:
test:
runs-on: ubuntu-latest
permissions:
contents: read
checks: write
steps:
- uses: actions/checkout@<verified-full-commit-sha>
- run: ./ci/test.shUse read-only access for ordinary tests. Grant write permissions only to the job that must publish a release, comment on a pull request, upload an artifact, or deploy. Separate build, test, signing, and deployment jobs so a compromised test dependency does not automatically receive deployment authority.
Pin and review every third-party Action
An Action is executable code, not a passive configuration snippet. Prefer GitHub’s workflow dependency lockfile, which records exact commits and verifies source identity. If you do not use that lockfile, pin each action to a verified full commit SHA rather than a mutable tag such as v3 or main. Confirm that the SHA belongs to the intended source repository, not a fork or an unexpectedly transferred repository.
Rank #4
- FIDO2 & Passkey Ready: Business-ready and FIDO2 L1 certified. This key is supported by major management suites and is ideal for both individual and enterprise deployment. Works seamlessly with Gmail, Facebook, GitHub, Dropbox, Coinbase, and more.
- Dedicated Manager App: Use the Thetis Manager App for the initial hardware PIN setup. Setting the PIN on the device first ensures a smooth registration process. Once the PIN is configured, you can begin registering the key across your favorite FIDO2-compatible online services.
- USB TYPE C Connectivity & DONGLE Design: Designed for PCs, Macs, laptops, iPhones, and Android devices that utilize a USB-C port. Plug and stay, or carry it on a keychain. (Item Size: 0.73 x 0.60 x 0.30 inches)
- Enhanced MFA (FIDO2 & TOTP/HOTP): Strengthen your security with flexible options. Use the Manager App to access TOTP/HOTP features for accounts that do not yet support FIDO2.
- Check FIDO2 compatibility before purchase - Known limitations: ID Austria is not supported (requires FIDO2 Level 2). Windows Hello login only works with Windows Enterprise editions that support Entra ID. NFC functionality is not supported.
Keep pinned actions updated with Dependabot and review the change like any other dependency. Read the action’s implementation and its permission needs for workflows that handle releases, deployment credentials, signing keys, or customer data. Code scanning can identify common risky Actions patterns, while OpenSSF Scorecards can flag supply-chain practices that deserve a closer review; neither tool proves that an action is harmless.
Keep secrets away from untrusted pull-request code
Audit workflow triggers, especially pull-request events that run code from forks or from contributor-controlled branches. Do not pass repository secrets or write-capable tokens to code that has not undergone trusted review. Avoid checking out untrusted code and then executing it in the same job that can access deployment credentials. Use separate jobs, environments with required approvals, and read-only tokens for untrusted validation.
Do not rely on log masking as a security boundary. A command can deliberately transform, encode, or exfiltrate a secret without printing the exact masked value. Limit which jobs receive each secret, avoid echoing environment variables, and review third-party actions that can read the process environment.
Replace long-lived cloud credentials
Where the cloud provider and GitHub setup support it, use OpenID Connect (OIDC) to exchange a short-lived identity token for cloud credentials. Bind the trust policy to the specific organization, repository, branch, environment, and workflow claims that should deploy. This removes the need to store a long-lived cloud key as a repository secret, although the OIDC trust policy itself still requires careful review.
Avoid classic personal access tokens and personal SSH keys in workflows. For cross-repository operations, evaluate narrower alternatives documented by GitHub, such as a deploy key or a GitHub App installation token, and understand each option’s repository scope, expiration, rotation, and write limits.
Understand the hosted-runner boundary
GitHub-hosted runners do not inspect every file or package downloaded by a job. GitHub states: “GitHub-hosted runners do not scan for malicious code downloaded by a user during their job, such as a compromised third party library.” Dependency review, action pinning, code scanning, and malware alerts reduce exposure but do not establish that every runtime input is safe. Treat downloaded tools, package install scripts, generated code, and build plugins as untrusted until reviewed.
6. Prepare and practise the response path
Publish a private reporting route
For a public project, add a SECURITY.md file explaining how to report vulnerabilities privately, which versions are supported, how to encrypt sensitive details if necessary, and what response timeline reporters should expect. Do not ask reporters to open a public issue containing exploit details.
Respond to a leaked credential in the right order
- Revoke or rotate the credential at its issuing service. Do this before cleaning files or rewriting history.
- Identify where the secret appeared: commits, pull requests, Actions logs, artifacts, caches, packages, and deployment systems.
- Review GitHub sessions, SSH keys, deploy keys, tokens, OAuth grants, installed Apps, organization membership, and recent workflow runs for unauthorized activity.
- Inspect branch-protection changes, workflow edits, releases, tags, artifacts, and package publications. Preserve relevant logs for investigation.
- Rotate related credentials if the exposed secret could access a vault, cloud account, signing system, or production service.
- Notify affected owners and users, document the timeline, and add a regression check so the same secret cannot be reintroduced.
Deleting a leaked value from Git history is cleanup, not revocation. Assume the value was copied once it entered a reachable repository, pull request, log, or artifact.
Coordinate a confirmed vulnerability
For a vulnerability in a public project, GitHub repository security advisories provide a way to coordinate a private fix and disclose it after a patched version is available. Keep the advisory, patch, release, and downstream notification consistent. If an attacker changed a build process or release artifact, investigate all versions produced during the affected interval rather than limiting the review to the source line that first looked suspicious.
Quick Recap
A practical rollout order
| Priority | Actions | Evidence that the control works |
|---|---|---|
| Today | Enable 2FA; add two WebAuthn credentials where possible; download recovery codes; revoke stale sessions, keys, tokens, and applications; rotate any exposed secrets | A second administrator can sign in using the spare credential, and revoked credentials fail |
| This week | Review organization and repository access; protect release branches with pull requests, reviews, code-owner approval, and required checks; set restrictive workflow permissions | A test pull request cannot merge or deploy without the required independent approvals and checks |
| This month | Enable secret scanning, push protection, code scanning, dependency review, Dependabot alerts, and security updates where the plan supports them; pin Actions to lockfile entries or full SHAs | Test commits containing a supported secret are blocked or generate the expected alert, and a dependency-change pull request shows review results |
| Every quarter and after incidents | Re-audit members, collaborators, teams, Apps, tokens, branch bypasses, workflow triggers, cloud trust policies, and recovery procedures | The audit has an owner, date, findings, remediations, and a recorded recovery exercise |
Common mistakes that defeat otherwise strong settings
- Using 2FA but keeping one unprotected fallback: an old SMS number, recovery code, or dormant token can become the attacker’s easier route.
- Removing a secret from the current branch: history, forks, caches, logs, and artifacts may still contain it, and the original credential remains valid until revoked.
- Pinning an action without checking its origin: a full SHA from a fork is not the same trust decision as a verified commit in the intended source repository.
- Running forked pull requests with deployment secrets: untrusted code can read available environment variables or abuse a write-capable token.
- Treating a vulnerability alert as a malware detector: advisory databases describe known issues; they cannot certify that a package has no malicious behavior.
- Granting every job write access: a compromised test command then has the authority intended only for publishing or deployment.
- Assuming a hosted runner is a malware sandbox: downloaded code still executes with the permissions and secrets assigned to the job.
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.
