1
00:00:00,070 --> 00:00:02,080
[Music]

2
00:00:02,080 --> 00:00:04,799
hello everyone and thank you for joining

3
00:00:04,799 --> 00:00:07,520
uh my presentation

4
00:00:07,520 --> 00:00:10,480
for uh cloud native security con and

5
00:00:10,480 --> 00:00:12,559
this presentation is going to be about

6
00:00:12,559 --> 00:00:14,960
the state of vulnerability in in cloud

7
00:00:14,960 --> 00:00:15,839
native

8
00:00:15,839 --> 00:00:18,400
security or in cloud native applications

9
00:00:18,400 --> 00:00:21,920
my name is magno logan and i work for

10
00:00:21,920 --> 00:00:26,800
trend micro as a security researcher

11
00:00:27,279 --> 00:00:30,400
so just a little bit about myself

12
00:00:30,400 --> 00:00:33,040
as i said i'm a senior researcher at

13
00:00:33,040 --> 00:00:35,280
trent micro also an information security

14
00:00:35,280 --> 00:00:38,239
specialist um currently doing cloud and

15
00:00:38,239 --> 00:00:41,040
container security research uh

16
00:00:41,040 --> 00:00:43,760
mostly working with kubernetes security

17
00:00:43,760 --> 00:00:46,399
and also open source security

18
00:00:46,399 --> 00:00:49,440
um i'm a member of the cncf security tag

19
00:00:49,440 --> 00:00:52,559
team as well since uh october last year

20
00:00:52,559 --> 00:00:54,559
and i've been doing container and

21
00:00:54,559 --> 00:00:56,640
security uh container and kubernetes

22
00:00:56,640 --> 00:00:59,359
security research as i said

23
00:00:59,359 --> 00:01:01,680
i also have a personal blog that's

24
00:01:01,680 --> 00:01:03,840
called katanasac.com

25
00:01:03,840 --> 00:01:06,960
where i used to post my

26
00:01:06,960 --> 00:01:08,640
articles at least

27
00:01:08,640 --> 00:01:10,960
once a month

28
00:01:10,960 --> 00:01:13,520
and there are also all my contact

29
00:01:13,520 --> 00:01:16,320
information there and all my previous

30
00:01:16,320 --> 00:01:18,560
presentations either like slides or

31
00:01:18,560 --> 00:01:21,119
videos from previous talks

32
00:01:21,119 --> 00:01:24,000
since since 2011 since i started

33
00:01:24,000 --> 00:01:27,840
speaking at tech conferences

34
00:01:28,720 --> 00:01:30,000
okay so

35
00:01:30,000 --> 00:01:33,439
uh before we start i just wanna

36
00:01:33,439 --> 00:01:35,200
give you a quick overview of what we're

37
00:01:35,200 --> 00:01:37,360
going to cover in this talk

38
00:01:37,360 --> 00:01:38,799
basically

39
00:01:38,799 --> 00:01:40,640
this is a project that i've been working

40
00:01:40,640 --> 00:01:44,159
on for uh a couple months now and um

41
00:01:44,159 --> 00:01:45,759
still ongoing there i think there are

42
00:01:45,759 --> 00:01:47,920
some uh improvements

43
00:01:47,920 --> 00:01:49,920
uh required and and we're gonna talk

44
00:01:49,920 --> 00:01:51,600
about that at the end

45
00:01:51,600 --> 00:01:52,799
but the

46
00:01:52,799 --> 00:01:55,200
i'm gonna explain to you the idea for

47
00:01:55,200 --> 00:01:58,479
the project uh what are the cncf

48
00:01:58,479 --> 00:02:01,439
security audits how they're done and and

49
00:02:01,439 --> 00:02:03,600
the list of of the ones that have been

50
00:02:03,600 --> 00:02:05,680
performed so far on many different

51
00:02:05,680 --> 00:02:06,799
projects

52
00:02:06,799 --> 00:02:09,360
and then we'll go into the details of

53
00:02:09,360 --> 00:02:11,038
the results of the data that we

54
00:02:11,038 --> 00:02:13,760
collected and analyze um basically i'm

55
00:02:13,760 --> 00:02:15,599
going to explain the methodology that we

56
00:02:15,599 --> 00:02:18,480
use the analysis that we've done and the

57
00:02:18,480 --> 00:02:21,760
results that we got and also uh talking

58
00:02:21,760 --> 00:02:24,000
a little bit about the third-party risks

59
00:02:24,000 --> 00:02:28,239
of some of this uh these projects and uh

60
00:02:28,239 --> 00:02:31,200
to uh conclude and summarize everything

61
00:02:31,200 --> 00:02:33,840
i'm gonna give some recommendations uh

62
00:02:33,840 --> 00:02:36,319
some recommendations to the cncf but

63
00:02:36,319 --> 00:02:38,080
also some recommendations for

64
00:02:38,080 --> 00:02:40,239
organizations and end users

65
00:02:40,239 --> 00:02:42,879
and some next steps on on how i'm

66
00:02:42,879 --> 00:02:45,760
planning to uh keep improving this

67
00:02:45,760 --> 00:02:49,280
project and doing uh as a as a kind of a

68
00:02:49,280 --> 00:02:52,560
periodic researcher

69
00:02:53,519 --> 00:02:56,319
before i start i just want to say that

70
00:02:56,319 --> 00:02:58,879
uh give a little disclaimer here the

71
00:02:58,879 --> 00:03:01,200
idea for this project is to generate

72
00:03:01,200 --> 00:03:03,280
awareness on the need for more cloud

73
00:03:03,280 --> 00:03:06,239
native security and open source security

74
00:03:06,239 --> 00:03:08,319
the idea for this project is not to

75
00:03:08,319 --> 00:03:10,879
generate fund as we call in information

