1
00:00:00,000 --> 00:00:05,100
Hey everyone, ever had that moment where your favorite app decides to crash right when you're

2
00:00:05,100 --> 00:00:08,560
about to snag those concert tickets, talk about frustrating.

3
00:00:08,560 --> 00:00:10,060
Yeah, that's the worst.

4
00:00:10,060 --> 00:00:12,360
And it makes you wonder what's going on behind the scenes, right?

5
00:00:13,360 --> 00:00:17,040
Well, that's exactly why we're diving into the world of secure coding today.

6
00:00:17,760 --> 00:00:21,800
We're going to figure out how those glitches happen and more importantly, how to avoid them.

7
00:00:22,400 --> 00:00:23,400
Sounds like a plan.

8
00:00:23,600 --> 00:00:28,320
We're lucky enough to have our hands on this really cool document that's basically like

9
00:00:28,320 --> 00:00:31,520
a cheat sheet for building seriously secure software.

10
00:00:32,080 --> 00:00:36,880
It's all about secure coding guidelines and standards stuff that keep your data safe and

11
00:00:36,880 --> 00:00:37,240
sound.

12
00:00:37,920 --> 00:00:38,760
You know, it's interesting.

13
00:00:38,760 --> 00:00:42,120
You mentioned that a lot of folks don't realize that security really starts the very

14
00:00:42,120 --> 00:00:43,960
beginning with the code itself.

15
00:00:43,960 --> 00:00:45,360
It's like building a house, right?

16
00:00:45,360 --> 00:00:46,360
Totally.

17
00:00:46,360 --> 00:00:47,360
You wouldn't want a shaky foundation.

18
00:00:47,360 --> 00:00:48,360
Exactly.

19
00:00:48,360 --> 00:00:52,480
Any weakness in the source card, whether it's an honest mistake or, you know, something

20
00:00:52,480 --> 00:00:54,320
intentional, like a hidden back door.

21
00:00:54,320 --> 00:00:58,720
OK, well, hold on intentional, like someone purposely making the code vulnerable.

22
00:00:58,880 --> 00:01:00,440
It happens more than you'd think.

23
00:01:01,520 --> 00:01:06,400
But whether it's accidental or on purpose, those weaknesses, they can turn into huge

24
00:01:06,400 --> 00:01:08,200
security risks down the line.

25
00:01:08,200 --> 00:01:10,640
We're talking system crashes, data leaks.

26
00:01:11,360 --> 00:01:11,960
You name it.

27
00:01:11,960 --> 00:01:12,960
That's scary stuff.

28
00:01:13,360 --> 00:01:17,840
So if we're thinking of the code itself as the first line of defense, what are some common

29
00:01:17,840 --> 00:01:20,320
ways it becomes a security liability?

30
00:01:20,840 --> 00:01:22,640
What do developers need to watch out for?

31
00:01:22,640 --> 00:01:26,640
Well, this document does a great job of highlighting common vulnerabilities.

32
00:01:26,640 --> 00:01:31,880
In fact, it even mentions a report by OOS, the Open Web application security project.

33
00:01:31,880 --> 00:01:36,960
They put together this list of the top 10 web application security risks.

34
00:01:36,960 --> 00:01:40,400
Think of it like the most wanted list for developers.

35
00:01:40,400 --> 00:01:41,240
Security wise.

36
00:01:41,240 --> 00:01:41,960
Oh, I like that.

37
00:01:41,960 --> 00:01:44,360
So it's like a teaching of what not to do basically.

38
00:01:44,360 --> 00:01:44,880
Exactly.

39
00:01:44,880 --> 00:01:47,880
And one of the big ones on that list is something called a buffer overflow.

40
00:01:47,880 --> 00:01:50,680
Buffer overflow sounds kind of technical.

41
00:01:50,680 --> 00:01:53,800
It can be, but imagine this, you're on a website, right?

