WEBVTT

1
00:00:00.080 --> 00:00:03.439
<v Speaker 1>Okay, let's unpack this. We all rely on software for

2
00:00:03.480 --> 00:00:04.960
<v Speaker 1>almost everything these days, don't.

3
00:00:04.839 --> 00:00:07.799
<v Speaker 2>We absolutely banking, smart homes, everything.

4
00:00:07.759 --> 00:00:10.359
<v Speaker 1>It's woven into the fabric of our lives. And frankly,

5
00:00:11.640 --> 00:00:14.640
<v Speaker 1>the stakes for security have never felt higher.

6
00:00:14.839 --> 00:00:17.839
<v Speaker 2>Yeah, incidents aren't just annoying anymore. They can be genuinely

7
00:00:17.960 --> 00:00:19.280
<v Speaker 2>dangerous exactly.

8
00:00:19.760 --> 00:00:22.879
<v Speaker 1>We're talking everything from massive data breaches to you know,

9
00:00:22.960 --> 00:00:26.679
<v Speaker 1>critical system failures. It really makes you wonder as developers,

10
00:00:26.920 --> 00:00:30.480
<v Speaker 1>what's our true obligation here to build software of the

11
00:00:30.559 --> 00:00:32.200
<v Speaker 1>highest quality and standards.

12
00:00:32.600 --> 00:00:35.240
<v Speaker 2>That sense of responsibility really resonates, doesn't it.

13
00:00:35.240 --> 00:00:36.280
<v Speaker 1>It does, And.

14
00:00:36.200 --> 00:00:39.719
<v Speaker 2>What's fascinating here is how deeply that mission is reflected

15
00:00:39.880 --> 00:00:43.560
<v Speaker 2>in the source material we're diving into today. Alice and

16
00:00:43.600 --> 00:00:45.479
<v Speaker 2>Bob learn Secure Coding.

17
00:00:45.320 --> 00:00:46.920
<v Speaker 1>AH by Tanya Jacka.

18
00:00:47.079 --> 00:00:49.200
<v Speaker 2>Yeah, she makes it really clear the book wasn't just

19
00:00:49.240 --> 00:00:51.960
<v Speaker 2>for herself, but for you the listener, and well for

20
00:00:52.039 --> 00:00:55.039
<v Speaker 2>the personal desire for loved ones to use software safely.

21
00:00:55.600 --> 00:00:56.359
<v Speaker 1>That's powerful.

22
00:00:56.520 --> 00:00:59.000
<v Speaker 2>It's a strong call to action, really to instill a

23
00:00:59.000 --> 00:01:02.920
<v Speaker 2>sense of responsibility in every developer to build more trustworthy products,

24
00:01:03.560 --> 00:01:06.159
<v Speaker 2>especially when I mean, we've all heard endless stories of

25
00:01:06.359 --> 00:01:08.480
<v Speaker 2>data breaches and security.

26
00:01:08.000 --> 00:01:09.400
<v Speaker 1>Incidents, too many stories.

27
00:01:09.519 --> 00:01:12.959
<v Speaker 2>It truly sets the stage for our mission today understanding

28
00:01:13.040 --> 00:01:16.120
<v Speaker 2>how to elevate our approach to software security.

29
00:01:16.200 --> 00:01:17.480
<v Speaker 1>That's a powerful framing.

30
00:01:17.760 --> 00:01:18.319
<v Speaker 2>Yeah.

31
00:01:18.480 --> 00:01:21.959
<v Speaker 1>So if that's the why, what are the foundational principles

32
00:01:22.519 --> 00:01:25.680
<v Speaker 1>the how? Today we're taking a deep dive into those

33
00:01:25.680 --> 00:01:30.760
<v Speaker 1>core principles and practical steps for secure coding, drawing directly

34
00:01:30.799 --> 00:01:32.599
<v Speaker 1>from this incredibly insightful book.

35
00:01:32.680 --> 00:01:33.480
<v Speaker 2>Yeah, lots to cover.

36
00:01:33.680 --> 00:01:37.040
<v Speaker 1>We'll explore general advice that applies across the board, specific

37
00:01:37.319 --> 00:01:42.359
<v Speaker 1>best practices for say, popular technologies and common vulnerabilities to watch.

38
00:01:42.120 --> 00:01:43.439
<v Speaker 2>Out for usual suspects.

39
00:01:43.560 --> 00:01:45.599
<v Speaker 1>Our goal is really to equip you with the knowledge

40
00:01:45.640 --> 00:01:50.120
<v Speaker 1>to create truly robust applications and hopefully contribute to a

41
00:01:50.120 --> 00:01:54.359
<v Speaker 1>safer digital world. So where do we even begin when

42
00:01:54.400 --> 00:01:56.560
<v Speaker 1>we're trying to build more secure software?

43
00:01:56.599 --> 00:01:58.040
<v Speaker 2>Well, the foundation For.

44
00:01:58.079 --> 00:02:00.519
<v Speaker 1>Many of us, I think trusting people is a natural instinct,

45
00:02:00.959 --> 00:02:03.599
<v Speaker 1>but when it comes to systems, that mindset needs a

46
00:02:03.599 --> 00:02:04.640
<v Speaker 1>fundamental shift, right.

47
00:02:04.640 --> 00:02:05.239
<v Speaker 2>Absolutely.

48
00:02:05.840 --> 00:02:08.919
<v Speaker 1>The book really hammers home the idea of adopting as

49
00:02:09.159 --> 00:02:10.360
<v Speaker 1>zero trust model.

