TL;DR: Secret scanning is a solved problem in one narrow lane — a key pushed to a public GitHub repo — and largely unsolved everywhere else. Across 106 high-scoring threads about leaked cloud credentials, the recurring complaint is not that leaks go undetected but that nobody can answer the two questions that determine urgency: is this key still valid, and what does it have access to. The gap between "a string was exposed" and "an identity is live and privileged" is where the work is.
The evidence
PainHunt holds 106 posts scoring 10 or higher out of 15 on leaked cloud credentials, averaging 12.1/15 — the highest average in this batch — with a pain intensity of 8.0/10 and a willingness-to-pay signal of 7.3. The distribution is unusual: Mastodon carries 51 of them, with Dev.to, Medium, Reddit, and Bluesky making up most of the rest. That mix matters. These are practitioners and security researchers writing about work they did, not vendors describing a category.
Three findings recur, and they compound.
Exposed keys stay valid. The threads describe large collections of publicly discoverable access keys where a substantial share still authenticate successfully. Not historical keys from abandoned projects — working credentials on live accounts. Whatever rotation policy the owning organizations believe they have, it did not catch these.
A meaningful fraction carry administrative rights. Among keys that still work, the discussions single out ones with full administrative policies attached. That is the difference between an incident and a company-ending one: an admin key is account takeover, data exfiltration, and a foothold for supply-chain movement in a single artifact.
Discovery is scattered and manual. Credentials surface across public code hosts, paste services, forums, container registries, and social platforms. No single scanner covers that surface, so the practical workflow is a person searching several places by hand and then having no reliable way to check what they found.
The consequence is stated plainly across the threads: teams have no simple way to correlate a credential found in public with a live IAM identity they own, and therefore no way to trigger fast revocation. Detection produces a list. The list does not produce action.
Why now
The exposure surface grew faster than the tooling. Secret scanning was designed around source control, and source control is no longer where most credentials leak. CI logs, container image layers, infrastructure-as-code state, notebooks, and agent transcripts all carry secrets now, and none of them are covered by the GitHub-to-cloud-provider quarantine pipeline that made the original problem look solved.
AI coding assistants moved secrets around. Code that used to sit in one repository now gets pasted into prompts, committed by agents into scratch branches, and reproduced in public write-ups. Every one of those is a new copy of a credential outside the perimeter where rotation policies apply.
Short-lived credentials were supposed to fix this and mostly haven't. Role assumption and workload identity are the correct answer and are widely recommended. The threads show long-lived static keys still in production everywhere, because the migration is real work and the old keys keep working. A tool that assumes everyone finished that migration is describing a world that doesn't exist yet.
The wedge
The general build here is "a secret scanner," and that market is crowded with products that do detection well. The unserved job is triage and closure.
- Start from validity, not from detection. The first screen should not be "we found 214 exposed strings." It should be "11 of these still authenticate, 3 of those have administrative policies, here they are." Everything else is noise until that filter runs.
- Make the customer's own account the source of truth. Connect read-only to the customer's cloud, enumerate their IAM identities, and match public exposures against identities they actually own. This solves the legal problem (you are validating credentials the customer owns) and the accuracy problem (no guessing about which organization a key belongs to) at the same time.
- Cover the surfaces the incumbents skip. Paste services, forums, image registries, and social platforms are where the threads say keys are found. Being second-best at GitHub and only at paste sites is a worse business than being the only one at paste sites.
- Close the loop, don't just alert. The measurable outcome is time-to-revocation. Ship the rotation path — draft the IAM change, stage the replacement credential, show what breaks — because an alert that lands in a channel nobody owns is the state teams are already in.
- Sell blast radius, not counts. "This key can read these 4 buckets and assume this role" is the sentence that gets a rotation approved on a Friday. A severity score is not.
Risks and honest caveats
- Validation of third-party credentials is a legal minefield. Testing whether someone else's key works can constitute unauthorized access depending on jurisdiction. The owner-side architecture above is not just a product preference — it is what keeps the company out of trouble, and it constrains go-to-market to customers who will connect an account before they see value.
- Cloud providers may absorb this. AWS already quarantines certain publicly exposed keys. Extending that to more sources is a plausible roadmap item, and a product whose entire value is "we noticed faster" would be squeezed. The durable part is the cross-surface discovery and the remediation workflow, not the notification.
- The sample skews toward practitioners. Half these threads are from Mastodon, which over-represents security-minded engineers. Their assessment of severity is probably accurate; their willingness to buy a commercial tool rather than build a script may not represent the buyer who signs.
- False positives are expensive here. Telling a team their production key is compromised when it isn't burns credibility once and the account shortly after. A tool built on validity checks inherits the cost of every wrong call.
- Rotation is organizationally hard, not technically hard. Most teams know which keys should be rotated. They don't do it because something might break and nobody owns the blast radius. A product that only shortens detection time is solving the easy half.
How to validate this further
The question that decides the product is whether buyers pay for discovery or for closure. Use the PainHunt dashboard to filter security threads by intensity and read the ones that mention rotation specifically — those separate teams that lack visibility from teams that have visibility and still can't act. Then test the remediation half directly with idea validation, because if the answer is closure, the scanner is a feature and the workflow is the product.
Related reading: auditing third-party OAuth access, patched, but were you already breached?.