Let's normalize something together very quick. If you've ever committed a secret to a repo, you are not alone. And if you haven't, you probably just haven't noticed yet. Trust me, everyone has done it. I know I have. But your repo is not a vault. And just hoping we don't leak secrets is not an actual real strategy. We can do better. Hi, I'm Tanya Jenka, also known as SheHacksPurple. Welcome to DevSecStation, a podcast for software developers who want to build more secure software. In each episode, I'll share a short practical lesson about secure coding, software security, and how to build safer systems without slowing development down. You can jump in at any episode, at any time. No homework required. This episode is sponsored by MAISE. One of the biggest problems in security right now is that every vulnerability or cloud scanner says everything is critical. And honestly, no one has time for that. MAZES uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment and not just theoretically scary. Their AI agents also generate and prioritize fixes that knock out multiple vulnerabilities at once, which is honestly the kind of scaling that security teams really need right now. Learn more about maze at mazehq.com slash devsec. If you've ever copied a token into a config file, pasted an API key into an N file, or shared credentials just to get something working, this episode's for you. Secrets are what computers use to authenticate to each other. API keys, certificates, passwords, tokens, all of those things and more are secrets. And that's what we are going to talk about today. Secrets aren't leaked because developers don't care about security. They leak because the easiest place to put a secret is into the code that uses it. Git is great at remembering things, which is exactly why it's terrible for forgetting secrets. And once a secret has been committed, even briefly, it's effectively public forever. Not because attackers are actively watching you specifically, but because scanning for secrets that have been leaked is automatic, cheap, and consistent. Here's how this usually happens. So you're working locally and you need a token. You paste it into a config file just to test something. You tell yourself, I'm gonna remove that later. But you forget. And later you commit, and that commit gets pushed. A bot scans it within 60 seconds, and your secret has been compromised. Even if you deleted it right away, it could be too late. Malicious actors are very ready to exploit this type of mistake. And then starts the whack-a-mole. Rotate the key, invalidate the token, update the config, hope that nothing else breaks. This is not a developer failure. It's a workflow problem. So, how do we fix this? A bad approach is reacting every time a secret has been leaked. Rotate the keys, send the warnings, talk about it again during the annual training. This approach fails because it treats the symptom and not the cause. But a slightly better approach would be telling developers, please don't put secrets in your code. I guess that helps a bit, but it relies on memory and discipline, and that is far from foolproof. The best approach is changing our workflow so committing secrets is difficult or near impossible. This means secrets live outside our repo in a secret management tool. And then they're injected at runtime programmatically. And our tools stop mistakes before they can cause damage. When the system prevents the leaks for us, developers don't have to be perfect all the time. And I don't know about you, but I'm not perfect. If you do just one thing this week, do this. Get a secret scanner and scan every repo that you actively work on. Here's what I actually mean. Step one, choose a secret scanner. Paid or free, I don't care. It can be built into your platform, it could be a pre-commit hook or a standalone scanner. The specific tool matters less than you actually running it. Step two, scan all the repos that you touch, not just the ones you're proud of and actively working on all of the ones that you are responsible for, please. Then if you find a real secret, here's what you do next. Step three, rotate that secret immediately. That means generating a brand new one. You need to assume it's been compromised, even if it's really old. Even if it probably wasn't used, you must assume the worst here. Step four, move that secret out of the code and put it into the secret management tool. This could be a cloud secret manager, a vault, whatever your team uses. The key point here is that the secret no longer lives in your source control, it lives where secrets should be stored. Step five, update the code so now it pulls the secret from the secret management tool instead of having it all hard-coded into your app. If you don't have a secret management tool yet, then this week's homework is very simple. Ask your boss to get you one. You can frame it like this boss, I found a secret in my code today. That is obviously not good. I don't want it to happen again. This tool will ensure that it never happens again. Please help me make us more secure. You don't need to solve the secrets in all the apps everywhere today. You can just scan your part, fix what you found, and make the next leak much less likely. This is why secrets management matters. Rotating keys might be annoying, but a security incident is way worse. When secrets live outside of your repo and we have tools helping us block mistakes, we can stop playing whack-a-mole with our secrets. Thanks for listening to DevSecStation. If you enjoyed this episode, please subscribe, share it with a friend, or leave a review. It helps more people discover the show. If you'd like to learn more, I'm Tanya Jenka, also known as SheHacksPurple. And I teach secure coding training for software developers. You can find me online at shehackspurple.ca. Thank you for being here.