Source Code Leakage

What it is

Source code leakage is the unauthorised exposure of proprietary code outside the controls that should contain it. The leak might be a few files in a public GitHub gist, a complete repository pushed by mistake to the wrong account, a fork made years ago that someone forgot to take down, or a 100-gigabyte archive of a company's monorepo posted on a Telegram channel after a ransomware intrusion.

The categories that show up most often:

• Accidentally public repositories on GitHub, GitLab, Bitbucket, or self-hosted equivalents
• Public forks of private code where a developer cloned to their personal account and never made it private
• Code in public package registries (npm, PyPI, Maven, NuGet) that includes more than the package author intended
• Embedded code in documentation, blog posts, or Stack Overflow answers that reveals proprietary logic
• Post-intrusion code dumps from ransomware groups using stolen source as extortion material
• Departing employee leaks, either out of malice or negligence, ending up on personal repos or sold to third parties
• Build artefacts and decompiled binaries that effectively expose the original code

The line between "your code" and "leaked code" blurs in practice. Snippets posted to debug a problem, internal SDKs embedded in mobile apps, and configuration templates checked in alongside infrastructure-as-code all carry varying degrees of sensitivity.

Why it matters

The financial and security impact of code leaks compounds in ways that are not always obvious.

Embedded secrets. This is the single most common immediate-harm finding. API keys, database credentials, signing keys, OAuth client secrets, internal service tokens, and cloud access keys end up committed to repositories all the time. A leak of even a few files often hands attackers active credentials. The 2022 Uber breach included exposure of AWS, GCP, and other credentials extracted from internal repositories.

Undisclosed vulnerabilities. Security researchers (and attackers) read leaked code looking for bugs that have not been publicly reported. Memory safety issues, broken authorisation logic, hardcoded paths, race conditions. The 2020 SolarWinds investigation revealed that leaked source had been used by adversaries to identify weaknesses for months before active exploitation.

Internal architecture exposure. Source code reveals service names, internal endpoints, authentication flows, data structures, and trust boundaries. An attacker who reads your code knows how to talk to your APIs, what the internal admin paths look like, and where the soft spots are.

Intellectual property loss. Algorithms, business logic, machine learning models, and proprietary techniques walking out the door. The Twitter (X) source code leak in 2023 exposed recommendation algorithms and internal tooling. Samsung had multiple leaks of mobile firmware source. Nvidia's 2022 breach included GPU driver source.

Supply chain implications. If your customers integrate with your code, leaked source can become a tool for attacking them. Compromised SDKs, modified dependencies, and forged updates all become easier when the attacker knows the original code.

Regulatory and contractual fallout. Many enterprise contracts include source code protection clauses. Insurance policies often have notification requirements. Some regulated sectors (defence, financial services) treat source leaks as material disclosures.

How attackers exploit it

The attacker workflow varies by leak type, but a few patterns are common:

1. Discovery. Continuous scanning of public repositories, GitHub search queries, dorking with specific terms (AWS keys, internal hostnames, employee names), and crawling of paste sites. Tools like TruffleHog, GitLeaks, and various commercial scanners sweep public Git history at scale.
2. Triage. Not every public repo with company code is interesting. Attackers prioritise based on age (recent matters more), apparent sensitivity (production code beats sample code), and visible secrets (a repo with hardcoded credentials gets attention immediately).
3. Secret extraction. Automated tooling pulls every plausible-looking credential from the code. Many of these are validated automatically against the relevant cloud provider or service, separating live keys from revoked ones.
4. Reading for weakness. Slower, more manual. Researchers and adversaries read the code for logic bugs, unsafe defaults, and exploitable paths.
5. Weaponisation. Live secrets get used directly. Logic bugs become exploits or get sold. Architectural insights inform targeted attacks.

For post-intrusion leaks (where a ransomware group has stolen and published code), the workflow compresses. The data is already exfiltrated, the leak is already public, and the only question is who gets to it first.

How to detect it

Detection across the spectrum of leak types requires several monitoring layers:

• GitHub, GitLab, and Bitbucket public scanning. Continuous queries for code containing your domain, internal product names, employee email patterns, and known infrastructure identifiers. New matches should generate alerts within hours.
• Code search by content fingerprint. If your code has distinctive patterns (specific copyright headers, unique function names, bespoke internal libraries), searching for those patterns finds copies regardless of who posted them.
• Secret pattern monitoring. Specific patterns like AKIA followed by 16 characters (AWS access keys), ghp_ prefixes (GitHub personal access tokens), and similar high-confidence indicators surfaced anywhere public are worth investigating.
• Paste site coverage. Pastebin, ghostbin, dpaste, and similar services regularly host code snippets. Coverage of these is its own monitoring problem.
• Dark web and Telegram monitoring. Ransomware leak sites and threat actor channels publish stolen source after intrusions. Daily monitoring of relevant venues is essential.
• Internal egress monitoring. Outbound code transfers from corporate networks (large pushes to personal Git accounts, unusual data volumes to file-sharing services) provide the leading indicator before the leak goes public.

A challenge specific to source code is the volume of false positives. Most "company X code" matches on public GitHub are actually job seekers including project descriptions in their portfolios, vendors with sample integrations, or completely unrelated projects with similar names. Filtering down to true leaks takes work.

How to remediate

When a leak is confirmed:

1. Stop the bleeding. Rotate every credential present in the leaked code immediately. Do not wait for confirmation that it has been exploited. Assume it has.
2. Take the leak down where possible. GitHub has a DMCA process and an abuse reporting flow. Most legitimate platforms will remove unambiguously leaked private code on request, often within 24 hours. Internet archives and forks complicate this but do not make it impossible.
3. Preserve evidence. Before takedown, capture full copies of what was exposed, including history, contributors, and timestamps. Legal and incident response teams will need it.
4. Assess what was exposed. A full code review of the leaked content. What secrets were in it? What architecture is now public knowledge? What vulnerabilities are now visible to anyone who reads carefully?
5. Patch what is visible. If the leak revealed a fixable vulnerability, fix it now, regardless of whether anyone has weaponised it yet. Assume someone has.
6. Investigate the source. Was this an accidental commit by a current employee? An old fork from a former employee? A post-intrusion exfiltration? Each scenario has different follow-up actions.
7. Notify as required. Affected customers, partners, regulators, and (for material leaks) sometimes shareholders. Legal counsel will scope this.
8. Long-term hardening. Prevent the next one through commit-time secret scanning, repository configuration policies, and offboarding controls.

Best practices

• Pre-commit secret scanning. Tools like git-secrets, Gitleaks, TruffleHog, and modern IDE plugins catch secrets before they ever leave a developer's machine. Make this mandatory, not optional.
• Repository visibility policies. Default to private. Require explicit approval to make any repo public. Audit existing public repos quarterly.
• No personal forks of corporate code. Or if you allow it, enforce that they remain private and deleted at offboarding.
• Short-lived credentials wherever possible. A leaked AWS access key matters less if it is a 15-minute STS token than if it is a long-lived IAM key.
• Secrets in vaults, not in code. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and similar systems remove the need to commit secrets at all. Treat anything else as legacy.
• Continuous monitoring of public code platforms for matches against your domain and identifiers. The leak you find in 24 hours is much less damaging than the one you find six months later.
• Offboarding hygiene. Departing developers' personal repos should be reviewed. Their access to corporate Git platforms should be revoked promptly. Their work email should not appear as a contributor on personal projects after departure.
• Threat model your code. Some code is more sensitive than others. Authentication flows, payment logic, ML models with competitive value. Treat these with extra protections (signed commits, restricted access, additional review).

A note on what is not realistic

You will not prevent every leak. Developers will sometimes commit secrets despite tooling. Personal accounts will sometimes mirror corporate code. Attackers who breach your network will sometimes exfiltrate source.

The realistic goal is to find leaks fast, contain damage quickly, and prevent the same mistake from happening twice. Organisations that treat source code leakage as a continuous monitoring problem (rather than a one-time audit) consistently find leaks earlier and contain them better than those who do not.

The 24-hour difference between finding a live AWS key in a public repo and missing it for a month often translates to a five-figure or six-figure cloud abuse bill, plus whatever the attacker did with the access.