50
00:02:10.479 --> 00:02:14.240
<v Speaker 2>It does, and this raises an important question. Why why

51
00:02:14.919 --> 00:02:17.159
<v Speaker 2>is never assumed trust so critical?

52
00:02:17.439 --> 00:02:17.719
<v Speaker 1>Yeah?

53
00:02:17.879 --> 00:02:21.840
<v Speaker 2>Way, Because if you implicitly assume trust you're opening yourself

54
00:02:21.919 --> 00:02:25.080
<v Speaker 2>up to a whole world of risk. I mean everything

55
00:02:25.159 --> 00:02:28.159
<v Speaker 2>from credential stuffing attacks.

56
00:02:27.680 --> 00:02:30.159
<v Speaker 1>Where they use stolen passwords from other breaches.

57
00:02:29.879 --> 00:02:33.680
<v Speaker 2>Exactly that, or malformed data. You simply cannot trust any

58
00:02:33.759 --> 00:02:36.120
<v Speaker 2>data you receive, not really, even if it's from your

59
00:02:36.159 --> 00:02:38.240
<v Speaker 2>own company's internal APIs.

60
00:02:37.840 --> 00:02:39.280
<v Speaker 1>Even internal stuff. Wow.

61
00:02:39.479 --> 00:02:43.120
<v Speaker 2>Remember Alice's experience in the book where executives were fish

62
00:02:43.240 --> 00:02:48.120
<v Speaker 2>because they had admin privileges and no anti malware. Oh right, Yeah,

63
00:02:48.159 --> 00:02:50.680
<v Speaker 2>that's the stark example of what happens when trust is

64
00:02:50.800 --> 00:02:54.560
<v Speaker 2>just assumed in a system. It truly highlights how every

65
00:02:54.599 --> 00:02:57.759
<v Speaker 2>piece of data, every interaction needs validation.

66
00:02:57.840 --> 00:02:59.960
<v Speaker 1>It's about being relentlessly proactive, isn't it.

67
00:03:00.120 --> 00:03:00.319
<v Speaker 2>Yes.

68
00:03:00.400 --> 00:03:03.800
<v Speaker 1>And part of that proactivity, which might sound a bit

69
00:03:03.840 --> 00:03:08.240
<v Speaker 1>pessimistic but is actually incredibly realistic, is to assume breach

70
00:03:08.759 --> 00:03:10.439
<v Speaker 1>and plan for failure precisely.

71
00:03:10.520 --> 00:03:13.439
<v Speaker 2>And this isn't just about having a disaster recovery plan

72
00:03:13.520 --> 00:03:17.240
<v Speaker 2>tucked away somewhere, No, No, it's about fundamentally altering your

73
00:03:17.280 --> 00:03:21.439
<v Speaker 2>development mindset. Imagine every line of code you write, you

74
00:03:21.520 --> 00:03:25.439
<v Speaker 2>design it assuming it will be probed, tested, or even compromised.

75
00:03:25.719 --> 00:03:27.919
<v Speaker 1>Okay, so what does that actually mean in practice?

76
00:03:27.960 --> 00:03:31.759
<v Speaker 2>Well, It affects your testing, your logging, your error handling,

77
00:03:31.800 --> 00:03:34.000
<v Speaker 2>not just at the end, but from day one, right

78
00:03:34.039 --> 00:03:37.240
<v Speaker 2>from the start. It means designing your systems, your processes,

79
00:03:37.280 --> 00:03:39.879
<v Speaker 2>and your reactions as if a breach will happen, like

80
00:03:40.400 --> 00:03:44.120
<v Speaker 2>launching your incident response the moment of vulnerability.

81
00:03:43.439 --> 00:03:45.680
<v Speaker 1>Is reported, not waiting for proof of exploit.

82
00:03:45.400 --> 00:03:48.800
<v Speaker 2>Exactly, using multiple layers of defense, constantly monitoring your network

83
00:03:48.840 --> 00:03:52.080
<v Speaker 2>for suspicious activity. It's about building in resilience from the

84
00:03:52.120 --> 00:03:54.800
<v Speaker 2>ground up, not just cleaning up after the fact.

85
00:03:54.960 --> 00:03:58.680
<v Speaker 1>Okay, So, if we accept that breaches are kind of

86
00:03:58.719 --> 00:04:02.120
<v Speaker 1>inevitable a matter of when, not if, how do we

87
00:04:02.199 --> 00:04:06.280
<v Speaker 1>make secure choices the easy choices for developers because often

88
00:04:06.319 --> 00:04:07.919
<v Speaker 1>the secure way feels harder.

89
00:04:08.199 --> 00:04:09.520
<v Speaker 2>That's a key challenge.

90
00:04:09.599 --> 00:04:13.520
<v Speaker 1>The book introduces this concept of secure defaults or a

91
00:04:13.560 --> 00:04:16.319
<v Speaker 1>paved road right yep, where the most secure settings are

92
00:04:16.319 --> 00:04:17.360
<v Speaker 1>the default Yes.

93
00:04:17.399 --> 00:04:20.879
<v Speaker 2>And this is a potential game changer because it applies

94
00:04:20.879 --> 00:04:23.240
<v Speaker 2>both to the products you build for users and your

95
00:04:23.279 --> 00:04:25.480
<v Speaker 2>own internal development environments.

96
00:04:25.800 --> 00:04:26.759
<v Speaker 1>How so well.

97
00:04:26.839 --> 00:04:30.759
<v Speaker 2>Examples from the source material include creating clear policies and

