1 of 23

A DEVELOPER'S GUIDE TO MAKING SECURITY REVIEWS SUCK LESS

JAMIE DICKEN

STIRTREK 2026

Hello everyone, it’s so great to be here a StirTrek, and I’m happy you’ve all chosen to spend this next session with me.

If you’re here right now or in the adjacent theaters, it’s most likely because you’ve gone through an internal security review process several times in your career, either because you’ve been told you have to, or you’re trying to do the right thing and get a security expert’s review.

Regardless of the reason, that process has probably sucked at least once.

Maybe it’s taken forever just to get your security review prioritized
Even if it’s prioritized, sometimes they can drag out because your security engineer is busy
You go through what feels to be an endless barrage of questions, some of which don’t make sense
Then when you get recommendations or findings, some of them seem to be irrelevant or actively contradict business needs
Sound familiar?

Unfortunately, this is pretty normal. And now with the emergence of all of these AI coding tools, some of these challenges could get worse before they get better – because feature delivery is accelerating, and the size of those features is increasing. If going through a security review already sucks now, let’s talk about how to make that better before they start to suck even more.

2 of 23

JAMIE DICKEN

Sr. Director of Security Platforms & Architecture at GitLab
Former developer and software engineering manager

Before that, let me introduce myself.

I’m Jamie Dicken, and I’m a Senior Director of Product Security at GitLab. One of the teams I lead is Application Security, and a large part of their remit is performing security reviews of new features before they ship to our platform. Before that, I led Application Security and Infrastructure Security New Relic, so I’ve been in this security review world for a while now.

While the 2^nd half of my career has been focused on security, I actually started out my career as a developer and software engineering manager here locally. Let me tell you, sometimes I hated working with security teams.

They blocked me more than they helped.
It felt like they were incentivized to prevent me from shipping software altogether.
There were times I found their advice absolutely wild. One security team said open source software was too risky, and they tried to roll out a requirement to remove all open source software from our platform in 3 months. There wouldn’t have been a platform left, had we done that.
Other times, I felt they were a second product manager with a completely different backlog of project work for me.

But security was becoming an obvious problem I couldn’t ignore. If I believed the products that my teams and I were building were valuable – and I did – I couldn’t ignore security and risk something bad undoing all of our hard work. That’s why I pivoted into security.

But it didn’t take me long to realize that….

3 of 23

IT SUCKS ON THE APPSEC SIDE, TOO.

4 of 23

APPSEC’S CHALLENGES

AppSec generally grows sub-linearly to the rest of Engineering

Reviews are only part of the AppSec job

The Security Review engagement model is rarely ideal

Let’s talk about why.

First, AppSec generally grows sub-linearly to the rest of Engineering. It frustrates me, every year various security companies put out “the State of AppSec” reports, and it never fails that they recommend a ratio of 1 security engineer to 50 software engineers. I have yet to see that be a common reality. At a previous company, we had a total of 3 AppSec engineers for over 100 engineering teams. The lower your ratio, the less context any of your security engineers can realistically have about your system or service, and the steeper the learning curve they’ll face on your review.

Second, security reviews are only 1 part of an Application Security Engineer’s job. In addition to the other important and time-sensitive security reviews other teams have asked them to do, they’re often also managing bug bounty programs, triaging vulnerabilities, responding to customer inquiries about vulnerability scan results, and dealing with investigations and security incidents for your whole R&D org, not just your team. And they’ve got their own strategic projects and goals too. Their attention is divided.

And let’s be real – most often, the security review engagement model isn’t great….

Security teams often get the message from Engineering that “We need to ship tomorrow. You need to review and approve this today, and if you don’t, we’ll escalate and tell leadership that Security is blocking this.”

And immediately, the security team takes a look and thinks “What am I even looking at? If I don’t find all the issues, there will be vulnerability reports or incidents later, and I’ll get paged in the middle of the night or on the weekend to investigate and coordinate”

5 of 23

THE SYSTEM IS SET UP TO SUCK.

6 of 23

SHIFT LEFT FOR SECURITY REVIEWS ISN’T ENOUGH

Current State

Potential Future State