76
00:03:10,879 --> 00:03:13,599
security which means fear uncertainty

77
00:03:13,599 --> 00:03:16,319
and doubt around cloud native projects

78
00:03:16,319 --> 00:03:18,720
right so we we just want to raise the

79
00:03:18,720 --> 00:03:21,519
awareness and show uh that security is

80
00:03:21,519 --> 00:03:25,040
important for this project especially uh

81
00:03:25,040 --> 00:03:27,920
some of them have been uh used for many

82
00:03:27,920 --> 00:03:30,239
different organizations and we rely on

83
00:03:30,239 --> 00:03:33,680
them uh to run our systems so it's

84
00:03:33,680 --> 00:03:37,680
important to focus on security as well

85
00:03:38,879 --> 00:03:41,200
a shameless plug here before we start

86
00:03:41,200 --> 00:03:44,799
with the content i have created this

87
00:03:44,799 --> 00:03:47,440
github project which i call the almost

88
00:03:47,440 --> 00:03:50,159
awesome kubernetes security list

89
00:03:50,159 --> 00:03:52,640
it has a lot of content there around

90
00:03:52,640 --> 00:03:55,120
kubernetes and kubernetes security it

91
00:03:55,120 --> 00:03:56,319
has

92
00:03:56,319 --> 00:03:59,280
videos books and articles and everything

93
00:03:59,280 --> 00:04:00,400
you need to know

94
00:04:00,400 --> 00:04:03,120
i think to um to learn more about

95
00:04:03,120 --> 00:04:04,799
kubernetes and kubernetes security at

96
00:04:04,799 --> 00:04:07,200
least to get started um so i think

97
00:04:07,200 --> 00:04:09,040
there's there's a lot of contributors

98
00:04:09,040 --> 00:04:12,000
there already people from the cncf have

99
00:04:12,000 --> 00:04:15,120
participated and submitted new links and

100
00:04:15,120 --> 00:04:17,918
new information so this has been going

101
00:04:17,918 --> 00:04:18,720
for

102
00:04:18,720 --> 00:04:20,880
almost a year now and it's it's really

103
00:04:20,880 --> 00:04:22,479
incredible to to

104
00:04:22,479 --> 00:04:24,400
have contributed to the community in

105
00:04:24,400 --> 00:04:26,960
that way so feel free to

106
00:04:26,960 --> 00:04:30,240
uh start this project and fork it and

107
00:04:30,240 --> 00:04:33,840
submit new prs if you want i'm always

108
00:04:33,840 --> 00:04:36,960
available and looking for new content to

109
00:04:36,960 --> 00:04:39,359
add there

110
00:04:41,280 --> 00:04:42,560
okay so

111
00:04:42,560 --> 00:04:45,680
how how how this project started how the

112
00:04:45,680 --> 00:04:48,160
idea of this project started right

113
00:04:48,160 --> 00:04:49,280
um

114
00:04:49,280 --> 00:04:50,400
i think

115
00:04:50,400 --> 00:04:53,280
uh in the beginning of this year i was

116
00:04:53,280 --> 00:04:56,639
uh helping the cncf

117
00:04:56,639 --> 00:04:59,120
uh security tag team to update the list

118
00:04:59,120 --> 00:05:02,880
of security audits that was done

119
00:05:02,880 --> 00:05:07,919
on on different cncf projects and and so

120
00:05:07,919 --> 00:05:09,360
i saw that

121
00:05:09,360 --> 00:05:12,080
like pretty much all of those security

122
00:05:12,080 --> 00:05:13,520
audits were

123
00:05:13,520 --> 00:05:16,320
pdf reports anyway some of them were

124
00:05:16,320 --> 00:05:17,520
kind of

125
00:05:17,520 --> 00:05:20,240
hidden inside of the repositories of

126
00:05:20,240 --> 00:05:22,400
those projects right so it was kind of

127
00:05:22,400 --> 00:05:24,960
hard to find and and you had to dig

128
00:05:24,960 --> 00:05:27,440
through them and and especially since

129
00:05:27,440 --> 00:05:29,759
they were on pdf there was no place that

130
00:05:29,759 --> 00:05:31,600
we could check the status of those

131
00:05:31,600 --> 00:05:34,400
vulnerabilities if if there were any cv

132
00:05:34,400 --> 00:05:37,600
reported uh because of of that

133
00:05:37,600 --> 00:05:40,000
vulnerability that was detected right so

134
00:05:40,000 --> 00:05:43,759
those security audits are usually um

135
00:05:43,759 --> 00:05:47,680
organized or directed by the cncf and

136
00:05:47,680 --> 00:05:49,680
and they hire third-party consulting

137
00:05:49,680 --> 00:05:52,160
firms to test the security of different

138
00:05:52,160 --> 00:05:54,800
cncf projects right as we can see here

139
00:05:54,800 --> 00:05:56,960
from the slides uh there are many

140
00:05:56,960 --> 00:05:58,720
different projects have gone through

141
00:05:58,720 --> 00:06:01,120
security audits right uh

142
00:06:01,120 --> 00:06:04,840
kubernetes helm grpc at cd are some

143
00:06:04,840 --> 00:06:08,080
examples and and you can see

144
00:06:08,080 --> 00:06:10,080
as well the audit vendors or their

145
00:06:10,080 --> 00:06:11,919
consulting firms that have tested these

146
00:06:11,919 --> 00:06:13,120
projects

147
00:06:13,120 --> 00:06:13,919
so

148
00:06:13,919 --> 00:06:16,800
basically the first thing that i did was

149
00:06:16,800 --> 00:06:18,400
okay um

150
00:06:18,400 --> 00:06:20,720
i need to concentrate all these reports

151
00:06:20,720 --> 00:06:23,280
in a single location so that's easy to

152
00:06:23,280 --> 00:06:26,000
find and and i can uh consult them and

