Checking Your Own Public Footprint Part 4: Code, Secrets, and What's Sitting in Your Own Repos

WHOIS and username exposure both cover things you knowingly published. This part covers the category that’s usually accidental: a secret committed and then “removed” without anyone touching git history, an internal service that’s reachable from the public internet without anyone quite meaning it to be, or a document that carries more metadata than the person who wrote it realised.

Secret scanning your own repos

Removing a secret from the current version of a file does not remove it from the file’s history. git log still has it, git blame can still find the commit, and anyone who clones the repository gets every version that was ever pushed, not just HEAD. Two tools handle this well and do genuinely different jobs.

Gitleaks is a single Go binary that pattern-matches against known secret formats across a repo’s full history. Fast, no network calls, no false confidence: a Gitleaks hit means “this matches a secret’s shape,” not “this secret still works.”

$ gitleaks git ./your-repo --no-banner

TruffleHog goes a step further and actively verifies whether a candidate credential is still live, with read-only checks against 700-plus provider APIs. A verified TruffleHog result means the credential works right now and needs rotating immediately, not just reviewing.

$ trufflehog git file:///path/to/your-repo

This site has five public repositories linked from its own projects page: rst-forensics, pmtud-sweeper, fgt-config-diff, web-traffic-generator, and ciscocmd1. Both tools were run against all five, full git history, this week. Gitleaks: no leaks found, in every repo. TruffleHog: zero verified and zero unverified secrets, in every repo. That’s not a guarantee nothing was ever missed by either tool’s pattern set, but it’s a genuine, current answer, not an assumption.

The practical takeaway if you maintain public repos: run both, on a schedule, not just once. Gitleaks as a pre-commit hook catches a secret before it’s ever pushed. TruffleHog run periodically catches anything that slipped through, and tells you specifically which ones are still exploitable versus merely embarrassing.

What’s publicly indexed about your own infrastructure

Shodan’s InternetDB is a free, unauthenticated lookup that returns open ports, service fingerprints (CPEs), hostnames, and known CVEs for a given IPv4 address, refreshed weekly, no API key or account required:

$ curl -s https://internetdb.shodan.io/YOUR_PUBLIC_IP

Run against a well-known public address just to show the shape of the response, not your own, that returns something like:

{"cpes":["cpe:/a:cloudflare:cloudflare"],"hostnames":["one.one.one.one"],"ip":"1.1.1.1","ports":[53,80,443,2052,2082,2087,8443,8880],"tags":[],"vulns":[]}

Point it at your own public IP and check three things: whether the port list matches what you actually meant to expose, whether the hostnames field surfaces anything you’d forgotten was pointing at that address, and whether vulns is non-empty. An empty vulns array is reassuring but not proof of anything beyond “nothing in Shodan’s current dataset matches this address”; it’s a starting point for a check, not a clean bill of health.

Only ever query an address you actually control. It’s a free lookup against a third-party database, not a scan you’re running yourself, but the same self-audit boundary from the rest of this series still applies.

Document metadata

Photos, PDFs, and office documents routinely carry more information than what’s visible on the page: authoring software, GPS coordinates for photos taken on a phone, sometimes the author’s real name pulled straight from the OS user account that created the file. exiftool reads all of it in one pass.

To show what this actually looks like without exposing anything real, here’s a blank throwaway image with fabricated metadata written into it for this post:

$ exiftool -Artist="Test Decoy Author" -GPSLatitude=51.5074 -GPSLatitudeRef=N \
    -GPSLongitude=0.1278 -GPSLongitudeRef=W -Software="DecoyEditor 1.0" decoy.jpg

$ exiftool decoy.jpg
Software                        : DecoyEditor 1.0
Artist                          : Test Decoy Author
GPS Latitude                    : 51 deg 30' 26.64" N
GPS Longitude                   : 0 deg 7' 40.08" W
GPS Position                    : 51 deg 30' 26.64" N, 0 deg 7' 40.08" W

That’s a fabricated author name and a fabricated coordinate pair, but the fields are real EXIF fields, and this is exactly what a real photo taken on a phone with location services on will carry unless it’s stripped before upload. Run exiftool against anything you’ve published publicly, a headshot, a PDF resume, a diagram exported from a design tool, and check the Artist, Author, Creator, and GPS* fields specifically. Most platforms strip EXIF data on upload for photos, but not all of them, and almost none strip it from linked PDFs or Office documents.

Part 5 moves further back in time: what’s already archived from before you thought to check any of this.