GitHub

Is GitHub Safe? Security Insights

Is GitHub Safe? Security Insights

GitHub holds SOC 1 and SOC 2 Type 2 reports and ISO/IEC 27001:2022 certification (GitHub Docs), so the platform itself is run reasonably well. The harm people actually run into comes from what surrounds it. Copied repositories and stolen third-party tokens cause most of it, and leaked secrets add to the pile.

Apiiro reported in early 2024 that more than 100,000 repositories had copied legitimate projects and added malware. GitHub took most of them down, yet the campaign kept going.

Where you land depends on what you’re doing. Downloading software is the riskiest thing you can do here. Hosting private code is safer, though how much safer comes down to your account setup, how far your tokens reach and which apps you’ve connected.

Is GitHub safe to use?

Mostly, yes. The platform holds up. What goes wrong tends to be what you download from it, or how your own account is configured.

GitHub hosts 630 million repositories and more than 180 million developers (GitHub Octoverse, 2025). Something that size gets abused constantly, so “is GitHub safe?” is a less useful question than “which link in the chain breaks?”

To see what GitHub is built to do, look at its open model: anyone can publish code. That’s great for collaboration and a headache for downloaders. Malwarebytes noted in July 2026 that GitHub does not check every repository for safety, so the safety call falls to whoever downloads.

The table below sorts use cases by risk. The incident record covered later backs it up, though the risk levels themselves are an editorial read.

Use caseMain threatRisk levelWho controls the fix
Downloading softwareMalicious or fake repositoriesHighestYou
Hosting public codeLeaked secrets, hijacked tokensModerateYou, with GitHub scanning
Hosting private codeAccount takeover, third-party app tokensModerateYou and your integrations
Protecting company IPWeak organization settings, vendor integrationsDepends on setupOrganization admins

Think of the table as a map of where trouble starts. The documented incidents mostly trace back to third-party tokens and exposed credentials rather than the repository host itself.

Account takeover, code exposure, malware delivery and data handling all come up below, and each one gets fixed in a different place.

Why is GitHub the heart of open source?

Uncover GitHub statistics: developer community growth, repository trends, collaboration patterns, and the platform that powers modern software development.

Explore GitHub Data →

Microsoft ownership and the audits GitHub holds

Microsoft owns GitHub. Enterprise and organization customers can download SOC reports and ISO and other certification documents from GitHub, and the Docs pages for that sit under GitHub Enterprise Cloud.

Who owns and operates GitHub

Microsoft completed its $7.5 billion acquisition of GitHub on October 26, 2018.

Microsoft’s announcement promised that GitHub would operate independently and stay open. In practice GitHub runs its own security organization. Mike Hanley, then chief security officer, wrote the 2022 and 2023 incident write-ups. Reports from 2026 name Alexis Wales as chief information security officer.

Which attestations and certifications GitHub holds

GitHub Docs offers the following for download as of October 2026.

  • SOC 1, Type 2
  • SOC 2, Type 2
  • Cloud Security Alliance CAIQ self-assessment, Level 1
  • ISO/IEC 27001:2022 certification
  • Cloud Security Alliance STAR certification, Level 2
  • GitHub Bug Bounty quarterly reports
  • GitHub.com Services Continuity and Incident Management Plan
  • PCI DSS Attestation of Compliance

Enterprise owners get them from the Compliance tab in enterprise settings. For organizations, owners have to open Security in the organization settings and then go to Compliance.

Looking to sharpen your Git skills? Branching, merging, rebasing, and everything else you need - including git rebase, git stash, and commit workflows - is on one page in the Git Cheat Sheet.

Sources disagree on one small thing. GitHub’s own 2023 and 2024 changelogs still cite the 2013 edition of ISO/IEC 27001, while the current Docs list the 2022 edition.

The December 2024 changelog says the newest SOC reports run from April 1 to September 30, 2024, and that a Type II report now includes Copilot Business and Enterprise.

Encryption and the limits of an audit