153
00:06:26,000 --> 00:06:28,639
query them in a in an easier way than

154
00:06:28,639 --> 00:06:31,120
than just go going through each project

155
00:06:31,120 --> 00:06:32,080
there

156
00:06:32,080 --> 00:06:35,440
so what i did was i created a repository

157
00:06:35,440 --> 00:06:37,840
on my git home called cncf security

158
00:06:37,840 --> 00:06:38,800
audits

159
00:06:38,800 --> 00:06:40,400
and each

160
00:06:40,400 --> 00:06:43,199
uh inside it folder that has the project

161
00:06:43,199 --> 00:06:46,080
name there is the pdf with the

162
00:06:46,080 --> 00:06:48,000
with the report and the security results

163
00:06:48,000 --> 00:06:50,479
of each security audit right

164
00:06:50,479 --> 00:06:52,639
okay that's that's good but

165
00:06:52,639 --> 00:06:54,400
how how do we go

166
00:06:54,400 --> 00:06:56,240
through each

167
00:06:56,240 --> 00:06:58,880
pdf report and and kind of

168
00:06:58,880 --> 00:07:01,360
uh analyze all those vulnerabilities

169
00:07:01,360 --> 00:07:03,840
right

170
00:07:03,919 --> 00:07:05,440
so

171
00:07:05,440 --> 00:07:07,360
as i said the security audits are

172
00:07:07,360 --> 00:07:08,960
independent done by third-party

173
00:07:08,960 --> 00:07:10,720
consulting companies they're usually

174
00:07:10,720 --> 00:07:12,560
required for projects that move to

175
00:07:12,560 --> 00:07:14,479
sandbox to incubating

176
00:07:14,479 --> 00:07:17,599
and they started in 2018 at least that's

177
00:07:17,599 --> 00:07:18,800
the the

178
00:07:18,800 --> 00:07:21,680
the first ones that we have uh uh

179
00:07:21,680 --> 00:07:24,400
details from and they're usually one

180
00:07:24,400 --> 00:07:26,960
time only with some exceptions right and

181
00:07:26,960 --> 00:07:30,720
unless the project is um very well known

182
00:07:30,720 --> 00:07:33,280
and very well used by the community such

183
00:07:33,280 --> 00:07:36,160
as kubernetes it usually goes through

184
00:07:36,160 --> 00:07:39,120
another uh security audit such as the

185
00:07:39,120 --> 00:07:41,039
one that kubernetes is probably going

186
00:07:41,039 --> 00:07:44,560
through right now or there is it has a

187
00:07:44,560 --> 00:07:46,800
rfp open at the time that i'm recording

188
00:07:46,800 --> 00:07:48,800
this video

189
00:07:48,800 --> 00:07:51,280
yeah so as i said that the result is a

190
00:07:51,280 --> 00:07:54,720
pdf report with the findings right and

191
00:07:54,720 --> 00:07:55,840
in

192
00:07:55,840 --> 00:07:58,960
in security that's fine and that's

193
00:07:58,960 --> 00:08:01,039
that's usually the artifact that you're

194
00:08:01,039 --> 00:08:03,599
expecting from a paint testing report a

195
00:08:03,599 --> 00:08:05,759
pdf with all the finance

196
00:08:05,759 --> 00:08:09,039
but for um i think for developers and

197
00:08:09,039 --> 00:08:12,560
and devops organizations uh we are way

198
00:08:12,560 --> 00:08:16,800
past that right we need a way to

199
00:08:16,800 --> 00:08:18,400
a easy way to list out those

200
00:08:18,400 --> 00:08:21,280
vulnerabilities and and and also

201
00:08:21,280 --> 00:08:23,440
check their status and see if the

202
00:08:23,440 --> 00:08:26,720
problem is it was fix it or not and and

203
00:08:26,720 --> 00:08:28,720
who's addressing that right

204
00:08:28,720 --> 00:08:30,400
so

205
00:08:30,400 --> 00:08:34,240
um so like uh as a suggestion here

206
00:08:34,240 --> 00:08:35,919
i'll probably give more recommendations

207
00:08:35,919 --> 00:08:37,839
at the end but as a suggestion here

208
00:08:37,839 --> 00:08:40,399
maybe uh having those

209
00:08:40,399 --> 00:08:41,279
uh

210
00:08:41,279 --> 00:08:44,640
finalized reports added as github issues

211
00:08:44,640 --> 00:08:46,959
or something like that would make easier

212
00:08:46,959 --> 00:08:47,920
for

213
00:08:47,920 --> 00:08:49,920
everyone and would give more visibility

214
00:08:49,920 --> 00:08:53,279
into those security audits

215
00:08:53,600 --> 00:08:56,000
okay so

216
00:08:56,000 --> 00:08:58,640
so how did i do uh how did i started

217
00:08:58,640 --> 00:09:01,200
this this kind of this project here the

218
00:09:01,200 --> 00:09:03,839
methodology that i used was download all

219
00:09:03,839 --> 00:09:05,839
those pdfs as i said i created this

220
00:09:05,839 --> 00:09:08,640
github repository to help me with that

221
00:09:08,640 --> 00:09:11,360
and and it's available for everyone

222
00:09:11,360 --> 00:09:14,240
um i parsed all the pdf reports and i

223
00:09:14,240 --> 00:09:16,240
collected all the relevant data that i

224
00:09:16,240 --> 00:09:17,200
needed

225
00:09:17,200 --> 00:09:20,480
um i basically aggregated everything

226
00:09:20,480 --> 00:09:22,800
into a single location

227
00:09:22,800 --> 00:09:26,160
of course i used a excel file for that

228
00:09:26,160 --> 00:09:28,640
because it was easier to

229
00:09:28,640 --> 00:09:30,800
see and and compare the issues and

