Address the issue within your current incident response process. Then do a post-mortem to see if there were any additional controls that may have been applicable and could be implemented in the future.
Additionally, since the original question was edited—the original post posited an intentional breach by an active internal threat actor—it's worth noting that:
- Education and awareness training are certainly useful tools in communicating about the security program.
- Opening a dialog is always a great way of exploring the root cause of a breach, especially an unintentional one
but neither is operationally effective as an automatable detective or preventative control. While tools can't substitute for human judgment, human beings are often the weakest link in continuous operational enforcement. That is why continuously-operating automated controls to enforce policies and standards are often more effective in addressing this kind of accidental exfiltration issue than policies, non-disclosure agreements, or routine awareness training.
Reframing the Issue
This isn't really "data leakage" as the original post (before it was edited) expressed it. This is really more within the domain of applying appropriate controls to your source code management system, as well as endpoint protection and data loss prevention (DLP) on your company-owned equipment.
If you're allowing people to use their own equipment, then you may have to apply other compensating controls, but the bottom line is that while you can limit accidental exposure you can never completely eliminate the risk of deliberate exposure from an active threat actor. That's just the reality of the information security domain.
Per GitHub's page on inherited fork permissions:
Private forks inherit the permissions structure of the upstream or parent repository. This helps owners of private repositories maintain control over their code. For example, if the upstream repository is private and gives read/write access to a team, then the same team will have read/write access to any forks of the private upstream repository. Only team permissions (not individual permissions) are inherited by private forks.
There is also a page dedicated to explaining how to manage the forking policy for private repositories hosted by an organization or for specific repositories.
If you haven't set any controls on your organization's repositories, or your repositories are public, then focus on implementing those controls. If you have already implemented those controls, then you need to re-evaluate your threat model and design operationally-effective controls that address your real workflow. You may even need to change your workflows if adequate controls can't be applied.
Just remember that no individual control or set of controls is 100% guaranteed. You are mitigating risk by applying appropriate controls. There's no such thing as perfect security, especially when faced with deliberate insider threats or a failure to apply basic controls in the first place.
Public Repository Scanning
While not really a preventative control, you might also consider applying detective controls such as scanning publicly-accessible code repositories on sites like GitHub or GitLab for specific SHAs, either directly or via a search engine. That won't prevent people from making a private repository public, but it can at least provide some insight into whether a specific commit, blob, or tree is publicly available.
For example, given a recent commit on the Ruby 3.1 branch, you might search for the short or long SHA of the commit like so:
Finding a good search on search engines (which may treat SHA hashes as stopwords or otherwise choose not to index them) is harder, but one supposes it would be possible if you invest the time. However, even within Git web-based user interfaces there are lots of caveats to this type of approach, including (but not limited to):
- The inability to search within private repositories outside your organization.
- Lots of false positives on abbreviated hashes.
- Lots of false positives for common trees such as a freshly-initialized project skeleton.
However, this may be useful within an organization's self-hosted repositories, or within common public repositories using their own search features. You may find other ways to perform OSINT as well, but avoid tinfoil hat territory. Your best bet is still to apply basic controls and data-loss prevention techniques, and then address policy violations in accordance with your organization's incident response process.