Source code on GitHub.com has been encrypted at rest by default since a May 2019 change, per the GitHub changelog.

An audit says nothing about your settings. A SOC 2 Type 2 report describes GitHub’s controls over a fixed window, so a leaked token or a weak organization policy sits outside it.

GitHub security features and the plans that include them

YouTube player

Dependabot alerts and security updates come with every plan. Secret scanning and code scanning on private repositories cost extra, according to GitHub Docs.

▶ GIT EXPLAINED

If you commit, branch, or merge code every day, it helps to know how Git came to be. This video covers how Linus Torvalds created Git in just 10 days after a license dispute and explains how its data model actually works.

Linus Torvalds Built Git in Days Out of Spite
Built in 10 Days Out of Spite. Git and its data model explained in plain language.
FeaturePublic repositoriesPrivate repositories
Dependabot alerts and security updatesIncludedIncluded
Secret scanning and push protectionFreeNeeds Secret Protection
Code scanning with CodeQLFreeNeeds Code Security
Branch protection rulesIncluded on GitHub FreeNeeds Pro, Team, or Enterprise

Secret scanning and push protection

GitHub’s own numbers for push protection are decent. Between the April 2022 beta and the May 2023 general release, developers using push protection prevented 17,000 potential secret leaks, saving over 95,000 hours of revoking, rotating and remediating (GitHub, 2023).

Push protection became free for all public repositories on May 9, 2023.

It has gaps, and GitHub documents them. Only a subset of the most identifiable secret patterns gets blocked, and a developer can push past a block just by stating a reason.

A push protection scan can also time out when a push is too large. GitHub still scans and creates alerts afterward, but by then the secret is already on the remote.

Dependabot, code scanning and branch protection

Dependabot alerts and security updates are available for all repository types. CodeQL code scanning runs free on public repositories, while private ones need a Code Security license.

Code scanning has been free for public repositories since it reached general availability in September 2020.

Each branch protection rule disables force pushes to matching branches by default, and it prevents deletion of those branches too.

What changed when Advanced Security was split

On April 1, 2025, GitHub split Advanced Security into two standalone products.

Secret Protection costs $19 per active committer per month, and Code Security costs $30. Both are open to GitHub Team customers without an Enterprise upgrade (GitHub changelog, March and April 2025; the same prices were still listed in October 2026, so check current pricing).

A small team with private repositories can now buy secret scanning alone instead of paying for the full bundle. I think that’s the most sensible change in the whole lineup.

Has GitHub been breached?

YouTube player

GitHub has disclosed several incidents. The April 2022 one, which reached customers, came from stolen third-party tokens, not a break-in to GitHub’s own systems.

The Heroku and Travis CI token theft

On April 12, 2022, GitHub Security began investigating an attacker who used stolen OAuth user tokens to download private repository data from dozens of organizations, including npm.

Heroku’s incident account and GitHub’s security alert give the sequence.

  • On April 7, an attacker accessed a Heroku database and downloaded stored GitHub integration OAuth tokens.
  • Two days later, on April 9, the attacker downloaded a subset of Heroku’s private GitHub repositories.
  • GitHub Security opened its investigation on April 12.
  • GitHub published its security alert, with the list of affected OAuth apps, on April 15.
  • Heroku revoked all GitHub integration OAuth tokens around then (its own review gives April 15, while press reports say April 16).

Laid side by side, the two timelines show three days between the attacker’s download of Heroku’s private repositories and the start of GitHub’s investigation.

GitHub said the tokens did not come from a compromise of its systems, and that it does not store them in a usable form.

Travis CI is a hosted service for continuous integration that acts on a user’s behalf. Heroku deployed apps from GitHub through the same kind of delegated grant.

The attacker presented OAuth tokens instead of passwords, which is token-based authentication working as designed.

Sophos described the tokens as sub-passwords that victims had handed to automated tools. The victims’ own GitHub accounts were not directly compromised, though Sophos noted they were exposed indirectly through those tokens.

