These New Vulnerabilities Could Break Your .NET Code

WEBVTT

1
00:00:00.080 --> 00:00:02.160
If you've ever thought your net app is safe just

2
00:00:02.200 --> 00:00:04.519
because you're running the latest framework, this might be the

3
00:00:04.559 --> 00:00:07.919
wake up call you didn't expect. O wasp's upcoming update

4
00:00:07.960 --> 00:00:11.679
emphasizes changes worth rethinking in your architecture. In this video,

5
00:00:11.720 --> 00:00:14.439
you'll see which O WASP twenty twenty five categories matter

6
00:00:14.560 --> 00:00:16.839
most for a net, three things to scan for in

7
00:00:16.839 --> 00:00:19.559
your pipelines today, and one common code pattern you should

8
00:00:19.600 --> 00:00:22.160
fix this week. Some of these risks come from everyday

9
00:00:22.160 --> 00:00:25.000
coding habits you might already rely on. Stick around. We'll

10
00:00:25.039 --> 00:00:28.039
map those changes into practical steps your net team can

11
00:00:28.120 --> 00:00:32.000
use today. The categories you didn't see coming. The categories

12
00:00:32.000 --> 00:00:34.079
you didn't see coming are the ones that force teams

13
00:00:34.119 --> 00:00:35.960
to step back and look at the bigger picture. The

14
00:00:36.039 --> 00:00:39.679
latest O WASP update doesn't just shuffle familiar risks. It

15
00:00:39.719 --> 00:00:43.399
appears to shift attention toward architectural and ecosystem blind spots

16
00:00:43.439 --> 00:00:46.799
that most developers never thought to check. That's telling because

17
00:00:46.840 --> 00:00:50.200
for years, many assumed that sticking with the latest net version,

18
00:00:50.479 --> 00:00:54.159
enabling defaults, and keeping frameworks patched, would be enough. Yet

19
00:00:54.200 --> 00:00:56.320
what we're seeing now suggests that even when the runtime

20
00:00:56.359 --> 00:00:59.119
itself is hardened, risks can creep in through the way

21
00:00:59.159 --> 00:01:02.479
components connect the dependencies you rely on and the environments

22
00:01:02.479 --> 00:01:05.480
you deploy into. Think about a simple real world example.

23
00:01:05.560 --> 00:01:07.640
You build a micro service in bolt net that calls

24
00:01:07.680 --> 00:01:10.879
out to an external API, straightforward enough, But under the

25
00:01:10.920 --> 00:01:12.959
surface that service may pull in you get packages you

26
00:01:13.000 --> 00:01:16.400
didn't directly install, nested dependencies buried three or four layers deep.

27
00:01:16.519 --> 00:01:19.280
Now imagine one of those libraries gets compromised. Even if

28
00:01:19.319 --> 00:01:22.000
you're fully patched on Net eight or nine, your code

29
00:01:22.079 --> 00:01:24.840
is suddenly carrying a vulnerability you didn't put there. What

30
00:01:24.959 --> 00:01:27.280
happens if a widely used library you depend on is

31
00:01:27.319 --> 00:01:29.760
compromised and you don't even know it's in your build.

32
00:01:30.000 --> 00:01:32.840
That's the type of scenario o WASP is elevating. It's

33
00:01:32.920 --> 00:01:35.280
less about a botched query in your own code and

34
00:01:35.319 --> 00:01:39.400
more about ecosystem risks spreading silently into production supply chain.

35
00:01:39.439 --> 00:01:42.560
Concerns like this aren't hypothetical. We've seen patterns in different

36
00:01:42.560 --> 00:01:46.719
ecosystems where one poisoned update propagates into thousands of applications overnight.

37
00:01:47.040 --> 00:01:48.840
For dot net, Neuget is both a strength and a

38
00:01:48.879 --> 00:01:52.319
weakness in this regard. It accelerates development, but it also

39
00:01:52.359 --> 00:01:55.760
makes it harder to manually verify every dependency each time

40
00:01:55.760 --> 00:01:59.079
your pipeline runs. The WASP shift seems to recognize that

41
00:01:59.120 --> 00:02:01.840
today's breaches offten come not from your logic, but from

42
00:02:01.879 --> 00:02:04.959
what you pull in automatically without full visibility, and that's

43
00:02:05.000 --> 00:02:08.000
why the conversation is moving toward patterns such as software

44
00:02:08.000 --> 00:02:11.280
bills of materials and automated dependency scanning. Will walk through

45
00:02:11.319 --> 00:02:14.039
practical mitigation patterns you can adopt later, but the point

46
00:02:14.039 --> 00:02:16.680
for now is clear. The ownership line doesn't stop where

47
00:02:16.680 --> 00:02:20.000
your code ends. The second blind spot is asset visibility.

48
00:02:20.000 --> 00:02:23.840
In today's containerized en ed deployments. When teams adopt cloud

49
00:02:23.919 --> 00:02:27.039
native patterns, the number of artifacts to track usually climbs fast.

50
00:02:27.120 --> 00:02:30.199
You might have dozens of images spread across registries, each