7 of 23

YOU CAN’T ALWAYS FIX THE SYSTEM, BUT YOU CAN CHANGE YOUR EXPERIENCE WITH IT.

8 of 23

WHAT THE SECURITY REVIEW PROCESS LOOKS LIKE

Context

Ramp-Up

Understand high-level design

Build a Threat Model

Code Review

Penetration Test

Documentation and Write-Up

Prep Work

Execute

But first, we have to understand what a typical security review looks like. That will give us insight as to how to make this better.

First, when a security review request comes in and finally gets assigned to an engineer, the first thing they have to do is figure out what the heck they’re reviewing in the first place. This typically entails reviewing whatever information the Engineering team provided, diving into epic and work item descriptions in whatever tracking system you’re using, clicking on the link that leads to another link that leads to another link, and coming back to ask initial questions.
Then, once they have an understanding of what you’re building and why, they go the next level deep and attempt to understand your high-level system design. This means they’re reviewing whatever architecture diagrams you have and constructing a mental model of how data flows throughout your system.
With this information, they build a threat model. They’re looking for what could go wrong, identifying what problems they should look for in their review, and usually constructing a test plan.
Using that information, they start reviewing code to look for obvious security smells and refine their test plan…
And then they will perform a penetration test, act like an attacker, and try to identify vulnerabilities.
When all of that is done, they document their findings.

So as you can see, Security Reviews generally aren’t small activities. And half of that <CLICK> is just prep work before they can actually start the review.

9 of 23

WHAT THE SECURITY REVIEW PROCESS LOOKS LIKE

Context

Ramp-Up

Understand high-level design

Build a Threat Model

Code Review

Penetration Test

Documentation and Write-Up

Prep Work

Execute

10 of 23

CONTEXT IS KEY

Let’s leave the world of tech for a minute to prove that point.

All of these could in some way to be referred to as a “house” or a “home.” However, you wouldn’t secure these all the same way. You’re going to protect your primary residence much more than you will kids’ backyard igloo they build when the weather’s crazy and they’re off school for a week.

These also have very different security and safety concerns that are inherent to the type of dwelling it is. With the treehouse, you have to worry about someone falling out. With an apartment, you have to worry about your neighbors doing something stupid and putting your unit at risk.

And that’s even before you get to environmental factors like location and part of town that go beyond the houses themselves and influence security needs. Here in Columbus, Ohio, I’ve got very different flooding concerns than someone in Miami Beach.

So if you tell your security engineer that you need help securing a home, and that’s all the information you give them, your security review could get wild real fast.

They could give you requirements that are misaligned to the actual risk profile, meaning you’re either going to over-secure or under-secure your system
They could miss really key threats relevant to you
Or they could suggest controls and requirements that just make no sense

And you’ve got to untangle all of that.

11 of 23

HOW TO COMMUNICATE CONTEXT

What are you building,

and why?

1 paragraph max

Pictures

Data flows, architecture, UX mockups

Your Security Considerations and Threat Model

Other business context and drivers

Reference Links to code, documentation, work tracking items

So when it comes to making a request for a security review…

Don’t give so little information that there’s nothing substantial to review. This is the equivalent of your teenage son who just got his license telling you he’s going to be gone with friends for a few days. I’m gonna need waaaay more details before signing off on that.
But don’t give so much information that you’re forcing them to undergo a 3-day reading assignment that goes down the rabbit hole of links. You’d be counting on them finding uninterrupted focus time before they can even start their review, and good luck with that.
Instead, make it simple. There are 5 key suggestions I have <CLICK>.

First, tell them what you’re building and why. Importantly, make this no more than 1 paragraph long. It should be able to click quickly.
Then help them visualize it. Show them what your system looks like, how data flows, and mockups if you have them. That will solidify their understanding.
This next one might surprise you, but tell them how you view the security of your system. Tell them the security considerations you’ve already made and what you’ve done about them. We’ll talk more about this one later.
Then give them any other business context and drivers. This is the equivalent of telling them you’re building a beach house in Miami, or backyard tree fort you have no intention on moving into.
Then – and only then – should you give them links to all the documentation so they can deep dive once they have a high-level understanding.