Other documented incidents

  • In December 2022, threat actors exfiltrated encrypted code signing certificates tied to some versions of GitHub Desktop for Mac and Atom. GitHub disclosed it on January 30, 2023.
  • GitHub replaced its RSA SSH host key on March 24, 2023, after briefly publishing it in a public repository (announced March 23).
  • In May 2026, GitHub disclosed that about 3,800 internal repositories were taken after a malicious Visual Studio Code extension ran on an employee’s device. GitHub said no customer data was affected.

GitHub said it had no reason to believe anyone abused the SSH key. Git over HTTPS and ECDSA or Ed25519 SSH keys were unaffected.

Users who kept the old fingerprint in known\_hosts saw security warnings until they updated it.

What the pattern shows

Delegated access and exposed credentials turn up again and again, with the occasional compromised third-party code mixed in. Moving to another Git host fixes none of that.

After the 2022 theft, affected organizations were told to review their audit logs and user security logs for suspicious activity.

Is it safe to download software from GitHub?

YouTube player

Not by default. Safety depends on the specific repository and on where you found its link.

How malicious repositories reach victims

Apiiro found more than 100,000 repositories carrying copied code with malware added, in a campaign it reported in early 2024.

Attackers rely on repo confusion. They clone a legitimate project and add a malware loader, then wait for someone to pick the copy.

Because a fork keeps the original’s name and README along with its commit history, the copy passes a quick look.

Clones of popular projects such as TwitterFollowBot and discord-boost-tool carried an obfuscated malware loader (Apiiro, as reported by The Register and others). Other repositories posed as Malwarebytes and LastPass to serve malware (Malwarebytes, September 2025 and July 2026), and hundreds more distributed infected versions of popular programs (Malwarebytes, July 2026).

GitHub deleted most of the flagged repositories, according to reporting on Apiiro’s findings, but the small share that survived still added up to thousands, and the campaign kept going.

How to check a repository before you download

Work through the checks in this order, and stop the moment one fails.

  1. Reach the repository from the project’s own website or package page. A forum post, an ad or a search result is the wrong starting point.
  2. Compare the owner name and repository URL, character by character, with the ones the project publishes.
  3. Read the releases page. Be wary of a release that offers only an executable or an archive from an unfamiliar link, with no source.
  4. Look for generic or copied README text that does not match the project’s real documentation.
  5. Verify the checksum or signature, or the artifact attestation if the project publishes one.
  6. Open unknown software in a virtual machine first, and keep real-time anti-malware running.

The mechanics of downloading from GitHub take one click, which is why the first three steps matter more than the download itself.

Where these checks fail

A convincing clone passes steps two through four if you started from the wrong link.

A checksum published in the same repository only proves that the download matches that repository. If the repository belongs to the attacker, the hash matches too.

Artifact attestations help, but on GitHub Free, Pro and Team plans they exist only for public repositories (GitHub Docs, as of October 2026). Reading the source yourself is the one check with no trust dependency. Most people won’t do it, so the starting link carries the weight.

How to secure a GitHub account and its repositories

YouTube player

Start with the account. A hijacked one skips every repository control, so the rest of the list matters less until that’s locked down.

  1. Enable two-factor authentication and add a passkey. The second factor cannot be your email inbox, and authenticator apps use time-based one-time passwords (TOTP, RFC 6238).
  2. Use SSH keys, GitHub CLI or Git Credential Manager for command line access instead of creating a token.
  3. When a token is unavoidable, create a fine-grained personal access token limited to selected repositories, with the shortest expiration that works.
  4. Review authorized OAuth apps and your security log, and revoke anything you no longer use.
  5. Keep push protection on. GitHub enables it by default for your user account when you push to public repositories.
  6. Add branch protection rules. By default each rule disables force pushes and prevents branch deletion, and you can require reviews and status checks on top.
  7. Pin third-party GitHub Actions to full-length commit SHAs, and set the default GITHUB\_TOKEN permission to read-only for repository contents.