51
00:02:30.240 --> 00:02:32.960
with its own base, layers and dependencies, all stitched into

52
00:02:32.960 --> 00:02:35.960
a cluster. The challenge isn't writing secure functions, it's knowing

53
00:02:36.039 --> 00:02:38.879
exactly which images are running and what's inside them. Without

54
00:02:38.879 --> 00:02:41.599
that visibility, you can end up shipping compromise layers for

55
00:02:41.719 --> 00:02:44.960
weeks before noticing. It's not just a risk. In theory,

56
00:02:45.199 --> 00:02:48.280
the attack surface expands whenever you lose track of what's

57
00:02:48.319 --> 00:02:52.240
actually in production. Framing it differently. Frameworks like net eight

58
00:02:52.280 --> 00:02:55.759
have made big strides with secure by default authentication, input validation,

59
00:02:55.840 --> 00:02:58.879
and token handling. Those are genuine gains for developers, but

60
00:02:58.960 --> 00:03:02.199
attackers don't look at individual functions in isolation. They look

61
00:03:02.199 --> 00:03:04.919
for the seams. A strong identity library doesn't protect you

62
00:03:05.000 --> 00:03:07.879
from an outdated base image in a container. A hardened

63
00:03:07.919 --> 00:03:10.840
minimal API doesn't erase the possibility of a poisoned new

64
00:03:10.879 --> 00:03:13.800
GAT package flowing into your micro service. These new categories

65
00:03:13.800 --> 00:03:18.439
are spotlighting how quickly architecture decisions can overshadow secure coding practices.

66
00:03:18.560 --> 00:03:20.759
So when we talk about categories you didn't see coming,

67
00:03:20.840 --> 00:03:23.599
we're really pointing to risks that live above the function

68
00:03:23.719 --> 00:03:26.960
level too. You should focus on today. Supply chain exposure

69
00:03:27.000 --> 00:03:30.560
through new GET and visibility gaps in containerized deployments both

70
00:03:30.639 --> 00:03:33.120
hit dot net projects directly because they align so closely

71
00:03:33.159 --> 00:03:35.400
with how modern apps are built. You might be shipping

72
00:03:35.400 --> 00:03:37.360
clean coat and still end up exposed if you overlook

73
00:03:37.400 --> 00:03:40.039
either of these. And here's the shift that makes this interesting.

74
00:03:40.240 --> 00:03:42.719
The owa's update seems less concerned with what mistake a

75
00:03:42.800 --> 00:03:45.599
single developer made in a controller and more with what

76
00:03:45.719 --> 00:03:49.759
architectural decisions entire teams made about dependencies and deployment parts.

77
00:03:50.360 --> 00:03:52.639
To protect your apps, you can't just zoom in, you

78
00:03:52.680 --> 00:03:55.599
have to zoom out now. If new categories are appearing

79
00:03:55.639 --> 00:03:58.360
in the top ten, that also raises the opposite question,

80
00:03:58.400 --> 00:04:00.319
which ones have dropped out? And does that mean we

81
00:04:00.319 --> 00:04:02.800
can stop worrying about them? Some of the biggest surprises

82
00:04:02.840 --> 00:04:05.039
in the update aren't about what got added at all.

83
00:04:05.199 --> 00:04:08.159
They're about what quietly went missing. What's missing and why

84
00:04:08.199 --> 00:04:11.000
You're not off the hook? That shift leads directly into

85
00:04:11.039 --> 00:04:13.240
the question we need to unpack now what happens to

86
00:04:13.280 --> 00:04:15.560
the risks that no longer appear Front and center in

87
00:04:15.599 --> 00:04:18.160
the latest O was bliss. This is the piece called

88
00:04:18.279 --> 00:04:20.680
what's missing and why You're not off the hook, and

89
00:04:20.720 --> 00:04:23.399
it's an easy place for teams to misjudge their exposure.

90
00:04:23.720 --> 00:04:26.920
When older categories are de emphasized, some developers assume they

91
00:04:26.920 --> 00:04:30.040
can simply stop worrying about them. That assumption is risky.

92
00:04:30.279 --> 00:04:32.600
Just because of vulnerability isn't highlighted as one of the

93
00:04:32.639 --> 00:04:35.639
most frequent attack types doesn't mean it has stopped existing.

94
00:04:36.199 --> 00:04:38.759
The truth is many of these well known issues are

95
00:04:38.800 --> 00:04:41.759
still active in production systems. They appear less often in

96
00:04:41.800 --> 00:04:44.279
the research data because newer risks like supply chain and

97
00:04:44.279 --> 00:04:47.959
asset visibility now dominate the numbers. But lower visibility isn't

98
00:04:47.959 --> 00:04:51.480
the same as elimination. Injection flaws illustrate the point. For decades,

99
00:04:51.519 --> 00:04:55.000
developer training has hammered at avoiding unsafe queries, and in

100
00:04:55.079 --> 00:04:59.040
need has introduced stronger defaults like parameterized queries through Entity Framework.

101
00:04:59.319 --> 00:05:02.759
These improvements drive incident volume down, Yet attackers can still