With this, you’ve drastically reduced your security engineer’s learning curve and timeline, which will speed up your security review and reduce your wait time. Plus, presenting this information in this way makes it so much easier for your security engineer to reference during their review, which means less forgetfulness and a reduced risk for wacky outcomes.

12 of 23

AI CAN HELP YOU DO THIS

The good news is that AI is really good at summarizing this, which makes your job of packaging and delivering this context really easy.

Now, you might be tempted to ask why AppSec can’t just use AI to create this summary instead. And the reality is that if you don’t package information in an easy-to-digest format, they might very well try.

The problem is they can’t actually fact-check it, and this can lead to bad assumptions, and bad assumptions lead to bad security review results and suckage for everyone.

Let me give you an example outside of technology.

<CLICK> It was long, long ago, Christmas Eve of 2025.
I had bought all the Santa presents. My youngest son wanted a Kindle.
One day, he came home from school having written a letter to Santa, asking all kinds of questions – like if he and Mrs. Claus were related, how Santa could tell all the elves apart, very cute.
My wonderful husband had a brilliant idea: he could use AI to respond!
So he asked Gemini to act like Santa and write a response letter. For context, he uploaded the letter to Gemini, said my son had been great all year, and told Gemini he as getting a Kindle for Christmas.
He looked at the output and was very impressed. The tone was perfect. He knew our son would love it.
But there was a catch.
The output included the line “I’ll make sure the elves make you a great case for it!”
<CLICK> I hadn’t bought a Kindle case.
But my husband wasn’t the one who bought the gifts, so he couldn’t fact-check it.
And if you’re wondering if you can have Prime deliver a Kindle Case within hours on Christmas Eve night, the answer is no.

It all ended up fine. However, this is why you have to aggregate information, because you can spot hallucinations. You can quickly see where scope changed after you wrote your epics or made your system diagrams. AppSec can’t.

13 of 23

WHAT THE SECURITY REVIEW PROCESS LOOKS LIKE

Context

Ramp-Up

Understand high-level design

Build a Threat Model

Code Review

Penetration Test

Documentation and Write-Up

Prep Work

Execute

14 of 23

DON’T WAIT UNTIL THE SECURITY REVIEW TO CONSIDER SECURITY.

15 of 23

Most of us are familiar with this graph, showing that it’s so much harder and expensive to fix bugs the further you go in the SDLC, and this is especially true if the bug you’re talking about isn’t an easy logic flaw, but actually an underlying design issue. If you designed your system to be insecure, that 100X cost factor is that way because you may have to rewrite that feature, change the core UX, and break existing customer workflows.

There’s another class of security flaw, in between systemic design flaw and isolated vulnerability, and that’s missing security features altogether, whether that’s logging, authorization checks, or rate limiting to prevent resource exhaustion. Those aren’t always quick fixes, especially if you discover them right before launch and you have no time left.

That’s why it’s so important to know and anticipate your security requirements in advance, factor them into your project plans, backlogs, and estimates, so there are no surprises before your launch.

How do you do that?

16 of 23

THREAT MODELING

17 of 23

THREAT MODELING CRASH COURSE

What are we working on?

What could go wrong?

What are we going to do about it?

Did we do a good job?

Source: Shostack 4 Question Frame

18 of 23

STRIDE METHODOLOGY FOR THREAT MODELING

S

T

I

R

E

D

Threat

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Elevation of Privilege

What it Means

Pretending to be something or someone other than yourself

Making unauthorized changes to a resource

Claiming you didn’t do something or weren’t responsible for an event (legitimate or not)

Revealing information to someone who should not see it

Exhausting resources needed to provide a service, either total outage or major degradation

Allowing someone to do what they’re not authorized to do

Property it Violates

Authentication

Integrity

Non-Repudiation

Confidentiality

Availability

Authorization

My preferred method is STRIDE, but there are many others out there. I find STRIDE to be one of the most intuitive, and as a long-time builder, I struggle when someone tells me to “think like an attacker” because I am not one. STRIDE cuts through that.

<CLICK> STRIDE is a mnemonic that stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. <CLICK>

