What a security leader should tell the CEO about leaked credentials
In this Help Net Security interview, Eric Fourrier, CEO of GitGuardian, talks about leaked credentials and personal liability for security leaders and boards. He explains how fear of blame pushes mistakes out of sight, and what a security leader should be ready to tell a CEO about exposed keys.
He also covers better ways to measure security progress beyond alert counts, how to handle disclosure deadlines, and why AI tools and agents are creating new paths for secrets to leak into public view going into 2027.
Boards are now asking about personal liability. Has that pushed behavior where you wanted it, or has it driven bad news further underground?
Both. At the top, personal accountability has made cybersecurity harder for boards and executives to treat as someone else’s problem. Cases involving security leaders, along with requirements like NIS2, have made it much clearer that leadership can be held responsible for how cyber risk is managed. That has pushed boards to ask better questions, which is a positive change.
The downside is that accountability can become counterproductive when employees start to fear being blamed for the mistake itself. We see the consequences of that with leaked credentials. When someone realizes they have exposed a secret, the instinct can be to remove the visible evidence by deleting the commit or making the repository private. But that does not revoke the credential. The mistake may be harder to see, while the underlying risk is still there.
That is where companies need to be very deliberate about separating accountability from blame. The person who reports the mistake should not be punished for surfacing it. What matters is what happens next: was the credential revoked, was the exposure investigated, and did the organization learn from it?
If people think speaking up will make them the problem, they will be less likely to speak up. And that gives security teams less visibility. The goal should be to create a culture where mistakes are reported quickly, and leadership is accountable for making sure the organization responds to them effectively.
A CEO reads that nine in ten leaked keys are still working a week later and asks one question: does that happen here? What should the security leader be able to answer in that meeting?
The honest answer for many companies is “yes, and we may not know.” At a baseline, the security leader should be able to say: we monitor public code for our credentials, including outside repositories we control; we can tell which exposed credentials are still valid; and we know who needs to act on them.
But there’s another part of this that companies think about much less: what happens when someone else finds the credential first? Can they reach you, and does that warning get to someone who can do something about it? The figure in the question, by the way, comes from our own research. The people associated with those exposures had been notified, and more than 90% of the credentials still had not been revoked days later.
A great example of this involved CISA. We sent nine automated alerts to the person who had published credentials in a public GitHub repository and received only an automated reply. The repository stayed public until our research team escalated through CERT/CC; it was taken down 26 hours later.
A security leader should be able to tell their CEO:
1. We have a published way for outsiders to report an exposed credential, a named person reads it, and it has been tested in the last quarter.
2. When an exposed credential of ours is reported or found, revocation is the first action, not deletion.
3. We measure time from report to revocation, and here is our number.
4. We can detect when a corporate credential appears outside the systems we control, including in a developer’s personal public repository.
The CEO needs confidence that the company can find them and that the access will be shut down quickly.
A CEO wants evidence the company is better at cybersecurity than it was a year ago. What would satisfy you, and what would you throw out?
I would not throw out the traditional operational metrics like alerts triaged, vulnerabilities found, training completion, attacks blocked, tools deployed, etc. Those numbers are useful. But I would add another layer, because activity is not the same thing as improvement. If you found twice as many vulnerabilities this year, did your security get worse, or did your detection get better? If you blocked more attacks, are you better protected, or simply being attacked more often? The number alone cannot answer that. I would want to see whether risk is becoming easier to find, faster to contain, and less likely to persist.
Time is particularly useful here. How long does a serious exposure remain open? How long from detection to containment or revocation? Are the slowest incidents getting resolved faster than they were a year ago? Are the same problems recurring after they have supposedly been fixed?
In my world, credentials are a very concrete example. How old is the oldest credential that still has meaningful access? What share of machine credentials have a known owner and an expiry or rotation policy? When a credential is exposed, how long until that access is revoked? I would look beyond the median, too. The slowest cases often tell you much more about where the program is breaking down.
A researcher’s publication deadline collides with an earnings date or a funding round. Have you sat in that conversation? Who won, and should they have?
I have been in conversations about delaying disclosure, although not necessarily because of an earnings date or funding round. My question would be: why is the company asking for more time?
If the exposure is still live, or publication could increase the risk to users, then the researcher should wait. The purpose of disclosure is to improve security. If the issue has been fixed and the request is purely about timing or reputation, I think a short courtesy window can be reasonable. We are not trying to create unnecessary damage. But that cannot become an indefinite delay because the timing is inconvenient.
Researchers also have a responsibility to the broader community. If a finding reveals a pattern that other organizations should be looking for, delaying publication for weeks or months has a cost too.
So I would not frame it as the company winning or the researcher winning. You need to look at what the delay is protecting. If it is protecting users while a real security issue is being fixed, move the date. If it is only protecting the comms calendar, it’s time to disclose.
What are you watching going into 2027 that most of your peers are not?
In the context of what we’re discussing, I am watching how the profile of a public credential leak is changing.
For a long time, the mental model was simple: a developer hardcodes a secret, pushes it to a public repository, and someone finds it. That still happens. But increasingly, the person exposing a credential may not think of themselves as a developer at all, and the credential may have passed through an AI tool or agent before it ever became public.
AI is making software creation accessible to far more people, which is a good thing. But it also means more people are handling secrets without necessarily having the security habits that engineering teams have spent years building.
At the same time, agents are creating and moving information across more places, creating more surfaces for credentials to escape.
I want to see whether security programs expand their idea of where public exposure comes from. Monitoring the company’s official repositories is no longer enough. A corporate credential can surface through a personal dev’s account, a side project, an AI-assisted workflow, or someone building an internal tool who would never describe themselves as a software engineer.
A working credential is still a working credential.
So going into 2027, I think the challenge is less about asking, “Are our developers leaking secrets?” and more about asking, “Where can one of our credentials escape, and would we see it when it does?”
Strategies: CISSP exam prep with ISC2 experts