102
00:05:02.759 --> 00:05:05.959
and do take advantage when teams slip back into unsafe habits.

103
00:05:06.199 --> 00:05:08.920
Lower ranking doesn't mean gone, it means attackers still exploit

104
00:05:08.959 --> 00:05:13.000
the quieter gaps. Legacy components offer a similar lesson. We've

105
00:05:13.040 --> 00:05:15.959
repeatedly seen problems arise when older libraries or passes hang

106
00:05:16.000 --> 00:05:19.199
around are noticed. Teams may deprioritize them just because they've

107
00:05:19.199 --> 00:05:21.920
stopped showing up in the headline categories. That's when the

108
00:05:22.040 --> 00:05:25.399
risk grows. If an outdated XML passer or serializer has

109
00:05:25.399 --> 00:05:27.680
been running quietly for months, it only takes one abuse

110
00:05:27.720 --> 00:05:30.199
path to turn it into a direct breach. The main

111
00:05:30.240 --> 00:05:34.480
takeaway is practical, don't deprioritize legacy components simply because they

112
00:05:34.480 --> 00:05:38.240
feel old. Attackers often exploit precisely what teams forget to monitor.

113
00:05:38.639 --> 00:05:40.879
This is why treating the top ten as a checklist

114
00:05:40.879 --> 00:05:43.680
to be ticked off line by line is misleading. The

115
00:05:43.759 --> 00:05:47.600
ranking reflects frequency and impact across industries during a given timeframe.

116
00:05:48.040 --> 00:05:50.959
It doesn't mean every other risk has evaporated. If anything,

117
00:05:51.240 --> 00:05:53.720
a category falling lower on the list should trigger a

118
00:05:53.759 --> 00:05:56.600
different kind of alert. You must be disciplined enough to

119
00:05:56.639 --> 00:05:59.519
defend against both the highly visible threats of today and

120
00:05:59.560 --> 00:06:03.680
the quiet ones of yesterday. Security requires balance across both

121
00:06:03.800 --> 00:06:06.800
on the net side. Insecure Civilization is a classic example.

122
00:06:07.000 --> 00:06:09.360
It may not rank high right now, but the flow

123
00:06:09.439 --> 00:06:12.720
still allows attackers to push arbitrary code or read private

124
00:06:12.800 --> 00:06:16.000
data if developers use unsafe defaults, many teams reach for

125
00:06:16.079 --> 00:06:19.600
jacent libraries or rely on long standing patterns without adding

126
00:06:19.600 --> 00:06:22.600
The Guardrail's newer guidance recommends attacks don't have to be

127
00:06:22.639 --> 00:06:25.120
powerful in volume to be powerful in damage. A single

128
00:06:25.160 --> 00:06:29.040
overlooked deserialization flow can expose customer records or turn into

129
00:06:29.079 --> 00:06:32.480
a stepping stone for deeper compromise. Attackers, of course track

130
00:06:32.560 --> 00:06:35.560
this mindset. They notice that once a category is no

131
00:06:35.600 --> 00:06:39.759
longer emphasized, development teams tend to breathe easier code written

132
00:06:39.800 --> 00:06:43.360
years ago, lingers, unchanged audit rules are dropped, Patching slows

133
00:06:43.399 --> 00:06:47.480
down For an attacker, these conditions create easy wins. Instead

134
00:06:47.480 --> 00:06:49.959
of competing with every security team focused on the latest

135
00:06:49.959 --> 00:06:53.360
supply chain monitoring tool, they target the forgotten injection vector

136
00:06:53.439 --> 00:06:56.639
still lurking in a reporting module or an unused service endpoint,

137
00:06:56.720 --> 00:07:00.279
exposing data through an obsolete library from their specse if

138
00:07:00.319 --> 00:07:02.720
it takes less effort to go where defenders aren't looking.

139
00:07:03.079 --> 00:07:05.519
The practical lesson here is straightforward. When a category gets

140
00:07:05.600 --> 00:07:09.000
less attention, the underlying risk often becomes more attractive to attackers,

141
00:07:09.199 --> 00:07:12.839
not less. What disappeared from view still matters, and treating

142
00:07:12.879 --> 00:07:16.040
the absence as a green light to deprioritize is short sighted.

143
00:07:16.319 --> 00:07:19.160
For dot net teams, the defensive posture should always combine

144
00:07:19.199 --> 00:07:22.279
awareness of emerging risks with consistent care for so called

145
00:07:22.360 --> 00:07:25.399
legacy weaknesses. Both are alive, one is just louder than

146
00:07:25.439 --> 00:07:27.800
the other. Next, we'll put this into context by looking

147
00:07:27.839 --> 00:07:30.360
at the kinds of every day net code patterns that

148
00:07:30.439 --> 00:07:33.720
often map directly into these overlooked risks. Some of the

149
00:07:33.720 --> 00:07:37.279
most overlooked risks aren't hidden in new frameworks or elaborate exploits.

150
00:07:37.480 --> 00:07:40.000
They're sitting right inside code you may have written years ago.

151
00:07:40.399 --> 00:07:43.680
This is the territory of hidden traps, where ordinary entity