42
00:01:53,800 --> 00:01:55,840
And there's a form asking for your address.

43
00:01:55,840 --> 00:01:58,960
OK, yeah, I filled that a million of those behind the scenes.

44
00:01:58,960 --> 00:02:02,800
The system sets aside a certain amount of memory to store whatever you type in.

45
00:02:03,440 --> 00:02:08,840
But what if a hacker comes along and enters an address that's like a mile long way longer

46
00:02:08,840 --> 00:02:10,200
than what the system is expecting?

47
00:02:10,200 --> 00:02:11,200
Uh-oh.

48
00:02:11,200 --> 00:02:13,120
I have a feeling that's not good.

49
00:02:13,120 --> 00:02:14,120
It's not.

50
00:02:14,120 --> 00:02:19,640
Without the right safeguards in place, that extra data spills over, overflows from the space

51
00:02:19,640 --> 00:02:24,600
it was given, like trying to cram a month's worth of clothes into a tiny overnight bag.

52
00:02:24,600 --> 00:02:26,080
OK, I can picture that.

53
00:02:26,080 --> 00:02:31,680
And that overflow can end up overwriting other important data, which can really mess things up,

54
00:02:31,680 --> 00:02:33,720
make the whole application go, hey, wire.

55
00:02:33,720 --> 00:02:34,720
Yikes.

56
00:02:34,720 --> 00:02:36,560
So input validation is key here.

57
00:02:36,560 --> 00:02:40,360
It's like having a security guard at the door, making sure nobody brings in more than

58
00:02:40,360 --> 00:02:41,360
they should.

59
00:02:41,360 --> 00:02:42,360
Exactly.

60
00:02:42,360 --> 00:02:44,240
You need those checks and balances to prevent chaos.

61
00:02:44,240 --> 00:02:45,360
Makes sense.

62
00:02:45,360 --> 00:02:46,960
Now, there was something else in here that caught my eye.

63
00:02:46,960 --> 00:02:50,040
To achieve to you, what in the world is that?

64
00:02:50,040 --> 00:02:51,040
Ah, yes.

65
00:02:51,040 --> 00:02:54,080
To achieve to you, time of check to time of use.

66
00:02:54,080 --> 00:02:55,080
It's a mouthful, I know.

67
00:02:55,080 --> 00:02:56,080
It's a mouthful.

68
00:02:56,080 --> 00:02:57,480
And it sounds a little ominous to be honest.

69
00:02:57,480 --> 00:02:58,480
It can be.

70
00:02:58,480 --> 00:03:03,520
It's all about those tiny split-second gaps in time that can be exploited.

71
00:03:03,520 --> 00:03:06,280
Think of it like buying a concert ticket online.

72
00:03:06,280 --> 00:03:09,280
The website says there's one left you go to buy it and bam.

73
00:03:09,280 --> 00:03:10,720
Someone else got it first.

74
00:03:10,720 --> 00:03:11,720
Ugh.

75
00:03:11,720 --> 00:03:12,720
Don't even remind me.

76
00:03:12,720 --> 00:03:13,720
Happens every time.

77
00:03:13,720 --> 00:03:16,920
But how does that relate to security vulnerabilities?

78
00:03:16,920 --> 00:03:22,280
Well, that split-second between checking for something and then actually using it.

79
00:03:22,280 --> 00:03:24,200
That's where the vulnerability lies.

80
00:03:24,200 --> 00:03:27,480
Let's say this system checks if you have permission to open a file.

81
00:03:27,480 --> 00:03:32,840
But in that tiny gap before you actually open it, an attacker swaps it for something malicious.

82
00:03:32,840 --> 00:03:36,280
Wait, so I think I have access, but I'm actually getting something totally different.

83
00:03:36,280 --> 00:03:37,280
Exactly.

84
00:03:37,280 --> 00:03:39,200
It's a bait and switch on a technical level.