230
00:09:30,800 --> 00:09:32,720
aggregate results

231
00:09:32,720 --> 00:09:35,120
basically in the beginning i analyzed

232
00:09:35,120 --> 00:09:36,880
the data from all those reports and

233
00:09:36,880 --> 00:09:39,279
understanding the results and did some

234
00:09:39,279 --> 00:09:42,560
measurements on okay what is what what

235
00:09:42,560 --> 00:09:43,959
which project has the most

236
00:09:43,959 --> 00:09:45,680
vulnerabilities what are the most

237
00:09:45,680 --> 00:09:47,440
critical vulnerabilities and all that

238
00:09:47,440 --> 00:09:48,480
stuff

239
00:09:48,480 --> 00:09:50,320
but then i decided okay maybe i could do

240
00:09:50,320 --> 00:09:54,000
more and i also assessed the third-party

241
00:09:54,000 --> 00:09:57,120
risk of those uh projects analyzing

242
00:09:57,120 --> 00:10:00,480
their libraries and dependencies with uh

243
00:10:00,480 --> 00:10:01,279
uh

244
00:10:01,279 --> 00:10:05,839
open source security tool called sneak

245
00:10:06,800 --> 00:10:08,880
one thing to note here is that there

246
00:10:08,880 --> 00:10:10,959
were some projects some security audits

247
00:10:10,959 --> 00:10:12,480
that were done

248
00:10:12,480 --> 00:10:15,760
that were specifically about fuzzing

249
00:10:15,760 --> 00:10:17,440
and and so

250
00:10:17,440 --> 00:10:20,160
the the the vulnerabilities reported

251
00:10:20,160 --> 00:10:22,800
were very specific to fuzzing and buffer

252
00:10:22,800 --> 00:10:24,720
overflows and stuff like that

253
00:10:24,720 --> 00:10:27,519
so for this uh this version of the

254
00:10:27,519 --> 00:10:30,079
project i decided to to laugh out those

255
00:10:30,079 --> 00:10:32,000
vulnerabilities otherwise you would kind

256
00:10:32,000 --> 00:10:32,880
of

257
00:10:32,880 --> 00:10:35,440
i think would mask the the data and the

258
00:10:35,440 --> 00:10:36,959
comparison there because not all

259
00:10:36,959 --> 00:10:41,599
projects have had uh fuzzing testing

260
00:10:42,560 --> 00:10:45,120
okay the analysis i'm gonna show some

261
00:10:45,120 --> 00:10:46,880
graphics here in a second right

262
00:10:46,880 --> 00:10:49,519
basically comparing the project numbers

263
00:10:49,519 --> 00:10:51,120
uh the project with the number of

264
00:10:51,120 --> 00:10:53,040
vulnerabilities the vulnerability

265
00:10:53,040 --> 00:10:56,720
categories and types as as reported by

266
00:10:56,720 --> 00:10:58,959
the consonti uh

267
00:10:58,959 --> 00:11:00,800
uh firms

268
00:11:00,800 --> 00:11:02,959
and also comparing vulnerabilities and

269
00:11:02,959 --> 00:11:06,800
severity so that we can see uh which uh

270
00:11:06,800 --> 00:11:09,040
the number of vulnerabilities that we

271
00:11:09,040 --> 00:11:12,160
have as low medium high and critical

272
00:11:12,160 --> 00:11:15,600
right and then i'll go into the um the

273
00:11:15,600 --> 00:11:17,360
open source security or the third party

274
00:11:17,360 --> 00:11:20,800
dependency and as we uh like to call

275
00:11:20,800 --> 00:11:23,600
software composition analysis right

276
00:11:23,600 --> 00:11:25,839
okay

277
00:11:26,480 --> 00:11:29,760
so moving on um

278
00:11:29,760 --> 00:11:33,680
this uh this presentation uh has some of

279
00:11:33,680 --> 00:11:36,800
the main results and graphics uh

280
00:11:36,800 --> 00:11:40,160
at the time of of the the recording of

281
00:11:40,160 --> 00:11:43,519
this we're working on finalizing the

282
00:11:43,519 --> 00:11:46,240
final the pdf report that we're probably

283
00:11:46,240 --> 00:11:48,959
going to publish together with this talk

284
00:11:48,959 --> 00:11:51,360
when when it's published when it's uh

285
00:11:51,360 --> 00:11:53,360
released during during the cloud native

286
00:11:53,360 --> 00:11:56,240
security con so you're probably gonna

287
00:11:56,240 --> 00:11:59,360
receive a link for the the full details

288
00:11:59,360 --> 00:12:02,399
for the the complete pdf report with my

289
00:12:02,399 --> 00:12:03,279
uh

290
00:12:03,279 --> 00:12:05,440
with all the details that i that i found

291
00:12:05,440 --> 00:12:09,560
and that i wrote about it

292
00:12:10,720 --> 00:12:12,399
okay

293
00:12:12,399 --> 00:12:14,880
so the first thing that we analyzed here

294
00:12:14,880 --> 00:12:16,480
was which project had more

295
00:12:16,480 --> 00:12:18,959
vulnerabilities reported to it right

296
00:12:18,959 --> 00:12:21,839
and it comes as no surprise that

297
00:12:21,839 --> 00:12:25,760
kubernetes came out on kind of the

298
00:12:25,760 --> 00:12:27,920
top with the most vulnerabilities

299
00:12:27,920 --> 00:12:29,279
reported to it

300
00:12:29,279 --> 00:12:32,079
it is the largest of those projects and

301
00:12:32,079 --> 00:12:34,880
the most adopted of them and

302
00:12:34,880 --> 00:12:38,320
of course it has more lines of code

303
00:12:38,320 --> 00:12:41,120
right so and thus more chances of