152
00:07:43.759 --> 00:07:47.439
patterns that once felt routine are now reframed as security liabilities.

153
00:07:47.920 --> 00:07:49.879
The unsettling part is that many of these patterns are

154
00:07:49.920 --> 00:07:52.720
still running in production, and even though they seemed harmless

155
00:07:52.759 --> 00:07:55.360
at the time, they now map directly into higher risk

156
00:07:55.439 --> 00:07:58.759
categories defined in today's threat models. One of the clearest

157
00:07:58.759 --> 00:08:02.519
examples is weak or partial input validation. Many projects still

158
00:08:02.519 --> 00:08:05.879
rely on client side checks or lightweight rejects filtering, assuming

159
00:08:05.920 --> 00:08:08.839
that's enough before passing data along. It looks safe until

160
00:08:08.839 --> 00:08:12.399
you realize attackers can bypass those protections with ease. Add

161
00:08:12.399 --> 00:08:15.759
in the fact that plenty of NEAT applications still deserialize

162
00:08:15.800 --> 00:08:19.680
objects directly from user input without extra screening, and suddenly

163
00:08:19.759 --> 00:08:23.480
that old performance shortcut becomes a structural weakness. The concern

164
00:08:23.560 --> 00:08:26.000
isn't a single mist bug, it's the way repeated use

165
00:08:26.000 --> 00:08:29.639
of these shortcuts quietly undermined system resilience over time. Another

166
00:08:29.680 --> 00:08:32.399
common case is the forgotten debug feature left open. A

167
00:08:32.480 --> 00:08:35.360
developer may spin up an endpoint during testing, use it

168
00:08:35.399 --> 00:08:37.480
for tracing, then forget about it when the service moves

169
00:08:37.480 --> 00:08:41.960
into production. Fast forward months later and an attacker discovers it,

170
00:08:42.200 --> 00:08:45.000
using it to step deeper into the environment. What once

171
00:08:45.039 --> 00:08:47.960
seemed like a harmless helper for internal diagnostics turns into

172
00:08:48.000 --> 00:08:50.919
an entry point classified today as insecure design. The catch

173
00:08:51.000 --> 00:08:53.960
is that these mistakes rarely look dangerous until someone connects

174
00:08:54.000 --> 00:08:56.960
the dots from small debugging aid to pivot point for

175
00:08:57.039 --> 00:09:00.600
lateral movement. To illustrate how subtle these risks can be,

176
00:09:00.919 --> 00:09:04.200
picture a very basic get endpoint that fetches a user

177
00:09:04.240 --> 00:09:06.399
by idings at ND look my code on the M

178
00:09:06.440 --> 00:09:09.240
three sixty five show blog post for this podcast. On

179
00:09:09.279 --> 00:09:12.120
the surface, this feels ordinary, something you or your teammates

180
00:09:12.159 --> 00:09:14.600
may have written hundreds of times in ef core or link.

181
00:09:14.759 --> 00:09:18.080
But underneath it exposes several quiet pitfalls. There's no type

182
00:09:18.080 --> 00:09:20.840
constraint on the ID parameter. There's no check to confirm

183
00:09:20.879 --> 00:09:23.600
the caller is authorized to view a specific user. There's

184
00:09:23.600 --> 00:09:27.120
also no traceability. No longer is recorded if repeated unauthorized

185
00:09:27.120 --> 00:09:29.519
attempts are made. Now, imagine this lives in an API

186
00:09:29.600 --> 00:09:32.960
gateway in front of multiple services. One unprotected pathway can

187
00:09:33.039 --> 00:09:35.960
ripple across your environment. Here's the scenario to keep in mind.

188
00:09:36.240 --> 00:09:38.519
What if any logged in user simply changes the ID

189
00:09:38.600 --> 00:09:41.799
string to another value in the request. Suddenly one careless

190
00:09:41.840 --> 00:09:45.159
line of code means accessing someone else's profile or worse,

191
00:09:45.639 --> 00:09:48.679
records across the entire database. It doesn't take a sophisticated

192
00:09:48.679 --> 00:09:51.279
exploit to turn this oversight into a data breach. So

193
00:09:51.279 --> 00:09:54.000
how do you tighten this endpoint without rebuilding the entire app?

194
00:09:54.120 --> 00:09:57.480
Three practical fixes stand out. First, strongly type and validate

195
00:09:57.519 --> 00:10:00.559
the input. For example, enforce a guide or numeric constrained

196
00:10:00.600 --> 00:10:04.679
in the root definitions, or malicious inputs don't slip through unchecked. Second,

197
00:10:05.080 --> 00:10:09.279
enforce an authorization check before returning any record. Add authorize

198
00:10:09.440 --> 00:10:12.200
and apply a resource based check so the caller only

199
00:10:12.240 --> 00:10:15.240
sees their own data. Third, add structured logging to capture

200
00:10:15.240 --> 00:10:18.639
failed authorization attempts, giving your team visibility into patterns of

201
00:10:18.679 --> 00:10:22.120
abuse before they escalate. These steps require minimal effort, but