85
00:03:39,200 --> 00:03:40,800
That is seriously sneaky.

86
00:03:40,800 --> 00:03:44,400
Like someone swapping out the stage props right before the curtain goes up.

87
00:03:44,400 --> 00:03:45,400
Exactly.

88
00:03:45,400 --> 00:03:50,880
Timing issues, there's some of the trickiest to catch and fix because they happen so fast.

89
00:03:50,880 --> 00:03:55,080
Okay, you've definitely given me a whole new appreciation for the complexity of all this.

90
00:03:55,080 --> 00:03:56,760
It's a wild world out there.

91
00:03:56,760 --> 00:04:00,920
Speaking of wild, this document also talks about back doors.

92
00:04:00,920 --> 00:04:04,000
I always thought those were things hackers created to break in.

93
00:04:04,000 --> 00:04:05,640
That's a common misconception.

94
00:04:05,640 --> 00:04:08,960
It's true that hackers love to exploit them, sure.

95
00:04:08,960 --> 00:04:12,880
But back doors can actually serve legitimate purposes, too.

96
00:04:12,880 --> 00:04:15,960
Really, tell me more about that because that's not what I would have thought.

97
00:04:15,960 --> 00:04:17,760
So back doors, right?

98
00:04:17,760 --> 00:04:22,520
I get that hackers love them, but you're saying there's a legit reason for them to exist.

99
00:04:22,520 --> 00:04:28,040
Sometimes, yeah, think of them like those hidden passages and old mansions, you know.

100
00:04:28,040 --> 00:04:32,560
Sometimes for secret rendezvous, but sometimes just a handy shortcut for the staff.

101
00:04:32,560 --> 00:04:33,560
Interesting.

102
00:04:33,560 --> 00:04:36,800
So how do they figure into this whole secure coding thing?

103
00:04:36,800 --> 00:04:41,040
Well, sometimes developers will actually build in and back door on purpose while they're

104
00:04:41,040 --> 00:04:42,840
still working on the software.

105
00:04:42,840 --> 00:04:44,640
It makes sense like a shortcut to test things out.

106
00:04:44,640 --> 00:04:45,640
Exactly.

107
00:04:45,640 --> 00:04:47,920
Makes things quicker, easier to troubleshoot.

108
00:04:47,920 --> 00:04:49,320
But, and this is important.

109
00:04:49,320 --> 00:04:50,880
They forget to board it up when they're done.

110
00:04:50,880 --> 00:04:51,880
You got it.

111
00:04:51,880 --> 00:04:56,760
If they don't get rid of that back door before the software goes live, that's a five-alarm security

112
00:04:56,760 --> 00:04:57,760
risk.

113
00:04:57,760 --> 00:04:59,400
Oh, yeah, anyone could just wall-trade in.

114
00:04:59,400 --> 00:05:00,400
Exactly.

115
00:05:00,400 --> 00:05:05,680
That's why secure coding is so big on removing any kind of temporary access point and sticking

116
00:05:05,680 --> 00:05:09,000
to strict security rules throughout the whole development process.

117
00:05:09,000 --> 00:05:12,040
It's like making sure all the doors and windows are locked up tight before you head

118
00:05:12,040 --> 00:05:13,040
out, right?

119
00:05:13,040 --> 00:05:14,040
Hey, it's high sleep.

120
00:05:14,040 --> 00:05:18,800
Okay, so we've talked about code vulnerabilities themselves, but what about how different

121
00:05:18,800 --> 00:05:21,480
software systems talk to each other?

122
00:05:21,480 --> 00:05:24,040
I'm thinking APIs.

123
00:05:24,040 --> 00:05:25,960
Honestly, I could use a little refresher on those myself.

124
00:05:25,960 --> 00:05:26,960
Sure.

125
00:05:26,960 --> 00:05:31,160
APIs are application programming interfaces are how different software systems communicate

126
00:05:31,160 --> 00:05:32,560
and exchange data.

