How to Do Secure Code Review (When You’re Not a Security Expert)

Secure code review isn't about finding obscure vulnerabilities or thinking like an elite hacker. It's about verifying that the security controls your application depends on are actually present, in the right place, and correctly implemented.

This episode is sponsored by Maze.

In this episode of DevSec Station, Tanya Janca explains how developers can perform effective secure code reviews without being security experts. You'll learn what security controls to look for, how trust boundaries help you focus your review, and a simple framework for turning security review from "vibes" into a repeatable engineering practice that meaningfully increases the security of your code. 

You'll learn:

•  why secure code review is about verifying security controls, not hunting for clever vulnerabilities 
•  how trust boundaries help you focus on the code that matters most 
•  the four areas every developer should examine during a security review 
•  why security issues are often missed during otherwise well done code reviews 
•  how a simple checklist can make security review faster, more consistent, and more effective 

Tanya walks through a realistic pull request that passes every normal review, yet still introduces security problems because no one explicitly checked authentication, authorization, input validation, or error handling. She explains why these omissions are process problems (not developer failures) and how focusing on security controls makes reviews far more effective. 

If you do just one thing after listening to this episode:

Add a short security checklist to your team's pull request template. Copy this one! Seriously, right now. Do it.

•  Does this change introduce new inputs or trust boundaries? 
•  Does it change who can access something? 
•  Does it touch sensitive data, secrets, or credentials? 
•  What happens if this code fails? 
•  Are the expected security controls where they should be and correctly implemented? 

You don't need a twenty-point checklist. Three to five thoughtful questions are enough to turn secure code review into a repeatable habit instead of a gut feeling.

DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.

Follow Tanya:

• https://shehackspurple.ca
• https://newsletter.shehackspurple.ca
• https://youtube.com/@shehackspurple
• https://news.letter.shehackspurple.ca
• https://linkedin.com/in/tanya-janca
• https://tanyajanca.com

This episode is sponsored by Maze.

One of the biggest problems in security right now is that every vulnerability 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, 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 need right now.

Learn more about Maze https://mazehq.com/devsec

Episode Transcript

SPEAKER_00 (00:00):
Most developers already do code review, but
almost no one is taught how todo secure code review.

So what usually happens is this: we review for style, for (00:08):
undefined
correctness, for would I be ableto maintain this?
Will I know what this doeslater?
And then the security of thecode kind of just gets vibes.
Today I want to fix thistogether.
Let's take a look at that.

(00:29):
Hi, I'm Tanya Jenka, also knownas SheHexPurple.
Welcome to DevSecStation, apodcast for software developers
who want to build more securesoftware.
In each episode, I'll share ashort practical lesson about
secure coding, softwaresecurity, and how to build safer
systems without slowingdevelopment down.

(00:51):
You can jump in at any episode,at any time.
No homework required.
This episode is sponsored byMaze.
One of the biggest problems insecurity right now is that every
vulnerability or cloud scannersays everything is critical.
And honestly, no one has timefor that.

(01:11):
Maze uses AI agents toinvestigate vulnerabilities in
context, so you can focus on theissues that are actually
exploitable in your environmentand not just theoretically
scary.
Their AI agents also generateand prioritize fixes that knock
out multiple vulnerabilities atonce, which is honestly the kind

(01:31):
of scaling that security teamsreally need right now.
Learn more about maze atmazehq.com slash devsec.
If you review pull requests,approve changes, or merge code
into shared repos, this episodeis for you.
And for your information, you donot need to be a security expert

(01:54):
to do a secure code review.
Secure code review is not aboutfinding clever vulnerabilities.
It's about verifying thatsecurity controls are present,
that they're in the correctspot, and usually doing what
they're supposed to do.
When I say secure code review, Imean asking some pretty specific

(02:14):
questions, such as, are weenforcing authentication where
we said that we would?
Are authorization checkshappening at the right boundary
every time?
Is untrusted input verified assafe before it's being used?
Are secrets, sensitive data, anderrors treated the same way that

(02:38):
our system expects that theyshould be?
Security controls are just code,and co-review is where we decide
whether that code is correct ornot.
A secure code review checks thatcontrols exist, they're applied
consistently, and that theyhaven't accidentally been
bypassed, weakened, ormisplaced.
And this is the important part.