202
00:10:22.200 --> 00:10:24.799
eliminate the most dangerous blind spots in this routine bit

203
00:10:24.840 --> 00:10:27.559
of code. This shift in perspective matters. In the past,

204
00:10:27.799 --> 00:10:30.679
discussions around secure code often meant debating whether or not

205
00:10:30.759 --> 00:10:33.480
a single statement could be injected with malicious values. Now,

206
00:10:33.480 --> 00:10:36.399
the focus is broader. Context matters as much as syntax.

207
00:10:36.759 --> 00:10:39.320
A safe looking method in isolation can become the weak

208
00:10:39.360 --> 00:10:42.519
link once it's exposed in a distributed cloud hosted environment.

209
00:10:42.840 --> 00:10:45.159
The design surface, not the line of code, defines the

210
00:10:45.200 --> 00:10:48.919
attack surface. Newer dot net releases do offer stronger templates

211
00:10:48.919 --> 00:10:52.360
and libraries that can help, particularly around identity management and routing,

212
00:10:52.480 --> 00:10:54.879
but those are tools, not safeguards. By default. You still

213
00:10:54.919 --> 00:10:58.840
need to configure authorization checks, enforce validation, and apply structured

214
00:10:58.919 --> 00:11:02.799
error handling ding. The newest framework version doesn't automatically undo

215
00:11:03.000 --> 00:11:06.600
unsafe coding habits that slipped into earlier bills. Guardrails can

216
00:11:06.639 --> 00:11:10.840
reduce friction, but security depends on active effort, not passive inheritance.

217
00:11:11.279 --> 00:11:13.799
The real takeaway is simple. Some of the riskiest patterns

218
00:11:13.799 --> 00:11:16.120
in your applications aren't the new lines of code you'll

219
00:11:16.120 --> 00:11:20.080
write tomorrow. They're the familiar routines already deployed today. Recognizing

220
00:11:20.120 --> 00:11:22.399
that reality is the first step toward cleaning them up.

221
00:11:22.559 --> 00:11:24.679
It also raises a bigger question. If many of these

222
00:11:24.720 --> 00:11:26.960
traps are already in your code base, how do you

223
00:11:27.000 --> 00:11:29.480
prevent them from creeping back in during the next project.

224
00:11:29.759 --> 00:11:32.240
But that's where process and workflow matter just as much

225
00:11:32.279 --> 00:11:34.600
as code and why the next step is about designing

226
00:11:34.639 --> 00:11:36.879
security into the way you build software from the start,

227
00:11:37.279 --> 00:11:40.320
not bolting it on at the eed, designing security into

228
00:11:40.320 --> 00:11:43.600
your sun's net workflow. Most development teams still slip into

229
00:11:43.600 --> 00:11:46.120
the habit of treating security as something that gets checked

230
00:11:46.159 --> 00:11:50.120
right before release. Features get built, merged, deployed, and only

231
00:11:50.159 --> 00:11:53.559
afterward do scanners or external pen tests flag the problems.

232
00:11:53.639 --> 00:11:56.320
By that point, your choices are limited. You either scramble

233
00:11:56.399 --> 00:11:58.600
to patch while users are waiting, or you accept the

234
00:11:58.679 --> 00:12:00.919
risk and hope it doesn't blow up for the next cycle.

235
00:12:01.320 --> 00:12:04.080
It's no surprise this pattern exists. Release schedules are tight,

236
00:12:04.120 --> 00:12:07.159
and anything that doesn't produce visible features often feels optional.

237
00:12:07.559 --> 00:12:10.159
The catch is that this lagging approach doesn't hold up anymore.

238
00:12:10.360 --> 00:12:13.440
Changes in oap's latest list reinforced that problems are tied

239
00:12:13.639 --> 00:12:15.519
just as much to how you build as to what

240
00:12:15.600 --> 00:12:18.200
you code. If the threats are in the workflow itself,

241
00:12:18.639 --> 00:12:22.080
Waiting until the end guarantees you'll always be reacting instead

242
00:12:22.120 --> 00:12:25.600
of preventing. Instead of treating security checks like late stage firefighting,

243
00:12:26.120 --> 00:12:29.600
use the OAP categories as inputs upfront. If issues like

244
00:12:29.679 --> 00:12:33.279
asset visibility or supply chain exposure are highlighted as systemic risks.

245
00:12:33.519 --> 00:12:35.840
Then the moment you add a new NUGAD dependency or

246
00:12:35.879 --> 00:12:39.639
publish a container image, that risk is already present. Scanning

247
00:12:39.679 --> 00:12:43.120
later won't erase it. Embedding security into the design process

248
00:12:43.120 --> 00:12:45.759
at every stage means you intercept those exposures before they

249
00:12:45.759 --> 00:12:48.960
harden into production. And it's about making security a default

250
00:12:48.960 --> 00:12:52.080
part of how your pipeline runs, protecting by prevention, not

251
00:12:52.159 --> 00:12:55.120
by cleanup. Right now, many teams technically have policies, but

252
00:12:55.159 --> 00:12:58.360
those policies live in wikis, not in actual code. Architects