98
00:04:31.040 --> 00:04:35.560
<v Speaker 2>importantly tools for things like secret management, even setting up

99
00:04:35.560 --> 00:04:37.040
<v Speaker 2>pre commit hooks.

100
00:04:37.079 --> 00:04:38.480
<v Speaker 1>In the version control Yeah.

101
00:04:38.399 --> 00:04:42.399
<v Speaker 2>Hooks that actually reject code if it contains secrets. Imagine

102
00:04:42.439 --> 00:04:45.480
<v Speaker 2>a system where the easiest path for a developer is

103
00:04:45.519 --> 00:04:46.639
<v Speaker 2>also the most secure.

104
00:04:46.800 --> 00:04:47.560
<v Speaker 1>That's the dream.

105
00:04:47.720 --> 00:04:52.000
<v Speaker 2>It's also why things like security policy compliance, you know,

106
00:04:52.160 --> 00:04:56.519
<v Speaker 2>actually prioritizing fixes for broken policies and using static application

107
00:04:56.639 --> 00:04:58.680
<v Speaker 2>security testing or SASD.

108
00:04:58.480 --> 00:04:59.879
<v Speaker 1>Where tools scan the code.

109
00:04:59.639 --> 00:05:03.759
<v Speaker 2>Itself right, using SAS to automatically block bad code patterns

110
00:05:03.759 --> 00:05:05.759
<v Speaker 2>before they even get checked in. That's crucial.

111
00:05:06.079 --> 00:05:09.439
<v Speaker 1>And speaking of making secured choices easier, a cornerstone of

112
00:05:09.480 --> 00:05:12.240
<v Speaker 1>that has to be applying the principle of least privilege.

113
00:05:12.399 --> 00:05:15.800
<v Speaker 1>Don't give more access than necessary for only as long

114
00:05:15.800 --> 00:05:19.720
<v Speaker 1>as necessary. Sounds simple, but I know in practice teams

115
00:05:19.720 --> 00:05:23.480
<v Speaker 1>can struggle with this, finding that balance between security and

116
00:05:23.879 --> 00:05:25.000
<v Speaker 1>well convenience.

117
00:05:25.160 --> 00:05:28.040
<v Speaker 2>It's a common struggle absolutely. But the real insight here,

118
00:05:28.079 --> 00:05:31.759
<v Speaker 2>I think, is understanding how reducing that blast radius isn't

119
00:05:31.800 --> 00:05:35.800
<v Speaker 2>just a security win, it can actually simplify maintenance and

120
00:05:35.839 --> 00:05:37.399
<v Speaker 2>compliance in the long run too.

121
00:05:37.519 --> 00:05:38.319
<v Speaker 1>How does that work?

122
00:05:38.639 --> 00:05:41.120
<v Speaker 2>Well, think about it. Whether it's giving a user access

123
00:05:41.160 --> 00:05:45.240
<v Speaker 2>to a network or an application, every privilege granted carries risk.

124
00:05:45.480 --> 00:05:45.800
<v Speaker 1>Sure.

125
00:05:46.079 --> 00:05:48.800
<v Speaker 2>The book illustrates this really well with Bob's strategy at

126
00:05:48.839 --> 00:05:53.639
<v Speaker 2>we hack Purple creating separate vaults like secure containers with

127
00:05:53.759 --> 00:05:58.000
<v Speaker 2>specific access for different teams. Marketing gets one admin gets another.

128
00:05:58.079 --> 00:05:59.839
<v Speaker 1>Okay, segmented access exactly.

129
00:05:59.879 --> 00:06:02.639
<v Speaker 2>So if someone leaves, you only have to rotate a

130
00:06:02.720 --> 00:06:06.639
<v Speaker 2>small subset of credentials. That saves immense time and reduces

131
00:06:06.720 --> 00:06:10.759
<v Speaker 2>risk compared to having shared overly brought access. It's all

132
00:06:10.800 --> 00:06:14.800
<v Speaker 2>about minimizing the damage if an account is ever compromised.

133
00:06:14.360 --> 00:06:19.199
<v Speaker 1>Right, containing the potential fallout makes sense. So we've covered

134
00:06:19.199 --> 00:06:22.680
<v Speaker 1>designing securely, but once that data starts flowing in, that's

135
00:06:22.720 --> 00:06:25.000
<v Speaker 1>often where the real vulnerabilities creep in, isn't it.

136
00:06:25.079 --> 00:06:27.000
<v Speaker 2>Oh? Absolutely, that's prime attack surface.

137
00:06:27.079 --> 00:06:31.199
<v Speaker 1>The book really emphasizes input validation and outputting coding.

138
00:06:31.040 --> 00:06:34.360
<v Speaker 2>And this is fundamental. So many attacks start here. Any

139
00:06:34.480 --> 00:06:39.000
<v Speaker 2>data entering your application or API is a potential attack vector, period.

140
00:06:39.160 --> 00:06:41.360
<v Speaker 1>And the critical insight you mentioned earlier.

141
00:06:41.079 --> 00:06:44.279
<v Speaker 2>Yes, never assume data is safe, even if it comes

142
00:06:44.319 --> 00:06:47.279
<v Speaker 2>from your own database, because it might have been maliciously

143
00:06:47.279 --> 00:06:49.720
<v Speaker 2>stored there previously. Someone might have found a way to

144
00:06:49.720 --> 00:06:50.920
<v Speaker 2>poison your data store.

145
00:06:51.000 --> 00:06:53.399
<v Speaker 1>Wow. Okay, paranoia is good here.

