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.
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.
The person who reports the mistake should not be punished for surfacing it.
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.
At the top, personal accountability has made cybersecurity harder for boards and executives to treat as someone else’s problem; the downside is that accountability can become counterproductive when employees start to fear being blamed for the mistake itself.
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.
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.
We see the consequences of that with leaked credentials, and what matters is what happens next: was the credential revoked, was the exposure investigated, and did the organization learn from it?
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.
I would not throw out the traditional operational metrics like alerts triaged, vulnerabilities found, training completion, attacks blocked, tools deployed, etc.
If you blocked more attacks, are you better protected, or simply being attacked more often?
If the exposure is still live, or publication could increase the risk to users, then the researcher should wait; if a finding reveals a pattern that other organizations should be looking for, delaying publication for weeks or months has a cost too.
What happened
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.
What changed
The person who reports the mistake should not be punished for surfacing it.
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.
Who is affected
At the top, personal accountability has made cybersecurity harder for boards and executives to treat as someone else’s problem; the downside is that accountability can become counterproductive when employees start to fear being blamed for the mistake itself.
Why it matters
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.
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.
Technical details
We see the consequences of that with leaked credentials, and what matters is what happens next: was the credential revoked, was the exposure investigated, and did the organization learn from it?
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.
Response
I would not throw out the traditional operational metrics like alerts triaged, vulnerabilities found, training completion, attacks blocked, tools deployed, etc.
If you blocked more attacks, are you better protected, or simply being attacked more often?
What security teams should do
If the exposure is still live, or publication could increase the risk to users, then the researcher should wait; if a finding reveals a pattern that other organizations should be looking for, delaying publication for weeks or months has a cost too.
What to watch next
Watch for revised vendor guidance, fixed versions and mitigation updates.