253
00:12:58.399 --> 00:13:02.039
write pages about input validation, parameterized queries, or how to

254
00:13:02.080 --> 00:13:06.360
manage secrets. Everyone nods, But once sprint pressure builds, convenience

255
00:13:06.360 --> 00:13:09.480
wins out, pull requests slip past, and the written guidance

256
00:13:09.519 --> 00:13:12.759
barely registers in the day to day. That's not bad intent.

257
00:13:12.960 --> 00:13:16.200
It's simply how software delivery works under pressure. Unless those

258
00:13:16.279 --> 00:13:19.399
rules are baked into tools, they collapse quickly. Dependency checks

259
00:13:19.399 --> 00:13:21.879
are a good example. Plenty of pipelines happily built and

260
00:13:21.919 --> 00:13:25.519
ship software without auditing packages until after deployment. To put

261
00:13:25.519 --> 00:13:28.559
it more directly, if a malicious dependency makes it through.

262
00:13:28.759 --> 00:13:32.279
The warning comes only once customers already have the compromise built.

263
00:13:32.799 --> 00:13:35.679
The bottom line is that testing security after deployment is late.

264
00:13:36.159 --> 00:13:38.879
You want those warnings before a release ever leaves CCD.

265
00:13:39.000 --> 00:13:41.919
That's why modern net defsec ops approaches and bed safeguards

266
00:13:41.960 --> 00:13:46.519
earlier think automated static analysis wired into every commit, dependency

267
00:13:46.519 --> 00:13:49.440
audits that run before build artifacts are packaged, and even

268
00:13:49.480 --> 00:13:53.240
merged checks that block pull requests containing severe issues. None

269
00:13:53.279 --> 00:13:55.879
of these rely on developers remembering wiki rules. They operate

270
00:13:55.919 --> 00:13:59.039
automatically every time code moves today. For example, you could

271
00:13:59.159 --> 00:14:02.559
enable automatic dependency auditing within your built pipeline, and you

272
00:14:02.600 --> 00:14:05.639
could add generation of a software bill of materials as

273
00:14:05.720 --> 00:14:10.919
BOM at every release. Both steps directly increase visibility into

274
00:14:10.960 --> 00:14:15.399
what's shipping without slowing developers down. Platform features reinforce this direction.

275
00:14:15.559 --> 00:14:18.320
Minimal APIs and bondnet eight don't push you toward broad

276
00:14:18.399 --> 00:14:22.960
exposed endpoints. They encourage safer defaults. Built in authentication libraries

277
00:14:23.000 --> 00:14:26.600
integrate with standard identity providers, meaning token handling or claims

278
00:14:26.639 --> 00:14:30.519
validation doesn't require custom and error prone code. These are

279
00:14:30.559 --> 00:14:33.240
not just extras, their guardrails. When you use them, you

280
00:14:33.279 --> 00:14:36.000
reduce both the risk of danger shortcuts and the developer

281
00:14:36.039 --> 00:14:38.679
overhead of securing everything by hand. A clear way to

282
00:14:38.720 --> 00:14:42.080
frame these practices is through the add workflow. Each stage

283
00:14:42.080 --> 00:14:45.519
maps neatly to a concrete security action. In analysis, inventory,

284
00:14:45.559 --> 00:14:48.639
your components build a list of every dependency and asset

285
00:14:48.639 --> 00:14:51.279
before adding them to a project. In design, run a

286
00:14:51.360 --> 00:14:54.960
lightweight thread model to highlight insecure design choices while you're

287
00:14:54.960 --> 00:14:58.480
still working on diagrams. In development, integrate static analysis and

288
00:14:58.519 --> 00:15:01.600
dependency checks directly into CE so problems are flagged before

289
00:15:01.639 --> 00:15:05.879
mergers complete. In implementation, configure your deployment pipeline to block

290
00:15:05.960 --> 00:15:09.360
releases that fail those checks. And in evaluation, schedule periodic

291
00:15:09.399 --> 00:15:11.320
refreshes of your threat models so they align with the

292
00:15:11.360 --> 00:15:14.159
most current risks. These concrete steps aren't abstract, They are

293
00:15:14.159 --> 00:15:17.679
practical recommendations that and need teams can start applying immediately.

294
00:15:17.759 --> 00:15:20.240
The result is a workflow that stops being reactive and

295
00:15:20.279 --> 00:15:24.000
starts being resilient. Caught during design, a risky pattern costs

296
00:15:24.039 --> 00:15:27.519
minutes to address. Found during evaluation, it costs hours found

297
00:15:27.559 --> 00:15:30.600
in production, it may cost months or worse reputational trust.

298
00:15:30.960 --> 00:15:33.000
The more you shift left, the more your team saves

299
00:15:33.200 --> 00:15:35.759
what feels like security overhead at first ends up buying

300
00:15:35.759 --> 00:15:38.759
you predictability and fewer last minute fire drills. In short,

301
00:15:38.759 --> 00:15:42.120
designing security into the workflow isn't about paperwork or box ticking.

302
00:15:42.240 --> 00:15:44.759
It's about structuring processes. So the right decision is the