127
00:05:32,560 --> 00:05:34,280
Okay, that's kind of what I thought.

128
00:05:34,280 --> 00:05:36,040
But it still seems a little fuzzy, you know?

129
00:05:36,040 --> 00:05:38,360
Think about it like ordering food online.

130
00:05:38,360 --> 00:05:40,520
You go to the restaurants website or app, right?

131
00:05:40,520 --> 00:05:42,000
That's how you interact with their system.

132
00:05:42,000 --> 00:05:46,480
But behind the scenes, that web site or app is using an API to talk to the restaurants

133
00:05:46,480 --> 00:05:52,360
actual system, sending your order one pad tie please, and then bringing back the info

134
00:05:52,360 --> 00:05:54,560
like your order will be ready in 30 minutes.

135
00:05:54,560 --> 00:05:59,440
Okay, so the API is like the messenger making sure everything runs smoothly.

136
00:05:59,440 --> 00:06:02,880
But how do we make sure those messages don't end up in the wrong hands?

137
00:06:02,880 --> 00:06:04,240
That's got to be a concern.

138
00:06:04,240 --> 00:06:07,000
Absolutely, and that's where API security comes in.

139
00:06:07,000 --> 00:06:10,080
One of the fundamental aspects is authentication.

140
00:06:10,080 --> 00:06:11,880
Lothinication, right? Like having a password.

141
00:06:11,880 --> 00:06:12,880
Exactly.

142
00:06:12,880 --> 00:06:17,240
Just like needing a username and password to log into a website.

143
00:06:17,240 --> 00:06:21,920
APIs often use similar methods to verify who's sending those requests.

144
00:06:21,920 --> 00:06:27,080
Could be something like API keys, kind of like unique IDs for each user or even fancier

145
00:06:27,080 --> 00:06:30,280
things like, oh, oh, oh, that rings a bell.

146
00:06:30,280 --> 00:06:33,840
It's what you're using when you log into an app using your Google or Facebook account.

147
00:06:33,840 --> 00:06:36,560
So you don't have to make a whole new profile for every single thing.

148
00:06:36,560 --> 00:06:37,400
Oh, right, right.

149
00:06:37,400 --> 00:06:38,080
That makes sense.

150
00:06:38,080 --> 00:06:41,120
But authentication just tells you who's knocking, right?

151
00:06:41,120 --> 00:06:44,000
How do you make sure they're allowed to do what they want once they're in?

152
00:06:44,000 --> 00:06:44,920
You're on the right track.

153
00:06:44,920 --> 00:06:46,240
That's what authorization comes in.

154
00:06:46,240 --> 00:06:46,560
Okay.

155
00:06:46,560 --> 00:06:47,240
Authorization.

156
00:06:47,240 --> 00:06:48,680
So there's like a two-step process.

157
00:06:48,680 --> 00:06:49,360
Exactly.

158
00:06:49,360 --> 00:06:53,440
It's about setting permissions, making sure each user or system can only access what

159
00:06:53,440 --> 00:06:54,440
they're supposed to.

160
00:06:54,440 --> 00:06:55,520
Nothing more.

161
00:06:55,520 --> 00:06:57,840
Imagine a bouncer at a club, right?

162
00:06:57,840 --> 00:06:58,880
They check your ID.

163
00:06:58,880 --> 00:07:00,400
That's authentication.

164
00:07:00,400 --> 00:07:03,840
But then they got to make sure you're on the list or have the right wristband to actually

165
00:07:03,840 --> 00:07:04,600
get in.

166
00:07:04,600 --> 00:07:05,960
That's authorization.

167
00:07:05,960 --> 00:07:10,120
Okay, I'm with you. So you've got your authentication bouncer checking IDs.

168
00:07:10,120 --> 00:07:13,800
But this document also mentions something called API gateways.

169
00:07:13,800 --> 00:07:16,080
Is that like extra security at the door?