GitHub announced in May 2022 that every code contributor on GitHub.com would need two-factor authentication by the end of 2023. A December 2022 update set the rollout to start in March 2023, and it began on March 13, 2023.

Fine-grained or classic personal access tokens

As of October 2026, GitHub Docs recommend fine-grained tokens wherever they work.

A fine-grained token is limited to resources owned by one user or organization, and it can be narrowed to specific repositories. Permissions get set one at a time, and organization owners can require approval.

Classic tokens reach every repository the owner can access. GitHub removes them automatically after a year without use, but some write access to public repositories you do not own still requires one.

Use fine-grained tokens unless a documented gap forces a classic one.

What to do after a secret leaks

GitGuardian’s State of Secrets Sprawl 2026 counted 28.65 million new hardcoded secrets in public GitHub commits during 2025, up 34% on the year before.

Of the valid secrets leaked in 2022, 64% still worked in January 2026. Deleting the commit does nothing for a key that someone already copied.

Revoke the credential at the provider before anything else. Then issue a new one and check provider logs for any use during the exposure window. Clean up last, which means removing the value from history and deleting any workflow logs that printed it.

Keeping keys out of commits is cheaper than cleaning up, and the steps to hide an API key in GitHub are short.

Pinning third-party GitHub Actions

Tags move. Commit SHAs do not.

GitHub Actions workflows run third-party code with access to your repository secrets, so one compromised Action reaches everything the workflow can read.

On March 14, 2025, the tj-actions/changed-files Action was compromised and began printing secrets into workflow logs (CVE-2025-30066, CVSS 8.6). StepSecurity’s disclosure put more than 23,000 repositories in scope, and GitHub removed the Action the next day.

GitHub’s Docs say pinning to a full-length commit SHA is currently the only way to use an Action as an immutable release.

Dependabot security alerts skip SHA-pinned Actions, but Dependabot version updates can still bump them. Also confirm that the SHA comes from the Action’s own repository and not from a fork.

Private repositories and how GitHub Copilot handles your code

GitHub treats private repository content as confidential, with a short list of exceptions for personnel access. Copilot is a separate matter, since data handling there depends on your plan.

Who can see a private repository

Section E of the Terms of Service (effective April 27, 2026) says GitHub personnel will not access private repository content without your consent, except for

  • Security purposes
  • Automated scanning or manual review for known vulnerabilities, active malware, or other content known to violate the Terms
  • Helping the owner with a support matter
  • Maintaining the integrity of the Service
  • Complying with legal obligations, if GitHub has reason to believe the contents violate the law

GitHub also states that it can be compelled by law to disclose repository contents. It gives notice of access except for legal disclosure or other legal obligations, automated scanning, or a response to a security threat or other security risk.

The March 2026 update moved this description out of the Privacy Statement and into the Terms. GitHub calls that a consolidation and says the same limits apply.

Switching a repository to private is one setting, and it changes visibility only. If a repository was ever public, treat everything in its history as exposed.

Non-public repositories are not cleaner, either. GitGuardian’s 2026 report found hardcoded secrets in 32.2% of internal repositories, against 5.6% of public ones.

How GitHub Copilot handles your code

GitHub’s changelog of March 25, 2026 changed an older default. From April 24, 2026, interaction data from Copilot Free, Pro and Pro+ trains GitHub’s models unless the user opts out.

Older guides and Docs excerpts still say individual data is not used for training by default, so check the date on whatever you read.

PlanTraining use of prompts and code contextControl
Copilot Free, Pro, Pro+Used unless you opt outOpt-out in Copilot privacy settings
Copilot BusinessNot usedData Protection Agreement
Copilot EnterpriseNot usedData Protection Agreement

In the Terms, GitHub Copilot receives Input, a category that covers prompts, attachments, code in your workspace and conversation history.

If private repository content goes into Copilot as Input on an individual plan, GitHub may use it for training, subject to the opt-out. Stored repository contents at rest are not used for training, according to GitHub.