303
00:15:44.799 --> 00:15:48.320
easy decision. That way, developers aren't relying on memory or intent.

304
00:15:48.679 --> 00:15:51.519
They're guided by built in checks and platform support. And

305
00:15:51.559 --> 00:15:54.159
the real test comes next. Once you've built this workflow,

306
00:15:54.360 --> 00:15:56.320
how do you confirm that it's working? How do you

307
00:15:56.360 --> 00:15:59.039
measure whether the safeguards you've integrated actually align with the

308
00:15:59.120 --> 00:16:01.600
risks or waspisofre lagging. Now, that's the next challenge we

309
00:16:01.639 --> 00:16:05.679
need to unpack measuring your application against twenty twenty five standards.

310
00:16:05.879 --> 00:16:08.879
Measuring your application against twenty twenty five standards means shifting

311
00:16:08.879 --> 00:16:11.840
your yardstick. The question isn't whether your pipeline is showing

312
00:16:11.840 --> 00:16:14.039
a green check mark. It's whether the tools you're relying

313
00:16:14.080 --> 00:16:17.240
on actually map to the risks developers face Now, too

314
00:16:17.240 --> 00:16:21.240
many teams still use benchmarks built around yesterday's threats, and

315
00:16:21.279 --> 00:16:24.240
that gap creates a dangerous illusion of safety. Passing scans

316
00:16:24.240 --> 00:16:27.080
may reassure, but reassurance is not the same thing as resilience.

317
00:16:27.200 --> 00:16:29.759
This is a common failure mode across the industry. Companies

318
00:16:29.840 --> 00:16:33.480
lean on outdated security checklists thinking they're current, but those

319
00:16:33.519 --> 00:16:36.200
lists often carry more weight for compliance than for protection.

320
00:16:36.720 --> 00:16:39.480
You still see forms focused on sequal injection or SSL

321
00:16:39.519 --> 00:16:42.840
settings from a decade ago, while whole categories of modern

322
00:16:42.919 --> 00:16:46.399
risk like improper authorization flows and supply chain compromise don't

323
00:16:46.440 --> 00:16:50.200
even make the page. When teams celebrate compliance, they confuse

324
00:16:50.200 --> 00:16:54.399
completion with coverage. OWASP twenty twenty five makes the distinction clearer.

325
00:16:54.600 --> 00:16:58.039
Compliance doesn't equal security, and the difference matters more than ever.

326
00:16:58.440 --> 00:17:01.919
The real pitfall comes from assuming that passing existing tests

327
00:17:01.919 --> 00:17:05.160
means you're covered. Pipelines may show that all dependencies are

328
00:17:05.200 --> 00:17:08.319
fully patched and static analysis found nothing critical, yet those

329
00:17:08.359 --> 00:17:11.640
same tools often miss structural flaws. A common failure mode,

330
00:17:11.640 --> 00:17:16.759
particularly in net environments, is broken object level authorization. Automated

331
00:17:16.799 --> 00:17:18.720
tools may not be designed to spot a case where

332
00:17:18.720 --> 00:17:20.759
a user tweaks an ID in a request to pull

333
00:17:20.839 --> 00:17:23.200
data that isn't THEIRS. On paper, the app looks fine.

334
00:17:23.279 --> 00:17:26.119
In reality, the GAP's wide open. The tools weren't negligent,

335
00:17:26.160 --> 00:17:29.240
they simply weren't measuring what attackers now target most To

336
00:17:29.319 --> 00:17:32.480
close that gap, evaluation has to adapt. This doesn't mean

337
00:17:32.519 --> 00:17:35.720
throwing out automation, it means layering it with checks aligned

338
00:17:35.759 --> 00:17:39.160
to modern categories. Three practical steps stand out for any

339
00:17:39.200 --> 00:17:43.200
bouton by net team. First, design automated integration tests that

340
00:17:43.279 --> 00:17:47.079
assert object level authorization. A quick example, run a test

341
00:17:47.119 --> 00:17:49.680
where one signed in user tries to access another user's

342
00:17:49.720 --> 00:17:52.279
record and confirm the API response with a four or

343
00:17:52.279 --> 00:17:56.039
three second Adopt API level scanning tools that test authorization

344
00:17:56.079 --> 00:17:59.799
and identity flows. Instead of checking for outdated libraries, these

345
00:18:00.319 --> 00:18:02.720
simulate real requests to see if roll checks and token

346
00:18:02.799 --> 00:18:07.039
validation behaviors expected. Third, round out what automation misses by

347
00:18:07.119 --> 00:18:12.160
running quarterly thread modeling workshops. Gather developers, architects, and security

348
00:18:12.240 --> 00:18:15.599
leads to ask what if questions that stretch across services.

349
00:18:15.920 --> 00:18:18.480
What if a container registry entry is outdated, or what

350
00:18:18.519 --> 00:18:21.319
if a messaging Q leaks data between tenants. None of

351
00:18:21.319 --> 00:18:23.920
these steps are heavy to implement, but they shift evaluation

352
00:18:23.960 --> 00:18:26.880
from box checking to risk mapping. The important point is

