---
title: "Jeroen Willemsen and Ben de Haan -- Dirty little secrets"
url: https://appsecpodcast.com/jeroen-willemsen-and-ben-de-haan-dirty-little-secrets/
date: 2022-01-11
duration_seconds: 2083
guests: ["Jeroen Willemsen", "Ben de Haan"]
topics: ["Cloud and Infrastructure", "DevSecOps and CI/CD"]
audio: https://www.buzzsprout.com/1730684/episodes/9864567-jeroen-willemsen-and-ben-de-haan-dirty-little-secrets.mp3
video: https://www.youtube.com/watch?v=0HGPnQAYFNY
transcript: true
---

# Jeroen Willemsen and Ben de Haan -- Dirty little secrets

*January 11, 2022 · 35 min*

with [Jeroen Willemsen](https://appsecpodcast.com/guests/jeroen-willemsen/), [Ben de Haan](https://appsecpodcast.com/guests/ben-de-haan/)

on [Cloud and Infrastructure](https://appsecpodcast.com/topics/cloud-and-infrastructure/), [DevSecOps and CI/CD](https://appsecpodcast.com/topics/devsecops/)

[Audio](https://www.buzzsprout.com/1730684/episodes/9864567-jeroen-willemsen-and-ben-de-haan-dirty-little-secrets.mp3) · [Video](https://www.youtube.com/watch?v=0HGPnQAYFNY)

## Show notes

Secrets management fails in surprisingly ordinary ways: credentials land in code, deployment files, containers, and cloud resources, then quietly become part of the system’s attack surface. Jeroen Willemsen and Ben de Haan join Chris and Robert to introduce OWASP WrongSecrets, an intentionally vulnerable application built to teach those failure modes. They explain how the project grew from incident-response experience, why cloud services change the threat model, and how teams can reason about blast radius and maturity. The conversation closes with practical guidance for scaling secrets management across an organization and using hands-on challenges to turn abstract advice into memorable engineering lessons.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Jeroen Willemsen and Ben de Haan:  
→ [Jeroen Willemsen on LinkedIn](https://nl.linkedin.com/in/jeroen-willemsen)  
→ [OWASP WrongSecrets](https://owasp.org/www-project-wrongsecrets/)

Mentioned in this episode:  
→ [OWASP WrongSecrets](https://owasp.org/www-project-wrongsecrets/)  
→ [WrongSecrets on GitHub](https://github.com/OWASP/wrongsecrets)  
→ [Secrets management deployment guidance](https://xebia.com/blog/secure-deployment-10-pointers-on-secrets-management/)  
→ [Terraform](https://developer.hashicorp.com/terraform)  
→ [Docker](https://www.docker.com/)  
→ [Kubernetes](https://kubernetes.io/)

Chapters:  
00:00 The dirty little secrets in software delivery  
02:00 How incident response shaped the project  
05:51 Introducing OWASP WrongSecrets  
08:46 Why secrets management keeps failing  
11:22 Cloud storage and common mistakes  
16:33 Maturity, threat models, and blast radius  
19:23 Turning real failures into challenges  
23:03 Secrets hidden in containers and deployment files  
27:36 Advice for security and engineering teams  
30:02 Scaling secrets management  
31:54 Written guidance and project resources  
33:39 Final takeaways

## Transcript

*5,831 words · assemblyai*

**0:00 Chris Romeo:** Jeroen Willemsen is a passionate hands-on security architect with a knack for mobile security and security automation. As a jack of all trades, he's been involved with various OWASP projects and has developed various trainings. He spent over 10 years as a full-stack developer and has worked as a security architect, security lead, and risk manager. Ben DeHaan is a freelance security consultant and engineer with specialties in architecting and implementing cloud security and building secure CI/CD environments in Agile, DevOps, and SRE cultures. Ben believes security should be built in and can be scaled to meet these modern ways of working. Outside of regular work, Ben enjoys hosting security trainings or workshops, and he's an AWS Netherlands meetup regular. Jeroen and Ben join us to speak about their OWASP project, Wrong Secrets. We discuss the problems that secrets bring into our applications and how they can be compromised, as well as how you can explore using wrong secrets to bolster your knowledge of what not to do with secrets, as well as they provide some ideas about how to properly protect secrets. We hope you enjoy this conversation with Jeroen and Ben.

**1:09** You're about to listen to AppSec Podcast. When you're done with this, be sure to check out our other show, High Five.

**1:17** Hey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I am the CEO of Security Journey, and I am flying solo today for a conversation about secrets management. And so, I'm joined by Jeroen Willemsen, who has been with us before on the podcast to talk about security automation and CI/CD, which means he gets out of having to share his security origin story because you've already heard it. But we are joined by Ben DeHaan, and this is Ben's first visit to the podcast. And so, Ben, we always start right off with Hearing people's security origin stories, if there was a comic book about your security story, what would episode 1 or issue 1 contain?

**2:04** Oh, well, actually, I think it would be somewhere the medical guy turning to IT. I always thought I wanted to be a doctor, but actually, I'd been interested in computers Growing up, running my own game servers, etc., etc. So eventually I find myself writing my my thesis, and it was in a hospital setting. But instead of writing the thesis, I was looking at the print queues of doctors and figuring all kinds of security issues within said hospital. So. I thought, well, if I like this, why don't I just go and make a career out of it? So I found myself a traineeship in security, specifically in the SOC SIEM area, combined that with my medical informatics background and moved into security development.

**3:06** So is that— do you have a focus on medical security now, or what's your kind of— where have you landed coming out of that? that world of a medical-focused background?

**3:17** Yeah, I still like to contribute somehow to the field, but I think I'd say I'm all over the place when it comes to the sectors that I work for right now. Obviously, I would like to bring the knowledge that I gained outside to the medical field in some way, but I'm not limited to that one specifically.

**3:43** So, now I'm curious about what are the parallels between focusing on going down a path of becoming a medical professional versus a security professional? Are there any parallels that you saw as you kind of were going in that direction and then changed your focus a little bit?

**4:03** I think primarily this is an incident response. Actually, there's the whole soft side of things. So the soft skills are, of course, really important when it comes to incident response, managing the people, communicating accurately, consistently, and in a way that doesn't, you know, upset everyone and let the incident response go down the drain entirely. And I find that very similar to being in a first aid setting and triaging the initial things, helping people, helping people. That's the thing, right? Regardless of which tools you're using.

**4:46** Yeah.

**4:46** And, I can see that parallel between incident response and a medical professional saving somebody's life. They're going through a process, they're doing a lot of the same things, different final goal, but I I could see how the parallels between those kind of directions. So, yeah, it's great to hear that you made that transition. And, you know, one of the things that's always interesting about asking people this question is no one's ever given me the same answer in 7 years of doing this podcast. Everybody has a different story and everybody comes from different perspectives. And that's what really makes our industry very unique and awesome because people are coming from different perspectives. Yeah.

**5:29** All right.

**5:29** So, Jeroen, at the end of our last interview, after we hung up and stopped recording, we started— I think we even mentioned this other project that you were working on and kind of caught our attention. So, tell us about this other project that you and Ben have been working on here, and then we'll get into the origin of the project. But let's define what the project is first.

**5:51** Yeah. So, Project Oorsprong Secrets is a vulnerable application that is designed to educate people about secrets management. So, we basically show— right now, we have about 12 assignments or challenges, actually, where you have to find a secret that has been hidden wrongly somewhere within the project, whether within a cloud environment or a Docker container or hardcoded in the application code itself or the configuration of the code. And the idea is that while you're hunting for those secrets and you find them with tools that we help you to use or that we hint towards, we hope that people start thinking thinking about, hey, if we can find a secret within this project, then now everybody can find my secret in my project as well. But the only difference is mine is a production project. So now I have to start working on it. So it's basically about spreading awareness a bit, as well as having some fun and games about different situations that we saw when it came to secrets management.

**6:54** And so what's the origin story of the project itself? That's one of the questions I ask every person that comes on here with a particular project. I'm always curious, like, where was the moment, where were you, and what was the moment where you were like, we got to start a project to solve this particular problem?

**7:11** So, this actually started in 2020 when I wanted to prepare a talk for All Day DevOps, which was about secrets management. And then I was like, okay, if I create a lot of slides, it doesn't make sense. Because you need to have some sort of code to explain the problem. So, it becomes tangible. It becomes sensible, something that becomes easy to understand, basically. So, back then, I only had, like, 7 examples which shows why you shouldn't put it in Docker and not in Git directly. But those examples were very rudimentary. So, if I would provide this to anybody without the slides, it just looked like, plain gibberish, basically. But during the presentation, it sort of kind of like makes sense. That's also where Ben and I hooked up together on this project, because at some point I had some trouble and I was under a lot of time pressure, because this is of course done in your spare time, to get some stuff working on Kubernetes. And Ben said, hey, nice to make it work like that, but maybe you should try this and that. That might be easier. And voilà, it was a lot easier to run forward. And then, well, the project went into slumber mode for more than a year. And then, at some time, basically, we got a lot of questions again about secrets management. And then, we figured, okay, we should pick this up again, but now pick it up seriously, which also means try to make it an OWASP project so that we can persist it over time and possibly also transfer it to other leaders over time when we've maintained it for a while. And that's where we're at right now.

**8:46** So, now that we have a perspective on the project and what you were trying to do, let's back up a little bit and talk about this secrets management problem in general. So, I don't want us to assume that all of our listeners understand all the intricate details of the problem that the vulnerable application is presenting. And so, Ben, maybe you can give us some context or some perspective on— let's talk about secrets management as a problem that exists across the world of technology.

**9:15** Yeah. So, Starting out, you might want to, yeah, if you have data you want to keep safe or access you want to keep safe, you need to manage these secrets somewhere. And obviously, that then brings us to the problem of how do you manage this? Eventually, this grows out of control, maybe from your small notebook or your password manager. You now have to— Yeah. Share things. Maybe you have secrets that you don't even want to touch yourself at all. You mean like sensitive data that you kind of want to protect in some way, or you want to scope to a very specific part of your organization. And this is where a lot of problems come in, like access management in general and the scoping, the duration of the secrets. You don't want everyone to have the highest privileges all the time. You might want to give that some temporality. And especially for the automated systems, probably these things shouldn't be very long-lived either. But now, how do you rotate them? And do you have to go and update all your applications all the time. Things break if you rotate a secret, maybe. So you have to build your application to deal with that. That's the kind of problem space that we're operating in. And we often see that in that problem space, that people try to make it work. And then don't— when it works, don't go further to refine and make it nice and make it secure. So, it's not generally one of the sexy topics of information or application security in general. So, we thought that this would need some addressing.

**11:22** Yeah. And I'm chuckling a little bit because your explanation of people just get it to work, working and then just kind of get back out of the way and say, I'm not touching it anymore. Like, that seems like half of cloud configuration. You're like, oh, it's working. So, just everybody step back and, you know, don't get too close to it. Don't touch it. And so, I could see how secrets management plays into that, especially when you start to think about it as a discipline or a set of solutions that are, you know, Amazon and Azure and Google Cloud. And, you know, everybody's got their own secrets vault kind of solution that's supposed to solve this, but they're not, you know, it's not like they're super easy to interact with and set up and whatnot. So, let's— Jeroen, maybe you can take us through some of the pitfalls that we see in this idea of secrets management. Like, you know, we've mentioned a few, like secrets in source code and stuff, but like, what is the entire body of of problem areas that we could have? We've mentioned source code, we've mentioned cloud. What else is there?

**12:30** So, the problem with where you can find secrets for pitfalls is basically all the type of lessons that we might have learned in information security actually apply to secrets management. So, wherever you would've made a mistake in terms of access management, in terms of logging, in terms of misconfiguration, you'll find it again in a microspace of secrets management. So, the answer can become very broad, but at least the pitfalls that we saw a lot, which are also somewhat included and some will be added in the future, are, for instance, container— part of an environment variable inside a container, but then hardcoded as part of the Dockerfile. So, not loaded in after, but directly exposed. Code configuration, Kubernetes secrets, which are committed to Git, misconfigurations if it comes to the secrets management solution, which is either on the access level or at the other direction. And one that's particularly coming by a lot lately and which we'll hopefully add soon to the challenge is when it comes to the CI/CD pipelines. So, for instance, if you set up your systems, and nowadays we all try to do this with continuous deployment, continuous integration pipelines, like solutions like GitLab, GitHub, or whatever the cloud providers provide, And what we often see is that the secrets over there are not very well protected. So when we then have some sort of public project from a company that wants to share their knowledge, then it becomes relatively easy to start extracting the secrets from the pipeline and move forward from there towards any part of the infrastructure. And actually then at some places actually hit up the actual secrets in the infrastructure.

**14:22** Mm-hmm.

**14:24** So that's one of the most recent things. The other thing that's still lingering along is the idea that if you compile something towards machine-level code and then hit the secret in that compilation, then nothing will hurt. So in mobile, we see that happening still a lot, that you have hardcoded secrets in your mobile application, for instance. And something that's still not completely killed but not overly abundantly available is, for instance, people hiding secrets in their JavaScript frontend with some funny obfuscation, which either sometimes just results in minification and sometimes in some sort of encryption, as well.

**15:02** So there's a lot of different places that you probably just— I mean, you made me think of a couple of different areas that wasn't even top of mind as far as where secrets could be hiding within here. So I guess a little bit more of a— I'm going to step back to the 10,000-foot view for a second here before we dive into the specific challenges that are part of this OWASP project and which ones you guys want to point us towards and kind of walk us through. But, and Ben, I'll throw this question to you first and then Jeroen, I'd love to get your take on this as well. But when you think about, when you think about like 2021, okay, supply chain, software supply chain, everybody was thinking software supply chain. It was top of mind for everybody coming into the end of the year of 2021. It was all about logging. Hey, look, logging, we made it. Logging's finally a big issue.

**15:52 Chris Romeo:** Yeah.

**15:52** Now, it was a big issue for not because of logging, but because of the various vulnerabilities in Log4j. Where does secrets management fit into the mind of developers and AppSec people? Like, do you think people— do people see this as the same— have the same priority for this problem that they do for software supply chain, for vulnerabilities in third-party components, or Do you feel like developers that you talk to, do they see the problem? Do they acknowledge the problem? Or is this something that we have to really teach them? We have to— you just have to bring that right to the front of their mind. So, Ben, what are your thoughts on that?

**16:33** When I look at it, the results are mixed there. So, sure, there might be teams out there who are very mature and really look at secrets management as part of their threat model. and consider things like the blast radius of a secret and how long it lives. And for instance, when the supply chain security thing comes along, that they know that, okay, this part could be affected, and now we have to rotate these and these and these secrets. On the other hand, I think there's a lot of teams still at the very early stage of doing any secret management at all, where if some compromise would show up, then probably the entire system would be compromised because they haven't scoped down their secrets to a specific blast radius. So once dev goes, or once the CI/CD pipeline goes, all environments go.

**17:36** Yeah.

**17:38** So, I think there's a lot of people out at sort of kind of the extremes of that maturity lifecycle there.

**17:47 Chris Romeo:** Okay.

**17:47** Yeah, I can definitely see that. Jeroen, any other thoughts about that particular issue from your perspective as far as what you've seen in talking to developers, talking to other security people? Do people really understand this issue and know the gravity of it?

**18:02** Well, similar like Ben was saying, there's a really broad spectrum there. And the funny thing is that even the teams that really have this heavy focus on doing this well sometimes forget to document some secrets, and then we still get into trouble. So, even if you have a high focus on it, having a grip on it is still something else than being aware of the problem, basically. So, in terms of awareness, it goes all over the place. Some people that we've presented, for instance, these challenges to gain some feedback were like, okay, if I looked at your challenge and I don't see the problem. What's the problem? That's okay, right? I mean, why was it a problem? Sure, that's where TruffleHawk is used for, to get a secret. But yeah, what's— for challenge 1, for instance. But why? What's the problem? I do this all the time. Where at the other end was, we got responses like, these first 4 challenges are silly. Nobody is doing this, right? So yeah, it's really all over the place. And that's also very nice about this project that you get, you know, that without any commercial things attached, you can actually just talk about this and get a feeling for it without— and that's the nice thing about OWASP in general, that you can get a feeling for where are we at outside of what we already have seen in the field. Where did you—

**19:23** did you get some of these challenges from the real world? Like, what was the source of these challenges? Because you just kind of— you mentioned it a little bit in passing in your last answer, and now I'm curious as to How did you mine the internet to find these problems so that you could create real-world challenges?

**19:41** I've been in the field for a while, and I've done quite a few pentests, and I did quite a few security coaching type of gigs, and that's where we found most of these. There's one issue in GitHub where we put even more challenges in that are easy to implement to a certain extent, which we also saw in the wild, basically. So, till now, it's all real-life examples. There are also examples that we would love to add, but I don't think we have the resources to implement that correctly so people can experience that. And it becomes very convoluted and very organization-specific, let's just say. But, yeah, most of it was just real-life experience, basically.

**20:21** Okay. So, let's explore a couple of these. So, I'm going to ask you both the same question as far as which challenge is your favorite. And since Ben came to the project after you, Jeroen, I'm going to let him go first so that he can take the one that you probably were like, ah, that was my favorite too, come on. But then we'll come back to you. You might have to fit it— you can't choose the same thing though. You might have to pick an alternative favorite. So Ben, what's your favorite challenge that's in this project?

**20:46** Well, I would definitely say that's challenge number 11, and that's probably what Jeroen was going to say as well. So what this challenge is, is It's very specific to cloud providers. So it's slightly different for each cloud provider, but they all boil down to the same issue, which is there's some kind of privilege escalation path, and you have to get somewhat creative in getting the secret out since from the code, yeah, the code directly interfaces with a specific cloud service.

**21:22** Okay.

**21:22** secret management solution. So there's really, without any advanced debugging tools running during or within the program, there's no way of extracting this secret. So you have to get creative within the configuration of the cloud and run your own resource, assume a certain role, or look at the Terraform definitions of how we have implemented it. and then figure out where the error is. And you can escalate to some different part and figure out the secret from there.

**22:02** So, how are you simulating the cloud environment then? Is this just— are you using a Docker container to kind of— or are you using live cloud connection? You know, like, how are you doing this so that it's more real-world?

**22:16** So, it's actually in a real cloud environment. It's deployed to either AWS and then EKS or GCP and then EKS and Azure AKS.

**22:30** Okay. So, it's real live cloud where the challenges are running. So, it's not like smoke— there's no smoke and mirrors of like, we're just making it look like it's working. Like, you're actually in the cloud environment trying to extract the secret. Okay. Yeah, that's cool. We like that type of real-world exposure. That's something that I'm a big fan of. So, Jeroen, you have to think of another favorite challenge since Ben actually took yours. I could tell by the expression on your face that he did take yours. But so, pick another one and kind of walk us through.

**23:03** There are 2 challenges that are my next favorite, if I can address them both a bit. So, the first one is challenge number 3, where we have something hardcoded into the side of a Dockerfile by means of a Docker env, and then we put a secret inside. So, what you have— so, the way you have to attain that is go over the Docker container image and find out what happened, whether through docker inspect or just at Docker Hub, look at the different layers, and you'll actually see the secret directly. The reason that this is one of my favorite challenges is because a part of me that drove this project was actually my conscience, because when I, at the very beginning, started to do some infrastructure development, a colleague of mine asked, and I wasn't very active in security yet, where do I put the secret? Where do I put the private key? And I was like, well, you shouldn't put it in code. Maybe you should put it in a container. And I felt ashamed of that advice ever since. Of course, it has been corrected. Not a problem at all. But that sort of kind of made me feel guilty. So I really had to create this challenge and make sure that this was very clear as a bad idea. The other challenge that I really like is challenge 9. Challenge 9 is the first cloud environment-related challenge where you have to find a secret in Terraform state. So for those who don't know what Terraform is, Terraform is one of the ways to do infrastructure as code. And then you can use that to instruct certain APIs to do stuff in a generic fashion. And you can, for instance, instruct the cloud providers like AWS, Azure, and Google GCP basically to to configure the cloud environment in a way through Terraform. But Terraform needs to do some state keeping because it needs to understand what's happening, and that's what's stored basically in the Terraform state. And now the nice thing is that during a lot of pen tests, once we reach the Terraform state, we sometimes need to find the key to encrypt the secrets that is also stored in the same Terraform state if it's really in a bad position, or we just find the secrets directly, or sometimes. it's really well done and we can't find squat. But often that's where we start our lateral movement because with the Terraform state secrets, we can have fun. And that's a problem we see in so many places. So in order to fix this challenge, you have to have, of course, a cloud environment where you can deploy the stuff to. And then when you run the script as provided in the READMEs of the project, you basically end up with a Terraform state on your computer, which you can easily go through, and then you will find some funny passwords.

**25:37 Chris Romeo:** Yeah.

**25:37** which is actually the solution to this problem. And this might sound very silly, as in nobody's ever doing that, but till now, and I'd done quite a few pentests, only had a customer or 2 that really didn't have a secret that wasn't downplayable by them, basically, in Terraform state. So all the rest, we always found funny stuff.

**25:58** Yeah, I love the real-world nature of what you're describing here, the fact that you've created these challenges that are not academic, or, you know, that have never— there's a chance they never happened in the real world or never could happen. You've taken things that are real-world, real-life, and you're using this as an educational method to teach people, though. So that's really cool. And I was scanning the OWASP Wrong Secrets project page here, and I noticed one of the contributors was Bjorn Kimmenich. And so any thoughts about taking Wrong Secrets and in providing, making it part of Juice Shop in any way? Or what are your thoughts there?

**26:38** We have ongoing conversations with Bjorn about, hey, would it be fun to have something similar, like, for instance, a CI/CD challenge or something else? But there is no direct overlap at this point in time. Of course, if you look at the Juice Shop, they actually already have some similar challenges already out there. Like, hey, find something specific, find an API key for, or something like that. But the focus for Juice Shop is quite different from Wrong Sequence. Where Juice Shop has a much broader audience, a much broader goal to attain, we really try to stay focused in that sense, which also shows in the way how the container is built. So we don't have some explicit vulnerable components inside. We try to actually maintain that a bit to not have those vulnerabilities in. Where Juice Shop is really about anything that can go wrong, will go wrong. So, you can really learn from it in a broad sense, basically.

**27:36** Yeah, that makes sense. So, one thing I want to make sure we do before, as kind of as we start to conclude our conversation here, is I want to make sure you guys take a moment to give some advice to people who are using Wrong Secrets. They're going to go download it. They're going to go through all the challenges and solve them. What's the solution in general to secrets management though? Like, what are you recommending? And Ben, I'm going to come to you first here. Like, what are you going to tell me as somebody who's like, okay, I didn't really understand this problem before we started this. I went and downloaded wrong secrets. I went through the challenges. I understand the problem now. What do I need to do to make sure I don't have these problems, like, from a high-level perspective in my projects?

**28:21** Right.

**28:22** Yeah.

**28:22** So, So first off, I'd say store the secrets in a safe place. So use a specialized tool for the job, any secrets manager, maybe even a password manager if it's for your personal secrets, for example, use something like 1Password, LastPass, whatnot, KeePass. And then ensure that every secret has a certain blast radius. So if it gets compromised, it's not everything at once that goes. That's really 2 highlights. I would also say that for automated stuff or things that is easy to rotate, making things temporal and really using temporary credentials. is really important. Leverage those tools. Like, I mean, every cloud provider, for example, has some way of providing temporary access to part of the code that's running inside it, be it via roles, be it via managed identities, be it via service account. And these things don't need hardcoded keys stored. They just don't need it unless they really can't run inside said cloud environment. And maybe you have to work in an IoT setup and you need certificates or something to authenticate the cloud. You don't need those things hardcoded. So, that's the top 3 things I would— Okay.

**30:02** Jeroen, what would you add on top of that as far as advice for people that are Thinking, hey, I'm going to go solve— I need to solve this now for my entire organization.

**30:11** So, first of all, do what Ben said. I think that's very solid advice. To add on top of that, make sure your secrets management is part of a threat model. If you haven't done threat modeling first, look up on that. I'm pretty sure there were already quite some cool episodes on threat modeling on this podcast as well. So, listen to that, try to get resources, get in there, try to understand how things work, try to apply it yourself. The next one will be add enough metadata to the secret so that your— when your replacement or the later you after you woke up again the next day still understands what the secret is about. And be ready to move the secret because there's so many solutions on where you can store the secret. And it's not all set in stone because organizations move, so will your secrets management. Make sure that you then understand whether that secret should move or not at all. Yeah. And last but not least, make sure you have your accounting in place. So make sure you can log when somebody accessed the secret and make sure you can also understand who that was. So if some MPA starts hitting it, it should be nice to understand who called the MPA in the first place and that the MPA still actually has some sort of metadata while calling the actual secrets management solution telling who invoked the MPA if you really want to go that route. So make sure it's always personalized, it's always logged so that at least you know what's happening. And the moment somebody is touching something that's not supposed to be touched, hey, at least you know by now. Most of that actually has also been published in a blog by Ben and me, which might be nice to pick up upon. And we can possibly share that link on that blog with 10 takeaways for secrets management.

**31:54** Yeah, definitely. We can add that to the show notes so that our listeners can go read that in more depth as far as how they can solve this problem, because it is fun to try to hack on things and find— solve challenges. But we also want to see our industry get better at just managing secrets in general. Like, I'd love to not be talking about this 5 years from now, but I have a feeling we probably are going to be still talking about it. But it'd be great if we were in a world where, you know, that wasn't an issue. So, any final— Ben, coming to you first— any final kind of call to action or key Any takeaway that you want to give the audience? You want to give them— this is your time to give them homework if you want. I don't know if they do it. I have no idea. But this is the moment where you can give them a homework assignment if you want to.

**32:40** Yeah. Look for anything that you have hardcoded and rotate that and get rid of it. Try to make it somewhere safe, store it somewhere safely. Get rid of those hardcoded secrets, please.

**32:54** Your own, anything? Yeah, it's tough to add on top of that. That's pretty solid advice. But any key takeaway or final takeaway from you? Definitely.

**33:04** As our project run sequence is very young, we would love to get your feedback. So get in touch with us. If you like it, start a project on GitHub. If you don't like it at all, please tell us why so we can maybe improve it in a way that it becomes more explainable. Because this is an issue that goes through all layers of the organization, but we totally understand that we're not reaching out to everybody yet in the way how the content is written. So we're really looking for feedback from you. from all of your listeners, basically. You can contact us in various ways. Just check the GitHub link that will be added to the podcast and get in touch with us. We would love to listen and learn from you, basically.

**33:39** Ben, Jeroen, thank you for your efforts in putting this project together. And I know there's some other contributors out there. So, thank you to everybody who's contributed to this project. And, you know, I'm always just amazed by people in the OWASP community because— and I try to say this all the time so people know, like, You guys aren't getting paid for this. You're doing this in your free time because you want to move our industry forward. And so, you know, I appreciate that and I thank you for that. And to all the contributors who are working on this project as well, thank you for the hours and time they're putting into this to help make our industry better. And so I can't wait to see what project you guys come up with next. So thanks for the time.

**34:17** Thanks for having us.

**34:17** Thank you so much.

**34:19 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast and on the web at www.securityjourney.com/resources/podcast. You can also find Chris on Twitter @EdgeRoute and Robert @RobertHurlbut. Remember, with application security, there are many paths, but only one destination.

---

Source: https://appsecpodcast.com/jeroen-willemsen-and-ben-de-haan-dirty-little-secrets/