WEBVTT
00:00:00.239 --> 00:00:08.160
Most developers already do code review, but almost no one is taught how to do secure code review.
00:00:08.400 --> 00:00:17.440
So what usually happens is this: we review for style, for correctness, for would I be able to maintain this?
00:00:17.600 --> 00:00:19.359
Will I know what this does later?
00:00:19.600 --> 00:00:23.679
And then the security of the code kind of just gets vibes.
00:00:25.120 --> 00:00:27.359
Today I want to fix this together.
00:00:27.519 --> 00:00:29.280
Let's take a look at that.
00:00:29.600 --> 00:00:33.359
Hi, I'm Tanya Jenka, also known as SheHexPurple.
00:00:33.600 --> 00:00:40.560
Welcome to DevSecStation, a podcast for software developers who want to build more secure software.
00:00:40.799 --> 00:00:50.880
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.
00:00:51.039 --> 00:00:54.799
You can jump in at any episode, at any time.
00:00:55.119 --> 00:00:56.960
No homework required.
00:00:57.759 --> 00:01:00.159
This episode is sponsored by Maze.
00:01:00.799 --> 00:01:08.239
One of the biggest problems in security right now is that every vulnerability or cloud scanner says everything is critical.
00:01:08.400 --> 00:01:10.959
And honestly, no one has time for that.
00:01:11.200 --> 00:01:22.560
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.
00:01:22.879 --> 00:01:34.319
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.
00:01:34.560 --> 00:01:39.760
Learn more about maze at mazehq.com slash devsec.
00:01:40.319 --> 00:01:48.959
If you review pull requests, approve changes, or merge code into shared repos, this episode is for you.
00:01:49.599 --> 00:01:56.079
And for your information, you do not need to be a security expert to do a secure code review.
00:01:56.400 --> 00:02:00.799
Secure code review is not about finding clever vulnerabilities.
00:02:01.040 --> 00:02:09.680
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.
00:02:09.919 --> 00:02:21.199
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?
00:02:21.680 --> 00:02:26.879
Are authorization checks happening at the right boundary every time?
00:02:27.520 --> 00:02:32.560
Is untrusted input verified as safe before it's being used?
00:02:32.800 --> 00:02:40.879
Are secrets, sensitive data, and errors treated the same way that our system expects that they should be?
00:02:41.199 --> 00:02:47.039
Security controls are just code, and co-review is where we decide whether that code is correct or not.
00:02:47.280 --> 00:02:57.439
A secure code review checks that controls exist, they're applied consistently, and that they haven't accidentally been bypassed, weakened, or misplaced.
00:02:57.680 --> 00:02:59.439
And this is the important part.
00:02:59.759 --> 00:03:03.360
You don't need to understand every attack to do this well.
00:03:03.599 --> 00:03:09.520
You just need to understand where trust changes and what is supposed to protect that boundary.
00:03:10.080 --> 00:03:11.280
That's it.
00:03:11.520 --> 00:03:20.400
When you focus on the controls and trust boundaries, secure code review becomes concrete, repeatable, and pretty fast.
00:03:21.360 --> 00:03:27.439
Let me show you how security usually slips by during code review in real life.
00:03:27.759 --> 00:03:34.719
A pull request comes in and it adds a new endpoint or a new handler, or there's a small refactor.
00:03:34.960 --> 00:03:46.240
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.
00:03:46.719 --> 00:03:50.080
And then guess what didn't get checked?
00:03:50.400 --> 00:03:50.719
Right?
00:03:50.879 --> 00:03:54.400
No one verified whether the endpoint was behind authentication.
00:03:54.879 --> 00:03:59.439
No one checked whether authorization happened before that action.
00:03:59.759 --> 00:04:02.240
No one checked that it happened every single time.
00:04:02.400 --> 00:04:09.039
No one noticed that the input validation was actually happening after that data had already been used in your system.
00:04:09.199 --> 00:04:15.120
And maybe no one confirmed what happened if a request fails, and so we don't have a plan for that.
00:04:15.439 --> 00:04:17.439
This isn't because reviewers don't care.
00:04:17.600 --> 00:04:18.560
That's not it.
00:04:18.800 --> 00:04:26.160
It's because the code looked reasonable and the review didn't explicitly ask security questions of the reviewer.
00:04:26.560 --> 00:04:29.920
The security controls weren't obviously wrong.
00:04:30.160 --> 00:04:36.240
They were just, they're missing, they're misplaced, or they're assumed.
00:04:36.639 --> 00:04:40.480
And that's how insecure code gets approved by good developers.
00:04:40.720 --> 00:04:43.920
It's not through negligence, it's through a mission.
00:04:44.800 --> 00:04:48.560
What should we be looking for during a secure code review?
00:04:49.040 --> 00:04:54.800
When you are doing your code review, you don't need to inspect everything for security.
00:04:55.040 --> 00:05:01.759
You only need to focus on additions or changes that affect security controls or trust boundaries.
00:05:02.000 --> 00:05:06.560
And here are the four areas that matter the most that I would like you to start with.
00:05:06.720 --> 00:05:09.680
I'm telling you this so that you can just start with four things.
00:05:09.839 --> 00:05:13.040
Eventually you can do more things, but please just start with these four.
00:05:13.360 --> 00:05:16.000
One, input and entry points.
00:05:16.240 --> 00:05:21.360
Any new input, parameter, request body, or event is a risk boundary.
00:05:21.519 --> 00:05:24.000
Ask, where does this data come from?
00:05:24.240 --> 00:05:25.759
Is it validated already?
00:05:26.000 --> 00:05:28.480
What happens if it's malformed or it's malicious?
00:05:29.040 --> 00:05:31.680
Two, authentication and authorization.
00:05:31.839 --> 00:05:36.160
Any changes that affect who can do what deserves attention.
00:05:36.480 --> 00:05:39.120
Ask, who is allowed to trigger this?
00:05:39.360 --> 00:05:42.240
Is that enforced in code or is it assumed?
00:05:42.560 --> 00:05:49.680
Do we reuse an existing known safe pattern, or are we just yellowing it and making something new?
00:05:50.079 --> 00:05:53.600
Three, data handling and secrets.
00:05:53.839 --> 00:05:58.319
Any changes that touch sensitive data or credentials are high risk.
00:05:58.480 --> 00:06:01.360
So ask yourself, where does this data live?
00:06:01.600 --> 00:06:03.920
Is anything being logged that shouldn't be logged?
00:06:04.079 --> 00:06:08.560
Are secrets pulled from a secret management tool or are they being hard-coded?
00:06:09.839 --> 00:06:10.480
4.
00:06:10.959 --> 00:06:12.720
Error handling and logging.
00:06:12.959 --> 00:06:17.920
Errors often leak information or hide problems if we don't handle them well.
00:06:18.160 --> 00:06:21.759
So ask yourself, what happens if this fails?
00:06:21.920 --> 00:06:24.240
This is an extremely important question.
00:06:24.560 --> 00:06:27.360
Do we expose internal or sensitive info?
00:06:27.839 --> 00:06:30.319
Would we know if this was abused?
00:06:30.800 --> 00:06:37.120
So these four areas catch the most serious issues, and I really want you to start with those four things.
00:06:37.360 --> 00:06:41.279
And now let's go over the bad, better, best, shall we?
00:06:41.600 --> 00:06:46.240
A bad approach is trying to mentally simulate every possible attack.
00:06:46.399 --> 00:06:50.959
That is exhausting and unrealistic and quite frankly a waste of time.
00:06:51.199 --> 00:06:57.360
A slightly better approach is assuming tooling or the security team will find all the issues later.
00:06:57.519 --> 00:07:03.120
And yes, they'll find some, but it is far from perfect and it's an expensive approach.
00:07:03.360 --> 00:07:18.639
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.
00:07:18.879 --> 00:07:25.279
When you look for these consistently, secure code review becomes fast and repeatable.
00:07:25.759 --> 00:07:29.920
If you do just one thing after this episode, please do this.
00:07:30.240 --> 00:07:34.399
Add a small security checklist to your pull request template.
00:07:34.560 --> 00:07:40.160
Keep it short, just three to five questions, perhaps the four that I suggested.
00:07:40.480 --> 00:07:42.319
Let me give you an example actually.
00:07:42.639 --> 00:07:45.279
Does this change include new inputs?
00:07:45.519 --> 00:07:48.000
Does it change who can access something?
00:07:48.240 --> 00:07:51.120
Does it touch sensitive data or secrets?
00:07:51.360 --> 00:07:54.000
What happens if this fails?
00:07:54.639 --> 00:07:57.040
You don't need to answer yes to all of these.
00:07:57.199 --> 00:08:00.160
You just need to think about them as you're reviewing the code.
00:08:00.399 --> 00:08:06.399
This turns secure code review from vibes into an actual repeatable habit.
00:08:06.639 --> 00:08:13.519
So for clarity, secure code review isn't about being paranoid, it's about being intentional.
00:08:13.759 --> 00:08:22.800
And when developers review for risk regularly, security stops being so scary and it starts being part of just regular engineering.
00:08:23.519 --> 00:08:26.160
Thanks for listening to DevSecStation.
00:08:26.319 --> 00:08:31.680
If you enjoyed this episode, please subscribe, share it with a friend, or leave a review.
00:08:31.839 --> 00:08:34.240
It helps more people discover the show.
00:08:34.480 --> 00:08:39.440
If you'd like to learn more, I'm Tanya Jenka, also known as SheHacksPurple.
00:08:39.679 --> 00:08:43.360
And I teach secure coding training for software developers.
00:08:43.600 --> 00:08:46.799
You can find me online at shehackspurple.ca.
00:08:47.519 --> 00:08:49.360
Thank you for being here.
00:00:00.239 --> 00:00:08.160
Most developers already do code review, but almost no one is taught how to do secure code review.
00:00:08.400 --> 00:00:17.440
So what usually happens is this: we review for style, for correctness, for would I be able to maintain this?
00:00:17.600 --> 00:00:19.359
Will I know what this does later?
00:00:19.600 --> 00:00:23.679
And then the security of the code kind of just gets vibes.
00:00:25.120 --> 00:00:27.359
Today I want to fix this together.
00:00:27.519 --> 00:00:29.280
Let's take a look at that.
00:00:29.600 --> 00:00:33.359
Hi, I'm Tanya Jenka, also known as SheHexPurple.
00:00:33.600 --> 00:00:40.560
Welcome to DevSecStation, a podcast for software developers who want to build more secure software.
00:00:40.799 --> 00:00:50.880
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.
00:00:51.039 --> 00:00:54.799
You can jump in at any episode, at any time.
00:00:55.119 --> 00:00:56.960
No homework required.
00:00:57.759 --> 00:01:00.159
This episode is sponsored by Maze.
00:01:00.799 --> 00:01:08.239
One of the biggest problems in security right now is that every vulnerability or cloud scanner says everything is critical.
00:01:08.400 --> 00:01:10.959
And honestly, no one has time for that.
00:01:11.200 --> 00:01:22.560
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.
00:01:22.879 --> 00:01:34.319
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.
00:01:34.560 --> 00:01:39.760
Learn more about maze at mazehq.com slash devsec.
00:01:40.319 --> 00:01:48.959
If you review pull requests, approve changes, or merge code into shared repos, this episode is for you.
00:01:49.599 --> 00:01:56.079
And for your information, you do not need to be a security expert to do a secure code review.
00:01:56.400 --> 00:02:00.799
Secure code review is not about finding clever vulnerabilities.
00:02:01.040 --> 00:02:09.680
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.
00:02:09.919 --> 00:02:21.199
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?
00:02:21.680 --> 00:02:26.879
Are authorization checks happening at the right boundary every time?
00:02:27.520 --> 00:02:32.560
Is untrusted input verified as safe before it's being used?
00:02:32.800 --> 00:02:40.879
Are secrets, sensitive data, and errors treated the same way that our system expects that they should be?
00:02:41.199 --> 00:02:47.039
Security controls are just code, and co-review is where we decide whether that code is correct or not.
00:02:47.280 --> 00:02:57.439
A secure code review checks that controls exist, they're applied consistently, and that they haven't accidentally been bypassed, weakened, or misplaced.
00:02:57.680 --> 00:02:59.439
And this is the important part.
00:02:59.759 --> 00:03:03.360
You don't need to understand every attack to do this well.
00:03:03.599 --> 00:03:09.520
You just need to understand where trust changes and what is supposed to protect that boundary.
00:03:10.080 --> 00:03:11.280
That's it.
00:03:11.520 --> 00:03:20.400
When you focus on the controls and trust boundaries, secure code review becomes concrete, repeatable, and pretty fast.
00:03:21.360 --> 00:03:27.439
Let me show you how security usually slips by during code review in real life.
00:03:27.759 --> 00:03:34.719
A pull request comes in and it adds a new endpoint or a new handler, or there's a small refactor.
00:03:34.960 --> 00:03:46.240
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.
00:03:46.719 --> 00:03:50.080
And then guess what didn't get checked?
00:03:50.400 --> 00:03:50.719
Right?
00:03:50.879 --> 00:03:54.400
No one verified whether the endpoint was behind authentication.
00:03:54.879 --> 00:03:59.439
No one checked whether authorization happened before that action.
00:03:59.759 --> 00:04:02.240
No one checked that it happened every single time.
00:04:02.400 --> 00:04:09.039
No one noticed that the input validation was actually happening after that data had already been used in your system.
00:04:09.199 --> 00:04:15.120
And maybe no one confirmed what happened if a request fails, and so we don't have a plan for that.
00:04:15.439 --> 00:04:17.439
This isn't because reviewers don't care.
00:04:17.600 --> 00:04:18.560
That's not it.
00:04:18.800 --> 00:04:26.160
It's because the code looked reasonable and the review didn't explicitly ask security questions of the reviewer.
00:04:26.560 --> 00:04:29.920
The security controls weren't obviously wrong.
00:04:30.160 --> 00:04:36.240
They were just, they're missing, they're misplaced, or they're assumed.
00:04:36.639 --> 00:04:40.480
And that's how insecure code gets approved by good developers.
00:04:40.720 --> 00:04:43.920
It's not through negligence, it's through a mission.
00:04:44.800 --> 00:04:48.560
What should we be looking for during a secure code review?
00:04:49.040 --> 00:04:54.800
When you are doing your code review, you don't need to inspect everything for security.
00:04:55.040 --> 00:05:01.759
You only need to focus on additions or changes that affect security controls or trust boundaries.
00:05:02.000 --> 00:05:06.560
And here are the four areas that matter the most that I would like you to start with.
00:05:06.720 --> 00:05:09.680
I'm telling you this so that you can just start with four things.
00:05:09.839 --> 00:05:13.040
Eventually you can do more things, but please just start with these four.
00:05:13.360 --> 00:05:16.000
One, input and entry points.
00:05:16.240 --> 00:05:21.360
Any new input, parameter, request body, or event is a risk boundary.
00:05:21.519 --> 00:05:24.000
Ask, where does this data come from?
00:05:24.240 --> 00:05:25.759
Is it validated already?
00:05:26.000 --> 00:05:28.480
What happens if it's malformed or it's malicious?
00:05:29.040 --> 00:05:31.680
Two, authentication and authorization.
00:05:31.839 --> 00:05:36.160
Any changes that affect who can do what deserves attention.
00:05:36.480 --> 00:05:39.120
Ask, who is allowed to trigger this?
00:05:39.360 --> 00:05:42.240
Is that enforced in code or is it assumed?
00:05:42.560 --> 00:05:49.680
Do we reuse an existing known safe pattern, or are we just yellowing it and making something new?
00:05:50.079 --> 00:05:53.600
Three, data handling and secrets.
00:05:53.839 --> 00:05:58.319
Any changes that touch sensitive data or credentials are high risk.
00:05:58.480 --> 00:06:01.360
So ask yourself, where does this data live?
00:06:01.600 --> 00:06:03.920
Is anything being logged that shouldn't be logged?
00:06:04.079 --> 00:06:08.560
Are secrets pulled from a secret management tool or are they being hard-coded?
00:06:09.839 --> 00:06:10.480
4.
00:06:10.959 --> 00:06:12.720
Error handling and logging.
00:06:12.959 --> 00:06:17.920
Errors often leak information or hide problems if we don't handle them well.
00:06:18.160 --> 00:06:21.759
So ask yourself, what happens if this fails?
00:06:21.920 --> 00:06:24.240
This is an extremely important question.
00:06:24.560 --> 00:06:27.360
Do we expose internal or sensitive info?
00:06:27.839 --> 00:06:30.319
Would we know if this was abused?
00:06:30.800 --> 00:06:37.120
So these four areas catch the most serious issues, and I really want you to start with those four things.
00:06:37.360 --> 00:06:41.279
And now let's go over the bad, better, best, shall we?
00:06:41.600 --> 00:06:46.240
A bad approach is trying to mentally simulate every possible attack.
00:06:46.399 --> 00:06:50.959
That is exhausting and unrealistic and quite frankly a waste of time.
00:06:51.199 --> 00:06:57.360
A slightly better approach is assuming tooling or the security team will find all the issues later.
00:06:57.519 --> 00:07:03.120
And yes, they'll find some, but it is far from perfect and it's an expensive approach.
00:07:03.360 --> 00:07:18.639
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.
00:07:18.879 --> 00:07:25.279
When you look for these consistently, secure code review becomes fast and repeatable.
00:07:25.759 --> 00:07:29.920
If you do just one thing after this episode, please do this.
00:07:30.240 --> 00:07:34.399
Add a small security checklist to your pull request template.
00:07:34.560 --> 00:07:40.160
Keep it short, just three to five questions, perhaps the four that I suggested.
00:07:40.480 --> 00:07:42.319
Let me give you an example actually.
00:07:42.639 --> 00:07:45.279
Does this change include new inputs?
00:07:45.519 --> 00:07:48.000
Does it change who can access something?
00:07:48.240 --> 00:07:51.120
Does it touch sensitive data or secrets?
00:07:51.360 --> 00:07:54.000
What happens if this fails?
00:07:54.639 --> 00:07:57.040
You don't need to answer yes to all of these.
00:07:57.199 --> 00:08:00.160
You just need to think about them as you're reviewing the code.
00:08:00.399 --> 00:08:06.399
This turns secure code review from vibes into an actual repeatable habit.
00:08:06.639 --> 00:08:13.519
So for clarity, secure code review isn't about being paranoid, it's about being intentional.
00:08:13.759 --> 00:08:22.800
And when developers review for risk regularly, security stops being so scary and it starts being part of just regular engineering.
00:08:23.519 --> 00:08:26.160
Thanks for listening to DevSecStation.
00:08:26.319 --> 00:08:31.680
If you enjoyed this episode, please subscribe, share it with a friend, or leave a review.
00:08:31.839 --> 00:08:34.240
It helps more people discover the show.
00:08:34.480 --> 00:08:39.440
If you'd like to learn more, I'm Tanya Jenka, also known as SheHacksPurple.
00:08:39.679 --> 00:08:43.360
And I teach secure coding training for software developers.
00:08:43.600 --> 00:08:46.799
You can find me online at shehackspurple.ca.
00:08:47.519 --> 00:08:49.360
Thank you for being here.