(02:59):
You don't need to understandevery attack to do this well.
You just need to understandwhere trust changes and what is
supposed to protect thatboundary.
That's it.
When you focus on the controlsand trust boundaries, secure
code review becomes concrete,repeatable, and pretty fast.

(03:21):
Let me show you how securityusually slips by during code
review in real life.
A pull request comes in and itadds a new endpoint or a new
handler, or there's a smallrefactor.
The reviewer looks at it andthey check the code compiles,
the tests pass, the naming looksgood, there's nothing obvious

(03:43):
that's broken, looks good to me.
And then guess what didn't getchecked?
Right?
No one verified whether theendpoint was behind
authentication.
No one checked whetherauthorization happened before
that action.
No one checked that it happenedevery single time.
No one noticed that the inputvalidation was actually

(04:05):
happening after that data hadalready been used in your
system.
And maybe no one confirmed whathappened if a request fails, and
so we don't have a plan forthat.
This isn't because reviewersdon't care.
That's not it.
It's because the code lookedreasonable and the review didn't
explicitly ask securityquestions of the reviewer.

(04:26):
The security controls weren'tobviously wrong.
They were just, they're missing,they're misplaced, or they're
assumed.
And that's how insecure codegets approved by good
developers.
It's not through negligence,it's through a mission.
What should we be looking forduring a secure code review?

(04:49):
When you are doing your codereview, you don't need to
inspect everything for security.
You only need to focus onadditions or changes that affect
security controls or trustboundaries.
And here are the four areas thatmatter the most that I would
like you to start with.
I'm telling you this so that youcan just start with four things.

(05:09):
Eventually you can do morethings, 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 comefrom?
Is it validated already?
What happens if it's malformedor it's malicious?
Two, authentication andauthorization.

(05:31):
Any changes that affect who cando what deserves attention.
Ask, who is allowed to triggerthis?
Is that enforced in code or isit assumed?
Do we reuse an existing knownsafe pattern, or are we just
yellowing it and makingsomething new?
Three, data handling andsecrets.

(05:53):
Any changes that touch sensitivedata or credentials are high
risk.
So ask yourself, where does thisdata live?
Is anything being logged thatshouldn't be logged?
Are secrets pulled from a secretmanagement tool or are they
being hard-coded?
4.
Error handling and logging.
Errors often leak information orhide problems if we don't handle

(06:17):
them well.
So ask yourself, what happens ifthis fails?
This is an extremely importantquestion.
Do we expose internal orsensitive info?
Would we know if this wasabused?
So these four areas catch themost serious issues, and I
really want you to start withthose four things.
And now let's go over the bad,better, best, shall we?

(06:41):
A bad approach is trying tomentally simulate every possible
attack.
That is exhausting andunrealistic and quite frankly a
waste of time.
A slightly better approach isassuming tooling or the security
team will find all the issueslater.
And yes, they'll find some, butit is far from perfect and it's
an expensive approach.

(07:03):
The best way to do this isfocusing security review on
what's changed in terms ofsecurity controls and trust
boundaries, which means newinputs, new permissions, new
data flows, new integrations.
When you look for theseconsistently, secure code review
becomes fast and repeatable.

(07:25):
If you do just one thing afterthis episode, please do this.
Add a small security checklistto your pull request template.
Keep it short, just three tofive questions, perhaps the four
that I suggested.
Let me give you an exampleactually.
Does this change include newinputs?
Does it change who can accesssomething?

(07:48):
Does it touch sensitive data orsecrets?
What happens if this fails?
You don't need to answer yes toall of these.
You just need to think aboutthem as you're reviewing the
code.
This turns secure code reviewfrom vibes into an actual
repeatable habit.
So for clarity, secure codereview isn't about being

(08:10):
paranoid, it's about beingintentional.
And when developers review forrisk regularly, security stops
being so scary and it startsbeing part of just regular
engineering.
Thanks for listening toDevSecStation.
If you enjoyed this episode,please subscribe, share it with
a friend, or leave a review.

(08:31):
It helps more people discoverthe show.
If you'd like to learn more, I'mTanya Jenka, also known as
SheHacksPurple.
And I teach secure codingtraining for software
developers.
You can find me online atshehackspurple.ca.
Thank you for being here.