170
00:07:16,080 --> 00:07:18,400
It's more like a whole security checkpoint.

171
00:07:18,400 --> 00:07:23,520
An API gateway is a central hub that manages all incoming API requests.

172
00:07:23,520 --> 00:07:24,920
It can enforce traffic rules.

173
00:07:24,920 --> 00:07:27,120
Make sure users are who they say they are.

174
00:07:27,120 --> 00:07:30,880
Even inspect the data going back and forth to make sure there's nothing fishy going on.

175
00:07:30,880 --> 00:07:31,880
Wow.

176
00:07:31,880 --> 00:07:33,200
So it's a pretty big deal for security then.

177
00:07:33,200 --> 00:07:36,400
And then, definitely, especially when you're dealing with lots of different systems all

178
00:07:36,400 --> 00:07:37,560
talking to each other.

179
00:07:37,560 --> 00:07:38,560
Make sense.

180
00:07:38,560 --> 00:07:39,880
Now there's something else in here.

181
00:07:39,880 --> 00:07:41,400
Rest and soap.

182
00:07:41,400 --> 00:07:43,360
Are those different types of APIs?

183
00:07:43,360 --> 00:07:44,360
They are.

184
00:07:44,360 --> 00:07:47,440
Rest and soap are two different ways of designing APIs.

185
00:07:47,440 --> 00:07:50,440
Each with its own quirks and security considerations.

186
00:07:50,440 --> 00:07:55,040
Okay, so for someone like me who's not a tech wizard, what's the main difference security

187
00:07:55,040 --> 00:07:56,040
wise?

188
00:07:56,040 --> 00:08:00,440
Think of soap, which stands for a simple object access protocol as the more traditional

189
00:08:00,440 --> 00:08:01,640
approach.

190
00:08:01,640 --> 00:08:06,280
It's got some built-in security features, but it can be a bit trickier to set up.

191
00:08:06,280 --> 00:08:07,600
The rest.

192
00:08:07,600 --> 00:08:12,760
Rest, short for representational state transfer, is kind of the newer kit on the block.

193
00:08:12,760 --> 00:08:15,600
It's known for being more flexible, easier to work with.

194
00:08:15,600 --> 00:08:19,560
It might not have all those built-in security bells and whistles like SO, but it's easy

195
00:08:19,560 --> 00:08:22,400
enough to secure using common protocols.

196
00:08:22,400 --> 00:08:24,840
So which one is better for security?

197
00:08:24,840 --> 00:08:27,080
It's not really a matter of better or worse.

198
00:08:27,080 --> 00:08:31,520
The best choice really depends on the specific app you're building, how important security

199
00:08:31,520 --> 00:08:35,240
is for that particular app, and what resources you have available.

200
00:08:35,240 --> 00:08:38,440
So like most things in life, it's not a one size fits all situation.

201
00:08:38,440 --> 00:08:39,440
Exactly.

202
00:08:39,440 --> 00:08:41,800
Sometimes the mix of approaches might be the way to go.

203
00:08:41,800 --> 00:08:42,800
Makes sense.

204
00:08:42,800 --> 00:08:45,120
We've covered some serious ground here.

205
00:08:45,120 --> 00:08:49,640
Common ways code can be vulnerable, API security, the whole nine yards.

206
00:08:49,640 --> 00:08:52,320
But let's bring it back down to Earth for a minute.

207
00:08:52,320 --> 00:08:56,160
What are some practical things the developers should be thinking about when they're actually

208
00:08:56,160 --> 00:08:57,160
writing code?

209
00:08:57,160 --> 00:08:58,480
That's a great question.

210
00:08:58,480 --> 00:09:02,600
This document actually does a good job of highlighting the difference between secure coding

211
00:09:02,600 --> 00:09:06,240
standards and secure coding guidelines, which is important.

212
00:09:06,240 --> 00:09:07,440
Can break that down for me.