146
00:06:53.279 --> 00:06:57.120
<v Speaker 2>A healthy dose, And for web applications, outputting coding is

147
00:06:57.199 --> 00:07:00.199
<v Speaker 2>essential to prevent cross site scripting excess.

148
00:06:59.839 --> 00:07:02.639
<v Speaker 1>As injecting malicious scripts into websites.

149
00:07:02.759 --> 00:07:06.800
<v Speaker 2>Precisely, and a huge takeaway from the book something really practical.

150
00:07:07.720 --> 00:07:11.480
<v Speaker 2>Always use an allow list when validating input, not a

151
00:07:11.519 --> 00:07:12.120
<v Speaker 2>block list.

152
00:07:12.240 --> 00:07:13.399
<v Speaker 1>Explain that difference again.

153
00:07:13.560 --> 00:07:16.240
<v Speaker 2>Okay, so a blocklist tries to list all the bad

154
00:07:16.279 --> 00:07:19.399
<v Speaker 2>things like specific characters or script tags and reject them.

155
00:07:19.720 --> 00:07:22.639
<v Speaker 2>But trying to block every possible bad input is a

156
00:07:22.720 --> 00:07:26.720
<v Speaker 2>losing battle. Hackers are clever, they'll find ways around it exactly.

157
00:07:27.160 --> 00:07:30.439
<v Speaker 2>The book points out examples using URL encoding to bypass

158
00:07:30.519 --> 00:07:33.720
<v Speaker 2>simple blocks, and allow list, on the other hand, defines

159
00:07:33.839 --> 00:07:38.360
<v Speaker 2>precisely what is acceptable, like only alphanumeric characters of a

160
00:07:38.360 --> 00:07:39.399
<v Speaker 2>certain length, so.

161
00:07:39.399 --> 00:07:40.839
<v Speaker 1>You define the good not the bad.

162
00:07:41.120 --> 00:07:44.480
<v Speaker 2>Right. It's far more robust and usually easier to maintain

163
00:07:44.519 --> 00:07:47.600
<v Speaker 2>because you're focused on what's permitted, not trying to guess

164
00:07:47.639 --> 00:07:48.639
<v Speaker 2>every possible attack.

165
00:07:48.800 --> 00:07:50.240
<v Speaker 1>That makes a lot of sense. And then there's the

166
00:07:50.240 --> 00:07:53.800
<v Speaker 1>big one, sequel injection. It feels like a classic, almost

167
00:07:53.839 --> 00:07:55.600
<v Speaker 1>mythical vulnerability.

168
00:07:54.959 --> 00:07:56.519
<v Speaker 2>Sometimes, but it's still out there.

169
00:07:56.519 --> 00:07:59.920
<v Speaker 1>Still the infamous number one worst vulnerability for web apps.

170
00:08:00.040 --> 00:08:03.560
<v Speaker 1>According to many sources, it's almost disturbingly easy to exploit

171
00:08:03.600 --> 00:08:04.000
<v Speaker 1>isn't it.

172
00:08:04.000 --> 00:08:07.040
<v Speaker 2>It really is Bob's eye opening experience at that capture

173
00:08:07.079 --> 00:08:10.600
<v Speaker 2>the flag contest, learning how something as simple looking as

174
00:08:11.279 --> 00:08:14.600
<v Speaker 2>or one on one could completely bypass a log instagram

175
00:08:14.800 --> 00:08:17.800
<v Speaker 2>just like that, Just like that. It illustrates just how

176
00:08:18.000 --> 00:08:21.240
<v Speaker 2>powerfully simple yet devastating these attacks can be.

177
00:08:21.560 --> 00:08:23.439
<v Speaker 1>So what's the defense the silver bullet?

178
00:08:23.720 --> 00:08:27.040
<v Speaker 2>Well, there's no single silver bullet in security. But for

179
00:08:27.120 --> 00:08:30.759
<v Speaker 2>SQL injection, the solution, as the book emphasizes, is using

180
00:08:30.800 --> 00:08:34.639
<v Speaker 2>parameterized queries or stored procedures properly implement.

181
00:08:34.759 --> 00:08:36.679
<v Speaker 1>Okay, parameterized queries, what do they do?

182
00:08:36.840 --> 00:08:39.600
<v Speaker 2>They ensure your user input is always treated as data,

183
00:08:39.919 --> 00:08:44.159
<v Speaker 2>just plaintext, never as executable code. It strips away those

184
00:08:44.200 --> 00:08:46.960
<v Speaker 2>special powers an attacker might try to inject with things

185
00:08:47.039 --> 00:08:50.679
<v Speaker 2>like or one or one makes their attempts harmless data

186
00:08:50.759 --> 00:08:51.879
<v Speaker 2>instead of active commands.

187
00:08:52.000 --> 00:08:57.240
<v Speaker 1>Okay, crucial technique. Now shifting gears slightly. A constant headache

188
00:08:57.240 --> 00:09:00.000
<v Speaker 1>for many developers I know from experience is secret manage.

189
00:09:00.360 --> 00:09:01.519
<v Speaker 2>Oh yes, big one.

190
00:09:01.679 --> 00:09:04.480
<v Speaker 1>It's just so tempting, isn't it to store connection strings

191
00:09:04.559 --> 00:09:07.080
<v Speaker 1>or apikeys right there in your code, or maybe you

192
00:09:07.080 --> 00:09:08.759
<v Speaker 1>can fig file checked into source control.

193
00:09:08.919 --> 00:09:12.080
<v Speaker 2>It is tempting easy, and the author shares a really

