Secrets & Credential Exposure Assessment

Developers do not leak keys on purpose. They commit a config file to debug something and force-push over it later, forgetting the history keeps the old blob. They ship a build with a test token still in it. They copy a working curl command into a public issue. Every one of those is recoverable, and we recover them the way an attacker would.

We map your external footprint: domains, repositories, published packages, container registries, and the web-facing assets tied to your organization. Using tooling such as TruffleHog, Gitleaks, custom regex and entropy analysis, and manual review, we pull candidate secrets from every source we can legitimately reach.

Git history mining

The current code is the least interesting place to look. We walk commit history, deleted branches, and dangling blobs, because a key removed from HEAD often lives on in a commit anyone can check out. This is where the highest-impact findings usually surface.

Every candidate is checked safely against the relevant service to see whether it still authenticates. For a live cloud key we enumerate its effective permissions without touching your data, so the report says exactly what the key can do rather than “an AWS key was found.” A read-only analytics token and a key with admin over your production account are very different problems.

You get a prioritized report and, after you rotate and remediate, a free retest confirming the exposure is closed and the secret no longer works. Rotation without verification is how the same key ends up leaked twice.

API keys, database passwords, and signing secrets committed into source or shipped in a client-side bundle are the classic finding. Anything in a frontend bundle is public by definition, so a paid-service key there is both a breach and a billing risk.

A leaked AWS, Azure, or GCP key is bad; a leaked key with broad IAM permissions is a full compromise. We report the effective privilege, because that is what determines whether this is an incident or an inconvenience.

A publicly reachable .git directory lets an attacker reconstruct your entire source tree, secrets included. Exposed .env files and stray backup archives do the same job faster. These are trivial to find and trivial to fix once you know.

Build arguments and secrets baked into image layers survive even after the final layer deletes them. CI/CD tokens leaked in logs or pipeline config give an attacker a path straight into your build and deploy chain, which is among the worst places to lose a credential.

Hardcoded and exposed credentials sit under ASVS V2 (authentication) and V6 (stored cryptography and secrets management), which require that secrets are not embedded in source or client code and are managed through a proper vault. We reference the relevant ASVS requirements so the report drops into an existing secure-SDLC review.

Secrets management supports ISO/IEC 27001:2022 A.8.24 (use of cryptography) and the access-control expectations behind SOC 2 CC6. If you carry either framework, this assessment produces usable evidence that credential exposure is actively managed rather than assumed.

Rotating a key is only half the fix if the old one still sits in git history for the next person to find. The report includes the steps to purge secrets from history and to move to managed secret storage, so the same credential does not reappear in your next assessment.

Attackers do not manually browse your repositories. They run automated crawlers against every public commit pushed to GitHub in near real time, and they scrape JavaScript bundles and exposed directories at scale. A secret pushed at 2am is often being tested against the relevant service within minutes. Speed of discovery is why a key you rotated a week after leaking it may already have been used.

A live cloud key is enumerated for permissions, and if it has any reach into storage, compute, or identity, the attacker pivots. A leaked database credential is connected to directly. A CI/CD token is used to inject into a build or read other secrets from the pipeline. None of this needs an exploit, because the credential is doing exactly what it was designed to do, just for the wrong person.

Once a valid credential is out, you cannot know what was accessed without logs you may not have kept, so the responsible assumption is that everything the key could reach was reached. That drives mandatory notifications, forced rotation across dependent systems, and a costly investigation. Finding and killing the key first is dramatically cheaper than proving the negative afterward.

Secrets belong in a managed store such as a secrets manager or vault, injected at runtime, never committed to source or baked into an image. We show you which findings would have been prevented by this alone, which is usually most of them.

Pre-commit hooks and pipeline scanning catch a secret before it ever reaches a shared branch. Combined with periodic assessments and, where you want it, continuous monitoring, this closes the window between a mistake and an attacker finding it.