213
00:09:07,440 --> 00:09:10,280
Think of standards like traffic laws.

214
00:09:10,280 --> 00:09:11,720
They're non-negotiable.

215
00:09:11,720 --> 00:09:14,480
You have to follow them to make sure everyone stays safe.

216
00:09:14,480 --> 00:09:17,760
Guidelines on the other hand are more like best practices.

217
00:09:17,760 --> 00:09:21,480
Think of it like driving tips from say a race car driver.

218
00:09:21,480 --> 00:09:23,280
Okay, so standards of the law.

219
00:09:23,280 --> 00:09:24,280
Guidelines are pro tips.

220
00:09:24,280 --> 00:09:25,960
I like it.

221
00:09:25,960 --> 00:09:29,160
After some of the big ones when it comes to secure coding practices.

222
00:09:29,160 --> 00:09:31,800
Well, we already touched on input validation.

223
00:09:31,800 --> 00:09:35,880
That's crucial for preventing those buffer overflow vulnerabilities.

224
00:09:35,880 --> 00:09:40,120
It's all about being careful and checking any data that comes into your application.

225
00:09:40,120 --> 00:09:41,120
Right.

226
00:09:41,120 --> 00:09:42,760
Don't let any sneaky data grow them through.

227
00:09:42,760 --> 00:09:43,760
Exactly.

228
00:09:43,760 --> 00:09:45,880
Another important principle is least privilege.

229
00:09:45,880 --> 00:09:50,920
It means you only give your users and processes the absolute minimum access they need

230
00:09:50,920 --> 00:09:53,000
to do their job and nothing more.

231
00:09:53,000 --> 00:09:54,000
Gotcha.

232
00:09:54,000 --> 00:09:58,440
You wouldn't give everyone an office a key to the executive washroom precisely.

233
00:09:58,440 --> 00:10:03,560
It limits the damage if someone does manage to compromise a user account or a process.

234
00:10:03,560 --> 00:10:08,320
And finally, proper air handling and logging are crucial even if they seem like minor

235
00:10:08,320 --> 00:10:09,320
details.

236
00:10:09,320 --> 00:10:10,600
Wait, air handling.

237
00:10:10,600 --> 00:10:14,240
I always thought those errors were just for the developers to figure out what went wrong.

238
00:10:14,240 --> 00:10:18,880
They are, but if you're not careful about how you handle those errors, the messages that

239
00:10:18,880 --> 00:10:23,520
pop up could actually give away sensitive information to someone trying to break in.

240
00:10:23,520 --> 00:10:28,000
Imagine an error message that accidentally reveals your entire database query along with

241
00:10:28,000 --> 00:10:30,440
the oops something went wrong, message.

242
00:10:30,440 --> 00:10:31,640
Ouch, not good.

243
00:10:31,640 --> 00:10:33,280
Not good at all.

244
00:10:33,280 --> 00:10:36,640
That's why secure coding stresses the importance of logging those errors in a way that

245
00:10:36,640 --> 00:10:39,960
helps the developers without putting sensitive data at risk.

246
00:10:39,960 --> 00:10:41,680
It's all about finding that balance.

247
00:10:41,680 --> 00:10:44,280
So we've covered all these ways to make code more secure.

248
00:10:44,280 --> 00:10:46,680
All these things developers need to keep in mind.

249
00:10:46,680 --> 00:10:49,760
But it sounds like securing software isn't a one time thing.

250
00:10:49,760 --> 00:10:51,760
It's got to be an ongoing process, right?

251
00:10:51,760 --> 00:10:52,760
Absolutely.

252
00:10:52,760 --> 00:10:56,520
And that kind of leads into a really interesting point this document makes.

253
00:10:56,520 --> 00:11:00,200
It talks about this idea of software defined security.

254
00:11:00,200 --> 00:11:01,040
Have you ever heard of that?