194
00:09:12.159 --> 00:09:16.679
<v Speaker 2>telling personal antecdote about finding live banking passwords in source

195
00:09:16.720 --> 00:09:18.240
<v Speaker 2>code in twenty twenty.

196
00:09:18.000 --> 00:09:20.360
<v Speaker 1>One, Wow in twenty twenty one, Yeah.

197
00:09:20.120 --> 00:09:24.159
<v Speaker 2>Long after she knew better, which just highlights that despite

198
00:09:24.200 --> 00:09:27.679
<v Speaker 2>common knowledge, the message isn't getting through to everyone, or

199
00:09:27.759 --> 00:09:29.480
<v Speaker 2>maybe the tooling isn't easy enough.

200
00:09:29.919 --> 00:09:31.399
<v Speaker 1>So what's the core principle here?

201
00:09:31.720 --> 00:09:36.200
<v Speaker 2>Secrets are fundamentally for machines to authenticate to other machines,

202
00:09:36.679 --> 00:09:39.919
<v Speaker 2>not for humans to read or manage directly in code.

203
00:09:40.360 --> 00:09:44.360
<v Speaker 2>The solution is dedicated secret management tools, things like Hashi

204
00:09:44.399 --> 00:09:48.279
<v Speaker 2>Court Vault as your Key Vault AWS secrets manager tools

205
00:09:48.279 --> 00:09:51.480
<v Speaker 2>built for the job exactly, and the book provides a

206
00:09:51.559 --> 00:09:55.840
<v Speaker 2>clear actionable path. First, migrate any existing secrets out of

207
00:09:55.840 --> 00:09:56.600
<v Speaker 2>your codebases.

208
00:09:56.639 --> 00:09:57.840
<v Speaker 1>That's step one the cleanup.

209
00:09:58.159 --> 00:10:01.759
<v Speaker 2>Then, crucially, implement those pre commit hooks we talked about

210
00:10:01.759 --> 00:10:05.200
<v Speaker 2>earlier in your version control hooks that specifically block any

211
00:10:05.240 --> 00:10:06.840
<v Speaker 2>future attempts to check in secret.

212
00:10:06.919 --> 00:10:08.639
<v Speaker 1>They get impossible to make the mistake again.

213
00:10:08.759 --> 00:10:12.080
<v Speaker 2>Essentially, yes, make it practically impossible to accidentally expose these

214
00:10:12.080 --> 00:10:13.159
<v Speaker 2>crucial credentials.

215
00:10:13.320 --> 00:10:18.159
<v Speaker 1>Okay, so we've talked code data input, but our systems

216
00:10:18.200 --> 00:10:20.960
<v Speaker 1>constantly interact with the outside world too. How do we

217
00:10:21.000 --> 00:10:23.519
<v Speaker 1>secure those interactions data flying back and forth?

218
00:10:23.559 --> 00:10:29.000
<v Speaker 2>Communication security is absolutely paramount HTTPS everywhere. Yes, the book

219
00:10:29.080 --> 00:10:32.399
<v Speaker 2>is very clear all data transmitted over the Internet must

220
00:10:32.440 --> 00:10:35.480
<v Speaker 2>be encrypted using AHGTPS and the latest version of Transport

221
00:10:35.559 --> 00:10:39.840
<v Speaker 2>Layer Security TLS. TLS the underlying protocol, right, the cryptographic

222
00:10:39.840 --> 00:10:43.480
<v Speaker 2>protocol that actually ensures secure communication over a network. And

223
00:10:43.559 --> 00:10:47.440
<v Speaker 2>a critical warning here something Bob learned the hard way

224
00:10:47.799 --> 00:10:50.360
<v Speaker 2>in another CTF story, Oh never try to write your

225
00:10:50.360 --> 00:10:51.360
<v Speaker 2>own encryption software.

226
00:10:51.440 --> 00:10:53.799
<v Speaker 1>Oh roll your own cryptot.

227
00:10:53.639 --> 00:10:56.399
<v Speaker 2>His homemade encryption which turned out to be just double

228
00:10:56.399 --> 00:10:59.320
<v Speaker 2>base sixty four encoding, not real encryption at all. Oh

229
00:10:59.360 --> 00:11:03.600
<v Speaker 2>dear was in less than a minute. It truly underlines

230
00:11:03.679 --> 00:11:06.799
<v Speaker 2>why encryption is a job for experts trying to diy

231
00:11:06.879 --> 00:11:10.480
<v Speaker 2>it is almost guaranteed to create a massive vulnerability. Use

232
00:11:10.600 --> 00:11:13.000
<v Speaker 2>the standard, vetted libraries and protocols.

233
00:11:13.200 --> 00:11:16.240
<v Speaker 1>Good advice. So when we're talking about hardening the entire system,

234
00:11:16.279 --> 00:11:19.360
<v Speaker 1>not just the web app part, what about securing things

235
00:11:19.399 --> 00:11:23.279
<v Speaker 1>like databases themselves or mobile apps. They have unique challenges.

236
00:11:23.600 --> 00:11:28.720
<v Speaker 2>Absolutely each layer needs attention. The book outlines a multifaceted

237
00:11:28.759 --> 00:11:33.159
<v Speaker 2>approach for databases. It's things like hardening the server itself,

238
00:11:33.639 --> 00:11:37.360
<v Speaker 2>securing the network connections to it, firewalls and such right

239
00:11:37.799 --> 00:11:41.639
<v Speaker 2>and using least privilege for access, for instance, making sure

240
00:11:41.679 --> 00:11:44.200
<v Speaker 2>the application connects with a read only account if that's