304
00:12:41,120 --> 00:12:43,279
vulnerabilities being found right there

305
00:12:43,279 --> 00:12:45,760
are some studies that uh

306
00:12:45,760 --> 00:12:48,800
have uh reported some researchers

307
00:12:48,800 --> 00:12:50,639
mentioning that

308
00:12:50,639 --> 00:12:53,200
there is at least one vulnerability per

309
00:12:53,200 --> 00:12:56,000
thousand lines of code in in

310
00:12:56,000 --> 00:12:58,880
any kind of of software right so this is

311
00:12:58,880 --> 00:13:00,880
of course this is an average but at

312
00:13:00,880 --> 00:13:03,120
least we know that the more lines of

313
00:13:03,120 --> 00:13:05,440
code the more chances you have of

314
00:13:05,440 --> 00:13:07,279
finding vulnerabilities so that's the

315
00:13:07,279 --> 00:13:08,399
given

316
00:13:08,399 --> 00:13:09,279
um

317
00:13:09,279 --> 00:13:11,440
in second place

318
00:13:11,440 --> 00:13:14,000
there is at cd which is also part of

319
00:13:14,000 --> 00:13:17,040
kubernetes by default and and helm which

320
00:13:17,040 --> 00:13:19,440
is the package manager for kubernetes

321
00:13:19,440 --> 00:13:21,839
projects as well in third place

322
00:13:21,839 --> 00:13:23,519
so that's that's quite interesting but

323
00:13:23,519 --> 00:13:25,839
you can see uh uh really see the

324
00:13:25,839 --> 00:13:27,600
difference between kubernetes and that

325
00:13:27,600 --> 00:13:30,959
cd here uh in second place and and the

326
00:13:30,959 --> 00:13:33,360
other projects as well so

327
00:13:33,360 --> 00:13:34,959
that's something that we need to be

328
00:13:34,959 --> 00:13:37,600
aware of uh

329
00:13:37,600 --> 00:13:39,760
most of these vulnerabilities were fixed

330
00:13:39,760 --> 00:13:43,279
or their risks were accepted so uh of

331
00:13:43,279 --> 00:13:45,760
course make sure that you're using uh

332
00:13:45,760 --> 00:13:48,480
the latest version available to you for

333
00:13:48,480 --> 00:13:51,920
your kubernetes projects

334
00:13:52,000 --> 00:13:54,639
um here is just a drill down of those

335
00:13:54,639 --> 00:13:56,480
numbers right uh how many

336
00:13:56,480 --> 00:13:58,240
vulnerabilities were found by each of

337
00:13:58,240 --> 00:14:02,560
them as we can see kubernetes has uh uh

338
00:14:02,560 --> 00:14:05,199
more than double from the second place

339
00:14:05,199 --> 00:14:08,720
from at cd and and so on i just showed a

340
00:14:08,720 --> 00:14:11,600
few of them here

341
00:14:12,240 --> 00:14:14,959
okay so before i go into the next next

342
00:14:14,959 --> 00:14:18,399
graphic uh we need to talk about the uh

343
00:14:18,399 --> 00:14:21,040
classes of vulnerabilities so

344
00:14:21,040 --> 00:14:24,160
uh one of the vendors i think was

345
00:14:24,160 --> 00:14:26,079
um trio of pets

346
00:14:26,079 --> 00:14:28,560
they in their reports they classify

347
00:14:28,560 --> 00:14:30,560
their vulnerabilities according to these

348
00:14:30,560 --> 00:14:33,120
classes and we have access control

349
00:14:33,120 --> 00:14:35,440
auditing login authentication and all

350
00:14:35,440 --> 00:14:38,560
that stuff and they uh they give you a

351
00:14:38,560 --> 00:14:42,160
description of each uh what each class

352
00:14:42,160 --> 00:14:45,680
means right um

353
00:14:45,680 --> 00:14:47,440
some of them uh

354
00:14:47,440 --> 00:14:49,440
some of the other consulting firms

355
00:14:49,440 --> 00:14:52,079
didn't adopt this this kind of approach

356
00:14:52,079 --> 00:14:54,959
and so we we found it interesting and we

357
00:14:54,959 --> 00:14:57,199
used this kind of classification to the

358
00:14:57,199 --> 00:14:58,959
other vulnerabilities as well according

359
00:14:58,959 --> 00:15:00,000
to the description of the

360
00:15:00,000 --> 00:15:02,720
vulnerabilities we assign a specific

361
00:15:02,720 --> 00:15:05,199
class or category to that vulnerability

362
00:15:05,199 --> 00:15:06,600
so that we could uh

363
00:15:06,600 --> 00:15:08,240
[Music]

364
00:15:08,240 --> 00:15:10,399
compound all the data and and create

365
00:15:10,399 --> 00:15:15,440
some some uh evaluations there

366
00:15:16,959 --> 00:15:18,800
so basically

367
00:15:18,800 --> 00:15:21,279
the the vulnerability class or category

368
00:15:21,279 --> 00:15:22,639
that has the most number of

369
00:15:22,639 --> 00:15:24,880
vulnerabilities is

370
00:15:24,880 --> 00:15:26,480
data validation

371
00:15:26,480 --> 00:15:28,639
right and um

372
00:15:28,639 --> 00:15:30,720
as we can see here it's

373
00:15:30,720 --> 00:15:32,959
it's way over the second place as well

374
00:15:32,959 --> 00:15:34,800
which is configuration and data

375
00:15:34,800 --> 00:15:37,680
validation relates to either input

376
00:15:37,680 --> 00:15:40,800
validation or or lack of verification

377
00:15:40,800 --> 00:15:44,560
and uh of data it could cause also like

378
00:15:44,560 --> 00:15:47,040
things like buffer overflows and heap

379
00:15:47,040 --> 00:15:49,440
overflows and all that stuff so