GitHub does not share Inputs or Outputs with third-party model providers for their own independent training (Terms, Section J.3).

For Business and Enterprise, a Microsoft Tech Community post from November 2025 says IDE completions and chat prompts are not retained. It says other access methods keep prompts and suggestions for 28 days. Check GitHub’s current documentation for newer features, which may differ.

When GitHub is not safe enough

GitHub falls short in a few specific situations, and none of them is exotic.

Teams with contractual security requirements need more than the standard Terms of Service, which disclaim warranties on security and limit liability (Sections O and P). For them the answer is a GitHub Customer Agreement.

Data residency is covered if you’re willing to pay for it. GitHub Enterprise Cloud with data residency in the EU became generally available in October 2024, and its SOC reports cover it.

If you want full control of the host, GitHub Enterprise Server runs on your infrastructure. Encryption at rest then depends on your own storage setup, because the 2019 changelog covers GitHub.com only.

Token coverage is the annoying one. Fine-grained tokens cannot reach multiple organizations at once or Packages, so those workflows fall back to classic tokens with wider reach.

The Terms also put account security on the account holder. GitHub offers tools such as two-factor authentication, but Section B.4 makes the account holder responsible for keeping the account secure.

Self-hosting adds its own risk. GitHub’s Docs say self-hosted runners should almost never be used for public repositories, because any user can open pull requests against the repository and compromise the runner environment.

Moving to another Git host rarely fixes the incidents on record. Delegated tokens, committed secrets and a compromised third-party Action go wherever the workflow goes.

A solo developer with public repositories gets most of what matters from the free tier. Paid security products earn their price once private code, several committers and compliance requirements arrive.

GitHub Safety FAQ

Is GitHub safe for beginners?

YouTube player

Yes, for learning and for hosting your own code. The risk comes from running code you downloaded, so start from projects linked on their official sites and turn on two-factor authentication on day one.

Is GitHub safer than GitLab or Bitbucket?

Not on the evidence of the documented incidents. The failures involved delegated OAuth tokens, committed secrets and a compromised third-party Action, and those travel with the workflow to any host.

Choose the platform on features and compliance needs, and fix token scope and secret handling either way.

Does GitHub scan repositories for malware?

Partly, and only after publication. The Terms of Service reserve automated scanning and manual review for active malware, but GitHub does not check every repository before it goes live.

The check before you download stays with you.

Do I need to back up my GitHub repositories?

Yes. The Terms of Service say GitHub is not liable for loss of data, so the copy you control is the only one you can count on.

A local clone holds the full commit history, and a scheduled mirror to a second host covers a lost account.

What should I do if my GitHub account is hacked?

Contact GitHub Support promptly, as the Terms require, then secure the account. Revoke personal access tokens and authorized OAuth apps and read through the security log. After that, rotate every secret the account could reach.

Can I get my code back after deleting a GitHub account?

Only within a limited window. If you ask within 90 days of cancellation, GitHub makes a reasonable effort to supply a copy of your account contents. Barring legal requirements, it deletes your profile and repository contents within 90 days of cancellation or termination, though some information can remain in encrypted backups.

Content that other users forked stays.

Which GitHub Setting to Fix First

Revoking unused tokens and OAuth apps comes before any other change on GitHub. Two-factor authentication protects the sign-in, not credentials already issued, and a token acts with the capabilities of its owner.

After that, add a passkey and two-factor authentication, then pin Actions and keep push protection on.

Upkeep is the cost. Expiring tokens break scripts when they lapse, and SHA-pinned Actions need Dependabot version updates to stay current.

Moving command line work to SSH removes one class of tokens, and adding an SSH key to your GitHub account takes minutes.

This order holds as of October 2026. It shifts when fine-grained tokens close their documented gaps on multiple organizations and Packages, or when a material Terms update arrives, which GitHub announces 30 days ahead.

Bogdan Sandu

Stay sharp. Ship better code.

Every week: one curated article, one tool worth knowing, one tip you can use tomorrow. No noise, no padding.