Let me tell you why security keeps failing in otherwise good software. It's not because developers don't care. It's not because they don't know enough. It's because no one ever clearly said what security actually means. And if security isn't explicit, that means it's optional. 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 shipped a feature and later been told this isn't secure, without anyone quite being able to explain why this episode was made for you. Security requirements are one of the most underrated tools in secure software development. And also one of the least understood. When most people hear requirements, they think bureaucracy. But security requirements aren't politics or policies, they aren't audits, they're not compliance checklists. What they should be is simple, clear, testable statements about how your software must behave to be considered safe and secure. If something matters, we write it down, right? And if we don't write it down, it's just wishful thinking. Here is a scenario that I see all the time. A feature ships and it works. Tests pass. Woo! Later, someone raises a security concern. Perhaps authentication wasn't enforced consistently. There's errors leaking sensitive information, and then the sensitive information is logged. Oh no. And the dev team says, honestly, well, we didn't know we weren't supposed to do that. They're not wrong, right? No one ever said this feature must enforce authentication at every entry point. There was nothing explicit anywhere. Or this data must never be logged, and then it explains what data it is. So developers did what developers always do, right? They filled in the gaps. And security, it got lost along the way. So how do we fix this? Well, a bad approach is assuming everyone has the same idea of what secure means. Because they definitely don't. And if you listen to this podcast regularly, you know that. And when expectations are implied, that means security is optional. And we can't have that. So a better approach would be hoping code review or security tools will just catch this issue later. And don't get me wrong, this helps, but it's reactive, it's expensive, and it's frustrating, and it misses stuff. The best approach we can do is writing security requirements and making them a part of the formal project requirements document. When expectations are crystal clear, developers don't have to guess. They can build the right thing the first time. So you might be thinking, what do security requirements actually look like, Tanya? Security requirements don't need to be long or complicated, but they do need to be specific and clear. So let me give you a whole bunch of examples because I love examples. Okay, example one, authentication. This endpoint must require authentication on every request. Example authorization. Only users with the admin role may perform this action. Input validation or input handling. All user supplied input must be validated before use. Data protection. This sensitive data must never be logged or returned in error messages. And then sensitive data is defined clearly elsewhere. Example, error handling. Errors must return a generic message to the client and log details internally. See how these aren't policies? They're clear and specific instructions. Plus, each one is testable and obviously we like that, right? If you do just one thing after this episode, please do this. Add security requirements to one feature or one ticket that you're working on. And here is how to do it without slowing things down too much. Step one, pick a feature, an endpoint, a change, something you're actively working on. Step two, write two or three security requirements for it. Think in terms of who can access this? What inputs should it be accepting? How it handles that data, what happens when it fails. That's a really important one. Okay, now step three, put those requirements somewhere visible. In a ticket, in the README, in the PR description, or better yet, add it to the project requirements if that's an option for you, if that's something that you have the power to do. So now the security on this feature is no longer guesswork, it's clear, it's precise, and it's testable. Security requirements aren't about control, they're about clarity, and clarity is kindness. When developers know what's expected, then they can meet those expectations. And when we don't know, then we improvise. And improvisation is where vulnerabilities are born, right? 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 Janka, 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.