380
00:15:49,440 --> 00:15:52,639
um it's it's really interesting to find

381
00:15:52,639 --> 00:15:55,600
that a lot of these projects have data

382
00:15:55,600 --> 00:15:57,279
validation issues right which is

383
00:15:57,279 --> 00:16:00,880
something that can be easily uh solved

384
00:16:00,880 --> 00:16:03,680
by adding proper validation in your code

385
00:16:03,680 --> 00:16:07,360
and doing uh proper uh exceptions and

386
00:16:07,360 --> 00:16:09,680
and try catches and and all that stuff

387
00:16:09,680 --> 00:16:12,000
right

388
00:16:14,480 --> 00:16:16,639
okay

389
00:16:16,639 --> 00:16:18,959
the next one here um

390
00:16:18,959 --> 00:16:21,279
is the severity right

391
00:16:21,279 --> 00:16:24,240
so the vulnerabilities per severity we

392
00:16:24,240 --> 00:16:27,600
found that uh

393
00:16:29,519 --> 00:16:31,440
that some of them

394
00:16:31,440 --> 00:16:35,120
actually most of the the reports the

395
00:16:35,120 --> 00:16:38,000
projects only had like low and medium

396
00:16:38,000 --> 00:16:40,480
vulnerabilities which is good right

397
00:16:40,480 --> 00:16:43,519
which uh i think it's reassuring for us

398
00:16:43,519 --> 00:16:45,759
using those projects that they don't

399
00:16:45,759 --> 00:16:48,160
have like few only very few of them had

400
00:16:48,160 --> 00:16:50,320
some critical vulnerabilities down there

401
00:16:50,320 --> 00:16:51,440
at the bottom

402
00:16:51,440 --> 00:16:52,720
um

403
00:16:52,720 --> 00:16:55,759
i think it's it's interesting to uh to

404
00:16:55,759 --> 00:17:00,079
note here that despite the the great uh

405
00:17:00,079 --> 00:17:03,040
quality of the consulting firms that

406
00:17:03,040 --> 00:17:06,000
have tested these projects even though

407
00:17:06,000 --> 00:17:08,240
they're they're kind of well known in

408
00:17:08,240 --> 00:17:11,599
their field they couldn't find a lot of

409
00:17:11,599 --> 00:17:14,160
critical or high vulnerabilities in all

410
00:17:14,160 --> 00:17:16,400
these projects right so that's that's

411
00:17:16,400 --> 00:17:18,319
interesting and something to note right

412
00:17:18,319 --> 00:17:20,959
so so i think that's that's important to

413
00:17:20,959 --> 00:17:24,079
to highlight here

414
00:17:24,160 --> 00:17:24,959
okay

415
00:17:24,959 --> 00:17:27,520
there is more uh reports and analysis

416
00:17:27,520 --> 00:17:29,360
that i've done i i couldn't show

417
00:17:29,360 --> 00:17:32,480
everything here in a 25-30 minute talk

418
00:17:32,480 --> 00:17:33,520
so

419
00:17:33,520 --> 00:17:35,679
in the interest of time please take a

420
00:17:35,679 --> 00:17:37,600
look at the the

421
00:17:37,600 --> 00:17:39,919
the report for more more details and

422
00:17:39,919 --> 00:17:42,400
more uh analysis

423
00:17:42,400 --> 00:17:43,200
so

424
00:17:43,200 --> 00:17:45,600
the last thing that we did was the open

425
00:17:45,600 --> 00:17:48,240
source security and independence is here

426
00:17:48,240 --> 00:17:50,480
right when when talking about cloud

427
00:17:50,480 --> 00:17:53,039
native security we need to be aware that

428
00:17:53,039 --> 00:17:55,440
most of these projects rely on libraries

429
00:17:55,440 --> 00:17:57,919
and dependencies there are also open

430
00:17:57,919 --> 00:18:00,720
source software right and these

431
00:18:00,720 --> 00:18:02,640
libraries are usually incorporated

432
00:18:02,640 --> 00:18:05,039
during the development life cycle and

433
00:18:05,039 --> 00:18:07,440
rarely get updated or checked against

434
00:18:07,440 --> 00:18:09,679
known vulnerabilities

435
00:18:09,679 --> 00:18:11,120
so in this

436
00:18:11,120 --> 00:18:14,000
section here we analyze the dependencies

437
00:18:14,000 --> 00:18:16,880
of these projects and look for outdated

438
00:18:16,880 --> 00:18:19,200
and or vulnerable libraries and

439
00:18:19,200 --> 00:18:22,240
licensing risks that they might be using

440
00:18:22,240 --> 00:18:24,160
in their code

441
00:18:24,160 --> 00:18:27,280
for this analysis we use the

442
00:18:27,280 --> 00:18:29,760
micro cloud one open source security

443
00:18:29,760 --> 00:18:32,080
which is powered by snake

444
00:18:32,080 --> 00:18:32,960
um

445
00:18:32,960 --> 00:18:35,280
and as we can see here from the results

446
00:18:35,280 --> 00:18:38,320
of all i only tested the projects that

447
00:18:38,320 --> 00:18:41,039
had security audits done

448
00:18:41,039 --> 00:18:43,039
for them right so i didn't test all the

449
00:18:43,039 --> 00:18:45,440
cncf projects so that we can make some

450
00:18:45,440 --> 00:18:46,960
comparisons here

451
00:18:46,960 --> 00:18:50,720
so again uh kubernetes shows on pretty

452
00:18:50,720 --> 00:18:53,039
much on top if you look at the numbers

453
00:18:53,039 --> 00:18:55,039
there is the project with the most

454
00:18:55,039 --> 00:18:57,600
vulnerabilities uh in in its

455
00:18:57,600 --> 00:19:01,120
dependencies uh besides just notary

