It depends on your organization setting. GitHub lets organization owners allow or prevent forking of private repositories, and new organizations start with forking of private repos turned off. If your org is older or someone changed the setting, check it, because a fork is a copy of your code outside your direct control.
Why forks are a shadow IT concern
A fork is a full copy of a repository under another owner. If that owner is a personal account, the copy lives outside your organization's access reviews, offboarding steps and audit routines. Nobody means harm. A developer forks a repo to experiment, leaves a project, and the copy stays.
You cannot inventory what you do not know about, and stray copies are code you have not accounted for.
Check the setting
GitHub's documentation gives the path. As an organization owner, open the organization's Settings, then under Access choose Member privileges, and look under Repository forking for the option to allow forking of private repositories. The page states that new organizations are configured to disallow forking of private repositories by default.
If you allow forking at the organization level, you can also configure forking per individual private repository. That is useful when one team needs it and the rest do not.
What the setting does not do
Be honest about the limits so nobody reads a false assurance into it:
- It controls forking of private repositories. It does not cover repositories you chose to make public.
- It does not stop someone from cloning a repo they can read and pushing the contents elsewhere. Read access is read access.
- It does not affect copies made before you changed the setting.
Treat it as one guardrail, next to access reviews and least privilege.
Look for stray copies
Start with what you control:
- Review the organization audit log for repository events. It records repository activity, including repository creation, is available to organization owners, keeps events for 180 days and supports qualifiers such as action, repo, actor and created.
- Search for distinctive strings from your code, such as internal package names or unusual file headers, in public code search. GitHub's code search syntax supports exact strings, path filters and regular expressions. Public hits that are not yours to publish are findings.
- Ask team leads which people have left and which projects they touched.
Do not assume a clean search means no copies exist. Private forks will not appear in public search.
Make it part of offboarding
Put one line in your offboarding checklist: confirm no personal copies of company repositories remain, and record the confirmation. Pair it with a periodic review of outside collaborators. For related access patterns, see GitHub token, app token or PAT in workflows.
Quick check
Does blocking forks stop leaks of source code?
No. It removes one easy path. People with read access can still copy files, so combine it with access reviews and logging.
Who can change the forking policy?
Organization owners, through the organization settings. Limit how many people hold that role.
Safeguard offers asset discovery and policy features that help you keep an inventory of repositories and owners. A free scan is available at gold.safeguard.sh/scan.
Sources
- GitHub Docs: Managing the forking policy for your organization
- GitHub Docs: Reviewing the audit log for your organization
- GitHub Docs: Understanding GitHub code search syntax
Last reviewed: 19 October 2026.
