Code Repositories & Developer Platforms

Learning Objectives

• Explain why public code repositories are one of the highest-value (and highest-risk) OSINT sources
• Locate secrets, internal hostnames, and identities in repositories, commit history, and metadata
• Recognize the many places developers accidentally publish secrets beyond code (pastes, containers, API collections)
• Describe the defensive controls (secret scanning, push protection) and their limits
• Apply the ethical rule: finding an exposed secret is not permission to use it

Why Developer Platforms Leak So Much

Modern software is built in the open. Developers publish code, configuration, and infrastructure definitions to collaborate, and they do it fast. In the rush, they hardcode secrets: passwords, API keys, cloud access tokens, private keys, and database connection strings. Once pushed to a public repository, a secret must be treated as compromised, even if deleted seconds later, because bots continuously scan public commits.

The scale is not theoretical. GitGuardian’s State of Secrets Sprawl 2026 report found roughly 28.6 million new hardcoded secrets added to public GitHub commits in 2025 alone, and that a large share of secrets leaked years earlier are still valid because no one rotated them. About a quarter of incidents came from collaboration and productivity tools, not just code repositories, so the problem is much broader than “someone committed a password.”

Ethics up front: discovering a live key is common in this space. In this class and in authorized work, you document and report exposed secrets; you never use them. Using someone else’s credentials is likely a crime under the CFAA (see Module 2). If you find a secret outside an engagement, report it responsibly and stop.

GitHub, GitLab, and Bitbucket

The big three hosting platforms all expose public repositories, profiles, organizations, issues, wikis, and more.

What’s exposed:
- Source code that can contain hardcoded credentials, internal hostnames and IP addresses, API endpoints, and business logic
- Configuration files (.env, config.yml, settings.py, CI/CD pipeline files) that are frequent homes for secrets
- Organizations and members: a company’s GitHub org lists public members, which maps developers to the company
- Issues, pull requests, and wikis: discussions that reveal architecture, bugs, and sometimes credentials pasted into a bug report

Searching code:
- GitHub’s code search is powerful but requires you to be logged in, even for public code. It has limits worth knowing: it indexes only the default branch, skips files over 350 KiB, excludes forks and generated/vendored code, and returns at most 100 results per query.
- Example scoped searches (conceptual; full technique in Module 4): org:companyx password, "companyx.com" filename:.env.
- grep.app is a free, no-login code search over roughly half a million public GitHub repositories that supports regular expressions, which is handy for finding patterns across many projects.

Commit History and Metadata (Identity Leaks)

Repositories leak people, not just secrets.

• Git commits store an author name and email for every change. Even if a developer hides their email on their GitHub profile, it may be exposed in commit data.
• The .patch trick: appending .patch to a commit URL (.../commit/<hash>.patch) shows the raw patch, whose From: header contains the author’s name and email. It does not work for commits made in forked repositories, and not if the developer used GitHub’s private-email feature.
• Deleted secrets often remain in history. Removing a password in a later commit doesn’t remove it from earlier commits. Investigators (and attackers) check the full commit history, not just the current files.
• Personal repos with work code: employees sometimes push work-related code to their personal accounts. This can be in scope or out of scope depending on the engagement, so check the rules of engagement (Module 2) before digging into personal accounts.

Gists and Paste Sites

• GitHub Gists: quick code snippets, often shared to get help. Public gists are searchable and frequently contain configs and tokens.
• Pastebin and similar (paste sites): developers and attackers alike dump code, logs, configs, and stolen data here.
• Pastebin has no useful public search of paste contents, and its Scraping API requires a paid PRO account with an allowlisted IP. So the usual OSINT approach is search-engine dorking: site:pastebin.com "companyx.com".
• Paste sites are also a common place for leaked credentials to appear (see Module 6 for the breach/leak angle).

Package Registries and Container Images

Published software artifacts carry secrets too.