456
00:19:01,120 --> 00:19:03,440
that's on top here uh

457
00:19:03,440 --> 00:19:06,080
because it has a critical vulnerability

458
00:19:06,080 --> 00:19:08,000
as well right

459
00:19:08,000 --> 00:19:10,240
and so that comes as no surprise as we

460
00:19:10,240 --> 00:19:13,039
found on the on the previous analysis of

461
00:19:13,039 --> 00:19:14,960
the security audits as well

462
00:19:14,960 --> 00:19:16,000
um

463
00:19:16,000 --> 00:19:18,160
and and

464
00:19:18,160 --> 00:19:20,000
in the

465
00:19:20,000 --> 00:19:22,000
in the second and kind of third place

466
00:19:22,000 --> 00:19:23,600
there on the number of vulnerabilities

467
00:19:23,600 --> 00:19:25,440
the total number of vulnerabilities of

468
00:19:25,440 --> 00:19:28,880
their dependencies we have harbor

469
00:19:28,880 --> 00:19:31,520
and uh vtes

470
00:19:31,520 --> 00:19:33,760
so it's interesting to note that

471
00:19:33,760 --> 00:19:37,440
although these projects have access to

472
00:19:37,440 --> 00:19:39,840
uh some open source tools and i think

473
00:19:39,840 --> 00:19:42,960
they use uh on the cncf they are they

474
00:19:42,960 --> 00:19:45,919
have kind of their own scans for

475
00:19:45,919 --> 00:19:48,640
vulnerabilities using sneakers one

476
00:19:48,640 --> 00:19:52,400
there's there's a lot of issues here um

477
00:19:52,400 --> 00:19:55,039
i i i don't mean to say that all those

478
00:19:55,039 --> 00:19:56,720
vulnerabilities are valid and

479
00:19:56,720 --> 00:19:59,039
exploitable but there is some analysis

480
00:19:59,039 --> 00:20:01,520
that needs to be done and to see

481
00:20:01,520 --> 00:20:03,120
probably there are some issues here that

482
00:20:03,120 --> 00:20:05,280
need to be addressed and fixed and and

483
00:20:05,280 --> 00:20:07,840
some of them could be just updating the

484
00:20:07,840 --> 00:20:10,799
library to the latest version and and so

485
00:20:10,799 --> 00:20:13,039
some of these should be uh prioritized

486
00:20:13,039 --> 00:20:15,760
and fixed

487
00:20:17,200 --> 00:20:18,240
um

488
00:20:18,240 --> 00:20:21,520
here we can see the vulnerability risks

489
00:20:21,520 --> 00:20:24,720
increasing over time uh regarding the

490
00:20:24,720 --> 00:20:26,880
libraries and dependencies right as we

491
00:20:26,880 --> 00:20:30,640
can see as as time goes by and new

492
00:20:30,640 --> 00:20:33,760
vulnerabilities are found and and the uh

493
00:20:33,760 --> 00:20:37,360
libraries get uh outdated uh so more

494
00:20:37,360 --> 00:20:41,039
issues are are raised and and the

495
00:20:41,039 --> 00:20:43,840
kind of the the risk increases for these

496
00:20:43,840 --> 00:20:45,840
projects right so the quickly we address

497
00:20:45,840 --> 00:20:48,799
those issues the faster uh we can have

498
00:20:48,799 --> 00:20:51,440
it fixed and reduce the risks of this

499
00:20:51,440 --> 00:20:55,020
projects being compromised

500
00:20:55,020 --> 00:20:56,880
[Music]

501
00:20:56,880 --> 00:21:01,679
so to summarize everything i think i um

502
00:21:01,679 --> 00:21:02,880
for this

503
00:21:02,880 --> 00:21:05,520
for this project in this report uh we

504
00:21:05,520 --> 00:21:08,400
came up with some recommendations for

505
00:21:08,400 --> 00:21:12,080
the cncf and especially the security tag

506
00:21:12,080 --> 00:21:14,720
team uh which i'm also part of and so

507
00:21:14,720 --> 00:21:17,120
i'm going to recommend that to them as

508
00:21:17,120 --> 00:21:18,640
well but

509
00:21:18,640 --> 00:21:21,200
uh first thing i think would be

510
00:21:21,200 --> 00:21:23,840
to improve this overall quality and

511
00:21:23,840 --> 00:21:25,520
security of those projects is

512
00:21:25,520 --> 00:21:28,159
establishing more periodical assessments

513
00:21:28,159 --> 00:21:29,039
um

514
00:21:29,039 --> 00:21:31,520
at least uh once a year or something

515
00:21:31,520 --> 00:21:33,919
like that if that's available and if of

516
00:21:33,919 --> 00:21:36,159
course if there is budget for that

517
00:21:36,159 --> 00:21:39,120
um implement a cncf buggy bounty program

518
00:21:39,120 --> 00:21:41,679
so when doing this analysis i found out

519
00:21:41,679 --> 00:21:45,280
that only one project from the cncf has

520
00:21:45,280 --> 00:21:47,440
a public bug bounty program which is

521
00:21:47,440 --> 00:21:50,400
kubernetes besides that all the others

522
00:21:50,400 --> 00:21:53,039
they only have like a uh what we call a

523
00:21:53,039 --> 00:21:55,840
vdp or vulnerability disclosure policy

524
00:21:55,840 --> 00:21:56,799
and so

525
00:21:56,799 --> 00:21:59,120
maybe that would increase the number of

526
00:21:59,120 --> 00:22:00,720
reports and vulnerabilities that get

527
00:22:00,720 --> 00:22:02,799
reported to these projects

528
00:22:02,799 --> 00:22:06,080
um other thing that i noticed um when we

529
00:22:06,080 --> 00:22:08,799
were trying to do the rfps for the new