241
00:11:44.200 --> 00:11:48.440
<v Speaker 2>all it needs, not with full database owner or DBO access.

242
00:11:48.600 --> 00:11:50.240
<v Speaker 1>Minimize the app's power over.

243
00:11:50.120 --> 00:11:55.000
<v Speaker 2>The database exactly. Plus regular patching obviously and strict detailed

244
00:11:55.039 --> 00:11:58.679
<v Speaker 2>logging are non negotiable, and for mobile apps, different set

245
00:11:58.679 --> 00:12:00.759
<v Speaker 2>of concerns. There. You need to think about things like

246
00:12:00.919 --> 00:12:04.720
<v Speaker 2>obfuscating and minifying your code to deter reverse engineering, making.

247
00:12:04.600 --> 00:12:06.559
<v Speaker 1>It harder to figure out how the app works.

248
00:12:06.399 --> 00:12:10.480
<v Speaker 2>Correct, And be extremely careful with storing sensitive data in memory,

249
00:12:10.679 --> 00:12:14.320
<v Speaker 2>especially on Android where memory isn't always truly wiped after use,

250
00:12:14.399 --> 00:12:16.080
<v Speaker 2>potentially leaving data accessible.

251
00:12:16.159 --> 00:12:17.480
<v Speaker 1>Oh interesting nuance.

252
00:12:17.279 --> 00:12:20.559
<v Speaker 2>And critically and sure sensitive data isn't included in unencrypted

253
00:12:20.559 --> 00:12:23.360
<v Speaker 2>device backups. That's a common slip up. It's about being

254
00:12:23.399 --> 00:12:25.080
<v Speaker 2>paranoid at every single layer.

255
00:12:25.320 --> 00:12:29.840
<v Speaker 1>Okay, paranoia is the theme. What about error messages? You'd

256
00:12:29.879 --> 00:12:32.919
<v Speaker 1>think being helpful is good telling users exactly what went wrong,

257
00:12:33.000 --> 00:12:34.759
<v Speaker 1>you would think so, but not always the case in

258
00:12:34.799 --> 00:12:35.600
<v Speaker 1>security isn't.

259
00:12:35.799 --> 00:12:38.759
<v Speaker 2>No, that's another lesson Bobb learned the hard way during

260
00:12:38.759 --> 00:12:39.799
<v Speaker 2>a penetration test.

261
00:12:40.240 --> 00:12:40.840
<v Speaker 1>What happened?

262
00:12:40.879 --> 00:12:44.960
<v Speaker 2>Those polite, detailed error messages that reveal too much about

263
00:12:44.960 --> 00:12:49.360
<v Speaker 2>the internal system workings like specific database errors, file paths,

264
00:12:49.559 --> 00:12:54.639
<v Speaker 2>server versions, information leakage precisely. They can be absolute gold

265
00:12:54.679 --> 00:12:57.960
<v Speaker 2>mines for attackers, allowing them to map out your system

266
00:12:58.000 --> 00:12:59.279
<v Speaker 2>and refine their attacks.

267
00:12:59.480 --> 00:13:00.399
<v Speaker 1>So what's the advice.

268
00:13:00.759 --> 00:13:04.679
<v Speaker 2>It's simple, really. For end users, error messages should be generic,

269
00:13:04.840 --> 00:13:08.320
<v Speaker 2>something like bad input, please try again, or an error

270
00:13:08.440 --> 00:13:12.639
<v Speaker 2>curd please contact support. Keep it vague, yes, save the details.

271
00:13:12.679 --> 00:13:15.879
<v Speaker 2>The stack traces all the specifics for your internal logging

272
00:13:15.919 --> 00:13:20.519
<v Speaker 2>and debugging systems where only authorized personnel can actually access them.

273
00:13:20.919 --> 00:13:23.519
<v Speaker 2>Don't give attackers free information, right.

274
00:13:23.600 --> 00:13:27.320
<v Speaker 1>Log it securely, don't display publicly. Makes sense now, the

275
00:13:27.360 --> 00:13:32.240
<v Speaker 1>book really emphasizes integrating security throughout the entire software development

276
00:13:32.279 --> 00:13:33.519
<v Speaker 1>life cycle the SDLC.

277
00:13:33.960 --> 00:13:35.679
<v Speaker 2>Yes, that's a core theme.

278
00:13:35.799 --> 00:13:38.440
<v Speaker 1>It's not just an afterthought or a final check but

279
00:13:38.519 --> 00:13:42.159
<v Speaker 1>woven into every single phase. That sounds great in theory,

280
00:13:42.799 --> 00:13:45.720
<v Speaker 1>but you know, in practice, I've seen teams struggle to

281
00:13:45.720 --> 00:13:49.279
<v Speaker 1>make it a continuous process rather than just a rushed

282
00:13:49.480 --> 00:13:50.600
<v Speaker 1>checkbox exercise.

283
00:13:50.639 --> 00:13:53.039
<v Speaker 2>At the end, you've hit on a crucial point there.

284
00:13:53.559 --> 00:13:57.399
<v Speaker 2>It's easy to say shift left, but harder to do consistently.

285
00:13:57.559 --> 00:13:58.559
<v Speaker 1>So how do we make it real?

286
00:13:59.039 --> 00:14:01.480
<v Speaker 2>It's not just about doing security at the end, it's

287
00:14:01.519 --> 00:14:06.039
<v Speaker 2>making it fundamental, from defining explicit security requirements right at

288
00:14:06.039 --> 00:14:06.639
<v Speaker 2>the start of a.