255
00:11:01,040 --> 00:11:04,000
It rings a bell, but I can't say I know exactly what it means.

256
00:11:04,000 --> 00:11:10,320
Basically, it's about shifting away from those traditional hardware-based security solutions,

257
00:11:10,320 --> 00:11:14,080
you know, like firewalls and intrusion detection systems.

258
00:11:14,080 --> 00:11:19,760
And instead, using software itself to enforce security policies, but across the entire network.

259
00:11:19,760 --> 00:11:24,520
Oh, OK. So instead of having this one big clunky security gate at the entrance, it's

260
00:11:24,520 --> 00:11:29,120
more like having checkpoints and security measures embedded throughout the whole network.

261
00:11:29,120 --> 00:11:30,120
Exactly.

262
00:11:30,120 --> 00:11:32,200
It's way more flexible, way more adaptable.

263
00:11:32,200 --> 00:11:35,920
Like imagine, instead of having security guards just standing in one place, they can move

264
00:11:35,920 --> 00:11:37,800
around and respond to whatever comes up.

265
00:11:37,800 --> 00:11:39,040
Yeah, that makes sense.

266
00:11:39,040 --> 00:11:43,720
This approach gives you a lot more control over network traffic and the security policies,

267
00:11:43,720 --> 00:11:45,600
and it can be super dynamic.

268
00:11:45,600 --> 00:11:47,000
I can see how that be important now.

269
00:11:47,000 --> 00:11:50,880
With cloud computing, remote work, everything being so interconnected.

270
00:11:50,880 --> 00:11:52,880
Exactly. Software defined security.

271
00:11:52,880 --> 00:11:57,360
It's got a lot of potential for keeping up with all the crazy cybersecurity threats out there

272
00:11:57,360 --> 00:11:58,760
that are constantly changing.

273
00:11:58,760 --> 00:11:59,760
For sure.

274
00:11:59,760 --> 00:12:04,240
Wow. We've covered a ton of ground today for the nitty-gritty of those code vulnerabilities

275
00:12:04,240 --> 00:12:07,080
to the big picture of network security.

276
00:12:07,080 --> 00:12:08,520
It's been quite the deep dive.

277
00:12:08,520 --> 00:12:09,720
It really has.

278
00:12:09,720 --> 00:12:15,320
So if our listeners take away just one thing from today's deep dive, what should it be?

279
00:12:15,320 --> 00:12:17,320
That's easy.

280
00:12:17,320 --> 00:12:18,320
Security.

281
00:12:18,320 --> 00:12:19,720
It's everyone's responsibility, right?

282
00:12:19,720 --> 00:12:24,760
From those developers writing the code to us, the people actually using the software.

283
00:12:24,760 --> 00:12:26,360
We all got a player apart.

284
00:12:26,360 --> 00:12:27,360
Couldn't agree more.

285
00:12:27,360 --> 00:12:30,440
And it's important to remember, building secure software.

286
00:12:30,440 --> 00:12:32,160
It's not about being 100% invulnerable.

287
00:12:32,160 --> 00:12:34,520
It's about understanding what those risks are.

288
00:12:34,520 --> 00:12:39,200
Putting up the best defenses you can and staying vigilant as technology changes, right?

289
00:12:39,200 --> 00:12:40,200
Right on.

290
00:12:40,200 --> 00:12:41,200
Awesome.

291
00:12:41,200 --> 00:12:43,840
Well, that's about all the time we have for today's deep dive.

292
00:12:43,840 --> 00:12:48,280
If you're interested in learning more about the secure coding practices, be sure to check

293
00:12:48,280 --> 00:12:49,760
out the show notes.

294
00:12:49,760 --> 00:12:53,000
And don't forget to take a look at that O-Wiles top 10 list we talked about.

295
00:12:53,000 --> 00:12:54,880
It's a great place to start.

296
00:12:54,880 --> 00:13:18,760
Until next time, stay curious and stay secure.