Mackenzie Jackson: Hello everyone. Welcome to another episode of The Secure Disclosure. Eric, thanks so much for joining me here today. It's a pleasure.
Eric Fourrier: Thank you for having me.
Mackenzie Jackson: I wanted to start off a little bit. You're the CEO and the founder of GitGuardian, but I kind of wanted to talk a little bit about the origin story. I know a little bit about the origin story because I used to work for you. So, but I just kind of wanted to, how did GitGuardian come about? Because I know it's a bit of an interesting story. It almost started off as a bit of a side project to start with.
Eric Fourrier: Yeah, so it's a very good question. I was myself a software engineer and especially an AI engineer. I was working in the Silicon Valley in San Francisco at a company called Vending Club. I was a data scientist over there and realized data scientists were probably the most terrible person at writing secure code and managing credentials. I assume I was one of them. And yeah, I came back to France with this idea of, how can I help developers write more secure code and especially better manage credentials? As a good French data scientist, you try to solve a problem first before trying to find a business. So the idea was for me, okay, how can I find the best dataset to train our secrets detection engine to find the best secrets and be the most accurate? And this dataset was GitHub public open source. So all the open source code you can find on GitHub, you can find so many repos in every language.
It started as just crawling all the open source code in real time and each time we were finding a secret, we actually were shooting an email to the developer saying, "Be careful, you actually leaked an API key here." And saying, "You shouldn't do that. You should use at the time environment variables or better secrets manager" and really help developers to understand how they can improve their hygiene, their security practice and be a better developer at the end.
Mackenzie Jackson: So that was I think 2017 or?
Eric Fourrier: Yeah, it started in 2017. The first product started in really 2017. Yeah. And actually at the beginning, we were AI engineers. So for a funny story about that, I was a specialist in deep learning for text in 2012, 2014, so before the LLM. And for the one who don't know, at the time we were a bit the loser of the deep learning before LLM. So I guess I missed a bit the boat at the time. A lot of my friends are on OpenAI or Mistral and all this research lab, but I decided to go another way with my co-founder.
Mackenzie Jackson: You're doing okay.
Eric Fourrier: Right, right, like we don't need to, like you're a taxi driver. No regrets, no, just a funny joke. But one day, actually, as a good data scientist, I was looking at all the data on the logs of the secrets we were processing. As I mentioned, it was a side project. We had a consulting company doing at the time building machine learning algorithms for company. I was looking at the data and the logs and one day, actually, we found the Slack admin API key from NASA, giving access to all the files, all the messages.
Mackenzie Jackson: From NASA?
Eric Fourrier: From NASA. Yeah. So crazy story. And, you know, we were two French engineers, 25 years old. We didn't know what to do. Actually, we didn't do any studies about cybersecurity. So we just bought a burner phone, tried to call the cybersecurity command of NASA to say, "Okay, you have this Slack API key that's exposed." And the funny part of it is, not only the leak was bad, but nobody understood the problem.
Mackenzie Jackson: Right.
Eric Fourrier: And that was a big revelation for us. It's a huge problem that nobody understands. And after looking a little bit more, we realized we were able to find a lot of credentials for Fortune 500 companies. And that's where GitGuardian was born as a company. We realized it was really not just developers leaking their own personal credential with very low access, with really developers leaking company credentials giving access to very...
Mackenzie Jackson: Tons of sensitive data.
Eric Fourrier: And that's really how GitGuardian was born. After that, we said, "Okay, we stop the consulting company, we go full-time on GitGuardian and we build the first product of the company," which is GitGuardian Public Monitoring, which is its main idea for any company in the world who can identify publicly active developers in GitHub and see if they are leaking actually company credentials and be able to warn the security team before attackers can find them. Yeah, it's so crazy to talk about this now because the idea that people didn't understand this problem, because it is such a prevalent issue today. And if we look at, it's been a crazy year especially with supply chain attacks in the last and all of them have one thing in common. They're all looking for secrets. And so like, we've, it hasn't, it's like, okay, it's almost 10 years ago since the project started. But it's amazing to think how far we've come in our understanding in that time of not understanding that these keys are very sensitive and they leak out.
Mackenzie Jackson: But today, there's still, when you look at a breach, where it goes bad is because someone found a secret. It may not be the initial access point, it could be from something like where everything goes bad is secrets are discovered. So we're still, we're still struggling with this 10 years on today. It's such a crazy, such a crazy scenario.
Eric Fourrier: It's such a crazy scenario. And I can share a story of the early days. I remember a very funny disclosure we made. It was 2018. So we found AWS credentials from one of the very famous French cybersecurity consulting group from a developer. And we warned the developer and actually he had leaked an environment variable file and inside it, there were also his personal cryptocurrency keys. And the guy just said, "Okay, oh, thank you so much for warning me about my personal crypto keys that could have been stolen and I could have lost all my money in my wallet." But he didn't really care about the company credentials, which was really the important stuff. Yeah. And so I think definitely the awareness has evolved a lot and if, especially if you look at the attacks over the past like five or six years, in the early days attackers were targeting one company. So they were looking for the AWS credential of a company or the Artifactory credential, any credential they could get access to the infrastructure of a company. And usually in the early days, actually attackers were pretty nice. They were just running on AWS machine, they were running crypto mining stuff and just making money out of it. And after it became more aggressive with malware and I think in 2021, 2023, we had the first Codecov and CircleCI attack. The first time actually not only targeted one company, but through company that provide software supply chain to CI infrastructure to other company, they were by hacking one company being able to target multiple companies. And that's the first example of that and in 2025, so only like 12 months ago, we have assisted to an industrialization of all these attacks, we've lived it through like Shulde, Miasma in PCP where here like the paradigm changed. It's attacks were industrialized and there was like a propagation with a worm like through the NPM or Pi packages. And that's, that's really scary when you think about it and but at the end of the day, you're right, like all these attacks, one of the purpose is to steal secrets to move laterally, because it's so easy to do. One thing that's interesting to me is where the secrets are kind of discovered and how the attack surface has moved. So when you first started GitGuardian, you're looking at public GitHub repositories, right? Later on you went into internal GitHub repositories, which were so much worse, but at least people didn't quite understand the problem because it was internal. So there's that. Now we've kind of gone further as well, is now attackers seem to be targeting secrets on developers' machines. So they're not only are people kind of changing how they're trying to find these secrets, but the places that they're finding them are changing. And the developer machine part is kind of scary to me, because the secrets that you, you would have a heart attack if you looked at my laptop. Like they're not in my GitHub repository, but I have ENV files everywhere. If you do download malware through Shahalude or something and they start propagating through the laptop, there's endless secrets.
Eric Fourrier: Yeah. So you're very correct. Even if I remember our own remediation guidelines at GitGuardian like four years or five years ago, the idea was, okay, you should not have secrets in code, but they should be in your environment variable. Yeah, on your laptop. So that was security recommendation we had like four or five years ago, but the paradigm has changed completely. And for me, it's the idea is very simple. It's really due to the rise of coding AI agents. An analogy I really like to give, an example I really like, is you have a big shift right now where you have non-developer, non-engineer that are able to install load code. It could be people from your marketing team, your ops team, your sales team, or even people that have no idea, no developer experience at all, that will actually produce code, but not push it on a VCS. And when you build application, you build code, you need credentials because you need connection between an API, you need access to a database, you need access to CRM, you need access to LLM provider model. And this creates an amazing attack surface for attackers. And obviously on the developers' laptop, you have tons of credential. We have crazy statistics that we just pulled a couple of weeks ago where we've seen on endpoint and developer laptop, we've seen 50 times more valid secrets on developer laptop than on Git repo.
Mackenzie Jackson: Right.
Eric Fourrier: And 45% of them are actually put by coding AI agents. So when a coding AI agent manipulates through doing tool calls through grab or when you feed them data, they will actually store everything in their memory or history through very weird place in your computer. And you can find tons of secrets here. And attackers, it's just such, the developer laptop just becomes such a juicy target for attackers.
Mackenzie Jackson: Yeah. It's kind of like what GitHub repos were five years ago, as like as a juicy target. You can get into a private GitHub repo, you know that you would find heaps of secrets. Now you can get into a developer laptop. And to be honest, like the attack path for both of those things is quite similar. Like the developer laptop isn't that much more secure.
Eric Fourrier: Yeah.
Mackenzie Jackson: Than the private GitHub repo, you know, like but we've, yeah, we've been trained to.
Eric Fourrier: But that's really interesting that you make a good point. The GitHub repo was a juicy target because you had a lot of interconnection. So if you think about the software supply chain, so the code was distributed, it was packaged into a binary, a Docker image, you could access it through the CI. So you had a lot of ways to access the GitHub repo, but also when you have access to the GitHub repo to propagate to the rest of the infrastructure. But now with a developer laptop and the coding agent is even more powerful because the sole purpose of your coding agent and your AI agent running locally on your machine is to get access to a lot of different data sources to be powerful in actually their thinking. The more data you have, the more context you have, the more business context you have, so the better you can take decision and the better you can answer any question an employee might have. So the biggest reason why developer laptop and laptops in general are becoming the next target of attackers is they are interconnected to every systems and right now we don't have a better protocol then we're trying to build it and to catch up.
Mackenzie Jackson: Yeah.
Eric Fourrier: But it's a lot of either human identity that's given to the agent or API keys. So yeah.
Mackenzie Jackson: I want to briefly interrupt this episode to thank our sponsor of the podcast Aikido Security. Aikido Security is your complete code to cloud security solution. It secures everything from the first line of code that you write all the way through your supply chain, your dependencies, and of course, Aikido is also a leader in AI pentesting and AI code auditing. So make sure you check them out today. You can start for free at aikido.dev. All right, enough about that. Let's get back to the episode. And what are, what is the best practice now for people, I guess like there's the best practices for people like developers are dealing with highly sensitive keys. And this is also probably the same but I'm also thinking about these vibe coding people, which are in companies everywhere at the moment. It's how do we train people to manage secrets in a correct in a correct way? Because most of the time, if you're just dealing with Claude, you probably don't even realize what these are. You're just copying and pasting them from prompts and from instructions. Yeah.
Eric Fourrier: I think it's a very difficult problem and probably we need to separate between developers and non-developers. I think for developers are multiple ways to limit the impact. I think the most important part is you need to consider your agent as its own identity and treat it as such, like it as an owner. You need to offboard it, offboard the credential it had access to. And after you need to apply the classic good practice, which is when we think about it, is less lease privilege for the secrets, trying to go to dynamic secrets instead of static secrets.
And at the end of the day, you have also other approach, which is really interesting. If you look at the environment right now where you have a lot of developers that actually use sandbox, which they basically say like, "Okay, like it's very hard to try to change how identity and API keys are working right now with agents. So I'm just going to put everything in a sandbox and if it get compromised, and it will probably, I don't care because the blast radius will be limited." And it's probably my biggest advice. In this world where velocity is everything because at the end of the day, people want to be fast and there is always a trade-off between security and velocity. Even as much as some people want to argue about it, it's just the case. So, so the best advice is like, yeah, I think we are in a world now and it's getting more and more comprehensive and people accept it more and more, it's you're going to get breached at some point and the best, the best defense is trying to limit the blast radius. And also, I think, and very few company in my opinion can achieve this, actually realize they have been breached because a lot of company don't know and we've seen it with the software supply chain attack where people realize at some point, "Oh, we've been breached" and they had no idea.
Mackenzie Jackson: Well, they were, if you look on GitHub for some of the many Shahalude variants, there's still repositories that are public with like because people haven't realized that they've been breached and they have this repository with secrets in it that's still sitting out there in public. I want to ask you about something else now. There's been a kind of a change in language around this that sometimes I struggle a little bit to understand it. Now, I know other people do, but we talk a lot about non-human identities now, NHIs. Are these what has kind of driven this language to kind of move away from just secrets and start talking about non-human identities?
Eric Fourrier: Yeah, it's a very good question. I think even us as expert in the domain, it's a struggle to even explain it to even customers and other person, but at the end of the day, it's I like, you know, when you have a secret, like AWS secrets, you have the AWS accounts, you have the AWS ID and the AWS access key. AWS ID is not sensitive, it's basically is as in your username and password, is the username.
Mackenzie Jackson: And.
Eric Fourrier: The AWS access key is like the password, the equivalent of a password. And this is where you can find the difference between like the secret and the non-human identity. So the AWS access ID is a non-human identity and the couple is a secret because with the two keys you can access to the infrastructure, you can perform action and stuff like that. And so there is this dual approach where you want to basically govern non-human identity. So you want to apply policies on top of it that we're pretty good right now with human identity. And you think about, you have an employee that is leaving the company, automatically all these access are deprovisioned, it cannot connect to the different application of the company. And we still struggle to do this on the non-human identity side. So imagine the user has provisioned a service account key, if he leaves the company, there is like the service account key is probably still available and probably still can be used by another person. So you need to apply governance on the non-human entity and you really need to secure the secrets which will be used by attackers. So actually you need both. You need to secure secrets and to govern with either NHI. So it's two different aspect, but at the end, it's the same thing. And so like, I guess that helps understanding it is that because, okay, we have all these secrets, but we don't necessarily know what they're attached to and what's actually accessing that and how much we have like everything going in. And what I immediately go to as AI agents in this because something that really kind of stresses me out with secrets and access is that when we're talking about prohibiting secrets, API keys for a system or a function, it's kind of like a binary function that we create. As in we've got this system that's fetching something from S3 bucket. We have a key for the S3 bucket, right? If we put an agent in the mix and we give them the same credentials, it's kind of non-deterministic. They now can do crazy stuff with that secret, but we're kind of, we're giving them the same non-human identity or the same secrets that we've given binary system. My binary is probably the wrong word, but deterministic kind of functions and systems and microservices. Do we kind of need to change how we approach authentication for this world of kind of AI agents?
Eric Fourrier: Yeah, it's a very good question. So you're right on the, I think the first point is very important to understand and very few people understand it deeply is agent are non-deterministic. So if you give them a credential with, for example, read, write and delete access, there is no guarantee they will not use the write and delete access to do bad stuff. We had tons of experience about agent deleting the production database. Another stuff I find really interesting that we have seen with a lot of agents. I've experimented myself vibe coding like everybody else. Is like the agent, even if for example, you give them, you're in a project, you say, "Okay, this is your secret or even if you do it through a secure vault or environment variable or bad way of coding credential, if they actually don't have enough credential or don't have enough permission to do that job, they will actually look someplace somewhere else in in the codebase in other project in your environment variable to find more secrets and from there perform action and move laterally and this is probably the biggest risk." And we see that lately with like the OpenAI hacking phase and what's very interesting here, it's like the barrier and the limit between like, "Okay, I'm using a credential to do my job and I'm hacking a company" is very, very thin.
And I think it's a big problem and that's why people are trying to do sandbox and stuff like that to try to constrain the agent. For example, to do all and obviously, it seems like agents are able to escape their own sandbox. So yeah, I think it's a very, very tough problem and at the end of the day, the best advice I have is apply what has been working for the past 10 or 15 years. So it is privileged, don't give an agent admin access key. The best practice from 10 and 15 years ago are still working today with an agent. And I think it's probably for me, one of the biggest learning is even if we look at the problem we're solving, which is secret sprawl, the AI agents and the agent TPI didn't create the secret sprawl, it was existing before. It's just amplifying it by a factor of 10. And I think it's the case for every other problem when you think about it like.
Mackenzie Jackson: Yeah. And I can also like imagine a scenario, just you brought up the OpenAI Hugging Face scenario. It's like the model, everyone's talking about like the model hacked Hugging Face and they kind of act as the model had some kind of malicious intention. It didn't, it was just trying to do the task.
Eric Fourrier: And then.
Mackenzie Jackson: So you kind of think about if you have secret sprawl in your systems, in your Git repositories, and an agent has access to that, then they could potentially have access to secrets that would, you know, allow them to work in weird ways, access things, delete, even if you've never given them access to those types of things. So there, it's not only that kind of secret sprawl remains a problem and that AI is amplifying it, it's also kind of amplifying the risk of it because we used to have to worry about bad guys getting secrets. Now you kind of have to worry about your own agents, getting a secret, like a naughty child getting access to a gun, you know, from this.
Eric Fourrier: Yeah, definitely. Yeah. And now also knowing that your AI agent can be accessed from the outside either by malicious skill, a prompt ejection, makes it even more dangerous when you think about it.
Mackenzie Jackson: Absolutely. Well, Eric, I like to play a game on this podcast when we start wrapping things up. And it's a terrible game, so I apologize for it, but it's my favorite, and it's called "Would You Rather?" And I'm going to give you two very crappy options, and you have to, and you have to pick one.
Eric Fourrier: Do I have to explain or just pick one?
Mackenzie Jackson: No, you have to explain. Yeah. Explain a little bit, a little bit about you. We'll go with the, we'll go with the secret sprawl kind of options. What would you rather? Would you rather have, let's say, the same amount of secrets, the exact same secrets, either inside your private Git repository, kind of in your history there permanently, or on a developer laptop somewhere? If you had to pick between having them in your Git repository or on your laptop, what is the biggest risk? Which one would you rather?
Eric Fourrier: It's a very good question. I would say three years ago, four years ago, I would have run like in my laptop, but right now, looking at all the attacks, definitely I prefer to have them in the Git repository. And the explanation is pretty simple when you think about it, is if you usually, if you manage to compromise a developer laptop, you have access to the GitHub token and you also have access probably to some locally cloned repo. So the reality is if you manage to breach a developer laptop, you probably already have access to the VCS and all the repo that are inside it.
Mackenzie Jackson: That was not the answer I expected, but okay, okay, but I think your logic is sound. I'm sold. All right, I have another one. Would you rather have all of your dependencies pinned to the current version and you cannot update them? So they're at that any vulnerabilities, any CVEs that come out, you now have to deal with that, or you have to auto-pull the latest version of dependencies? Which would you rather? It's a terrible question. This is a terrible choice.
Eric Fourrier: Honestly, same here. Six months ago, I would have said I prefer to have the dependency pinned to try to avoid like software supply chain attack, even if I would have like vulnerabilities and zero days.
Mackenzie Jackson: But right now, I hope, and it's probably my biggest hope right now, that the package manager and GitHub is going to correct the issue with the cool down and stuff like that. Yeah, I mean, NPM just came out with some, they're doing their own scanning. So we are improving on this matter. We are improving on those matters. And yeah, I think it's at the end of the day, it also needs to come from here because it's much, much rather to, it's easier to correct in the centralized repo and where all the package are than to correct it on every developer machine. And personally, I think you need to do both, because it's like, it's multi-layer, multi-layer defense when you think about it, like you need to have defense everywhere. But yeah, right now, I would say I prefer to have dependency upgrade to the latest, even if I would be very scared every day probably.
Eric Fourrier: It is such an interesting challenge because I've been asking this question a lot and I feel like at the start the answer was kind of like auto-pull, then we went through all of these supply chain attacks and then the answer was pin. But now we're also in this world where like the time for like zero day to be exploited or CVE is like negative now. So, it's kind of, there really is no good answer for this one here. All right, I have one more. This one maybe is a little bit easier, but would you rather use the same password for everything, but it can be highly complex, or you can have different passwords, but they're all stored in Notepad on your phone? I would rather use the same password but highly complex and having all my password not same, same logic and then the first question. I think I'm going to be breached at some point and so if it's so easy to get all my passwords, everything is compromised.
Mackenzie Jackson: Yeah. Yeah.
Eric Fourrier: And if we're honest with each other, I think the vendors have worked tremendously on hashing password. You find very few company that don't do that anymore. Now you have people that are a bit afraid by crypto like being able to break the crypto with quantum algorithm and stuff like that, but I think we're not there yet. So, so yeah, that's why we choose that.
Mackenzie Jackson: Well, Eric, thanks so much for coming on the, coming on the show. It's been awesome and yeah, it's been great to great to see you and hear about the journey about GitGuardian. It's amazing to kind of see how it's all moved. I never would have picked this outcome two years ago, three years ago. So, it's crazy to see where we are, but it's it's been awesome. So, thanks so much for coming in.
Eric Fourrier: Thanks for having me, Mac.