530
00:22:08,799 --> 00:22:11,120
kubernetes security audit is that we had

531
00:22:11,120 --> 00:22:14,480
a hard time uh finding uh consulting

532
00:22:14,480 --> 00:22:16,880
companies and vendors to uh that were

533
00:22:16,880 --> 00:22:19,039
interested in doing that so maybe

534
00:22:19,039 --> 00:22:22,559
promoting that those rfps even more and

535
00:22:22,559 --> 00:22:25,280
and have that available and kind of

536
00:22:25,280 --> 00:22:27,039
publicizing it for different

537
00:22:27,039 --> 00:22:28,799
organizations and maybe in different

538
00:22:28,799 --> 00:22:32,799
countries would get more uh rfps for for

539
00:22:32,799 --> 00:22:35,039
those audits

540
00:22:35,039 --> 00:22:36,640
another thing is that

541
00:22:36,640 --> 00:22:39,280
um it's it's hard to

542
00:22:39,280 --> 00:22:40,400
um

543
00:22:40,400 --> 00:22:43,120
to see if this those issues reported on

544
00:22:43,120 --> 00:22:45,600
those audits if they have been fixed or

545
00:22:45,600 --> 00:22:48,159
if they have any kind of cve assigned to

546
00:22:48,159 --> 00:22:50,799
it right and and so you would have to go

547
00:22:50,799 --> 00:22:52,640
through the code and analyze all the

548
00:22:52,640 --> 00:22:54,320
commits and everything and find these

549
00:22:54,320 --> 00:22:56,240
issues if there is something related to

550
00:22:56,240 --> 00:22:58,400
the vulnerabilities that were fixed so

551
00:22:58,400 --> 00:23:00,799
making easier and more visible to see

552
00:23:00,799 --> 00:23:02,960
these reports and status of each

553
00:23:02,960 --> 00:23:04,799
vulnerability i think that's something

554
00:23:04,799 --> 00:23:06,880
that would be interesting that that we

555
00:23:06,880 --> 00:23:09,440
can improve upon

556
00:23:09,440 --> 00:23:11,679
um another thing is prioritize issues

557
00:23:11,679 --> 00:23:13,120
related to critical third-party

558
00:23:13,120 --> 00:23:15,120
components right and we saw there is at

559
00:23:15,120 --> 00:23:16,880
least one project that has a critical

560
00:23:16,880 --> 00:23:18,400
vulnerability there on on the

561
00:23:18,400 --> 00:23:20,640
dependencies and there is also a bunch

562
00:23:20,640 --> 00:23:22,080
of projects with with high

563
00:23:22,080 --> 00:23:24,640
vulnerabilities as well so maybe trying

564
00:23:24,640 --> 00:23:27,520
to prioritize that and talk to the

565
00:23:27,520 --> 00:23:29,600
project maintainers to see if they could

566
00:23:29,600 --> 00:23:31,840
fix those issues of course without

567
00:23:31,840 --> 00:23:34,159
causing any problems on the on the

568
00:23:34,159 --> 00:23:35,760
projects and the applications itself

569
00:23:35,760 --> 00:23:38,799
because we know that sometimes updating

570
00:23:38,799 --> 00:23:40,720
libraries can be tricky and might break

571
00:23:40,720 --> 00:23:42,559
your application so

572
00:23:42,559 --> 00:23:46,080
we need to be careful there as well

573
00:23:46,320 --> 00:23:47,360
okay

574
00:23:47,360 --> 00:23:48,159
so

575
00:23:48,159 --> 00:23:50,559
this as i said this project is the i

576
00:23:50,559 --> 00:23:52,720
think would be uh i can call it the

577
00:23:52,720 --> 00:23:55,200
first edition and i'm planning to uh do

578
00:23:55,200 --> 00:23:58,400
a second edition next year um but the

579
00:23:58,400 --> 00:24:00,720
goals uh and next steps here i would say

580
00:24:00,720 --> 00:24:02,840
that i can provide the data back to the

581
00:24:02,840 --> 00:24:06,080
community and share that with the cncf

582
00:24:06,080 --> 00:24:08,799
security tag team uh basically all the

583
00:24:08,799 --> 00:24:11,120
data that i i aggregated from the

584
00:24:11,120 --> 00:24:12,960
different security audits

585
00:24:12,960 --> 00:24:15,760
and as i said i'll try to run this uh

586
00:24:15,760 --> 00:24:17,679
once every year and compare the results

587
00:24:17,679 --> 00:24:19,760
with the previous version as well

588
00:24:19,760 --> 00:24:20,640
um

589
00:24:20,640 --> 00:24:23,360
also adding some static analysis and

590
00:24:23,360 --> 00:24:25,039
reviews for all the projects right

591
00:24:25,039 --> 00:24:28,159
analyzing the the code of those projects

592
00:24:28,159 --> 00:24:30,159
for one of security vulnerabilities as

593
00:24:30,159 --> 00:24:31,039
well

594
00:24:31,039 --> 00:24:31,840
and

595
00:24:31,840 --> 00:24:34,240
check and see if there were any issues

596
00:24:34,240 --> 00:24:37,760
here that were unreported or unfixed and

597
00:24:37,760 --> 00:24:40,559
report those to the proper projects and

598
00:24:40,559 --> 00:24:43,200
and hopefully get them fixed

599
00:24:43,200 --> 00:24:44,159
so

600
00:24:44,159 --> 00:24:46,640
i think that concludes my presentation i

601
00:24:46,640 --> 00:24:49,520
hope you enjoyed this uh talk

602
00:24:49,520 --> 00:24:53,200
and i'll be available for questions uh

603
00:24:53,200 --> 00:24:54,799
either on

604
00:24:54,799 --> 00:24:57,679
the q a section or on slack

605
00:24:57,679 --> 00:25:00,919
thank you