Finding exposed secrets is not the same as fixing them

by Suresh Ramasubbu

Verizon’s 2025 Data Breach Investigations Report puts compromised credentials as the initial access vector in 22% of all breaches, the leading entry point for the second year running.

A Sophos report from this year puts stolen identities behind 79% of ransomware attacks. However you cut it, the credential is the way in.

In this post I want to walk through how we work with organisations to find the credentials and sensitive data scattered across their environment, and why the part that actually reduces their risk is not the finding but what happens afterwards.

Credential exposure

The credentials attackers use are not always the ones people picture. Some are phished or bought from a broker, but a great many are already sitting inside the organisation, in the places people work: a password in a Confluence page, an API key pasted into a support ticket, a database login in a document nobody has opened in years.

Once an attacker is in, this is exactly what they go looking for, searching your chat, your wikis and your tickets for the words password, key and token in the same way your own engineers do when they have forgotten where something is.

It takes nothing clever, and when they find a live API key in a ticket or a database credential on a forgotten page, that one credential opens onto a payment system or a customer database or an admin account, and the breach becomes real.

The attacker and your own security team are running the same search across the same systems, and the only thing that decides who wins is whether you found and closed that credential before they went looking for it.

Discovery and remediation: the easy part and the hard part

Discovery has become straightforward. You can write a regular expression that matches the patterns credentials follow and run it across the systems where people store and share things. Free tools do a version of it, and the large commercial platforms do it at scale.

If the question is whether you have sensitive data spread across your collaboration tools, the answer is almost always yes, and you can prove it in a matter of days.

Which is why a discovery exercise so often ends with a security lead sitting in front of a spreadsheet of several thousand rows, each one a real credential with a location and a list of who can reach it.

It is good information that is nearly impossible to act on, because the findings are scattered across the whole organisation, one in a developer’s Jira project, one in the commercial team’s SharePoint, one in a folder owned by someone who left last year.

Security can see all of it and directly fix almost none of it, because remediation means going into other people’s systems, which means involving those people, their managers, and whoever runs the tool the credential is sitting in.

So the list gets passed around, a handful of obvious ones get handled, and the rest wait for a quiet month that never arrives.

I have watched an organisation run a thorough discovery exercise, get a genuinely clear view of its exposure, and still have almost none of it remediated close to two years later. They had paid to learn how exposed they were and then stayed exactly that exposed, with the only difference being that it was now written down.

Why fixing it is so hard 

Remediation stalls for reasons that have little to do with effort or budget. The right fix changes with every finding and cannot be chosen from a spreadsheet: deleting an exposed password is correct only if nothing depends on it, moving it to a secrets store is correct only if it is still in use, rotating it is right if it might already be compromised, and sometimes the document has to stay where it is with its access tightened instead.

You cannot tell which of these applies without understanding why the credential is there, which means tracking down whoever put it there, and for something shared eighteen months ago by someone who has since left, that is not always possible.

When exposure is spread across dozens of teams, nobody owns it. Everyone agrees it is a problem and no one’s role makes it specifically theirs, so it sits in the gap between security, who do not own the systems, and the system owners, who do not own the risk.

Much of the exposure is also behavioural, so clearing the instances does nothing about the cause, and if people are sharing passwords in a channel because it is the quickest way to unblock a colleague, you can remove every one you found and they will be back by the next quarter.

What the work looks like when it is done properly

The first thing that changes the picture is risk scoring, because nobody is going to fix several thousand things and should not try.

Rating the findings against agreed criteria turns an unworkable spreadsheet into a list of things that genuinely matter, which is something a team can actually focus and act on.

For the findings that count, the work is then case by case: someone establishes the context, chooses the treatment, and carries it out with the people who own the system, relocating one credential to a secrets manager, rotating another and updating whatever depends on it, redacting a document and restricting who can open it, or deleting outright and, where the volume justifies it, scripting that deletion so it runs across every instance at source.

Where the root cause is behaviour, the work goes upstream to the team and to whoever owns internal communication so the same thing stops appearing.

It is coordination-heavy work that does not demo well, and it is also the only part of the exercise that reduces risk at all, because a secret you have found but not fixed is exactly as exposed as one you never knew about.

Where I would start

If this is familiar, the useful question is not whether you can find your exposed credentials, because you almost certainly can, or already have, or are paying for a tool that is finding them right now and filling a dashboard nobody has opened in months.

The question is what happened after: who owned closing the findings, and whether the highest-risk exposure from the last exercise was dealt with or is still sitting in a spreadsheet, found and unfixed.

If it is the latter, that is not a sign the team is not good enough, but a sign that finding and fixing are two different jobs, and almost everything in this market is built to do the first one and hand you the second.

 

If this is something you are working through and would like a conversation about how we have approached it, please get in touch.