Public Code Repository Reconnaissance (T1593.003): Defenders

Adversaries may search public code repositories for information about victims. MITRE lists this under Reconnaissance with platform PRE, last modified in May 2026. Repositories sit on third party sites such as GitHub, GitLab, SourceForge, and Bitbucket, and people use them through web apps or command line tools such as git.

MITRE points out that this is distinct from collection from private and internally hosted code repositories.

How attackers use it

MITRE says public repositories can show general information about a victim, such as commonly used programming languages and libraries and the names of employees. They can also hold more sensitive data, such as accidentally leaked credentials or API keys.

Results can lead to phishing for information, to compromising accounts or infrastructure, and to initial access through valid accounts or phishing.

Think about what a repository shows even without any secret. A manifest lists the dependencies and versions you rely on. Commit metadata includes names and email addresses. Both help an attacker plan.

The history matters as much as the latest version. A key that was committed and later deleted still sits in earlier commits.

The reason this technique pays off for attackers is that developers copy. A personal project, a sample, or a fork can carry a real configuration file. Employees may use their own accounts for work, so the organization's name may appear in a place the company does not manage.

MITRE separates the types of information. The general kind, languages, libraries, and names, helps with planning and with believable lures. The sensitive kind, credentials and API keys, can be used directly. A leaked credential found in a repository can support initial access through valid accounts without any exploit at all.

There is also the question of time. Code hosting platforms keep history. Even a quick fix that deletes a secret leaves the earlier version one click away, and copies may exist in forks and clones you cannot recall. That is why MITRE's audit mitigation talks about the commit history and not just the current version.

How to detect it

MITRE notes that this activity may have a very high occurrence and false positive rate, and may take place outside your visibility, which makes detection difficult. Its advice is to focus on related stages of the adversary lifecycle, such as initial access.

Because the search happens on a third party site, the detection that works is looking at your own public footprint. Check what repositories exist under your organization and under staff accounts, and review what they contain.

If a credential has been exposed, the later signal is its use. Monitor for sign-ins and API calls using those credentials from unusual places. That is the related stage MITRE points to.

Detection is mostly about knowing your footprint. Start by listing organizations and accounts that publish on your behalf, then search each public code host for your company name, internal host names, and domain names. Include the names of your products.

Add exposure alerts if your code host offers secret scanning for your repositories, and read what it reports. A hit on a public repository should be handled as a live incident, since the data is already visible to everyone.

For credentials you suspect were exposed, look at the audit logs of the service they belong to. Sign-ins, token use, and new keys created from an unfamiliar address after the date of the exposure are the evidence that matters. That is the later stage MITRE tells you to watch.

How to reduce the risk

• MITRE lists two mitigations. Audit: scan public code repositories for exposed credentials or other sensitive information before making commits, and ensure leaked credentials are removed from the commit history, not just the current latest version. Application Developer Guidance: developers uploading to public repositories should be careful to avoid publishing credentials and API keys.
• In practice, that translates into the steps below.
• Add a secrets scan to the commit or pull request path, so problems are caught before a push.
• Rotate any credential that has appeared in a public repository, then clean the history.
• Keep a list of the public repositories your organization owns, and review it.
• Keep company email addresses and internal host names out of commits where practical.
• Review which dependencies and versions you disclose, and keep them patched.

If a secret has been exposed, the order of work matters. Revoke or rotate it first, because removing the text from history does not undo the exposure. Then clean the history as MITRE advises, and then check the logs for use.

Finally, write the rule down for developers: no real credentials in code, no production configuration in public samples, and a pull request check that fails on a detected secret. People follow a clear rule backed by a check more reliably than a reminder.

Check your own environment

Two read-only git checks you can run in a repository you own, on Linux, macOS, or Windows:

# commits that ever touched common secret-bearing files
git log --all --oneline -- .env '*.pem' '*.key'

# list the distinct commit author emails in the history
git log --all --format='%ae' | sort -u

Then work through these questions:

• Which repositories under our organization and staff accounts are public?
• Has any secret ever been committed, even if later removed?
• Do commit author emails reveal personal or internal addresses?
• Is a secrets scan part of our pull request checks?

For the dependency side, the free in-browser dependency scan at https://gold.safeguard.sh/scan needs no login, keeps your file on your machine, and covers up to 100 dependencies.

Try it yourself

A walkthrough of finding and handling secrets in code before they reach a public repository.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK, Code Repositories (T1593.003): https://attack.mitre.org/techniques/T1593/003