SPEAKER_00 0:00

Most developers already do code review, but almost no one is taught how to do secure code review. So what usually happens is this: we review for style, for correctness, for would I be able to maintain this? Will I know what this does later? And then the security of the code kind of just gets vibes. Today I want to fix this together. Let's take a look at that. Hi, I'm Tanya Jenka, also known as SheHexPurple. 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 Maze. 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. Maze 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 review pull requests, approve changes, or merge code into shared repos, this episode is for you. And for your information, you do not need to be a security expert to do a secure code review. Secure code review is not about finding clever vulnerabilities. It's about verifying that security controls are present, that they're in the correct spot, and usually doing what they're supposed to do. When I say secure code review, I mean asking some pretty specific questions, such as, are we enforcing authentication where we said that we would? Are authorization checks happening at the right boundary every time? Is untrusted input verified as safe before it's being used? Are secrets, sensitive data, and errors treated the same way that our system expects that they should be? Security controls are just code, and co-review is where we decide whether that code is correct or not. A secure code review checks that controls exist, they're applied consistently, and that they haven't accidentally been bypassed, weakened, or misplaced. And this is the important part. You don't need to understand every attack to do this well. You just need to understand where trust changes and what is supposed to protect that boundary. That's it. When you focus on the controls and trust boundaries, secure code review becomes concrete, repeatable, and pretty fast. Let me show you how security usually slips by during code review in real life. A pull request comes in and it adds a new endpoint or a new handler, or there's a small refactor. The reviewer looks at it and they check the code compiles, the tests pass, the naming looks good, there's nothing obvious that's broken, looks good to me. And then guess what didn't get checked? Right? No one verified whether the endpoint was behind authentication. No one checked whether authorization happened before that action. No one checked that it happened every single time. No one noticed that the input validation was actually happening after that data had already been used in your system. And maybe no one confirmed what happened if a request fails, and so we don't have a plan for that. This isn't because reviewers don't care. That's not it. It's because the code looked reasonable and the review didn't explicitly ask security questions of the reviewer. The security controls weren't obviously wrong. They were just, they're missing, they're misplaced, or they're assumed. And that's how insecure code gets approved by good developers. It's not through negligence, it's through a mission. What should we be looking for during a secure code review? When you are doing your code review, you don't need to inspect everything for security. You only need to focus on additions or changes that affect security controls or trust boundaries. And here are the four areas that matter the most that I would like you to start with. I'm telling you this so that you can just start with four things. Eventually you can do more things, but please just start with these four. One, input and entry points. Any new input, parameter, request body, or event is a risk boundary. Ask, where does this data come from? Is it validated already? What happens if it's malformed or it's malicious? Two, authentication and authorization. Any changes that affect who can do what deserves attention. Ask, who is allowed to trigger this? Is that enforced in code or is it assumed? Do we reuse an existing known safe pattern, or are we just yellowing it and making something new? Three, data handling and secrets. Any changes that touch sensitive data or credentials are high risk. So ask yourself, where does this data live? Is anything being logged that shouldn't be logged? Are secrets pulled from a secret management tool or are they being hard-coded? 4. Error handling and logging. Errors often leak information or hide problems if we don't handle them well. So ask yourself, what happens if this fails? This is an extremely important question. Do we expose internal or sensitive info? Would we know if this was abused? So these four areas catch the most serious issues, and I really want you to start with those four things. And now let's go over the bad, better, best, shall we? A bad approach is trying to mentally simulate every possible attack. That is exhausting and unrealistic and quite frankly a waste of time. A slightly better approach is assuming tooling or the security team will find all the issues later. And yes, they'll find some, but it is far from perfect and it's an expensive approach. The best way to do this is focusing security review on what's changed in terms of security controls and trust boundaries, which means new inputs, new permissions, new data flows, new integrations. When you look for these consistently, secure code review becomes fast and repeatable. If you do just one thing after this episode, please do this. Add a small security checklist to your pull request template. Keep it short, just three to five questions, perhaps the four that I suggested. Let me give you an example actually. Does this change include new inputs? Does it change who can access something? Does it touch sensitive data or secrets? What happens if this fails? You don't need to answer yes to all of these. You just need to think about them as you're reviewing the code. This turns secure code review from vibes into an actual repeatable habit. So for clarity, secure code review isn't about being paranoid, it's about being intentional. And when developers review for risk regularly, security stops being so scary and it starts being part of just regular engineering. 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.