289
00:14:06.600 --> 00:14:08.960
<v Speaker 1>Project before coding even begins.

290
00:14:08.799 --> 00:14:12.759
<v Speaker 2>Exactly, performing threat modeling during the design phase. And this

291
00:14:12.799 --> 00:14:15.000
<v Speaker 2>doesn't have to be super formal all the time. Even

292
00:14:15.039 --> 00:14:19.120
<v Speaker 2>an informal team brainstorming session about what could go wrong

293
00:14:19.600 --> 00:14:20.960
<v Speaker 2>can be hugely beneficial.

294
00:14:21.159 --> 00:14:23.480
<v Speaker 1>Just thinking like an attacker for a bit, right.

295
00:14:23.440 --> 00:14:26.759
<v Speaker 2>Then using those AST tools we mentioned, and also software

296
00:14:26.759 --> 00:14:29.559
<v Speaker 2>composition analysis or SCA tools ah, the.

297
00:14:29.519 --> 00:14:32.080
<v Speaker 1>Ones that check third party libraries.

298
00:14:31.720 --> 00:14:35.440
<v Speaker 2>Yes, checking your dependencies for known vulnerabilities during coding, and

299
00:14:35.480 --> 00:14:39.919
<v Speaker 2>of course rigorous security testing both automated and manual before release.

300
00:14:40.240 --> 00:14:42.200
<v Speaker 1>It sounds like a lot for developers to take on.

301
00:14:42.440 --> 00:14:44.679
<v Speaker 2>It can be, which is why the book encourages you

302
00:14:44.720 --> 00:14:47.440
<v Speaker 2>to become a security champion within your team.

303
00:14:47.600 --> 00:14:48.480
<v Speaker 1>What's that involved?

304
00:14:48.679 --> 00:14:52.159
<v Speaker 2>Acting as a kind of liaison with the main security team.

305
00:14:52.519 --> 00:14:56.360
<v Speaker 2>You get extra training, maybe increase visibility, and you help

306
00:14:56.440 --> 00:14:59.600
<v Speaker 2>translate security needs into practical steps your team can take.

307
00:15:00.120 --> 00:15:02.799
<v Speaker 2>You become the go to person for security questions on

308
00:15:02.840 --> 00:15:03.200
<v Speaker 2>the team.

309
00:15:03.519 --> 00:15:06.200
<v Speaker 1>So bridging the gap between dev and sec.

310
00:15:06.240 --> 00:15:11.159
<v Speaker 2>Exactly, directly contributing to protecting your colleagues, customers, and the

311
00:15:11.200 --> 00:15:12.120
<v Speaker 2>whole organization.

312
00:15:12.360 --> 00:15:15.080
<v Speaker 1>That's interesting that the book also touches on something very current,

313
00:15:15.559 --> 00:15:19.519
<v Speaker 1>very rapidly evolving, using AI safely in development.

314
00:15:19.639 --> 00:15:21.679
<v Speaker 2>Oh yeah, the elephant in the room these days.

315
00:15:21.759 --> 00:15:23.840
<v Speaker 1>There's a lot of excitement obviously, but also a lot

316
00:15:23.840 --> 00:15:25.399
<v Speaker 1>of potential pitfalls, isn't there?

317
00:15:25.519 --> 00:15:29.279
<v Speaker 2>Absolutely, and it highlights common pitfalls directly. The core advice

318
00:15:29.919 --> 00:15:34.480
<v Speaker 2>never allow AI to have agency over your systems or data, meaning.

319
00:15:34.240 --> 00:15:37.080
<v Speaker 1>Don't let it deploy code or change settings automatically.

320
00:15:37.279 --> 00:15:41.120
<v Speaker 2>Precisely, you, the human, need to validate all code written

321
00:15:41.159 --> 00:15:44.960
<v Speaker 2>by AI before it goes anywhere near production, runsst and

322
00:15:45.080 --> 00:15:47.519
<v Speaker 2>sea tools on it, just like you would your own code.

323
00:15:47.879 --> 00:15:49.879
<v Speaker 1>Treat it like code from a junior dev, your.

324
00:15:49.720 --> 00:15:53.399
<v Speaker 2>Mentoring kind of Yeah, and critically, you need to understand

325
00:15:53.399 --> 00:15:56.360
<v Speaker 2>what the AI generated code actually does yourself. Don't just

326
00:15:56.480 --> 00:15:59.279
<v Speaker 2>blindly trust it because the AI said it works, just like.

327
00:15:59.240 --> 00:16:02.120
<v Speaker 1>You wouldn't blindly pull a random image from Docker Hub.

328
00:16:02.039 --> 00:16:05.240
<v Speaker 2>Exactly same principle. The human in the loop is still

329
00:16:05.279 --> 00:16:07.840
<v Speaker 2>the ultimate gatekeeper for security and quality.

330
00:16:08.000 --> 00:16:11.840
<v Speaker 1>Okay, wow, this deep dive has really shown I think

331
00:16:12.200 --> 00:16:15.559
<v Speaker 1>that secure coding isn't just another technical skill to learn.

332
00:16:15.840 --> 00:16:16.919
<v Speaker 2>No, it's more than that.

333
00:16:16.960 --> 00:16:21.000
<v Speaker 1>It's profound mindset shift, isn't it And a continuous.

334
00:16:20.519 --> 00:16:22.039
<v Speaker 2>Journey, definitely continuous.

335
00:16:22.120 --> 00:16:25.519
<v Speaker 1>From understanding these core principles like never assume trust and