353
00:18:26.880 --> 00:18:29.640
matching your tools to the actual thread model. Tooling scores

354
00:18:29.680 --> 00:18:32.240
can absolutely be misleading if the tools aren't aligned to

355
00:18:32.319 --> 00:18:35.279
the categories you're most vulnerable to. A polished dashboard showing

356
00:18:35.400 --> 00:18:38.960
zero issues is worthless if it doesn't consider authorization weaknesses

357
00:18:39.000 --> 00:18:42.440
or hidden dependencies. Instead of blindly chasing one hundred percent,

358
00:18:42.839 --> 00:18:45.440
focus on whether your checks are answering the hard questions

359
00:18:45.519 --> 00:18:48.279
or WASP is raising. Can your process confirm that only

360
00:18:48.319 --> 00:18:51.200
authorized users see their own data? Can it show exactly

361
00:18:51.240 --> 00:18:54.480
which dependencies ship in every build? Can it surface architectural

362
00:18:54.559 --> 00:18:57.640
risks that appear when services interact. If the answer is no,

363
00:18:57.759 --> 00:18:59.839
your score is incomplete, no matter how good it looks

364
00:18:59.880 --> 00:19:02.359
on paper. Minu review still earns a place in this

365
00:19:02.440 --> 00:19:05.559
mix because design risks can't be scanned into the open logic.

366
00:19:05.599 --> 00:19:08.839
Flaws often arise from how services fit together, the gaps

367
00:19:08.880 --> 00:19:11.799
between components, not the lines of code inside them. Workshops

368
00:19:11.799 --> 00:19:15.279
where teams simulate misuse cases and identify architectural weak spots,

369
00:19:15.279 --> 00:19:19.000
are where these issues surface. They're also where developers internalize

370
00:19:19.039 --> 00:19:22.400
the difference between writing good code and designing secure systems.

371
00:19:22.480 --> 00:19:25.279
That's the culture shift overs twenty twenty five pushes toward,

372
00:19:25.759 --> 00:19:28.640
and why measurement today has to include both technical scans

373
00:19:28.640 --> 00:19:31.640
and human review. The payoff here is simple. You stop

374
00:19:31.640 --> 00:19:34.680
measuring success by old metrics and start measuring against the

375
00:19:34.799 --> 00:19:38.400
risks attackers actually exploit. Right now, for dot net teams,

376
00:19:38.599 --> 00:19:42.880
that's a sharper focus on authorization, visibility into supply chain dependencies,

377
00:19:43.079 --> 00:19:46.359
and validation of how cloud native services combine in production.

378
00:19:46.640 --> 00:19:49.480
Treating evaluation as an ongoing cycle rather than a static

379
00:19:49.519 --> 00:19:52.759
gait means you catch tomorrow's week spots before they become

380
00:19:52.920 --> 00:19:55.960
yesterday's breach. So here's a question for you directly. If

381
00:19:56.000 --> 00:19:58.000
you had to add just one security control to your

382
00:19:58.039 --> 00:20:00.839
cipipeline this week, would it be an authorization test or

383
00:20:00.839 --> 00:20:03.640
a supply chain check? Drop your answer in the comments.

384
00:20:03.880 --> 00:20:06.960
Your ideas might spark adjustments in how other teams approach this,

385
00:20:07.400 --> 00:20:09.359
because at the end of the day, measurement isn't about

386
00:20:09.400 --> 00:20:13.680
filling out checklists. It's about resetting how you define secure development.

387
00:20:13.799 --> 00:20:16.359
And once you start changing that definition, it leads naturally

388
00:20:16.400 --> 00:20:20.000
into the broader insight. The standards themselves aren't just pointing

389
00:20:20.000 --> 00:20:23.440
out code mistakes. They're pointing to how our development practices

390
00:20:23.519 --> 00:20:25.960
need to change. So what should you leave with from

391
00:20:26.039 --> 00:20:29.000
all of this? Three clear moves to keep in mind. First,

392
00:20:29.240 --> 00:20:32.559
map OASP twenty twenty five categories to your architecture, not

393
00:20:32.680 --> 00:20:36.640
just to your code. Second, design security into your CIICD

394
00:20:36.720 --> 00:20:40.119
pipeline now, don't leave it as an afterthought. Third measure

395
00:20:40.160 --> 00:20:42.960
with modern tests and regular threat modeling, not old checklists.

396
00:20:43.319 --> 00:20:45.839
If this breakdown helped, hit like and subscribe so you

397
00:20:45.880 --> 00:20:49.119
don't miss future walkthroughs, and drop a comment which of

398
00:20:49.200 --> 00:20:52.880
the new O WASP categories feels like your biggest blind spot.

399
00:20:53.079 --> 00:20:55.680
Your answers help surface the real challenges and net teams

400
00:20:55.680 --> 00:20:58.160
face day to day. If you're rebuilding a pipeline or

401
00:20:58.240 --> 00:21:00.480
want a quick checklist, I can point you to let

402
00:21:00.480 --> 00:21:02.960
me know in the comments will highlight the most common

403
00:21:03.000 --> 00:21:04.440
asks in future discussions.