Spoofing means pretending to be something or someone other than yourself. If I masqueraded [someone in the room], that’s me spoofing him.
Tampering is making unauthorized changes to something, whether that’s code, data, infrastructure, or other resources. It can be malicious, but also accidental. Who hasn’t accidentally left a where clause off a SQL statement or accidentally committed directly to main by accident?
Repudiation is claiming you didn’t do something or weren’t responsible for an event. Those claims can be true, like disputing fraudulent charges on your credit card. Or they can be false, like in that old Shaggy song “It wasn’t me.” (It was obviously him)
Information Disclosure is revealing information to someone who shouldn’t see it
Denial of Service is taking out or degrading a system so severely it’s practically unusable
And Elevation of Privileges is allowing someone to something they’re not authorized to do. As a normal user of a system, I shouldn’t be able to run arbitrary commands or execute admin functionality.

Those are the threat definitions, but if that’s still too attacker-like for you, instead of thinking what could go wrong, <CLICK> think of what you actually want in a system, and build towards that. For example, you want to know who your users are, what they’ve done, and know they’ve only done things they’re allowed to do. You want data integrity, you want your system to remain up, and you want sensitive data to remain confidential.

Once you’ve gone through STRIDE, you’ve answered that Threat Modeling Question of “What could go wrong?”, and now you’re ready to answer “What are we going to do about it?”. The answer to that question can vary. It could be to put something in your project backlog and budget for it before launch. Perhaps preventing an issue is too hard or expensive – maybe you decide to build a detection so you can respond to it if it happens. Or it could be to acknowledge that it could go wrong, but agree to accept that possibility. At the end, the most important part is to make sure you’ve considered the security of your system, you’ve done what you can within your constraints, and you aren’t surprised at the end.

Now, you can do this process manually, and it’s really good to understand how to do it. AI is also a useful companion here too.

Regardless, your goal with threat modeling isn’t to identify and address absolutely every threat, or you’d never ship. What you’re trying to do is address what’s big and obvious to you, because if something is big and obvious to you as an expert in your system, it’s probably big and obvious to an attacker who’s spent time learning your system too.

The two things we’ve covered in depth – context aggregation, packing, and delivery, and threat modeling – are two of the biggest things you can do to make security reviews suck less. But there are also three much easier and quick wins you can have.

19 of 23

DO THE BASICS

Branch Protection
Use current versions of 3^rd party libraries to tackle easiest Critical/High vulnerabilities
Operational Runbooks
Logs

20 of 23

TIMING IS EVERYTHING

Context

Ramp-Up

Understand high-level design

Build a Threat Model

Code Review

Penetration Test

Documentation and Write-Up

Prep Work

Execute

21 of 23

DON’T FALL INTO A TRAP

“That will never happen.”

“This system or feature isn’t significant enough to attract attacker interest.”

And finally, don’t fall into a trap.

There are two common things that drive security engineers crazy.

The first is when you assert that a bad security outcome will never happen. Security people are trained that it’s not a matter of if, but when something bad happens. Security people are also dealing with your company’s entire portfolio of products and features, not just your own. Saying something like this is dismissive, which causes conflict, which means you’re no longer talking about your review – the thing you actually want to get done – and instead, you’re bickering.

<CLICK>Instead, you can argue that the likelihood of something is low and give your reasons. Then, acknowledge it could happen, and make sure your leadership accepts and that you’re all willing to bear the responsibility for collaborating on response if it happens. That’s it.

And then there’s the argument that your system or product isn’t important enough to attract attacker attention. Again, your security team is focused on your whole attack surface. They see it as a system of interconnected parts, not an isolated system. In fact, some of the worst security incidents have been caused by “old” or “uninteresting” systems that are seen as the initial targets for an attacker, providing a gateway to the rest of the ecosystem.

<CLICK>Same as before – it’s just easier to not go down this path. When you say things like either one of these, security feels like they have to compensate for fundamentally flawed logic – and it will come at the expense of your completed security review.

22 of 23

YOU’RE ALL ON THE SAME TEAM.

23 of 23

THANK YOU!