336
00:16:25.639 --> 00:16:31.840
<v Speaker 1>least privilege to implementing practical steps like parameterized queries and

337
00:16:31.879 --> 00:16:35.320
<v Speaker 1>proper secret management, every choice you make as a developer

338
00:16:35.360 --> 00:16:36.080
<v Speaker 1>truly has an.

339
00:16:36.039 --> 00:16:37.320
<v Speaker 2>Impact, every single one.

340
00:16:37.399 --> 00:16:40.360
<v Speaker 1>It's really about building quality and trustworthiness into every line

341
00:16:40.399 --> 00:16:41.639
<v Speaker 1>of code from the ground up.

342
00:16:41.840 --> 00:16:44.440
<v Speaker 2>And if we connect this to the bigger picture, it

343
00:16:44.559 --> 00:16:48.120
<v Speaker 2>raises an important question for you, the listener. In a

344
00:16:48.159 --> 00:16:52.759
<v Speaker 2>world that's increasingly reliant on technology, what if every piece

345
00:16:52.759 --> 00:16:55.960
<v Speaker 2>of software you interact with, your banking app, your smart

346
00:16:55.960 --> 00:16:58.759
<v Speaker 2>home divides the systems at work. What if it was

347
00:16:58.799 --> 00:17:00.840
<v Speaker 2>all built with the level of care and the security

348
00:17:00.840 --> 00:17:02.240
<v Speaker 2>principles we discussed.

349
00:17:01.840 --> 00:17:04.359
<v Speaker 1>Today, that would be significantly different.

350
00:17:04.519 --> 00:17:07.960
<v Speaker 2>Think about the widespread impact, how much safer our digital

351
00:17:08.039 --> 00:17:11.920
<v Speaker 2>lives could actually be. The responsibility really lies with all

352
00:17:11.960 --> 00:17:15.960
<v Speaker 2>of us developers, testers, architects, everyone to raise the bar,

353
00:17:16.160 --> 00:17:20.559
<v Speaker 2>to keep learning and to proactively engage with these security practices.

354
00:17:20.680 --> 00:17:23.200
<v Speaker 1>That's a powerful thought for you to mull Over. The

355
00:17:23.200 --> 00:17:25.599
<v Speaker 1>book makes a great point too that technical debt is

356
00:17:25.640 --> 00:17:27.440
<v Speaker 1>almost always security debt and disguise.

357
00:17:27.599 --> 00:17:31.079
<v Speaker 2>Oh that's so true, that outdated library, that unpatched server

358
00:17:31.640 --> 00:17:32.680
<v Speaker 2>security risks.

359
00:17:33.119 --> 00:17:36.119
<v Speaker 1>So staying on top of updates and managing dependencies isn't

360
00:17:36.160 --> 00:17:40.839
<v Speaker 1>just about efficiency or new features. It's fundamental to robust security,

361
00:17:41.119 --> 00:17:44.559
<v Speaker 1>and our source encourages us all to be super rosers,

362
00:17:45.160 --> 00:17:47.920
<v Speaker 1>not just in our technical skills, but in our awareness

363
00:17:48.039 --> 00:17:52.039
<v Speaker 1>awareness that we as people who build and manage systems

364
00:17:52.559 --> 00:17:53.319
<v Speaker 1>are targets.

365
00:17:53.480 --> 00:17:56.400
<v Speaker 2>We have privileged access exactly, and.

366
00:17:56.400 --> 00:17:59.480
<v Speaker 1>So we must protect our own work devices, our accounts

367
00:17:59.720 --> 00:18:04.160
<v Speaker 1>are data with extreme vigilance. So maybe a final question

368
00:18:04.200 --> 00:18:07.400
<v Speaker 1>for you listening, what new security practice will you try

369
00:18:07.400 --> 00:18:10.119
<v Speaker 1>to implement this week in your own projects, even a

370
00:18:10.160 --> 00:18:10.720
<v Speaker 1>small one.

371
00:18:10.839 --> 00:18:13.519
<v Speaker 2>And remember you don't have to figure this all out alone.

372
00:18:13.680 --> 00:18:17.880
<v Speaker 2>Good point joining security communities like oas, finding mentors, or

373
00:18:17.920 --> 00:18:21.279
<v Speaker 2>even just asking your organization's security team for help. These

374
00:18:21.279 --> 00:18:24.200
<v Speaker 2>are invaluable steps. As the author says, they are experts

375
00:18:24.240 --> 00:18:27.559
<v Speaker 2>hired specifically to help you make them earn their paychecks exactly.

376
00:18:27.680 --> 00:18:31.000
<v Speaker 2>Your commitment to these principles, your questions, your efforts, they

377
00:18:31.000 --> 00:18:33.279
<v Speaker 2>make a tangible difference. Not just for your own code,

378
00:18:33.279 --> 00:18:36.160
<v Speaker 2>but really for the wider digital ecosystem we all depend on.

379
00:18:36.599 --> 00:18:38.839
<v Speaker 1>That's it for this deep dive into secure coding. We

380
00:18:38.880 --> 00:18:41.359
<v Speaker 1>hope this has given you plenty to think about and

381
00:18:41.680 --> 00:18:44.960
<v Speaker 1>some actionable insights to apply. Hopefully, so join us next

382
00:18:45.000 --> 00:18:47.200
<v Speaker 1>time for another deep dive into a topic that will

383
00:18:47.240 --> 00:18:51.039
<v Speaker 1>leave you well informed and probably, as usual, a little surprised.

384
00:18:51.720 --> 00:18:53.079
<v Speaker 1>Until then, keep digging,