• Package registries (npm, PyPI, RubyGems): a published package can accidentally include secrets, internal URLs, or private source. Package metadata also reveals maintainer emails and internal naming.
• Container images (Docker Hub and others): each image is built in layers, and secrets copied in during a build often survive in a lower layer even if “removed” later. In a November 2025 scan, the security firm Flare found more than 10,000 Docker Hub images exposing secrets, including cloud credentials and AI API keys, across hundreds of accounts, some tied to major organizations. Many came from personal or contractor “shadow IT” accounts outside corporate monitoring.
• AI/model platforms (Hugging Face): in late 2023, researchers at Lasso Security found over 1,500 exposed Hugging Face API tokens in public repositories, some granting write access to major organizations’ models. Any developer platform with tokens is a potential leak source.

Q&A Sites, Project Boards, and Shared Docs

• Stack Overflow and developer forums: to get help, people paste real error messages, stack traces, configs, and occasionally credentials, complete with internal hostnames and paths.
• Public API collections (Postman): Postman “workspaces” are collections of API requests, often including auth tokens. In a 2024 investigation, CloudSEK reported finding sensitive data such as API keys and tokens across roughly 30,000 public Postman workspaces. Public workspaces are indexed and searchable.
• Public project boards (Trello, etc.): boards set to public can expose roadmaps, credentials, and customer data; search engines index many of them.
• Shared cloud documents: Google Docs/Sheets/Drive links set to “anyone with the link” sometimes get indexed by search engines, exposing internal documents.

Defensive Controls (and Why Leaks Still Happen)

Platforms have added guardrails, but investigators and defenders should know their limits:

• GitHub secret scanning + push protection: since March 2024, new public repositories owned by personal accounts have secret scanning and push protection on by default, blocking many known secret types at push time. Limits: it doesn’t cover existing repos automatically, new org-owned public repos aren’t covered by default, admins can disable it, and it only catches recognized secret patterns.
• Secret-scanning tools for authorized self-audits:
• TruffleHog and Gitleaks scan repositories (including history) for secrets. Use them on your own organization’s code or in authorized engagements.
• The remediation gap: the biggest problem isn’t detection, it’s that leaked secrets often stay valid for years because no one rotates them. When a defender finds an exposed secret, the fix is to rotate/revoke it, not just delete the file.

Ethics and Scope (Read Before You Search)

• Finding is not using. An exposed key you can see is still not yours to use. Log in to nothing.
• Report responsibly. In an engagement, document it for the report. Outside one, use the organization’s security.txt/vulnerability disclosure contact (see Module 3, Module 7).
• Mind scope. Company org repos are usually fair game in an authorized test; employees’ personal accounts and unrelated projects may not be.
• Handle secrets carefully. Don’t paste real live secrets into your notes, screenshots, or the class chat. Redact them.

Key Terms

• Secret: a credential such as a password, API key, token, or private key that grants access
• Hardcoded secret: a secret written directly into source code or config instead of a secure store
• Commit: a saved change in a Git repository, storing the author’s name, email, and timestamp
• Commit history: the full record of past changes, where “deleted” secrets often still live
• Container image: a packaged, layered filesystem for running software; secrets can persist in lower layers
• Secret scanning / push protection: automated detection that flags or blocks secrets in repositories
• Rotation: replacing a leaked credential with a new one and revoking the old (the real remediation)

Key Takeaways

• Public code is one of the richest OSINT sources: secrets, internal hostnames, identities
• Tens of millions of secrets hit public GitHub every year, and many stay valid for years
• Git commits leak author name/email; the .patch trick exposes them; deleted secrets persist in history
• Leaks go far beyond code: Docker images, Postman workspaces, pastes, shared docs
• GitHub’s default push protection helps but has real gaps
• Finding an exposed secret is never permission to use it: document, report, rotate

References

• The State of Secrets Sprawl 2026 (GitGuardian)
• About GitHub Code Search (GitHub Docs)
• Code search now requires login (GitHub Changelog)
• grep.app code search
• OSINT — Grab GitHub User Details from Commit with .patch (Medium)
• Pastebin Scraping API documentation
• Over 10,000 Docker Hub images found leaking credentials, auth keys (BleepingComputer)
• Exposed Hugging Face API tokens offered full access to Meta’s Llama 2 (The Register)
• 30,000 Postman workspaces leak API keys & credentials (SecurityBrief)
• Postman Data Leaks: The Hidden Risks Lurking in Your Workspaces (CloudSEK)
• Secret scanning and push protection enabled by default on new public repositories (GitHub Changelog)