What do developers need to know about AppSec and building secure software?
We have Tanya Janca, aka SheHacksPurple, on the show to tell us all about it.
We talk about what developers should expect from threat modeling sessions,
as well as concrete tips for securing your apps and services.
This is Talk Python to Me, recorded November 15th, 2024.
Are you ready for your host, Tanya?
You're listening to Michael Kennedy on Talk Python to Me.
Live from Portland, Oregon, and this segment was made with Python.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython,
both accounts over at fosstodon.org, and keep up with the show and listen to over nine years
of episodes at talkpython.fm.
If you want to be part of our live episodes, you can find the live streams over on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube and get notified about upcoming shows.
This episode is sponsored by Posit Connect from the makers of Shiny.
Publish, share, and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.
Posit Connect supports all of them.
Try Posit Connect for free by going to talkpython.fm/Posit.
P-O-S-I-T.
And this episode is brought to you by Bluehost.
Do you need a website fast?
Get Bluehost.
Their AI builds your WordPress site in minutes, and their built-in tools optimize your growth.
Don't wait.
Visit talkpython.fm/bluehost to get started.
Tanya, welcome to Talk Python.
I mean, it's awesome to have you here.
Oh my gosh, I'm so excited to be here.
Thank you for having me, Michael.
Yeah, you're very welcome.
And I'm super excited.
You know, in a good and bad way, excited to have you here because I'm very excited to talk to you.
But some of the stuff that we're going to talk about might be a little unnerving for people out there listening.
They may pause the show and then run off to make some changes to what they're doing and then come back.
And then that part might be a little exciting in a different way.
Yes, it will.
Have you ever had that experience where you're giving a presentation or something and somebody goes gasp in the audience and maybe runs away or something?
I was doing a capture the flag contest once and I was showing people how to do an SQL injection.
And then we just like logged in without a password.
And this woman was like, oh my gosh.
And she literally just she stood up.
She's like, I have to go.
And she told me the next day she fixed three of them at work.
And she just stayed all night.
Oh, amazing.
You made a huge impression.
It was pretty cool.
Yeah, that's pretty awesome.
I've never had that around security, but I was doing an in-person class once for database things, which we're going to touch on databases for sure.
And this had to do with transactions.
And I said, if you do things this way, it doesn't actually use a transaction unless, oh, yes, it does.
And I showed that it did.
And somebody said, I'll be back later.
And they just took off.
Oh my gosh, this is not good.
We have to fix this now.
So, yeah, hopefully no one actually has to do that here.
But I'm sure there's a ton for people to learn.
Speaking of learning, let's start with a little bit about you.
You have a domain, shehackspurple.ca.
That tells us several things about you, I believe.
Purple is interesting.
Hacks is interesting.
And Canada.
Tell us about yourself.
So I was a software developer for a really long time.
And then I switched to security.
And when I was a software developer, I used to also play music in bars and music festivals as sort of my hobby.
But I released albums and did all of that.
So that's why I'm quite the public speaker, because I've been on stage my whole life.
And so I switched to security.
And I became a pen tester, which is Red Team.
And that's where you attack things.
And it's a fence of security.
And I don't mean we swear at people.
But then...
It's the other way around, I believe.
This is the direction the swearing probably goes.
Right?
But then as I was doing pen testing, I kept sitting with the devs.
And I would pair a program with them.
And I would help them fix things.
And I'm like, well, if we threat model this...
And I kept doing AppSec, essentially.
And people are like, you keep doing blue team.
You keep doing defenses.
It's like you can't make up your mind.
And eventually one of them is like, you're a purple team.
And so I was at a conference in Europe.
And on stage during the conference, this woman, she kept playing with her phone on a panel, ignoring the audience.
And I was super shocked.
And finally, she's like, I'm really sorry.
But her company had created WannaCry by accident.
Yeah.
And it had just broken out.
And she's like, so there's this virus.
And it just hit the NHS and took down the hospitals and this and that.
And oh, my gosh.
And so everyone ran out of the room freaking out.
And they all went to check Twitter.
Because that's where everyone was talking.
And so people are like, you have to make a Twitter account.
And so I was like, oh, what will I call myself?
And I was like, she acts computers.
And then it was too long.
Because that was my email address.
She acts computers at gmail.com.
That used to be my email.
But then basically, that was too long.
So I was like, I don't know.
And someone's like, well, you know, you have that purple team thing going.
So I was like, well, it's not like anyone will ever follow me.
So I changed it into She Hacks Purple.
And then it turns out that I really, so then I put some purple in my hair to tease my friend
Kevin.
And it went all from there.
Like, yeah.
I own a lot of purple now.
That's amazing.
Yeah.
It's now part of the vibe, right?
That's awesome.
That's a really cool story.
So you said you've been a programmer for a while and then got into app security and pen
testing.
How did you get into all that?
It was totally an accident.
So like I said, I was in a band.
And so we had this pen tester in our office and he was in a band.
And so we obviously became friends.
And one day I came to his desk and I was like, hey, my band wrote this song called Mandatory
Dance Party.
And we want to make this mobile app where if you're near someone else that has the app,
it goes beep, beep, beep.
Mandatory Dance Party.
And then you both have to dance or else.
And then whoever jiggles their phone the most wins.
I'm like, did you want to make this app with me?
He's like, there's nothing I want to do more.
And so our friendship began.
And then for a year and a half, he just nagged me to become a pen tester.
He's like, you'd be so good.
You'd be really good at it.
You've been doing you've been a dev for like 17 years.
It's time for something new.
And I was like, no, I am the king of software.
This is the best.
I make something out of nothing all day.
It'll never be cooler than this.
But then it turned out it was pretty cool.
And you still get to write code sometimes.
And then eventually I figured out I was not meant to be a pen tester.
I was meant to do app sec.
So I still get to hang out with devs all day.
I'm not alone freezing cold in a data center at night.
And I get to it's like more like a social butterfly type of job where a pen tester is more like
the lone wolf type of job.
Yeah.
You're working on the disassembly, looking for, you know, fuzzing something, looking for a crash.
Yeah.
So you still get to break stuff in app sec sometimes, but like, that's not all you do.
You do a lot of conversations, a lot of brainstorming, and that's better for my extroverted personality.
Yeah.
That's awesome.
You have a newsletter.
People can visit your website and sign up and I'll put links to all those sorts of things
in the show notes for you.
So yeah, a couple of things I wanted to talk about.
First of all, I've seen you given presentations about threat modeling and tell us what is threat
modeling and what are some of the takeaways?
Obviously our audience here is largely Python developers, data scientists, and a ginormous assorted
other that sort of orbits around those spaces.
So they'd probably be pretty interested on the developer data scientist side of threat modeling.
What is it and what's it like for devs?
So threat modeling is sort of like evil brainstorming.
So you get a security person like me in the room, you get a dev or one of the technical leads
for your system, and then you get the product owner.
So the person that understands the business of this app and like why it exists in the world.
And at least those three people.
If more people come, it's better, but that's fine.
And then you talk about what could go wrong and what are you going to do about it?
I have this friend named Adam Shostak who's written a bunch of books about it.
And so I used to ask a ton of questions and then I met him.
And now I ask four things.
What are we doing?
And so then I usually draw it out on a whiteboard.
So like, oh, there's an API and it talks to this and then this happens and then people steal bikes.
Okay.
And then it's like-
Do we have a database?
Is it in the cloud?
Is it in a data center that we own?
Whatever, yeah.
Yeah.
And then I ask questions along the way and then I'm like, so what could go wrong here?
And then it's like, you know, these two things are talking.
Do we authenticate first or do we just talk to any old API?
Right?
And we go through and we come up with some things that could go wrong and we make a list.
And then I'm like, okay, so what are we going to do about these things?
And you talk about basically, is this a serious risk?
Is it scary?
Or is it like, you know what, if that happens, it's not really a big deal and the likelihood is really, really rare.
So maybe we'll accept that risk.
But a lot of them, it's like, you know, if we added a certificate here or we included authentication there, like we can make some small changes.
And if you're during the design phase of the system development lifecycle, it costs you nothing, right?
Or usually it costs you nothing or very little.
And so then you basically improve your design and then you write it all out.
And then hopefully someone approves these changes.
And then at the end, a thing that Adam asks is, did we do a good job?
And that is the magical question.
Because the very first time I did one of these in the government, I did not realize that that's what I was doing to my director.
I was like, well, what about this?
And what about that?
And this could go wrong.
And because I was trying to kill the project because I thought it was a terrible part.
And we did end up canceling it.
But I brought up like all these huge existential risks to this ridiculous project they were thinking of doing.
And he just kept saying, it'll be fine.
And I'll manage that risk.
And I was like, you realize manage that risk means nothing, right?
You're going to do nothing.
So I brought up eight really big risks.
And you want to do nothing about any of them.
I'm like, are we doing it?
Like, do you think we've done a good job here?
Like, you feel proud today?
Because I don't.
And then we started again.
And then eventually over the months, we canceled the project because it was quite silly.
Just to be clear, I usually love it when software development projects go forward.
This was a very special situation where it was not in the taxpayer's best interest.
Yes.
Anyway, I'm like, there's more there.
But I'm like, NDAs.
Yeah, of course.
But usually we come up with like a couple of changes that grossly reduce the risk of the system.
And it's quite fun.
Like, once you start.
So the first time I went to a threat model, I came with my dev background of, I will fix any problem you bring to me.
I just need to do code.
And I can fix whatever you need.
But it's different when it's like, I'm going to try to break things.
You have to learn kind of this new skill set of like, how can I make it do stuff it should not do?
And it took me a while.
And now I'm brutal.
Like, I go to the movies.
I'm like, we could have gotten free.
It's even outside of technology now, huh?
Oh, yeah.
Oh, it's everywhere now.
My significant other who does not work in tech will be like, I'm just trying to threat model this for the kids.
If we go to the pool, they'll have wet bathing suits.
Yeah.
Very nice.
You know, I think there's two different ways to look at this, right?
Obviously, from a developer perspective, you've got to look at, well, what packages or libraries am I using?
And how are we validating input and all those kinds of things?
And I feel like that's one level, but maybe the threat modeling is a little bit broader.
Like, are we storing stuff unencrypted anywhere?
Yeah.
Who could get that?
And it's the thing that makes me nervous.
I said I would be somewhat nervous about this at the beginning.
The stuff that makes me nervous about all of these things is the asymmetry of it.
As a developer or data scientist or somebody in charge of this information and the systems, you have to be right all the time, right?
And if you're ever not right, little Bobby Tables is on you like nothing.
It's like a goalie.
It's like a goalie, right?
Like, you let into goals and everyone's like, you're the worst.
And it's like, I defended against hundreds of shots.
Do I get nothing?
Exactly.
Well, developers shouldn't be on their own in this, though.
That's the whole thing.
So, like, the job of the AppSec person, in my opinion, is to support the developers in making more secure apps, right?
So, booking a threat modeling time with them or, you know, providing a static analysis tool or a secret scanner or whatever to scan their code so that they can make better code.
So, they have help giving them training, giving them, like, a list of super clear requirements at the beginning of the project rather than at the end telling them it's wrong.
That is a huge one.
Like, if someone's going to build an API, I would prefer the API be behind an API gateway if it's publicly accessible.
And I want to do things like turn on authentication and authorization and rate limiting and all sorts of fancy, nice, awesome stuff that they offer.
And so, I tell them at the very beginning of the project, I don't wait until the end and I'm like, well, this design's all wrong.
Like, if, you know what I mean?
Yeah.
But that's what we did back in the day.
Like, when I had my first vulnerability assessment done, I, you know, I'm supposed to go to prod in two days.
And they ran the world's crappiest dynamic scanner on my computer, on my app.
And they're like, you have cross-site scripting.
And this was so long ago.
I searched for cross-site scripting on the internet and there was only three web pages.
So, I'm old, everyone.
And one was this thing called OWASP.
And I was like, what the heck is that?
And it took me quite a while to figure out how to fix it, right?
Like, we've come a long way, but yeah, the developer shouldn't be alone in this anymore.
They should have help.
I'm not saying that every company does have that.
I'm saying every company should.
If you have a bunch of devs, you should have eventually a security person that supports them.
Right.
Maybe sits with them for a few hours a week or a month or something.
And sort of, as you said, like a butterfly sort of moves around the team, hanging out with other people.
Like, oh, you work on the API.
Okay, let me hang out with you a bit this morning.
Ideally, that would be great.
Also, I mean, if you have a big enough company doing something like a security champions program.
So, like each dev team, there's one representative and you just give them way more training and way more time.
And you check in with them regularly.
Like, if I'm working with only like 50 or 60 devs, like you can get to know a lot of them.
But I remember working at this one place and there were 2000 devs and me.
And I was like, okay, so how do I do this?
And just very quickly, there was just like that one person per team that I would talk to all the time.
And I remember, ironically, I went to Montreal on this vacation trip and my car got stuck in the mud because there'd been this big rainstorm.
And I was like tweeting about it and how I was so sad.
And one of my devs came to me and dragged me out of the mud.
And I was like, he is a champion.
I know.
Oh, that's amazing.
And there's benefits to large teams aren't in there.
I know.
I like, it never occurred to me that like I would get an answer.
He's like, hey, I live in Montreal.
Do you need help?
And I was like, I do.
And he's like, you help me all the time.
I'll be right there.
I was just like, oh, that's very cool.
Yeah.
This portion of Talk Python to Me is brought to you by Posit, the makers of Shiny, formerly RStudio, and especially Shiny for Python.
Let me ask you a question.
Are you building awesome things?
Of course you are.
You're a developer or a data scientist.
That's what we do.
And you should check out Posit Connect.
Posit Connect is a way for you to publish, share, and deploy all the data products that you're building using Python.
People ask me the same question all the time.
Michael, I have some cool data science project or notebook that I built.
How do I share it with my users, stakeholders, teammates?
Do I need to learn FastAPI or Flask or maybe Vue or React.js?
Hold on now.
Those are cool technologies, and I'm sure you'd benefit from them.
But maybe stay focused on the data project.
Let Posit Connect handle that side of things.
With Posit Connect, you can rapidly and securely deploy the things you build in Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, ports, dashboards, and APIs.
Posit Connect supports all of them.
And Posit Connect comes with all the bells and whistles to satisfy IT and other enterprise requirements.
Make deployment the easiest step in your workflow with Posit Connect.
For a limited time, you can try Posit Connect for free for three months by going to talkpython.fm/posit.
That's talkpython.fm/P-O-S-I-T.
The link is in your podcast player show notes.
Thank you to the team at Posit for supporting Talk Python.
So you managed it almost, I don't want to endorse Scrum necessarily, but like a Scrum of Scrum equivalent.
So sort of you found somebody or different people from who could sort of represent different segments or apps and stuff and got together with those groups.
Yeah.
So I didn't know what it was called when I started doing AppSec because I didn't have any training, right?
I was just like, all of our apps are a total mess.
I just switched to the security team.
I need to fix this.
And so I was trying to talk to all of them, but very quickly, there was like a person that sort of self-identified as the person who was totally willing to tolerate Tanya and all of her security nerdiness.
And I would hold these little lunch and learns where I was like, oh my gosh, my first one.
I remember I, because I'd been on the dev team and then I switched to the security team and I was like, I'm going to break into a bank at lunch.
Who wants to watch?
I brought donuts.
And everyone's like, you're not going to.
And I'm like, it's a, it's a pretend bank, but I'm going to do it.
And they're like, but donuts, right?
I'm like, yeah.
You just got to choose the right motivation.
I feel like pizza, any sort of carb goes really like it goes over well.
But yeah, I just slowly formed more and more relationships.
And then that is how I got a lot of security done because I'm not their boss.
I can't make them prioritize security.
I need to persuade them that it's important.
And one of those people from my very first program, he became an application security engineer and he just started his first security champions program this year.
And I spoke for them two months ago and it was amazing.
Exciting.
Yeah, that's awesome.
Honestly, I think coming from the software dev side probably gets you a lot of credibility with the software teams.
Yeah, because I can just like read code and stuff and the rest of the security team usually can't.
And also, so I've gotten in trouble for that, though.
I've gotten in trouble with the security team at a couple of places I've worked where they're like, you're always on their side.
And I was like, yeah, but they're right and we're wrong this time.
Because sometimes the security team's being so completely unflexible.
And I'm like, listen, this is like a minute risk if you really think about it.
Where like if you look at the context of this and this, it doesn't generate legitimate business risks.
So, no, I'm not going to upgrade off of this vulnerable library because it's not actually exploitable.
And there's this and this and this precaution.
And like we're actually fine.
And it's going to cost like months and months of time.
And so I'd rather use my social currency on something that really matters.
And I've just had people get really pissed at me on the security team.
Like this plus between username and query.
So, yeah, it's just not good.
It's just not good.
There is, you know, you see all the time, whether it's NPM or pip or whatever package management tool you're using,
you might see, oh, or GitHub.
This library you're using has this vulnerability.
And it sounds scary.
But if the vulnerability is in a portion of it that you literally never use and you never expose the internet, you know, it might be bigger fish to fry.
Who knows?
Maybe not.
But a lot of it's hard to decide.
Insecurity, we call...
As you're saying where to spend your time.
Yeah, so we call that reachability in the InfoSec field.
And so my advice, and not everyone agrees, is basically if something...
So let's say you have the math library.
And the math library has like a thousand different math functions because we love math.
And one of them has a great big bug in it.
But we're not calling that one.
Right.
And it's probably like a denial of service.
If you give it this weird number, it'll overflow and then like loop forever.
And we're never calling it.
Yeah, maybe it's something like really bad.
It's like remote code execution.
Like this sucks.
Okay.
But if it's not reachable from within your code, it's probably not actually a risk.
So let's say it's like the worst one.
It's remote code execution.
I'm like, listen, at some point, could you upgrade off of this?
And I need you to keep scanning it with your software composition analysis tool every time you check your code in to make sure you are not calling that dangerous function.
So if you switch it around and you are no going to prod, but as long as it's not reachable, then we're not causing legit business risk.
But I do want it in the backlog because at some point I'd like you to upgrade off.
But like, let's say it's a medium.
It's like there's so many bugs that I want people to fix.
And some of them aren't even bugs.
Like some of them are, I want you to use content security policy header.
Is that a bug that you're not using it?
In my heart it is, but technically no.
But it's an additional layer of security that basically stops cross-site scripting in its tracks.
Right.
And so I'd rather spend my social currency getting like the entire organization to adopt CSP than to fit like upgrade off of tons of different dependencies that aren't actually hurting anyone.
Yeah, I agree.
I think that makes a lot of sense.
This is why security people yell at me.
Yeah.
Once you've solved all the other security problems, you can come back to the unreachable ones, right?
Yeah, for sure.
Yeah.
I want to dive into your book and you've got a bunch of good recommendations.
But before I do, I just have a quick question.
What do you think, you know, the White House last year or beginning of this year released a thing saying we call for memory safe languages.
And I know you started in C and C++.
I also started C++.
I was kicked a Fortran kicking and screaming for a little while and went back to it and then moved on.
But, you know, we got a lot more options these days, right?
And I know folks at the PSF were actually working with the people at the White House to encourage them to consider Python as one of the options.
But what do you think about this and its implications?
Oh, a lot of software is written in C.
A lot.
Like, maybe half.
Like, it's nuts how much is written of our whole world is written in C.
And they're like, oh, future software.
So, if we're writing brand new software, yeah, I wouldn't write it in C unless I absolutely had to.
I would try to use Rust.
But do I think that everyone's going to suddenly, like, rewrite everything into Rust?
No, I don't believe that.
And it's because of a lot of reasons.
One, like, I'm told it's difficult to develop in Rust because basically there's, like, no libraries for it compared to C.
C is so rich.
There's so many options in C, C++, right?
Because it's been around forever.
There's a zillion code samples that you can copy from and then paste into your code, which you should not do unless you understand it fully.
Yeah.
So many comments there.
So, memory safety.
Like, if you are going to write a new app, I want it to be memory safe.
Yes, absolutely.
Do I expect everyone to rewrite all the old code?
No, no one's going to do that.
No one can afford to do that.
No.
But I'd love to see, like, a framework over top of C and C++ that provided memory safety.
That would be amazing.
I'd pay for that, right?
Like, a library that just, like, I collect your garbage and you don't have to think about it anymore.
Right?
Like, that would be beautiful.
That would solve, that would do a lot of backwards compatibility if we started turning that on in my brain.
Yeah, you talked about the remote code execution issues.
A lot of that has to do with exceeding a buffer we've allocated, using a freed buffer before the pointer was gone.
Like, a lot of it has to do with this memory ownership and stuff that you're talking about.
Yeah, and sometimes mismanagement of objects as well.
And so, basically, you know, you make a memory.
Can I explain this?
Or is this, like, way below?
Okay.
So, we can overflow an integer, a string, a buffer.
But basically, like, you declare a variable of some form.
And let's say you're like, oh, my string's 20.
Cool.
If you put 25 in there, where do you think that extra 5 goes?
Right?
Next bit of execution, probably.
Yeah, it goes somewhere else.
Or a heap or something, yeah.
Yeah, it goes somewhere else in the stack or the heap.
And guess what?
If you happen to do enough of it, you'll find the stack pointer.
And guess what the stack pointer does?
It tells you where the next instruction is.
And what if I tell it where the next instruction is and it's in my overflow?
And what if I've added my own shell code with instructions to do bad stuff, like open a web prompt?
I would like a shell, please.
A shell would be nice.
Thank you.
And then you can execute code on their server remotely, which is the RCE worst in the world thing we do not want to have happen.
And this is because of memory safety.
Because it's not automatically checking the bounds for us.
And because we ourselves have not done perfect input validation, which is a hard thing to get right.
I was teaching it today.
And literally, we spent one hour and 15 minutes just on input validation.
And they had a trillion questions.
And a lot of them were like, yeah, but we don't need to do input validation if it's just internal, right?
And I'm like, are you handling the employee paychecks?
Do you want me to see your employee paychecks?
Then you probably need to validate.
So I'm a slippery fish.
Yeah.
Are you reading from the database that somebody else could have gotten into and leveled up?
Yeah.
There is a lot there, Michael.
There's so much.
It's not good.
It's a negotiation, though, right?
And it's about persuasion.
And it's about what their threat model looks like.
Because if you're handling hundreds of millions of dollars a day, your threat model is very different than I used to work at a place.
And their entire job was to show videos to nurses and doctors that they had to watch each month so they could continue their certification.
And it was like, did they see the video or did they not see it?
Threat model low.
Yeah.
You don't want people to mess it up and pollute it or whatever or take it down.
But at the same time, it's not going to make the front page of the news.
Exactly.
We now know.
Everyone we know that Nurse 7725 has not been up to date.
I mean, it's not great, but it's not the same as social security numbers and all that.
Exactly.
Yeah.
All right.
Let's talk about your book.
I think your book is really good.
Yes.
Now, to be clear, specifically the Alice and Bob Lawrence Cure Coding, because I haven't read the other book.
But if it's in the same style, it seems to me, I'm sure it's also good.
Tell us about your books.
Thank you.
So my new book's called Alice and Bob Lawrence Cure Coding.
And I'm dyslexic.
And I'm about to get diagnosed for ADHD, too.
Because why not?
They go so well together.
Yay.
And so when I read a textbook, I find it really hard.
So I read a zillion books.
Like, I love books.
Sitting still is hard for me.
Reading a textbook, I find really, really hard.
I want that knowledge to be in my brain very badly.
But sitting my butt still for eight hours is really difficult.
And I found traditional textbooks really difficult.
So I started blogging because someone double dog dared me when I worked at Microsoft.
And what else could I do, right?
There's no way out.
They've done it.
I know.
There's nothing I could do.
Brock, you faded me into a corner.
But I just kept blogging and blogging.
And people kept telling me I should write a book.
And publishers started reaching out to me.
I'm like, yeah, but my blog's very casual language.
I use a lot of examples with Alice and Bob.
Alice and Bob were used by mathematicians to explain cryptography to normal people.
So Alice wants to tell Bob a secret.
How does Bob know it was Alice?
And so I just kept using them because we all use them.
And so basically, Wiley approached me.
And they're like, yeah, you can write the weirdest textbook in the whole world.
I'm like, because Alice is going to date people.
He's like, okay.
So my first book was for AppSec engineers and people that want to work in application security
because there was no book of how to do that.
So I wrote a book for past me.
And so then when I thought about Alice and Bob having a sequel, I was like, I want to write
a book for really past me for when I was a software developer.
And so I was like, what should I cover?
And so I covered the 10 top programming languages and the eight most popular frameworks within
reason.
So like some frame, like it was hard to pick the frameworks because I was like, oh, I was
thinking about that when I was reading.
I'm like, oh yeah, these are, it's not so easy.
It was hard.
And so I asked a lot of my followers.
And so you might disagree with me about the frameworks I chose, but I really liked .NET.
So it was obviously going to be in there.
Flask, obviously going to be in there.
But I was like, should I put pandas in here?
Or should I put, I put in jQuery and my advice is don't use jQuery.
Yeah.
But document ready was so good.
Come on.
And so, so it was hard to choose.
And then I wanted to cover like all the different agnostic programming advice, because to be quite
blunt, there's a lot of stuff like input validation that applies to every single language in the
world and every framework.
It just doesn't matter.
And I don't care if some of them say they do some input validation for you.
It's not enough.
Trust me.
And so I wanted, so like the first third of the book is just completely agnostic.
And I've been giving secure coding training basically since before the first book.
And I just keep refining it and refining it and improving and improving it.
And I was like, well, I have a lot to say on this subject now.
And so then I asked all my followers, like, what do you want to see in the book?
And they added a bunch of things.
Like, they're like, oh, I want to see this topic.
I want to see that topic.
So it got even bigger.
But then the end of the book, the last third is the system development lifecycle, all the
security steps, but from a developer's point of view.
Because when I was a dev, it was like, why am I being subjected to this?
Like, what's a threat model?
I remember being in a meeting and this woman was like, you want to do a penetration test on
me?
And then she turned bright red and was like, I don't know if I should be in this meeting.
I was like, no, no, no, no, no, no.
She's like, I was talking.
I'm not a doctor.
This is going to be fun.
I know.
I was like, your web app, your web app.
She's like, you just used a lot of words that were uncomfortable.
I'm like, I'm so sorry.
And so it's like, what to expect when a penetration test happens or like in a threat model, like
bring your awesome ideas of how you would hack your app.
And like, this is maybe how much will be expected from you.
And why we like, what all these tools are and what they do and how you might want to use
them.
Because I feel like sometimes we just, I've heard a lot of security teams say to me, well,
they should know.
I'm like, do you think if they knew they would have done that thing?
No.
Did you, did you tell them it explicitly?
Well, I felt it was implied.
Dude, that's not good enough.
This portion of Talk Python to Me is brought to you by Bluehost.
Got ideas, but no idea how to build a website?
Get Bluehost.
With their AI design tool, you can quickly generate a high quality, fast loading WordPress
site instantly.
Once you've nailed the look, just hit enter and your site goes live.
It's really that simple.
And it doesn't matter whether you're a hobbyist, entrepreneur, or just starting your side hustle.
Bluehost has you covered with built-in marketing and e-commerce tools to help you grow and scale
your website for the long haul.
Since you're listening to my show, you probably know Python, but sometimes it's better to focus
on what you're creating rather than a custom built website and add another month till you
launch your idea.
When you upgrade to Bluehost cloud, you get 100% uptime and 24 seven support to ensure your
site stays online through heavy traffic.
Bluehost really makes building your dream website easier than ever.
So what's stopping you?
You've already got the vision.
Make it real.
Visit talkpython.fm/bluehost right now and get started today.
And thank you to Bluehost for supporting the show.
Yeah, I totally agree with you.
And there's a really, let me do a quick search.
There's a really interesting fact, at least from the Python space.
If you look at the latest survey from the PSF and the JetBrains, how long have you been programming?
There's a little one somewhere.
Yeah.
How long have you been programming professionally?
33% less than a year.
And if you look at less than two years, that's 50, that's half of the people doing software just
got started.
They probably don't even get the little Bobby table jokes, you know?
Yeah, I know.
They need to read XKCD.
Yes, I know.
But, you know, seriously, they, how are they supposed to know?
They're struggling to just figure out how does it compile?
Where do I get a virtual environment?
Why won't I import that thing?
They're, they're just, they're not at the place where they're, they're polishing it and
they're, they're protecting.
They haven't had the experience of, oh, I put it on the internet.
I was hacked in eight seconds.
You know?
It hurts, man.
I remember, so the guy that became my mentor, he gave a talk for my dev team because I ran
the community of practice where I work.
Shocker, me being an extrovert wanting to run a community of practice.
And so I invited him to come and talk and he took one of our apps and he was at the login
screen and he's like, I'm going to break into your app without a password and it's going
to take over a minute just because I'm talking.
And then he just did an SQL injection and he just got in and I was like, what?
No, no, no, no, no.
And then he was like telling us.
And then of course, like all the SQL codes going in my head and I'm like, oh my gosh,
that is very bad.
What if my name, what if my name was quote dash, no quote, semicolon, drop tables, semicolon,
dash, dash.
That's an, that's an interesting name, isn't it?
Right.
We all, we all have special names, but yeah.
So, I for, I forgot when you asked about my book, part of why it is weird is I try to
make it casual language.
So it's really easy to understand.
Yeah.
And I try to get, honestly, I didn't, I didn't put that together, but I had that experience
reading it.
So I think you nailed it.
Thank you.
And I try to use like different ways of explaining the same thing, like with a story and then
like the technical explanation.
And then maybe, there's like a funny story from Alice and Bob, cause Alice will not
put up with unethical dates with pen testers.
And Bob really worships this really cool guy.
Um, and like seeing it, how it applies to people's real lives, I felt like hit home with
a lot of people.
Um, and so, yeah, I just, I want, I feel like security can be really hard and I was like,
how can I make it a lot easier for people?
So that was my goal with the book.
Both of them.
Yeah.
Well, I think it's, I think it's really approachable.
So I want to pull up a few quotes out of it that I thought we could sort of riff on that
I think would be fun here.
So you start out the book by talking about humans and how humans are implicitly trusting
of each other in general, right?
In general.
But you know, that's why we have societies and groups rather than every time we see a
person, we either run away or attack, you know, like that's just not how it works to
be a person.
Right.
And that trust is not necessarily appropriately transferred to computer systems and communication
systems and all.
Right.
So you gave some examples of implicit trust and you also gave a warning or an important
news.
Maybe tell us about this bit.
So basically when we started designing things, like we didn't even have passwords at first.
Like I remember in college, my sister telling her friend, my sister's so crazy.
She has a password on her computer.
Like who wants to log into your stupid computer?
And she thought I was-
What are you working at a bank?
Come on.
Right.
And so now we all have passwords on our computers.
And, but we design our systems the way that our society operates with implicit trust.
Like just imagine like someone comes to your door with a package and they ring the doorbell,
you open it.
But in the animal kingdom, which I have watched a lot of nature documentaries because I have small
children at home, panthers, if they see another panther, it's going down.
They're going to fight or make a new baby panther or both.
That is what happens in the animal kingdom.
Um, and so like they have no trust.
Like some of them like try to kill each other after they try to make baby panthers.
Like they're all over the place because they have no implicit trust.
So you see them alone a lot.
And so when we started designing networks, one of the things we would do is we would, first
of all, a lot of networks in this world today are still flat, which means one firewall around
the outside and that's it.
So if you can get to anything in the network, you can get to everything in the network.
And that is an implied trust.
So then we came up with zoning, like the data, the databases are all in one zone and there's
a firewall around that.
And then we have like a public access zone.
And then we have a deep militarized zone because we think we're badasses, et cetera.
Right.
And, but what happened is if you have an SQL injection, you've gotten behind the firewall and now you
can get to every single database in the entire organization.
You have hit the gold mind.
Right.
So that is bad.
Um, and then we came up with zero trust.
The idea of everything is closed by default.
And unless there's a business requirement, you don't open it.
Right.
So, let's say you have a database and an API and it has a front end and then you have
a service account for those.
So the service account only can talk to those three things.
Oh, and it can talk to the secret management tool to get your secrets because you store your
secrets in a correct place.
You don't put those in source code and just check them in the GitHub.
Please do not do that.
Um, I only do that when I'm trying to prove a point.
But, but then ideally the API checks that who's calling it is its front end and not someone
else.
Right.
And then it authenticates and authorizes to the database.
And we have, and nothing else.
No one else can call that API.
Why would you be calling it unless you're a malicious actor or you're a tester?
Right.
So once the testing phase is over, we're in production, no one else should be talking
to it.
So you only accept connections from there.
And if, if we do zero trust perfectly, it is amazing.
But quite often, we have partial implementations because it's quite a lot of work to implement.
And if you get it wrong, it can be painful.
Yeah.
What do you think about, things like thinks to canaries and those types of things?
Maybe tell me what that is real quick.
Yeah.
So, there's this guy named Harum Mia who goes on risky business all the time, which is
a podcast.
I like.
It's a good podcast.
Yeah.
Patrick Gray and Alex.
What's the guy's first name?
It's not Alex.
Is it?
Um, I thought the guy, like the, is it Nick, the guy that he chats with?
I haven't listened to it in like a year.
Yeah.
I'm sorry.
Last name below, but first name, forget it.
Anyway, they, they do a good show.
Yeah.
So yeah, go on.
They're really good.
It is a fun show and they're so like catty.
I love it.
Like they make fun of everything.
Nothing is sacred.
It's so fun.
Absolutely.
But basically, things canary, the company that Harum Mina works for,
which why I've heard so much about it.
Cause he's always on the show.
They make, basically like these things that go on your network.
So for instance, it could be like a fake word file.
Um, it could be a, some sort of fake file somewhere on your network.
And then you see if it gets stolen and shows up somewhere cause it calls home.
And so people go, so imagine like you have a data breach and then you can see because it
phones home or you search the internet all the time to look for that.
And you see, Oh crap, that's there.
I actually was on stack overflow today.
Um, as a viewer, cause I'm banned for life.
That's a long story.
I tried to answer all the SunGrap questions in one day and they didn't like it.
I feel like they should give you an award, not a ban, but okay.
I know it's a, I agree.
Right.
Some of my answers, they didn't like, like, don't suppress that result.
You have cross-site scripting.
Here's how you fix your code.
They're like, you didn't answer his question.
Down vote, down vote.
But anyway, the internet can be harsh.
What were you saying about this trust and well-meaning?
I don't know.
Yeah.
But so, so basically like this guy was saying his website keeps getting scraped by all his
competitors rather than them typing out the information himself.
So he puts fake musical artists into his database and then he goes to other companies and he searches
for those fake musical artists and then he sends them ceases and desists.
And so like the idea of a canary is that like the canary in the coal mine, but basically
someone steals it.
And then if it can, I believe that some of them can call home, but basically if they use
it somewhere, you can see it's yours.
And then you're like, oh, we are in trouble.
Yeah.
It's an early, early alarm.
You know, the canary in the coal mine sort of deal, right?
I think that it's a cool idea, but I think that if the canary calls out to you, you're already
pretty screwed, right?
Yeah.
It's pretty bad.
I think that it's cool, but it wouldn't be the first security measure I would do.
It would be like, I have an advanced program that's like good and I want it to be super
great.
Yeah.
Sounds good.
All right.
So you say, if you only learn one single thing from your book or this podcast episode,
let's put it, let's adapt it.
I hope it is this.
Design every system with as little implied trust as possible.
It's true.
And I highlighted that in purple for you.
How's that?
It's true.
We want to, so in my first book, I'm like, trust no one, not even your mom, because my
mom accidentally sent me a virus one day and I opened it because it was from my mom.
Oh no.
And so you can't even trust your mom, even if your mom's a brilliant mathematician chemist,
because she can still get a virus on her computer.
Yeah.
Because it turned out grandma sent it to her.
Yeah.
And she trusted grandma.
Grandma's not even sophisticated enough to send a virus.
Is she?
I know.
Well, it turned out she was.
But anyway, so don't trust anyone.
So when you get input to your app, to your API, wherever it comes from.
So that can mean getting stuff out of your database.
So unless it's a static table that you know for sure is trusted, you should be checking the
stuff from the database.
So let's say someone's like filling out a form and then you save it to the database.
So you would want to validate those values.
You save it to the database.
So then let's say an API goes and get some of that data to go do stuff with it.
I would validate those values again before I use that.
And then they put it on a webpage and it has JavaScript angle brackets in it.
Yes.
Then I would output and code it before I put it out there.
And I would have content security policy header and a bunch of other things.
But I digress.
But if we could not trust anything that we get and always validate that it is what we
are expecting.
And if it's not, we reject it.
So we don't try to fix it.
Is it what we're expecting?
And so this can mean like, so let's say it's a date of birth.
So is it first of all, is it a date?
Is it in the past?
Is it more than 150 years in the past?
Because that's less likely.
Is it in the format you're expecting?
Those are some of the things that we could check.
And if it's not any of, if any one of those things are wrong, reject and just say, hey,
actually we're expecting this.
But let's say you need a person's name.
So I work with someone named Luke O'Malley.
Well, he has a single quote in his last name, which is a special character if we are going
to use an SQL database.
So what am I expecting?
I'm expecting letters, lower and uppercase.
And I'm expecting a hyphen and or a single quote.
All of those are on my yes approved list, my allow list.
So I check it against my allow list, not a block list.
Because a block list of bad characters, guess what's going to happen?
Tanya's goes around it.
Yep.
Thanks.
I'm in.
Usually Unicode escape sequence forward or some random thing.
Yes.
There's a zillion ways around it.
And like, I remember when I learned that, how sad I was for all my past apps.
And so you use an approved list of good stuff and you accept the single character and you
accept the hyphen and then you sanitize or escape them.
So sanitize means changing it for a different value.
So you might want to change the hyphen to a pipe and you might, or probably not a pipe,
maybe that's still a special character.
But like, let's say the carrot.
And then you change the single quote to the tilde symbol.
And then those are not a problem.
And then you pass that on.
So you validate that's what you're expecting.
And then you have either escape, sanitize it or escape them.
So just put like a backslash in front of the special characters.
Or maybe HTML or URL encode them to that, you know, percent some numbers, which is the
quote or I don't know, whatever, whatever it resolves to.
It depends on what you want to do with it.
So if you're going to take that and then put it into a parameter and send it to a
parameterized query, maybe, maybe you want to escape it.
It's going to escape it for you when it gets there.
There's a lot of options, but single quotes are kind of the danger zone.
So I want to be careful.
They're definitely tricky.
All right.
Next section.
This is the Python section.
So you have, as you said, a bunch of different technologies and they're quite up to date.
You've got Node.js.
You've got .NET Core, not the old crusty Windows only .NET.
You've got Python, Python 3 stuff.
So I think that's great.
So let's talk about some of the what to do.
Maybe just pick a few off this list that jump out at you that you want to talk about.
Okay.
So some of them are really obvious.
Like, please use Python 3.
It's time to say goodbye to Python 2.
I know that we can still love it in our hearts, but new apps need to be Python 3.
And updating our environment often.
This goes for every framework.
One thing is, is if you find a real security bug, reporting it to the security folks from Python, that is a valuable thing to do.
Whatever programming language or framework you're in, if you feel you found a real legit bug, you should support it or you should report it.
Because as a result, when they fix it, they're fixing it for thousands and thousands and thousands of devs.
And you are a wonderful human.
So that is that.
Pay it forward.
Yeah.
And I want to give a shout out to the PSF and Python folks.
They've made a lot of efforts in putting more time and energy into the security at Python.
Both Mike Fiedler got hired as the security person behind PyPI, the package index.
And Seth Larson got hired for more broadly Python security.
Hopefully I've characterized that right.
But we now have two full-time people working on it.
Whereas before it was kind of core devs and other people contributing their spare time.
Hopefully they could grab it, you know?
So that's good.
And you point out that there's a security at python.org email address for legitimate reports and not hassling busy people.
Yes.
Don't hassle them.
Test and make sure it's repeatable.
Like these people are very busy.
There are so many things.
So one of the things was, so like let's say you're taking, because we're talking about user input.
And we're taking, so the bottom of that page, we're taking user input as a string from your code.
And we can use the template class from the string module rather than other functions for string manipulation.
So if we do that, it's safer.
There's less string overloads.
Like if we avoid using, for instance, fstring and string format for handling user input, because that can be manipulated by the user.
So it sounds weird, but like using the template class from the string module can't be manipulated as easily.
Interesting.
Yeah, I know.
I had to do a lot of research for this.
I bet.
Yeah.
And they just added a new type to the Python type system called a literal string, which works for SQL for things that are not meant to accept user input.
So if you had a literal string, that was a query and you combined it with stuff that came from a regular string, like a user input.
And then you would check it with a Python type checker.
And then you would check it with a mypy type of checker.
That is very cool.
Yeah, yeah, yeah.
That's pretty neat.
There's not too many tools to support it, but the static type checkers do.
Another one I think that's worth calling out here is you talked about, be sure you pin your dependencies.
Yes.
I'm like looking through all of the notes.
You have them.
Pinning.
So I got into like a lot of arguments with my technical editors about this one.
So you want to pin your dependencies, like as you're going through all the different environments and not allow it to update out when you get to prod, because otherwise you're all testing different versions.
Right.
So you want to make sure you're using the same one across the board that you're testing, because otherwise your tests aren't accurate.
Right.
Yeah.
It might be the same, or it could be an important library got an update between when you checked it in and when it got built to a Docker container or something.
And it's different.
But the other thing is, is that you don't want it to be permanently like that forever.
And so like when you're, so it sounds weird.
So you pin it there, but then I can't remember where it is.
I think the, I think the big distinction is, are you building an application or are you building a library?
People are building applications with, because your application should pick its versions.
But if you pick them concretely for the library, you're forcing potentially old vulnerable versions onto people.
Right.
There's this tension of, of what role am I playing, which I think is tricky.
Yes.
So ideally, like if you're like about to go to prod with something, you don't want it changing in different environments.
That could be really bad.
But yeah, like you said, pinning the version.
Well, I'm just like reading it on the screen.
We, so I remember like I was installed, I was doing like a proof of concept with this company.
And in order to install it, it wanted me to downgrade a bunch of NPM dependencies.
And then it showed me that there were huge vulnerabilities in those dependencies that they'd asked me to use.
And I was like, well, like deal breaker buddy.
Right.
And so when you are creating like a product for someone, if they can see that and how it's compiled, like that's a deal breaker for a lot of customers.
Customers are very savvy in regarding security right now.
And I love it.
Yeah, it's really good.
And even putting security aside, you can end up, if you have two libraries, they both use a sub library, a dependency, and they have different pin versions or ones less than or greater than or less than or equal to the other is greater than equal to.
And there's no intersection of those numbers.
You just, you're like, well, I can't run this.
I guess we just can't use these because it'll say, I can't give you both greater than two and less than two at the same time.
Right.
It's a hassle.
But the security bid is also important, obviously.
I agree.
Let's see.
Yeah.
So, bandit.
Bandit's an interesting, interesting tool.
Bandit is a free static analysis tool that specifically is made for Python.
Um, and so some of the mat, so for instance, if you're using Ruby, there's Breakman and it's made just for Ruby and that's it.
So it's awesome because it only cares about your language because it's free and open source.
There's not a giant security team behind it, supporting it.
But if you have never used a static analysis tool, this is an excellent place to start.
It's recommended over and over and over again.
When I, when I teach secure coding in this, I have like this list of free Python resources.
People love Python.
People make a lot of tools for it because they love it.
And Bandit is like really popular.
Yeah.
That's awesome.
And it has a cool logo.
It is very cute.
I like how they call it.
They call it a security linter.
I would say it's a bit more like stack analysis.
Um, cause like it, it definitely is trying to find like sources and syncs, like doing flow analysis.
I don't know if it does symbolic execution.
Like I haven't seen like under the hood.
Um, so like when you buy like a SAS tool, there's like first generation and second generation and like different ways that they work.
And I went, I'd love to know more under the hood of how it works.
Yeah.
It looks really, it looks really cool.
You know, it'll find common things like pickle issues or parsing YAML that might be bad or, you know, all the different things that you're still allowed to do, but people decided probably are not the best choices, but we'll leave it there.
So we don't break things that are doing it, but don't do it.
And kind of like the, the, the pointer safe string copies and C++, don't copy like you used to like, well,
how do I do it now?
And I don't even know anymore.
You know, I feel too that like, so it's called security linter rather than stack analysis.
I feel like it also focuses on code quality and not just security.
And that's helpful too, because if you have higher quality code, it's just going to be more secure.
It's going to be easier to maintain, easier to debug.
So if there is a security problem, you can address it faster.
You have less technical debt if you have higher quality code.
So that's a win as well.
Absolutely.
All right.
Let's talk about SQL relational databases, these kinds of things a little bit.
I think there's, you know, the majority of people out there have an app that talks to a database.
That database is relational.
Usually it's running on its own server.
Yeah.
And when things go bad, it's usually the data that came out of the server that makes the news.
Not always, but usually.
Yeah.
But it can be the server.
What's an advisor?
So, so an SQL server is a server, right?
So it is a server.
You need to patch it.
You need to keep it up to date.
You need to harden it.
It comes with a hardening guide.
You should do all the steps in the hardening guide.
You should make sure that every single person you work with cannot access it, right?
Like it seems really obvious, but you would be surprised.
So like basic server hygiene applies to them.
On top of that, then the SQL software, the SQL server software itself, it can be hardened as well.
And that might sound odd, but like it has updates that it needs.
So you, you want to make sure that you want to make sure that you have locked it down the way that you think that you should.
Yeah.
Then absolutely.
And it can run in different users as well, right?
It's easy to, it's easiest if it just runs as root, but wouldn't it be better if it, in case somebody gets to it and breaks in through it, right?
You don't want them to use it as a lateral movement.
You know, first they got into the server and then they went over to, you know, who knows where.
We also want to make sure ideally that people are not accessing it with database owner unless they're the database owner, right?
Like ideally DBO users are used rarely.
Like let's say you're using MS SQL server.
Yeah.
That has database owner privileges.
I get it.
Cause you're a database administrator, but if your app or your API is accessing the database, we want to use a least privilege approach.
So if you're just doing Slack statements, just do a read only user.
If you're doing cred, create, read, update, delete, then you should use a read, write user.
But DBO is not almost ever actually needed if we think about it.
And so if you don't have that, then less can happen.
That is bad.
Right.
Does it need access to every table or just these 10 tables?
Exactly.
Another thing is like classifying the data that's in each table as sensitive or not sensitive and maybe work for the government.
So maybe it's like classified or secret or top secret or whatever your organization uses.
But if you could classify those things and then label them, a lot of databases now have labels for sensitivity, which is awesome.
But if not just add an extra field, if not just like add a field called sensitivity, and then it's just like public or unclassified or super secret.
Don't show people.
And when you do that, it makes life so much better if there is a security incident, because I know if I need to freak out a little or if I need to freak out a lot.
And if it's not labeled, I have to assume the absolute worst when I respond until I know it's a lower threat.
And that really sucks.
Yeah.
Yeah, for sure.
Another thing that you called out in this section is make sure that logging is turned on.
And you need to do this before something goes bad, because it's the logs that tell you what happened.
Yes.
I think logging, not just for databases, but across the board, logging is super important.
Oh, yeah.
I have a whole giant section in the book about what to log, what not to log, when to log, like exactly what I would love a log to look like, how to protect your logs.
I had a customer and they're like 28 of our customers, their credit cards got nicked and Visa called us and they want us to prove that it wasn't us.
And I'm like, great, let's go get the logs.
They're like, we kind of deleted those.
You know, they're hard to back up.
I said, what?
And they're like, well, we just switched to a new server four months ago.
And so we just deleted the old server.
So like, and we just did that.
So like for four months, we have no records.
And I said, oh my gosh.
And so luckily, it turned out there was a sandwich shop in the same building and they caught an employee was skimming the cards.
And so Visa's like, we figured it out.
And we're like, great.
I'm like, we're all getting fired.
Because they just knew.
But if Visa yanks your ability to use it and your main way of making money is charging money over the Internet, like you've just reduced your ability to do the main purpose of capitalism.
Yeah, life is, you do not want to tick off Visa or MasterCard.
Don't do it.
All that stuff is definitely, it's definitely unnerving.
Let's see some more advice.
You got using ORM if you can, because they basically are immune, but they have a lot of automatic guards against.
You're not writing direct string.
So it's harder to concatenate that stuff.
Yeah.
They will also do a lot of the code for you, depending upon the one that you use.
Like, I've used the entity relationship framework with .NET.
It's like, I'm going to write all your gets and sets and do this and that for you.
I'm like, oh, sweet.
Thanks, buddy.
And even your migrations and stuff.
Yeah.
It's pretty nice.
Yeah.
I'm a fan.
I'm a believer.
I know some people say, oh, it's a little bit slower or whatever.
Like, yeah.
But I like getting stuff done and sleeping at night.
Yeah.
So another one I think is really worth pointing out.
Most important for databases, but also just generally.
Good idea.
Have an extensive and well-thought-out backup plan and try to back up something at least once.
Or try to restore something at least once.
Yes.
I worked somewhere and we had a computer problem and they lost everyone's work in our entire 2,000-person department for the whole week.
So for like the three days.
It was the Wednesday.
And they had lost all of our work.
Everyone's work was not saved.
All of it was gone.
And we go to the backup guys and we're like, okay, do your thing.
And they're like, oh, well, it'll take like at least a month.
And we've never really tried it before.
And we don't think it'll really work.
And so you guys should just still redo it.
And my boss was like, oh, I guess we have to redo it.
And I was like, well, can I hire two new software developers?
And he's like, why?
I'm like, well, because those guys are obviously fired.
Right?
And then I can just like hire two new devs.
It'll be great.
And he's like, Tanya, go back to your room.
But I'm like, we don't need them.
Their job, they just proved that their job is completely worthless.
So let's just get rid of them.
And he was like, stop talking.
Go away.
I understand you're frustrated.
That's not constructive, Tanya.
If I fire them, then they're going to have to fire me because I hire them.
No, I'm just kidding.
You know, one thing that comes to mind, though, is, you know, back in the day,
we had Suburgeon and CVS and SourceSafe and all these things.
And if something went wrong with that, it was just gone.
It was just gone.
And now we have Git.
And if something goes wrong, there might be 100 copies of it.
It's less bad from a software person's perspective.
Three times I have worked somewhere where they lost their code repository.
Yeah.
One of the times I started and one of the employees was junior and he had just deleted it by accident.
And I managed to go to each person's computer and recover a ton of the code and put a lot of it back together.
Another time someone just deleted it and they, I feel, were malicious.
And then another time, basically, we didn't want to wait for shared services.
So the Canadian government decided we would make a department that was the IT department for the whole government.
And they just wouldn't give us a server.
So we just took a server from another room and repurposed it and decided that was our code repo survey.
And so I set up a whole network.
I set up Active Directory and all this.
I installed Team Foundation server.
I did all the stuff.
I set it all up.
And I was like, listen, bud, I did this for you, but you need to back it up every night.
And he promised me he would.
And then five months later, it crashed.
And he's like, are you going to make it go again?
And it was a RAID server.
And it automatically deleted everything.
Yeah.
And so I was like, well, get your backup.
Did its job.
It replicated.
He had not backed it up a single time in five months.
And we lost 11 contractors work for like months, like five months.
I was like, I am so angry.
And he's like, could you spend this weekend making us a new?
I was like, no.
I'm so angry at you.
You'll make it.
He's like, but I don't know how.
I'm like, I guess it's tough to be you.
You're going to learn.
You're going to learn the hard way.
Yeah.
So we're pretty much out of time here.
But I do want to maybe just point out that there is a whole section on Flask, which is pretty awesome.
And you talk a lot about different extensions that you can use, like Flask Secrets for secret management or Flask WTF for SEO.
There are CSRF protection and things like that.
So there's a bunch of stuff in there.
People want to go check that out.
But I think we might need to call it for time.
But yeah, this is good stuff.
If you want to learn more besides obviously purchasing all of my books, I have a free online academy at academy.semgrep.dev.
I don't know if you want me to spell it because that's like...
Yeah.
I'm going to...
I'll find it.
There.
Oh, it's like it's through my full-time job.
So I train on the side and I do stuff for them full-time.
But I put it in our private chat.
And basically, I have a free secure coding course in there.
It's a few years old.
Like the book is all brand new stuff.
But it covers like agnostic, you know, how to do input validation, how to do output encoding, how to make sure that you are using parametrized queries, how to configure every single security header.
And it's just free.
And I do that because I need us to do better real bad.
Please, please, please, please, please.
Yeah.
Well, thank you.
That's awesome.
Thank you.
Yeah.
It's been a really fun conversation.
And I feel like we could probably talk for another two hours, but...
I know.
Well, maybe in another year or two, we'll come back if you'll have me.
Yeah.
That'd be amazing.
Well, let's leave it with a final call to action.
People are...
You have their attention.
They thought, well, maybe I should validate that or learn more or do more.
What do you tell them before we wrap it up?
I want you to go look at whatever framework that you are using and see if there are security features and start using them in your code.
So if you're using Flask, there's a whole bunch of super awesome things in Flask.
Please use them.
Your life will be better.
Yeah, absolutely.
Well, thank you for sharing all your experience and the story.
That's been a lot of fun.
Thank you so much for having me, Michael.
Yeah, you bet.
Bye.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
This episode is sponsored by Posit Connect from the makers of Shiny.
Publish, share, and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.
Posit Connect supports all of them.
Try Posit Connect for free by going to talkpython.fm/Posit.
P-O-S-I-T.
And this episode is brought to you by Bluehost.
Do you need a website fast?
Get Bluehost.
Their AI builds your WordPress site in minutes, and their built-in tools optimize your growth.
Don't wait.
Visit talkpython.fm/bluehost to get started.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I really appreciate it.