WEBVTT

1
00:00:14.439 --> 00:00:18.679
Hey, what's going on? Y'all? Welcome to another episode of Adventures in

2
00:00:19.039 --> 00:00:25.280
dev Ops and joining me in the
studio today my new routine co host,

3
00:00:25.640 --> 00:00:28.839
Warren Parade. What's going on?
Warren? Hey? Thanks? Well,

4
00:00:28.879 --> 00:00:31.320
you know, at some point that's
going to get old and I'll be the

5
00:00:31.359 --> 00:00:35.039
old co host and we'll have to
come up with a new tagline for me.

6
00:00:35.799 --> 00:00:38.840
I know, I was just thinking
that and I was like, damn,

7
00:00:38.840 --> 00:00:41.039
I didn't come up with anything new
to say, so I had to

8
00:00:41.079 --> 00:00:45.200
go with the old, stale one. I'll work on. I'll work on

9
00:00:45.240 --> 00:00:49.479
that before next week's episode. I
promise you didn't have enough homework to do.

10
00:00:49.719 --> 00:00:53.159
You've got one more thing now,
right, right, It's good to

11
00:00:53.240 --> 00:00:59.520
keep busy. But also joining us
today we have the co founder and CTO

12
00:01:00.159 --> 00:01:06.359
A Hero, Jonathan Elder. Welcome
Jonathan, thanks for having me. Hey,

13
00:01:06.400 --> 00:01:08.760
I'm excited to have you here,
and I'm looking forward to this episode

14
00:01:10.239 --> 00:01:15.280
because I've got two security experts here
in the studio with me, and I

15
00:01:17.040 --> 00:01:23.760
think security is one of those really
really, it's a really odd specialty to

16
00:01:23.920 --> 00:01:32.040
have because it's one that I feel
like from a business perspective, like businesses,

17
00:01:32.239 --> 00:01:37.319
let's just be honest. Here,
businesses tend to prioritize customer facing features

18
00:01:38.280 --> 00:01:46.480
and cheer about those much more than
they do security work. But the end

19
00:01:46.560 --> 00:01:52.040
customers themselves, I don't think they
ask for Like the end users of my

20
00:01:52.159 --> 00:01:57.079
applications don't ask for security related stuff. They just assume that I'm doing it.

21
00:01:57.760 --> 00:02:00.719
And so from a developer's perspective,
it's really hard to feel like security

22
00:02:00.760 --> 00:02:07.560
gets the prioritization that it needs because
everyone, I think everyone just assumes that

23
00:02:07.639 --> 00:02:13.719
you're doing that, because that's what
you do as a good steward of your

24
00:02:13.800 --> 00:02:20.840
code. And so I'm interested to
talk about that and how y'all view that

25
00:02:21.159 --> 00:02:28.439
and get some actionable tips that help
us all bring security up and like make

26
00:02:28.439 --> 00:02:32.280
it the first class citizen that it
should be. So, with that rambling

27
00:02:32.400 --> 00:02:38.319
intro out of the way, Jonathan, how did you get to this point

28
00:02:38.360 --> 00:02:44.039
where you're the co founder and CTO
of a bureau? That's a long road,

29
00:02:47.120 --> 00:02:53.639
Like professionally it's been twenty years starting
in the idea in Israel, but

30
00:02:54.120 --> 00:02:59.400
even before that, like there are
many developers who are you know, tinkers

31
00:03:00.240 --> 00:03:05.840
to like pick apart things, figure
out how it works, trying to reverse

32
00:03:05.879 --> 00:03:14.520
engineer stuff, whether it's you know, toasters or applications or back in the

33
00:03:14.599 --> 00:03:16.919
day like I don't know, Prince
of Persia or whatever, trying to figure

34
00:03:16.919 --> 00:03:22.280
out how stuff works. So I
think this was the start for me.

35
00:03:23.360 --> 00:03:30.199
I've been working on many startups since
then, quite a few, and it

36
00:03:30.199 --> 00:03:34.439
took me twenty years to or maybe
twenty minus five years since we started a

37
00:03:34.560 --> 00:03:40.639
bureau to start as a founder with
the down plotting my partner who's the CEO.

38
00:03:42.639 --> 00:03:46.759
After we work together on a totally
different thing, which is also security,

39
00:03:47.520 --> 00:03:53.520
but in a different field altogether,
because security is really really broad,

40
00:03:53.800 --> 00:04:00.680
you know. Yeah, for sure, I think it's one of those that

41
00:04:00.560 --> 00:04:09.759
it's easy to to get specialized in
a specialized specialty. When you talk about

42
00:04:09.800 --> 00:04:17.639
security. Yeah, there's there's a
lot of niche like niches in in security

43
00:04:17.879 --> 00:04:24.079
now now people are saying cybers like. There are a lot of terms.

44
00:04:24.959 --> 00:04:29.839
There are people who are you know, working on ed R, people who

45
00:04:29.839 --> 00:04:34.279
are working like in pentests, people
who are working on AppSec for thirty years.

46
00:04:34.319 --> 00:04:40.600
People. There are various fields that
are everything is related, but there

47
00:04:40.600 --> 00:04:48.160
are many specialties in the industry.
So there are communalities like the cat and

48
00:04:48.199 --> 00:04:56.079
mouse game with like good people versus
bad people. It happens a lot,

49
00:04:56.279 --> 00:05:00.759
and it's it's like it takes different
shapes in the net work security domain where

50
00:05:01.160 --> 00:05:05.800
it done. And myself we worked
back in the day in Microsoft and UH

51
00:05:06.000 --> 00:05:11.879
and in in other places, but
also in apsec, and also in in

52
00:05:12.079 --> 00:05:20.680
IoT and in very like diverse like
sub cyber terms right on. And so

53
00:05:21.879 --> 00:05:31.319
with a hero, you're working to
to provide visibility and and actionable context to

54
00:05:31.839 --> 00:05:35.959
the consumers of your platform. What
does that what does that actually mean?

55
00:05:36.000 --> 00:05:41.759
What kind of things do you help
help someone do or accomplish? Uh,

56
00:05:42.439 --> 00:05:47.279
there's a there's an evolution in AppSec, in application security. UH. It

57
00:05:47.439 --> 00:05:56.480
started with like very like technology related
products. There was at first there was

58
00:05:56.879 --> 00:06:01.000
you know, SASS finding vulnerabilities in
your code and it and it evolved,

59
00:06:02.040 --> 00:06:09.720
and there there came os S security, s c A finding vulnerabilities in open

60
00:06:09.759 --> 00:06:15.000
source, and then software supply chain
security that finding stuff like this is more

61
00:06:15.079 --> 00:06:21.199
develops proper right if the GitHub configuration
allows you to do such and such as

62
00:06:21.240 --> 00:06:27.920
an example and various other fields,
right, secret detection, et cetera.

63
00:06:28.040 --> 00:06:34.920
So it all evolved and now it's
like got a proper abbreviation, a SPM

64
00:06:35.040 --> 00:06:44.920
Application Security pasture management, which like
takes everything into one single like UI or

65
00:06:45.079 --> 00:06:49.519
one single source of truth where you
can see what goes on in your applications

66
00:06:49.839 --> 00:06:55.319
and it Uh, we've come a
long way uh for Gartner to coin that

67
00:06:55.439 --> 00:07:03.360
term and for companies to understand that
having seven different like specialized tools is not

68
00:07:03.480 --> 00:07:08.639
a good way to understand what goes
on. There's a lot of reasons,

69
00:07:08.639 --> 00:07:13.360
but I think that the main one
is you don't have context. Right.

70
00:07:13.399 --> 00:07:19.399
You have thirty thousand alerts, twenty
thousand came from that SAS tool, five

71
00:07:19.439 --> 00:07:25.560
thousand came from that OSS tool.
And now what I have three people in

72
00:07:25.560 --> 00:07:34.399
my A team covering thirteen thousand developers, We have twelve hundred poor requests a

73
00:07:34.480 --> 00:07:42.600
day. What do I do so
to answer your question like this is the

74
00:07:42.639 --> 00:07:47.600
context maybe to answer your question like
we look at it in like three layers.

75
00:07:48.040 --> 00:07:51.839
First is visibility, knowing what you
have. I always say, you'll

76
00:07:51.879 --> 00:08:00.639
be amazed how developers, CTOs,
CEO, CIOs, AppSec people they don't

77
00:08:00.680 --> 00:08:05.279
have a clue what they have.
As long as you have more than maybe

78
00:08:05.439 --> 00:08:11.240
ten fifteen twenty developers, not to
mention one thousand or thirty thousand, you

79
00:08:11.279 --> 00:08:13.800
don't know. I don't know which
database is, what technology is, how

80
00:08:13.879 --> 00:08:20.279
many platforms for oh off you are
using? How many languages are all this

81
00:08:20.720 --> 00:08:28.079
you can't fathom too much. So
you can go from there to what APIs?

82
00:08:28.079 --> 00:08:30.759
Do I have? Do I have
graph quel even? I don't know?

83
00:08:31.639 --> 00:08:37.720
Does it go through some engeniques?
What's the technology that says don't go,

84
00:08:39.159 --> 00:08:43.000
go, no go? I don't
know? So first visibility, like

85
00:08:43.440 --> 00:08:48.360
what do I have? We call
it an inventory? Right. The second

86
00:08:48.399 --> 00:08:54.039
phase is, as I said,
you have thirty thousand alerts, findings,

87
00:08:54.039 --> 00:08:58.639
whatever. So prioritize. Tell me
what should I focus on right now?

88
00:08:58.919 --> 00:09:03.159
What will bring most value to my
company? What will stop and attack,

89
00:09:03.759 --> 00:09:07.000
what will be worth my time,
what will save us the most money,

90
00:09:07.759 --> 00:09:15.279
et cetera. So prioritization is the
second thing after that remediation. And after

91
00:09:15.360 --> 00:09:20.799
remediation, like help me find who's
the right person to talk to because I

92
00:09:20.840 --> 00:09:24.600
have again thirteen how much did I
say, thirteen thousand developers? Who's the

93
00:09:24.679 --> 00:09:31.320
right person who can say this API
should actually go to the internet and download

94
00:09:31.399 --> 00:09:37.480
such and such other Who I can
say should I go and ask? So

95
00:09:37.279 --> 00:09:43.440
this is remediation, and after that, like the advanced customers of a PIRO

96
00:09:43.960 --> 00:09:52.519
do more of managing and prevention for
such things, so they employ workflows that

97
00:09:52.600 --> 00:10:01.480
automatically whenever a certain risk goes above
a certain threshold, then they will start

98
00:10:01.840 --> 00:10:07.919
a certain trigger, maybe appentest,
maybe a code review. So this is

99
00:10:07.919 --> 00:10:13.399
how we help people, like three
people versus thirteen thousand people maybe try to

100
00:10:13.440 --> 00:10:18.879
get a hold of application security right
on. Yeah, So a big part

101
00:10:18.919 --> 00:10:24.039
of that is just, well,
like you said, just set in context,

102
00:10:24.039 --> 00:10:28.480
like taking all of this information and
figuring out what parts of it's relevant,

103
00:10:28.559 --> 00:10:33.759
which parts are urgent, and just
trying to turn it into something actionable

104
00:10:33.799 --> 00:10:41.120
so you don't feel like you're overwhelmed
and destined to never succeed. Yeah,

105
00:10:41.480 --> 00:10:48.679
it's really like I think personally,
one of the most frustrating things that I

106
00:10:48.840 --> 00:10:54.279
faced in that context is people saying
shift left, shift left, which is

107
00:10:54.720 --> 00:11:00.000
like, it's a nice term,
I get it, but if it says

108
00:11:00.240 --> 00:11:05.480
all the burden on me, the
developer or the develops engineer, then someone

109
00:11:05.480 --> 00:11:09.840
else do the job, Well,
why should I be the one to handle

110
00:11:09.879 --> 00:11:16.080
everything? Right? So shift left
is really important, but you have to

111
00:11:16.080 --> 00:11:22.399
do it right. If you have
six thousand findings from your automat like automated

112
00:11:22.879 --> 00:11:31.399
certain process of static analysis, and
you're shifting it left. You have to

113
00:11:31.440 --> 00:11:37.519
really chew it up and spit out
only the three, the five, whatever

114
00:11:39.440 --> 00:11:46.399
actionable findings that I can handle.
If you'll give me one hundred, it

115
00:11:46.440 --> 00:11:50.000
will be deprioritized in my I have
features to develop. But if you'll say

116
00:11:50.879 --> 00:11:58.159
these certain vulnerabilities, it might have
false positives, it's fine. But if

117
00:11:58.159 --> 00:12:01.840
it's two out of three, I'm
fine with it because I see the value.

118
00:12:01.879 --> 00:12:05.679
I can see I'm helping my company
be more productive. But if these

119
00:12:05.799 --> 00:12:11.960
three a let's say vulnerabilities are in
APIs that I know that are not in

120
00:12:11.039 --> 00:12:16.519
test code. They are in some
application that is facing the internet, right,

121
00:12:18.039 --> 00:12:22.519
so it's exploitable. Perhaps maybe not, but it has a certain like

122
00:12:24.000 --> 00:12:28.480
it might be exploitable, and I
know the code right, it's like people

123
00:12:28.519 --> 00:12:33.399
from my team has written the code. And more than that, I'm a

124
00:12:33.480 --> 00:12:37.759
security champion, right because my team
has one hundred developers. But the apps

125
00:12:39.080 --> 00:12:43.639
gave that task to me because they
know that I'm like well versed in security

126
00:12:43.679 --> 00:12:48.039
stuff. Right. In that case, go on shift left. I will

127
00:12:48.039 --> 00:12:52.559
make it right. If you have
a false positive, I'll help you be

128
00:12:52.679 --> 00:12:58.159
better. But I will fix it
and I will accept the the two out

129
00:12:58.200 --> 00:13:05.000
of three false positives. I got
a hypothetical for you here, So like,

130
00:13:05.480 --> 00:13:09.799
I know that there are these other
platforms out there that are compliance driven

131
00:13:09.000 --> 00:13:15.720
checklist aggregators right there for SoC two
or ISO, and they collect a lot

132
00:13:15.720 --> 00:13:20.240
of things from individual sources within your
your company, your engineering organization to help

133
00:13:20.279 --> 00:13:26.919
you achieve passing some sort of certification
or regulation. But it feels like your

134
00:13:26.960 --> 00:13:31.080
company, uh actually focuses on the
value of security there right like actually,

135
00:13:33.000 --> 00:13:37.799
rather than some sort of checkbox approach. It really is these things are important

136
00:13:37.840 --> 00:13:46.000
to solve and not just to achieve
a particular In my that's a great question.

137
00:13:46.480 --> 00:13:52.039
As my head is a CTO.
I have to go through sock to

138
00:13:52.360 --> 00:13:58.799
type two. Of course I have
to do that, and it's important too

139
00:13:58.840 --> 00:14:03.559
write right like show our customers that
we take it seriously, even if some

140
00:14:03.679 --> 00:14:13.159
questions in those compliance frameworks are kind
of mundane and seem like that they didn't

141
00:14:13.159 --> 00:14:20.600
adapt to twenty twenty four maybe,
but these two are important. So in

142
00:14:20.639 --> 00:14:24.879
general, we do have like a
module for questionnaires. There are a lot

143
00:14:26.360 --> 00:14:31.279
by the way, for I'm not
sure from the audience here, what's the

144
00:14:31.320 --> 00:14:37.120
average size of a company that they
work for, from independent contractors to one

145
00:14:37.120 --> 00:14:43.200
of thirteen thousand developers maybe or thirty
thousand. But for the larger companies,

146
00:14:43.519 --> 00:14:48.720
they do have a lot of compliance
going on, sock to type, sock

147
00:14:48.799 --> 00:14:58.480
to ISO, and also like they
have all sorts of controls for you don't

148
00:14:58.960 --> 00:15:07.000
you can't change a certain area of
the code base without answering like two hundred

149
00:15:07.080 --> 00:15:13.840
questions. So this is an area
that we also help our customers and do

150
00:15:13.879 --> 00:15:18.039
it smart. Like if we can
automatically answer, as you said, or

151
00:15:18.519 --> 00:15:26.879
thirty seventy sixty percent of the questions
because they are code related or developer related,

152
00:15:28.000 --> 00:15:33.360
we can easily answer that. But
for the rest of the forty percent

153
00:15:33.399 --> 00:15:37.840
of the questions you can go and
answer. Then you can automate the process.

154
00:15:39.039 --> 00:15:41.519
I say, I mean, and
I'm just really intrigued here, Like

155
00:15:41.639 --> 00:15:48.440
it sounds like you could almost utilize
a pro to replace whatever automation platform you

156
00:15:48.480 --> 00:15:54.360
have for soalk two findings and utilize
that to actually achieve it is that accurate

157
00:15:56.519 --> 00:16:03.720
well talk to like let's say it
might require you to present that you have

158
00:16:04.120 --> 00:16:11.519
some sort of like a rule set
of how you do back up and restore,

159
00:16:12.039 --> 00:16:15.679
so this is an area that we
won't help you with that. You'll

160
00:16:15.720 --> 00:16:19.960
still you still also have to go
through I don't know, some sort of

161
00:16:21.320 --> 00:16:26.159
an audit vendor that will the stamp
you have to do that. I won't

162
00:16:26.159 --> 00:16:30.440
tell. I won't save you from
that one. But for the real answers

163
00:16:30.480 --> 00:16:37.200
like that are expensive in terms of
time and money to together, right uh

164
00:16:37.600 --> 00:16:47.159
uh. They will ask you show
me evidence that developers, maybe statistical evidence,

165
00:16:47.200 --> 00:16:53.200
but that developers are going through such
and such process in order to to

166
00:16:53.240 --> 00:17:00.840
trigger some uh some other let's say
paintest or whatever. Okay, and all

167
00:17:00.960 --> 00:17:06.319
of these things, like many of
these things we can derive from what we

168
00:17:06.359 --> 00:17:12.480
analyze. Because we analyze every commit
in your guitar, bit bucket, git

169
00:17:12.559 --> 00:17:18.319
lab, whatever you use. Perforce. We analyze every commit, every ProQuest,

170
00:17:18.519 --> 00:17:22.319
every Gerra ticket, as a DevOps
ticket, whatever. There's a lot

171
00:17:22.359 --> 00:17:27.839
of data there. And the last
thing I want like our customers to do

172
00:17:29.400 --> 00:17:37.720
is go through tedious like uh like
exports of things and go with their eyes

173
00:17:37.799 --> 00:17:42.880
over a thousands of rows and figure
out stuff by themselves. We want to

174
00:17:42.920 --> 00:17:47.279
help as much as we can,
hope I answer the question, yeah,

175
00:17:47.319 --> 00:17:48.480
No, I mean you said something
really interesting to me, and I think

176
00:17:48.480 --> 00:17:52.319
maybe interesting for the listeners as well
as like where do you hook into the

177
00:17:52.359 --> 00:17:56.440
process? And I got this idea, maybe there's an integration that happens if

178
00:17:56.440 --> 00:18:02.000
I change some database through terror form
that I'm already a learned that this could

179
00:18:02.079 --> 00:18:08.440
have security applications. That is that
accurate? Yes? Yeah, so so

180
00:18:08.640 --> 00:18:15.200
if you if you go let's say
let's say that you're an advanced shop,

181
00:18:15.480 --> 00:18:18.240
right and you have everything via their
form. Okay, so this is a

182
00:18:18.240 --> 00:18:25.240
good case. Uh we uh at
at least hook up into your source control

183
00:18:25.279 --> 00:18:29.519
manager. Okay. If you're more
advanced, we will hook into your gra

184
00:18:30.400 --> 00:18:37.079
maybe your Kubernetes environment in a w
S or Google or asure. If you're

185
00:18:37.079 --> 00:18:41.720
more advanced than that, then to
your API gateway, a PI security tool,

186
00:18:42.480 --> 00:18:47.759
and and and maybe your security scanner. Maybe you have sneak, maybe

187
00:18:47.799 --> 00:18:52.839
you have menned, maybe you have
like dozens of others. Right. Uh,

188
00:18:52.880 --> 00:18:56.319
And we take all that data and
crunch it up together. But at

189
00:18:56.759 --> 00:19:00.799
the very minimum, we analyze your
code. You can opt out, you

190
00:19:00.839 --> 00:19:04.880
can choose what code to analyze and
whatnot of it. But assuming that you

191
00:19:04.960 --> 00:19:11.400
have terror form, then yes we
will alert if let's say a certain application

192
00:19:11.640 --> 00:19:15.720
shouldn't be connected to the internet,
and maybe you hook it up into an

193
00:19:15.960 --> 00:19:22.759
ingress in GK whatever that is connected
to the internet, then you can automate

194
00:19:22.799 --> 00:19:27.119
that process and put a guardrail.
Right. So I should have mentioned maybe

195
00:19:27.200 --> 00:19:33.559
before that we have like a concept
that we called governance, which by default

196
00:19:33.599 --> 00:19:38.759
it comes with a certain rule set, but you're free to change, to

197
00:19:38.839 --> 00:19:44.680
delete rules, to add rules,
to tailor it to your specific needs.

198
00:19:45.400 --> 00:19:52.359
But you can say, you can
define what's to you, what's a material

199
00:19:52.480 --> 00:19:56.480
change, as we say, right, if someone added an API, it

200
00:19:56.640 --> 00:20:00.319
might not be material to you.
But if someone add then API that is

201
00:20:02.119 --> 00:20:07.160
connected to the internet and it is
exposing a certain type of data, then

202
00:20:07.200 --> 00:20:11.799
maybe this is dangerous because whatever in
your realm, this is what happens,

203
00:20:11.200 --> 00:20:15.680
right, And then you can say, let's define a workflow. If such

204
00:20:15.680 --> 00:20:22.079
and such happens, then open a
ticket block. The PR don't allow a

205
00:20:22.160 --> 00:20:27.720
developer to change the terraform module X, y or z in such a way,

206
00:20:29.240 --> 00:20:32.960
right, and so you can control
that. Usually people start with understanding

207
00:20:32.960 --> 00:20:37.240
what they have and then they evolve, like their process evolves into putting more

208
00:20:37.240 --> 00:20:44.200
and more prevention guardrails like that one. I think automated feedback to the engineering

209
00:20:44.200 --> 00:20:48.200
teams when they're performing something that matches
one of these governmance rules. I feel

210
00:20:48.200 --> 00:20:52.039
like there's going to be a bunch
of platform develops related people out there that

211
00:20:52.079 --> 00:20:59.519
are jumping for joy over this functionality. Honestly, yeah, this is as

212
00:20:59.519 --> 00:21:06.359
a developed like I have to people
enjoy it, like people usually say,

213
00:21:06.440 --> 00:21:08.680
eat your own dog food. Right, Yeah, it's an important concept.

214
00:21:10.640 --> 00:21:15.279
So for us, it's like in
the extreme, right, because our platform

215
00:21:15.359 --> 00:21:23.039
is for APSEC teams and developers.
Developers are are a bunch of people who

216
00:21:23.039 --> 00:21:26.519
are really hard to please. Okay, let let's put it that way.

217
00:21:27.920 --> 00:21:34.759
And that again, like developers are
used to tools like compilers or IDs where

218
00:21:34.799 --> 00:21:38.359
they get I don't know, five
nines of accuracy. Right, the compiler

219
00:21:38.400 --> 00:21:45.359
doesn't make mistakes. Usually it happens, but it's really rare. That's good

220
00:21:45.359 --> 00:21:48.759
point. Actually, usually it's your
fault as a developer if you see an

221
00:21:48.839 --> 00:21:53.359
error, it's not the compiler.
So again, going back to the example

222
00:21:53.400 --> 00:22:00.759
from before, like going through six
thousand alerts from a certain security platform is

223
00:22:00.880 --> 00:22:08.720
not acceptable for a developer, So
we we really make an effort to cater

224
00:22:08.880 --> 00:22:14.640
the needs of developers where they get
when we get to the developer like the

225
00:22:14.720 --> 00:22:18.000
develops as you said, the develops
engineer who or who is jumping out of

226
00:22:18.079 --> 00:22:23.839
joy. We really we are working
with our customers to make sure that the

227
00:22:23.960 --> 00:22:30.799
process we will start with visibility.
They understand, we understand what goes on.

228
00:22:30.839 --> 00:22:41.119
And then when they let's say,
automate jolting with electricity, the developer

229
00:22:41.200 --> 00:22:45.599
who did such a bad thing,
do it only when you're sure, right,

230
00:22:45.519 --> 00:22:51.000
or let's say more realistically, like
opening a ticket for a certain team

231
00:22:51.680 --> 00:22:56.599
when such a thing happens, is
only when they are certain right. There's

232
00:22:56.680 --> 00:23:06.079
always mistakes, It's fine, but
we really advise customers to evolve into it.

233
00:23:06.160 --> 00:23:11.640
And if you see that, you
can not ask your develop steam to

234
00:23:11.799 --> 00:23:18.839
be always they will be alert.
But don't go every day at five pm

235
00:23:18.079 --> 00:23:22.000
go through all pull requests and make
sure there is no such and such right,

236
00:23:22.480 --> 00:23:26.799
don't do that. Automate that right. This is an easy thing,

237
00:23:26.079 --> 00:23:32.640
let's say so yeah, with care, but as much automation as we can

238
00:23:33.400 --> 00:23:37.839
is really the ROI is really clear
for the customer. Yeah, definitely,

239
00:23:40.960 --> 00:23:45.319
Yeah, And I think that's really
a great approach as well, because by

240
00:23:45.519 --> 00:23:52.759
making sure that you're relaying the information
to only the people who can actually do

241
00:23:52.839 --> 00:23:57.000
something about it. You're going to
minimize the tendency that we have to just

242
00:23:57.319 --> 00:24:03.759
turn off things that we we determined
to be background noise, you know,

243
00:24:03.839 --> 00:24:06.839
like you like you mentioned you know, if you get ten thousand security alerts,

244
00:24:07.440 --> 00:24:10.480
we're going to turn it off as
background noise, even though they might

245
00:24:10.519 --> 00:24:18.680
not be. But if you provide
specific information and and remediation steps for it,

246
00:24:18.880 --> 00:24:22.400
and it's like, oh, that's
that's something I can do, And

247
00:24:22.599 --> 00:24:29.119
I think that actually lends a lot
of long term stability to your overall security

248
00:24:29.119 --> 00:24:37.400
process for sure. Also, there's
a I think something that that is people

249
00:24:37.480 --> 00:24:45.559
tend to consolidate certain tasks. Let's
say there's a there's an app SEC team.

250
00:24:45.599 --> 00:24:51.240
Let's say I get a report every
day every week with a list of

251
00:24:51.319 --> 00:24:57.680
vulnerabilities. I might say, hey, John, you're the you're the remediation

252
00:24:57.839 --> 00:25:03.440
guy. H here's the list.
Go every day again and again, go

253
00:25:03.519 --> 00:25:07.920
through it, make sure it's fine. You might stick some boxes. You'll

254
00:25:07.960 --> 00:25:14.400
say to the ISO person from the
auditor, You'll say, I have a

255
00:25:14.480 --> 00:25:21.640
process. Here's John, here's my
vulnerability person. I'm good, and you'll

256
00:25:21.640 --> 00:25:26.599
get You'll get the v there but
like, at least in some cases,

257
00:25:26.640 --> 00:25:30.839
not all the time, but this
in some cases, the shift left here

258
00:25:30.880 --> 00:25:37.319
is really substantial. Right out of
the six thousand developed developers. Sorry vulnerabilities,

259
00:25:37.440 --> 00:25:41.440
you might say, these four thousand
are irrelevant because they are in tesco,

260
00:25:41.799 --> 00:25:47.720
they are in old repositories that are
not deployed anywhere. Forget about it.

261
00:25:48.160 --> 00:25:52.079
Yeah and so and so, And
you narrow it down and you get

262
00:25:52.079 --> 00:25:59.279
to the twenty seven actionable vulnerabilities that
like tending to will bring impact to the

263
00:25:59.319 --> 00:26:03.839
company. And then you'll say,
for each one of the twenty seven,

264
00:26:03.160 --> 00:26:07.720
who's the right person? And here
comes the concept that I like the most

265
00:26:07.720 --> 00:26:14.079
here, which is code ownership.
In appare we have a collective code ownership,

266
00:26:14.599 --> 00:26:19.440
but when a certain problem arises,
there's always the one person that knows

267
00:26:19.480 --> 00:26:25.279
about this thing the most. And
it's not, you know, naively,

268
00:26:26.240 --> 00:26:32.279
the last person who touched that piece
of code. It's more usually reality is

269
00:26:32.359 --> 00:26:41.680
more complicated than that. So we
make huge efforts in analyzing the behavior of

270
00:26:41.720 --> 00:26:47.799
every developer, what code they are
touching in which way do they like.

271
00:26:47.880 --> 00:26:55.119
There's a difference between like the CEO
doesn't know well enough and he does refractoring

272
00:26:55.200 --> 00:27:00.319
and he makes the code cleaner because
he wants to the difference between that guy

273
00:27:00.640 --> 00:27:11.000
and someone else who went and replaced
the authentication mechanism from user password to octa

274
00:27:11.119 --> 00:27:15.599
integration datata. Right, there's a
huge different difference between those two. I'm

275
00:27:15.640 --> 00:27:22.799
not saying the latter is better,
but that person is way more capable in

276
00:27:23.039 --> 00:27:27.000
saying, hey, this vulnerability is
real, it's actionable. This is the

277
00:27:27.000 --> 00:27:30.799
way to solve it. Maybe some
other person will solve it, but this

278
00:27:30.880 --> 00:27:34.960
is the way, and this is
how we can, you know, get

279
00:27:36.000 --> 00:27:41.240
to do remediation much much faster and
cheaper. That's super cool. So you're

280
00:27:41.279 --> 00:27:48.119
actually building like a a historical audit
of the actions of the people on the

281
00:27:48.200 --> 00:27:53.119
platform, so you can identify what
their expertise is and figure out who the

282
00:27:53.200 --> 00:27:59.119
right person is without asking, without
doing like an ad channel and a SLAT

283
00:27:59.160 --> 00:28:03.559
group with thirteen thousand people in it. Mm hmmm, yeah exactly. And

284
00:28:04.559 --> 00:28:12.119
we have a thing where we I
feel more like, let's say it's maybe

285
00:28:12.160 --> 00:28:18.480
a bad word, like more privileged
than my previous self. When we did

286
00:28:18.640 --> 00:28:25.240
in previous company, we did network
security. We analyzed network traffic, so

287
00:28:25.279 --> 00:28:30.920
we connected to switch in the server
farm and we tapped to the traffic and

288
00:28:30.960 --> 00:28:37.079
we analyzed it. But it started
tequal zero. It started when we connected.

289
00:28:37.240 --> 00:28:42.240
Right now we are privileged is an
app sec company where we connect like

290
00:28:42.359 --> 00:28:48.920
via API to let's say guitub and
then we can analyze the entire history of

291
00:28:48.920 --> 00:28:53.079
a Git repository from ten years ago. Right. So in that sense,

292
00:28:53.200 --> 00:28:57.839
we have from when we start as
we start to have a lot of information

293
00:28:57.960 --> 00:29:04.440
about the code behavior, who's doing
what, and we analyze the behavior ever

294
00:29:04.599 --> 00:29:12.279
developer and we say this subset is
what we call a security champion, right.

295
00:29:14.079 --> 00:29:19.720
So some of our customers have actually
using that. They have built like

296
00:29:19.759 --> 00:29:26.160
a security champion program. So they
have let's say three app sec people on

297
00:29:26.200 --> 00:29:30.799
the team, like who's in charge
of the entire company, and they have

298
00:29:30.079 --> 00:29:37.319
one hundred and fifty development teams and
they chose one or two people from every

299
00:29:37.400 --> 00:29:45.559
division will be like their ambassadors into
security. So when there's an issue with

300
00:29:45.240 --> 00:29:52.200
product X, they can say,
hey, team, we've talked before,

301
00:29:52.400 --> 00:29:57.640
we've taught you about our processes,
there's such and such problem, please advice,

302
00:29:59.200 --> 00:30:03.519
right, And he's one out of
seventy people, so they don't need

303
00:30:03.559 --> 00:30:07.880
to go through proper channels with the
management and and do like a like a

304
00:30:07.920 --> 00:30:14.160
heavy thing. They have people they
can talk to and it's not bureaucratic.

305
00:30:14.200 --> 00:30:18.799
It's data driven, which is really
like it proves helpful in many cases,

306
00:30:22.119 --> 00:30:25.880
right, and that's super cool.
One of the things you talked touched on

307
00:30:26.200 --> 00:30:33.920
a little bit earlier was talking about
the context and the visibility of it,

308
00:30:34.720 --> 00:30:40.319
and you kind of mentioned that,
you know, fixing these vulnerabilities gives you

309
00:30:40.359 --> 00:30:45.400
the ability to say, hey,
we prevented or we blocked this before it

310
00:30:45.519 --> 00:30:52.200
was exploited. How much value do
you think there is in that by by

311
00:30:52.279 --> 00:30:57.400
showing the things the ability that you
had to stop something before it happened and

312
00:30:57.480 --> 00:31:03.440
kind of elevate secure already work to
that of like future requests because everyone gets

313
00:31:03.440 --> 00:31:08.640
excited over the new future requests.
Do you think that showing the security vulnerabilities

314
00:31:08.640 --> 00:31:18.119
you've re mediated helps bring bring some
awareness to that? For sure? So

315
00:31:18.599 --> 00:31:22.000
I think coming back to something I
think you said maybe before we started recording,

316
00:31:23.680 --> 00:31:30.759
security is a thing like everybody wants
it to not exist until something hits

317
00:31:30.799 --> 00:31:36.400
a fan somewhere, right, and
then oh my god, we had to

318
00:31:36.440 --> 00:31:42.000
do such and such before. I
wish three months ago when we designed the

319
00:31:42.039 --> 00:31:48.640
feature we would have thought about it. I wish we drink testing. We

320
00:31:48.720 --> 00:31:55.960
would go through the list of things
that could go wrong and find out about

321
00:31:56.000 --> 00:32:02.240
it. So, but the reverse
of it is everyone, everybody wants to

322
00:32:02.319 --> 00:32:08.480
celebrate new features and sell it to
customers. So uh, it's a hard

323
00:32:08.519 --> 00:32:15.480
bargain sometimes to for security teams to
prove their their worth to the organization because

324
00:32:15.880 --> 00:32:23.440
nobody pays attention to quiet. Like
the CSO can can come to a board

325
00:32:23.519 --> 00:32:30.720
meeting, or the APPSC engineer can
come to a certain meeting all hands for

326
00:32:30.799 --> 00:32:36.920
the company and say, hey,
for seven months no incident, everything is

327
00:32:37.000 --> 00:32:40.039
quiet on my front. They might
say, okay, let's reduce the team

328
00:32:40.480 --> 00:32:45.319
right exactly. Yeah, life,
life of security is really hard that way.

329
00:32:46.440 --> 00:32:52.839
But I think I think that it's
a game of numbers proving. Let's

330
00:32:52.880 --> 00:32:58.920
say again, when people are used
to false positives, and it's true both

331
00:32:59.000 --> 00:33:07.319
for networks, security, intrusion alerts, whatever, DLP viruses, for everything

332
00:33:07.359 --> 00:33:14.440
including appsect. When people are used
to false positives, they're they're they're not

333
00:33:14.480 --> 00:33:19.279
paying attention, like everything is noise. We have a we have a concept

334
00:33:19.359 --> 00:33:29.799
of funnel where we are showing you
have starting with thirty thousand alerts, and

335
00:33:30.240 --> 00:33:35.279
via various steps you go to a
lower and lower and lower number until you

336
00:33:35.319 --> 00:33:39.319
get to a manageable amount of things
that you can actually work on. And

337
00:33:39.359 --> 00:33:43.920
if this is the focus, and
in each team, it's a little bit

338
00:33:43.920 --> 00:33:49.400
different. For some is like the
is it connected to the is it exposed

339
00:33:49.440 --> 00:33:52.000
to the internet? Just no,
it really reduces. For some everything is

340
00:33:52.039 --> 00:33:55.839
exposed to the internet, So there
are differences. But as long as the

341
00:33:55.920 --> 00:34:04.039
number goes down and and is it
becomes manageable and real, then the teams

342
00:34:04.279 --> 00:34:08.000
pay more attention. When you come
as an absect to the dev team,

343
00:34:09.039 --> 00:34:16.480
you're not wasting their time. They
feel once they do like there's a I

344
00:34:16.519 --> 00:34:24.679
think there's people underestimate developers or develops
engineers in the industry where some say that

345
00:34:24.719 --> 00:34:29.960
they don't care about security because it's
someone else's concern. I don't think it's

346
00:34:29.960 --> 00:34:35.920
true. Maybe that's just my opinion, but I don't think it's true.

347
00:34:36.119 --> 00:34:43.599
And and if if like apseck came
to developers with a small number of real

348
00:34:43.719 --> 00:34:50.760
things, then the developers will be
excited to deliver on it and they will

349
00:34:50.800 --> 00:34:53.880
feel that they're building a stronger product. By the way, the same thing

350
00:34:54.639 --> 00:35:01.639
is true also with performance and other
things that are not like purely like features.

351
00:35:02.280 --> 00:35:06.400
Performances a feature. Security is a
future. I really believe in it.

352
00:35:06.480 --> 00:35:13.599
So I think as long as the
numbers are are manageable, I think

353
00:35:13.679 --> 00:35:19.599
people will treat it the same way
as features, and they can even celebrate

354
00:35:19.639 --> 00:35:27.199
it. Yeah, for sure.
I think especially like if you are just

355
00:35:28.159 --> 00:35:30.360
trying to say, Okay, we
got to get we got to get a

356
00:35:30.400 --> 00:35:36.119
grip on our security, and you're
working with a code base that's been around,

357
00:35:36.360 --> 00:35:37.920
you know, for a year or
more. The first time you run

358
00:35:37.920 --> 00:35:44.360
that security scan, it's going to
be overwhelming and that your first at least

359
00:35:44.360 --> 00:35:46.840
for me, my first instinct is
to look at the findings and go,

360
00:35:47.039 --> 00:35:52.840
yeah, that's a problem for next
sprint and then move on and next year

361
00:35:52.840 --> 00:35:55.880
I'll have the same conversation with myself. So I think there's really a lot

362
00:35:55.920 --> 00:36:01.239
of value in saying, Okay,
let's just put this in context and here

363
00:36:01.239 --> 00:36:06.360
are the key things that you can
focus on this brand that'll actually make a

364
00:36:06.400 --> 00:36:08.119
difference. Yeah. I mean,
you're really talking about curation there, and

365
00:36:08.159 --> 00:36:10.920
I think that's one of the things
that a lot of tools in the Devil

366
00:36:10.960 --> 00:36:15.440
of Space overall get wrong. They
think it's like a lack of information.

367
00:36:15.559 --> 00:36:19.360
They're all about exposing as many things
as possible as if that's where the value

368
00:36:19.440 --> 00:36:22.920
is. And I think the tool
we haven't said but kept talking about here

369
00:36:22.000 --> 00:36:27.400
is sort of like depend upon on
GitHub, which you know spams every single

370
00:36:27.440 --> 00:36:30.840
thing, and it's very difficult to
know whether or not there's value in any

371
00:36:30.880 --> 00:36:32.800
one of those alerts. So realistically, you want it to be curated.

372
00:36:32.800 --> 00:36:37.320
That's where the value is, right, having not only information, but relevant

373
00:36:37.360 --> 00:36:44.039
and useful and correct information, Right, that's prioritized. Yeah, exactly,

374
00:36:45.159 --> 00:36:49.199
like this is our this is our
claim to fame actually, because we're saying

375
00:36:49.199 --> 00:36:54.719
like ESPM is the is the abbreviation, and we say deep SPM because we

376
00:36:54.880 --> 00:37:02.400
really believe that just aggregating alerts,
putting putting them, displaying them in a

377
00:37:02.480 --> 00:37:08.079
nice table which streams nicely, uh, and putting nice graphs on top.

378
00:37:08.519 --> 00:37:13.880
It's like, I don't want to
sound disrespectful, but as you said,

379
00:37:14.000 --> 00:37:21.440
right now, we're putting context uh
into into that data is really crucial,

380
00:37:21.840 --> 00:37:28.280
uh, in order to allow prioritization
and remediation. So we when we say

381
00:37:28.360 --> 00:37:35.119
deep I'll give you an example,
when we say deep uh we uh we

382
00:37:35.159 --> 00:37:38.840
analyze the code right, We analyze
the gerry tickets, We read all the

383
00:37:38.880 --> 00:37:45.360
fields. We analyze. We know
what's an API. We know what's a

384
00:37:45.480 --> 00:37:51.840
data model, and if it's safe
to the database, if it's exposed via

385
00:37:52.400 --> 00:37:58.039
that a PR or that I p
I we know UH if a certain UH

386
00:37:58.480 --> 00:38:02.880
like code element is in a certain
module, which might be a part of

387
00:38:02.920 --> 00:38:07.639
a repository. There might be a
mono repo, might be a certain application

388
00:38:07.840 --> 00:38:15.840
that has seventeen different modules from six
different repositories, some in guitub and some

389
00:38:15.960 --> 00:38:22.159
in bit bucket, and some I
don't know from somewhere else. So when

390
00:38:22.239 --> 00:38:28.440
we see a vulnerability, it might
be a secret that we detected secret in

391
00:38:28.480 --> 00:38:34.599
code. It might be a vulnerability
that came from check marks or sneak or

392
00:38:34.639 --> 00:38:39.360
someone else. We know a lot
of context around it. Okay, So

393
00:38:39.800 --> 00:38:44.920
if it's part of an API,
we know a lot about that API.

394
00:38:45.480 --> 00:38:52.239
If you connected to a COMI,
then we can say, okay, that

395
00:38:52.360 --> 00:38:58.719
API is exposed in that cluster and
is getting bombarded right now in production.

396
00:38:59.800 --> 00:39:05.400
So we try as as more and
more things get connected, we add more

397
00:39:05.440 --> 00:39:10.760
context into it. So it's really
really important to inject that context into those

398
00:39:10.840 --> 00:39:19.639
lists of vulnerabilities or material changes,
because asking the developer to do the work

399
00:39:19.719 --> 00:39:24.440
is not realistic. Right. We
see we have customers with I think the

400
00:39:24.440 --> 00:39:34.400
most has a forty something thousand repositories. Oh wow, that's that's a that's

401
00:39:34.400 --> 00:39:39.480
a number that I don't think a
person, a human being can fathom in

402
00:39:39.599 --> 00:39:46.000
terms of like there's no intuition around
it. So you have you have to

403
00:39:46.079 --> 00:39:52.039
have that knowledge modeled somewhere. I
mean I do, I do have some

404
00:39:52.119 --> 00:39:55.360
intuition there that micro services went wrong
somewhere, But you know from that,

405
00:39:58.400 --> 00:40:02.880
I mean you bring abouts an interesting
aspects here, which is information about the

406
00:40:04.039 --> 00:40:07.159
likelihood of these vulnerabilities actually being a
problem. And I think this is a

407
00:40:07.280 --> 00:40:10.440
difficult area to answer. You can
look at some code, even with the

408
00:40:10.480 --> 00:40:15.400
context, and know that there is
a security problem there. Maybe it's open

409
00:40:15.440 --> 00:40:21.360
to ssr F, you know,
service I Request forgeries or something on the

410
00:40:21.440 --> 00:40:25.480
UI side that's open to cross site
scripting, but it's you know, I've

411
00:40:25.480 --> 00:40:30.519
been doing research and I just cannot
find actual numbers on the number of say

412
00:40:30.639 --> 00:40:36.480
data breaches there are, because the
actually detecting that it's happened and knowing that

413
00:40:36.559 --> 00:40:40.840
a change that you've made is going
to has actually stopped. One is really

414
00:40:42.039 --> 00:40:45.519
a challenge, and I assume that
it's not even something that you would be

415
00:40:45.559 --> 00:40:51.599
able to know about. Right.
We do have some statistics for interesting,

416
00:40:52.239 --> 00:41:04.320
but I can say easily that a
state in terms of like level of hacking

417
00:41:04.960 --> 00:41:14.199
might might uh utilize or take advantage
of some some sort of nobility that could

418
00:41:14.239 --> 00:41:19.880
be found in code and might help
you to find your way through after four

419
00:41:19.920 --> 00:41:24.960
months of an attack, like doing
various things in order to get to a

420
00:41:25.000 --> 00:41:32.000
certain crown jewel type of information.
It happens, but many more times,

421
00:41:32.440 --> 00:41:40.400
ah, some some person has connected
the wrong wires and and and opened the

422
00:41:40.400 --> 00:41:45.559
the I don't know, the some
proxy server connected to the wrong the wrong

423
00:41:45.639 --> 00:41:52.599
network and like maybe it's via terraform
or click ups or uh, maybe a

424
00:41:52.639 --> 00:42:01.000
certain a p I that is supposed
to be under authorization is actually without because

425
00:42:01.199 --> 00:42:07.199
like a bug in the code,
these type of things are not immune to

426
00:42:07.239 --> 00:42:12.760
bugs in code. And you might
have like a huge wall, a firewall

427
00:42:13.039 --> 00:42:21.079
and octa and whatever in front of
your application that prevents the most brilliant hacker

428
00:42:21.159 --> 00:42:27.519
to pass through. But your API
doesn't require authorization. You can just approach

429
00:42:27.559 --> 00:42:32.400
it and inject things into a database
or pulled data from the database. So

430
00:42:36.159 --> 00:42:46.480
I think what we see in various
companies is evolving from the notion that we

431
00:42:46.559 --> 00:42:54.719
have X vulnerability is let's solve every
vulnerability right, and evolving into let's do

432
00:42:55.280 --> 00:43:02.440
a threat model, analyze what I
have in the most important applications or the

433
00:43:02.559 --> 00:43:08.159
most sensitive applications, which is another
area that we help with. But let's

434
00:43:08.199 --> 00:43:13.960
focus on those, and in those, let's understand what's the attack vector,

435
00:43:14.440 --> 00:43:20.320
and there we will say what types
of actions we think we need to do.

436
00:43:21.039 --> 00:43:24.719
Maybe make sure there are no exposed
secrets. Maybe make sure that the

437
00:43:27.000 --> 00:43:32.480
APIs don't do things that they shouldn't
do. Maybe it's super duper critical.

438
00:43:34.000 --> 00:43:37.960
Let's make sure we have zero verun
abilities and do everything we can, but

439
00:43:38.239 --> 00:43:43.920
not for everything. So this is
really important in terms of time and effort

440
00:43:44.440 --> 00:43:49.199
that the people put into it.
Does that mean that you're actually also able

441
00:43:49.239 --> 00:43:55.000
to investigate the sort of transitive dependencies
of source code pack venders that are being

442
00:43:55.079 --> 00:44:02.039
utilized? Yeah, actually yeah we
do so, uh open sources. I'm

443
00:44:02.079 --> 00:44:06.639
assuming you're in open source, but
not necessarily but yeah, I mean right,

444
00:44:06.760 --> 00:44:10.039
I mean they could be internal packages
that another team has published or you

445
00:44:10.079 --> 00:44:14.719
know, obviously code that comes from
outside for sure. Yeah, okay,

446
00:44:14.960 --> 00:44:17.960
so uh yeah, we do.
We have a distinction between external and internal

447
00:44:19.000 --> 00:44:24.800
packages, whether you publish it via
an internal Nougat or Maven or something else

448
00:44:25.239 --> 00:44:30.760
inside your organization, or even if
you have a package that you copy and

449
00:44:30.840 --> 00:44:36.639
paste it into some other area.
I think, for me, the most

450
00:44:37.159 --> 00:44:43.039
the more interesting thing in terms of
like developing a product is that you have

451
00:44:43.920 --> 00:44:52.440
a certain module that is shared between
various applications. Right So you have the

452
00:44:52.519 --> 00:44:59.039
classic example is an infrastructure package that
has I don't know, utilities or ways

453
00:44:59.079 --> 00:45:06.079
to connect to you or central user
service or something like that, and it's

454
00:45:06.800 --> 00:45:13.599
being used in like three different versions
of that are being used in seventeen different

455
00:45:13.639 --> 00:45:21.519
applications. So what's the impact of
Warren going and changing a certain threshold of

456
00:45:22.159 --> 00:45:28.159
I don't know password, the strength
in that package. What's the impact If

457
00:45:28.159 --> 00:45:32.679
it's on seventeen applications, it might
be more substantial, right so, and

458
00:45:32.800 --> 00:45:39.320
it could go through more than one
hop of analysis. So we're doing really

459
00:45:39.320 --> 00:45:45.559
interesting things in that area. And
it's hard that computationally if you think about

460
00:45:45.559 --> 00:45:52.079
it. Yeah, for sure.
So Warren, you're the CTO of a

461
00:45:52.360 --> 00:46:00.079
security off company. How do you
like obviously security is like front of your

462
00:46:00.079 --> 00:46:07.760
company. How do you approach this
whenever you're building and deploying your product?

463
00:46:07.199 --> 00:46:13.320
Oh, definitely don't ask me that
question. Sorry, Should we have the

464
00:46:13.440 --> 00:46:16.280
editor cut this part out? No, I mean it's totally fine. I

465
00:46:16.280 --> 00:46:20.280
mean realistically, we are definitely looking
for products that, like you know,

466
00:46:20.440 --> 00:46:22.480
ton Scott here to review. I
think a lot of the problem is that

467
00:46:22.639 --> 00:46:28.840
many products in the space fall into
this sort of uncanny value where they're either

468
00:46:29.199 --> 00:46:34.480
unnecessary alerts that don't really tell us
anything. We've definitely gone through the snakes,

469
00:46:34.719 --> 00:46:38.400
sneaks and dependent bots code QLs of
the world, and as well as

470
00:46:38.440 --> 00:46:43.039
look at the ones that review stuff
for a Soalk two and ISO, but

471
00:46:43.159 --> 00:46:47.960
they're mostly checkbox driven security and don't
really focus on actually finding real problems.

472
00:46:49.480 --> 00:46:55.000
So I think realistically it's on us
to do this investigation most of the time

473
00:46:55.119 --> 00:46:59.760
manually, I mean obviously using the
tools that are available to make these decisions.

474
00:47:00.119 --> 00:47:02.960
Now, I think we have a
lot of benefit over some other companies

475
00:47:04.280 --> 00:47:07.480
given the size that we are at
much smaller, so it's not like we

476
00:47:07.559 --> 00:47:12.639
have forty seven thousand repositories that we've
got I think the number is under a

477
00:47:12.679 --> 00:47:15.559
thousand, and most of them are
not services. Yeah, well, I

478
00:47:15.599 --> 00:47:22.199
mean there's just an amount of overhead
as far as cognitive overload that teams will

479
00:47:22.239 --> 00:47:27.000
have to deal through. So more
repositories can only be managed by more people,

480
00:47:27.159 --> 00:47:30.960
and that breaks down as size increases. So I mean, realistically,

481
00:47:31.360 --> 00:47:35.000
there are things that you just don't
want to have to deal with. Now

482
00:47:35.960 --> 00:47:39.320
in my position, what I've really
focused on is what are the platforms or

483
00:47:39.360 --> 00:47:44.559
tools that are out there that help
eliminate a whole class of problems. So

484
00:47:44.840 --> 00:47:47.559
classes of problems can be eliminated by
I mean me personally, you know,

485
00:47:47.599 --> 00:47:52.519
i'd say get away from Kubernetes,
but really virtual machines in general. While

486
00:47:52.559 --> 00:47:57.119
it may seem like it's easy to
spin them up, the number of security

487
00:47:57.119 --> 00:48:02.280
concerns from my standpoint is just massive. There just patch schedules, et cetera.

488
00:48:02.840 --> 00:48:06.440
Even for things that are zero day, right, it's so much easier

489
00:48:06.440 --> 00:48:09.119
to delegate that to a potential cloud
provider. How to get around those.

490
00:48:09.760 --> 00:48:13.840
Another thing that we're leading with I'm
not sure when this is going to be

491
00:48:13.880 --> 00:48:17.639
available in production, is allowing our
customers to sign the data that they're sending

492
00:48:17.639 --> 00:48:22.119
to us. That means that we
have a fidelity over you know, whether

493
00:48:22.199 --> 00:48:24.719
or not that data has actually been
changed, not necessarily access, but specifically

494
00:48:25.239 --> 00:48:28.639
since we are in the AWE space, we do care about when it's been

495
00:48:28.719 --> 00:48:31.440
changed, and so there are things
like this that we consider novel, but

496
00:48:31.480 --> 00:48:36.800
realistically, it's about finding those tools
that help us elevate what we're utilizing to

497
00:48:36.840 --> 00:48:43.679
another level. Yeah, and I
think that's like a unique problem because you

498
00:48:43.719 --> 00:48:49.719
do have like a limited number of
people on your team, but literally an

499
00:48:49.920 --> 00:48:59.199
unlimited number of security problems. You
know, Yeah, for sure, you

500
00:48:59.239 --> 00:49:01.480
know that that's always going to be
a trouble. I think I think this

501
00:49:01.559 --> 00:49:07.280
goes for everything. Focus on your
core competency, whatever that is, and

502
00:49:07.800 --> 00:49:12.360
find a way to eliminate or at
least delegate those concerns elsewhere. So every

503
00:49:12.360 --> 00:49:15.440
time one of those comes up,
find a company that helps you eliminate the

504
00:49:15.480 --> 00:49:19.400
broadest class of them, or you
know, transition to a different stack or

505
00:49:19.400 --> 00:49:22.679
something like that where you don't have
those issues, because you will never solve

506
00:49:22.679 --> 00:49:25.000
every problem. And I think often
you may hear things like, well,

507
00:49:25.000 --> 00:49:30.519
we can't depend on another company offering
a critical component for us, because what

508
00:49:30.599 --> 00:49:32.239
happens if it's down, what happens
if there's an issue there? I mean,

509
00:49:32.280 --> 00:49:37.519
like you should trust the security experts
to get that right more so than

510
00:49:37.719 --> 00:49:39.679
I mean, there's no different between
the set of engineers that they're hiring and

511
00:49:39.719 --> 00:49:43.840
the ones that you can hire.
And they're probably focused on this, right.

512
00:49:43.880 --> 00:49:46.039
You know, we're focused on hiring
people that do care about that security

513
00:49:46.039 --> 00:49:50.639
aspect, just as you know Tom's
focused on this as as well. I'm

514
00:49:50.639 --> 00:49:52.360
sure, right, you know,
you hire people that understand this part of

515
00:49:52.440 --> 00:49:57.079
platform management and security to go forward, and you're not going to be able

516
00:49:57.079 --> 00:50:01.679
to do it as effectively unfortunately.
Time and resources, Yeah, for sure,

517
00:50:05.360 --> 00:50:12.719
we at Apparel, we do have
an infinite amount of time and resources

518
00:50:12.480 --> 00:50:15.639
that that's their usp there right right
there. You know you heard it there

519
00:50:15.719 --> 00:50:22.760
first, right, So a lot
of times with sort of continuing on what

520
00:50:22.920 --> 00:50:25.920
you were saying there, Warren,
you know, there's like a there's three

521
00:50:27.599 --> 00:50:36.159
models of solving a problem. There's
do it yourself, there's tell get someone

522
00:50:36.239 --> 00:50:38.840
to tell you what to do,
or there's just hire someone to do it

523
00:50:38.920 --> 00:50:45.199
for you. And so, Jonathan, what are the what's the like entry

524
00:50:45.280 --> 00:50:52.920
level do it yourself version of handling
this like obviously your apiro is like the

525
00:50:53.840 --> 00:50:59.039
Hey, we're gonna collect all the
data and and put it in context and

526
00:50:59.159 --> 00:51:02.719
prioritize it for you. But like, what's the entry level version of that

527
00:51:02.719 --> 00:51:07.960
that probably most of us are actually
trying to do but unsuccessfully. That would

528
00:51:08.000 --> 00:51:15.840
tell us, man, there's got
to be a better way. You mean,

529
00:51:15.880 --> 00:51:20.280
you mean, how how the company, like a software shop would do

530
00:51:20.559 --> 00:51:29.119
what we do manually like without yeah, uh so so like people more people

531
00:51:29.599 --> 00:51:36.519
essentially? Uh yeah, so so
we see that, uh and I understand

532
00:51:36.559 --> 00:51:43.559
the like like when when you're facing
a certain amount of work, then you

533
00:51:43.599 --> 00:51:50.199
can either uh focus the team on
it and do it like one person for

534
00:51:50.280 --> 00:51:53.880
a small shop or one team for
a larger shop that handles like the load

535
00:51:53.960 --> 00:52:01.079
for everyone. And there's the companies
that uh distribute to work with the load

536
00:52:01.199 --> 00:52:09.280
on the developers. I think the
most important thing to understand to maybe a

537
00:52:09.320 --> 00:52:17.679
marker that might tell you that this
thing got out of hand is if like

538
00:52:17.719 --> 00:52:24.800
hopefully you're asking your developers like how
they are doing and if they they feel

539
00:52:24.840 --> 00:52:32.719
that their job is going well.
So if they say twenty percent, thirty

540
00:52:32.760 --> 00:52:38.519
percent, seventy percent of my time
is going after things that I don't see

541
00:52:38.719 --> 00:52:45.320
any value coming out of this is
a good marker that you might want to

542
00:52:45.519 --> 00:52:51.320
change the process. Either either use
it like a platform, like a peer,

543
00:52:51.480 --> 00:52:55.000
or maybe something else. Either either
that or don't do it. Like

544
00:52:55.159 --> 00:53:02.440
sometimes it's better to take take the
lead and not go through a certain process

545
00:53:04.119 --> 00:53:12.760
save like ten percent of your one
hundred developers time, that's ten ten developers.

546
00:53:13.639 --> 00:53:16.599
Ten developers can bridge the gap and
bring more either more value, more

547
00:53:16.639 --> 00:53:22.960
features, or more security. So
either use the right tool for the job,

548
00:53:22.360 --> 00:53:27.239
or maybe do less of it of
the of the noise. Sometimes it's

549
00:53:27.280 --> 00:53:32.480
better then, like bringing everything to
a halt. That's probably a really great

550
00:53:32.480 --> 00:53:36.000
point there, actually using the right
tool for the job. And I don't

551
00:53:36.000 --> 00:53:37.800
think that could be said enough because
you know, to answer a little bit

552
00:53:37.840 --> 00:53:42.000
more of your question, Well,
i've seen the let's build our own sort

553
00:53:42.039 --> 00:53:47.119
of internal strategy for automatically updating versions
of packages for instance, right, And

554
00:53:47.280 --> 00:53:51.000
it's like, well, you're building
this yourself, Like why are you building

555
00:53:51.039 --> 00:53:54.000
the tool versus using something that's way
more intelligent at actually finding where the security

556
00:53:54.039 --> 00:53:59.280
vulnerabilities are and focus on that one. And I think there's the other one

557
00:53:59.280 --> 00:54:01.840
I've seen, which I also am
not a fan of is the replicate all

558
00:54:01.840 --> 00:54:08.159
the external packages in the world locally
in your own package repository, because unless

559
00:54:08.199 --> 00:54:12.800
you have a team that is expert
in reviewing that or a tool that's actually

560
00:54:12.840 --> 00:54:15.960
going to do it, you're not
really doing anything other than having out of

561
00:54:15.039 --> 00:54:21.079
date versions that are available. So
you're actually almost hurting yourself more than you're

562
00:54:21.119 --> 00:54:24.559
helping by using one of these because
it's not solving a problem of security,

563
00:54:24.559 --> 00:54:30.039
it's solving a problem of anything reliability
or where the single point of failure is.

564
00:54:30.119 --> 00:54:32.519
Right. It's not a highly reliable
package manager out in the world that

565
00:54:32.599 --> 00:54:37.519
has security teams dedicated to finding vulnerabilities. It's some tool off the shelf that

566
00:54:37.559 --> 00:54:42.639
you're deployed in your own infrastructure which
is out of date. Yeah. I

567
00:54:42.679 --> 00:54:47.719
think also this is a great example
of sometimes not understanding the trade off usually

568
00:54:49.679 --> 00:54:54.280
most things, maybe in life,
but in our field, there's a trade

569
00:54:54.280 --> 00:55:00.960
off. Like if you're saying,
don't like I have a certain certain version

570
00:55:01.039 --> 00:55:07.559
of package X that is not vulnerable, then let's freeze it in time and

571
00:55:07.719 --> 00:55:12.880
not never ever upgrade it because there
might be a vulnerability. There's a trade

572
00:55:12.920 --> 00:55:17.599
of there, right, both functionally
and maybe maybe it does have a vulnerability,

573
00:55:17.599 --> 00:55:23.000
but it's unknown. Now I'm not
saying like for everything, newer is

574
00:55:23.039 --> 00:55:29.039
better, but there's always a trade
off. So yeah, I think that

575
00:55:29.079 --> 00:55:32.440
they like what what you said is
really really true. If you're doing it

576
00:55:32.519 --> 00:55:39.039
yourself and like inventing things that are
not your core business, then be really

577
00:55:39.079 --> 00:55:45.679
careful because you're probably not the best
of breeding usually. No, I mean

578
00:55:45.840 --> 00:55:47.800
no, no, it's for true. I mean I think there's another problem

579
00:55:47.800 --> 00:55:51.920
there, which is you don't know
whether or not you're doing it right.

580
00:55:52.039 --> 00:55:54.480
So you're going through the motions of
things right, you know, you're even

581
00:55:54.480 --> 00:55:58.559
if maybe maybe updating the versions is
the right thing, but it could just

582
00:55:58.599 --> 00:56:00.559
as easily be the case where it's
not, and you're actually having a negative

583
00:56:00.599 --> 00:56:07.039
impact overall. So you're not doing
the research to understand what the best practice

584
00:56:07.079 --> 00:56:10.679
trends are, and you're using your
own sort of heuristics from your own experiences,

585
00:56:10.880 --> 00:56:15.480
which they're still valid, right,
but just in a small niche compared

586
00:56:15.519 --> 00:56:20.119
to what the collective wisdom says,
and going about that, you know,

587
00:56:20.199 --> 00:56:22.199
in that way, which may lead
you to, oh, yeah, we

588
00:56:22.199 --> 00:56:24.880
need to automatically roll all versions of
all packages all the time, or we

589
00:56:24.920 --> 00:56:29.239
need to freeze all of them,
and I think both of them are equally

590
00:56:29.280 --> 00:56:34.960
problematic in some way. Yeah.
One of the other things you know,

591
00:56:35.000 --> 00:56:39.280
you mentioned higher or use the people
who are best at that. I think

592
00:56:39.320 --> 00:56:45.840
one of the things that I see
common with that is whenever you go to

593
00:56:46.320 --> 00:56:51.599
like you say, Okay, I
shouldn't be writing on authentication package myself.

594
00:56:51.639 --> 00:56:55.079
That's a solved problem that's been solved
by people way smarter than me. So

595
00:56:55.159 --> 00:57:00.079
you go out and you start looking
at available packages. Like part of that

596
00:57:00.159 --> 00:57:06.000
research is understanding who the expert really
is and digging in, like dig into

597
00:57:06.039 --> 00:57:10.480
their GitHub repo. Is it being
updated frequently? How many committers are working

598
00:57:10.480 --> 00:57:15.400
on this? Because if you find
an authentication package that was updated three years

599
00:57:15.400 --> 00:57:22.039
ago by one person and hasn't been
touched since, that may not be an

600
00:57:22.039 --> 00:57:29.159
improvement over your current authentication layer.
Yeah. Sure, I mean i'd be

601
00:57:29.159 --> 00:57:31.320
curious what you know, Tom,
actually if it has any information about this,

602
00:57:31.480 --> 00:57:37.079
Like are there heuristics about update frequency
or the type of packages that lend

603
00:57:37.119 --> 00:57:40.920
themselves, especially in the open source
world, to being more vulnerable or more

604
00:57:40.920 --> 00:57:47.719
secure? Yeah? So really interesting, especially right now, so in Apiro

605
00:57:47.960 --> 00:57:54.960
you can see a lot of like
interesting properties about open source packages. Okay,

606
00:57:55.039 --> 00:58:00.559
so I think will you mentioned some
of the most important ones, like

607
00:58:00.760 --> 00:58:07.599
if it's maintained or not maintained.
There are other things as well, but

608
00:58:07.800 --> 00:58:12.239
right now, we just published,
like I think a week ago, like

609
00:58:12.639 --> 00:58:19.320
our research team found a lot of
malicious code in many guitab repositories and some

610
00:58:19.400 --> 00:58:22.239
of the guitub repositories. Like it
made a lot of waves I heard about

611
00:58:22.360 --> 00:58:28.679
some of some of the guitub repositories
are really things that you would like at

612
00:58:28.679 --> 00:58:34.639
first glance. You you wouldn't say
there's something fishy here, right, A

613
00:58:34.639 --> 00:58:44.079
lot of maintainers, it's being maintained
really st regularly. So I think not

614
00:58:44.199 --> 00:58:52.480
to be too cynical, but I
don't think you can trust anything right pully

615
00:58:52.599 --> 00:58:54.599
with you. Actually, I was
just thinking about this, like whatever a

616
00:58:54.599 --> 00:58:59.119
metric you're going to use, just
think about how it's going to be potentially

617
00:58:59.119 --> 00:59:01.360
abused, right, you know,
it's maintainers or updates or issues. You

618
00:59:01.400 --> 00:59:06.880
could easily clone an existing package out
there on GitHub, have the same number

619
00:59:06.920 --> 00:59:09.559
of issues, copy everything one to
one and then make just a small little

620
00:59:09.639 --> 00:59:15.360
malicious change in the package somewhere,
you know, post install, or just

621
00:59:15.519 --> 00:59:19.679
for a production run time and also
publish it to a new get MPM,

622
00:59:19.880 --> 00:59:22.159
you know, wherever, and you
would never tell the difference unless someone actually

623
00:59:22.239 --> 00:59:25.480
investigated that source code. So those
sorts of heuristics and may not even be

624
00:59:25.559 --> 00:59:31.360
valuable. Yeah, yeah for sure. But you know, the same way

625
00:59:31.519 --> 00:59:38.320
is it's hard to get like a
good grasp over forty thousand repositories in your

626
00:59:38.400 --> 00:59:44.920
organization. Yeah, which there's not
a lot of eyes going through that code

627
00:59:44.960 --> 00:59:50.559
base, but in like let's say
React, JS and Internet there's a lot

628
00:59:50.559 --> 00:59:57.280
of people like going through. But
even that repository is really large, and

629
00:59:57.599 --> 01:00:05.440
there are dark places within that repository
that people like for years didn't pay attention

630
01:00:05.559 --> 01:00:13.239
to. So when you get big
data, it's really like it's easier to

631
01:00:12.599 --> 01:00:20.440
to to hide in plain sight sometimes
then if there's a two file repository and

632
01:00:20.679 --> 01:00:24.880
to take hold of that, so
you really need the tools the machines to

633
01:00:25.760 --> 01:00:30.000
do the work for you. No, I mean that that actually gives me

634
01:00:30.039 --> 01:00:32.239
some flashbacks to I think it was
a few years ago there was a bunch

635
01:00:32.280 --> 01:00:40.519
of academic centers that were intentionally making
malicious changes to like Linux Foundation source code

636
01:00:40.719 --> 01:00:45.119
for the kernel as well as other
things just to prove that you could get

637
01:00:45.199 --> 01:00:52.440
malicious code into an open source project
under all pretenses and so like that's pretty

638
01:00:52.519 --> 01:00:57.519
ridiculous. Yeah, yeah, I
remember that. That was kind of wild.

639
01:00:58.079 --> 01:01:01.159
Yeah, So nothing not things off
the table when it comes to where

640
01:01:01.159 --> 01:01:04.440
problems could be. And you know, if you look at the lots of

641
01:01:04.559 --> 01:01:07.800
issues that show up in public repositories, like they're not necessarily people that know,

642
01:01:08.159 --> 01:01:12.440
you know, fundamentally every single aspect
that's going on there, Uh,

643
01:01:12.679 --> 01:01:15.519
poll requests that get opened are you
know you don't. No one has full

644
01:01:15.679 --> 01:01:20.159
understanding of how all the packages interact
with each other, so you know,

645
01:01:20.239 --> 01:01:22.199
who is even able to validate that? I think at this point you pretty

646
01:01:22.239 --> 01:01:25.360
much need to rely on some sort
of tool to do this for you.

647
01:01:30.039 --> 01:01:32.760
Right on. Cool, So I
want to ask both of you this question,

648
01:01:32.840 --> 01:01:39.840
because you both have strong security backgrounds. For someone who's just starting to

649
01:01:39.880 --> 01:01:50.119
put focus on their security footprint,
what's your best piece of advice on where

650
01:01:50.159 --> 01:01:58.159
to start start with? We'll start
with Jonathan. Okay, So, without

651
01:01:58.440 --> 01:02:02.280
qualifying if it's a small company or
a large company or like one developer,

652
01:02:02.679 --> 01:02:08.400
I think the most important thing to
get a grasp on is like inventory,

653
01:02:08.480 --> 01:02:15.760
what I have. I think this
is the fundamental part here. By the

654
01:02:15.760 --> 01:02:19.840
way, as a developer, you
might want to reduce it as much as

655
01:02:19.880 --> 01:02:25.519
you can get rid of what you
don't really need, and in large scales

656
01:02:25.559 --> 01:02:30.960
it's even more important. But knowing
what you have, I think this is

657
01:02:30.000 --> 01:02:36.960
the most fundamental thing to really really
understand before I do anything advanced. Know

658
01:02:37.079 --> 01:02:40.559
what you have and plot twist.
Apiro can help you with that, right,

659
01:02:43.320 --> 01:02:49.920
I wouldn't I wouldn't imagine saying anything
that won't lead you to say that.

660
01:02:52.280 --> 01:02:55.760
All right, Warren, what's your
thoughts? Yeah? I mean I

661
01:02:55.800 --> 01:03:00.760
think actually Anton mentioned this earlier and
I know I've become a broken record for

662
01:03:00.800 --> 01:03:06.000
this, but it's start with your
threat model. If you build or approach

663
01:03:06.039 --> 01:03:09.079
any problem without first thinking about why
you're doing it, not only can you

664
01:03:09.320 --> 01:03:13.719
what you're doing isn't going to nessly
be useful or relevant. It can even

665
01:03:13.719 --> 01:03:17.239
be harmful as far as your overall
approach goes. So you know concretely what

666
01:03:17.280 --> 01:03:20.679
like, what do we need to
do, why are we doing it?

667
01:03:20.920 --> 01:03:23.880
And then start looking at okay,
what are our options for implementing solutions?

668
01:03:23.920 --> 01:03:28.719
Because otherwise, I mean, you'll
end up with the six thousand dependent on

669
01:03:29.119 --> 01:03:32.000
alerts and not knowing what to do, and the result may be developing your

670
01:03:32.039 --> 01:03:37.920
own platform that automatically increments, you
know, package versions, versus knowing that,

671
01:03:37.960 --> 01:03:42.519
hey, we're getting lots of spam
on our endpoints in the form of

672
01:03:42.719 --> 01:03:46.400
WP dash admin and we're not running
any PHP stuff. You know, it's

673
01:03:46.400 --> 01:03:52.719
not a DUS attack, but it's
someone's looking for an exposed WordPress instance or

674
01:03:52.079 --> 01:03:57.719
Mango dB or elastic search, and
if you've got that exposed, then you're

675
01:03:57.719 --> 01:04:00.840
going to have a problem. So, as Youzon said, the the inventory

676
01:04:00.880 --> 01:04:03.599
of what your services are and how
they're exposed to the Internet is equally valuable

677
01:04:03.639 --> 01:04:15.039
for sure, right on excellent.
Any any other closing or parting thoughts on

678
01:04:15.119 --> 01:04:23.559
security before we move on to picks, I'd say, alluding to a previous

679
01:04:23.559 --> 01:04:28.519
point that you made before, that
security is a feature and and uh,

680
01:04:28.800 --> 01:04:32.639
if if you do the right thing, then then people will appreciate it.

681
01:04:33.039 --> 01:04:36.360
If it's sometimes even more than doing
the features. No, I mean,

682
01:04:36.400 --> 01:04:40.960
I love that approach actually, because
often people see it as the like a

683
01:04:40.960 --> 01:04:45.039
cost center to prevent something and the
best case scenario is that you nothing happens,

684
01:04:45.559 --> 01:04:47.079
and so the ROI you know,
is a hard justifier, But I

685
01:04:47.119 --> 01:04:53.320
think the missing part there is that
actually the way you've implemented security has a

686
01:04:53.360 --> 01:04:58.239
lot of value that for your product, for your end users, potentially a

687
01:04:58.440 --> 01:05:02.400
better experience with s oh and log
in is it is it defining factor for

688
01:05:02.800 --> 01:05:09.039
companies, especially enterprises, who want
to be secure likewise goes having the latest

689
01:05:09.079 --> 01:05:14.119
functions and features from your dependencies,
being able to utilize them and not be

690
01:05:14.119 --> 01:05:17.320
stuck on legacy versions for fear of
a security issue that just on my gets

691
01:05:17.320 --> 01:05:20.920
pulled in. Like using a platform
like a bureau you know, helps you

692
01:05:20.960 --> 01:05:26.440
get that, helps you achieve that
without getting stuck in in fear land or

693
01:05:26.719 --> 01:05:31.159
dedicating your resources in an area that's
not your core competency. Yeah. I

694
01:05:31.159 --> 01:05:40.400
think that's like one of the common
things that I see with teams or departments

695
01:05:40.400 --> 01:05:46.159
that are traditionally seen as cost centers
is changing that perspective that you're not a

696
01:05:46.199 --> 01:05:50.280
cost center, you're just bad at
marketing, you know, because there's like

697
01:05:50.280 --> 01:05:55.599
it there is like it's everything comes
down to politics at some form or another,

698
01:05:56.159 --> 01:06:00.119
and so part of getting your team
to not be is a cost center

699
01:06:00.440 --> 01:06:06.840
is by marketing your team and showing
hey, this is these are the security

700
01:06:06.920 --> 01:06:11.679
vulnerabilities that we closed down that we
were exposed to? Or from a DevOps

701
01:06:11.719 --> 01:06:16.039
perspective, hey, here's how implementing
this platform allowed the engineering teams to go

702
01:06:16.119 --> 01:06:23.760
from fifteen deployments today per day to
fifty deployments per day in a safe and

703
01:06:23.800 --> 01:06:29.960
secure manner. So I think really
learning to market your team helps give you

704
01:06:30.360 --> 01:06:34.559
mind share across the leaders of the
company and brings additional focus. And with

705
01:06:34.639 --> 01:06:39.119
additional focus, you get additional resources. I mean, last time we talked

706
01:06:39.159 --> 01:06:43.639
about product management, and I think
this is closely connected to it. Like,

707
01:06:43.920 --> 01:06:45.119
you know, you can even start
before that, right, Like,

708
01:06:45.320 --> 01:06:48.559
if you're going to be rolling out
features or functionality or a platform to your

709
01:06:48.639 --> 01:06:53.599
organization, what do the other engineering
teams actually think about? You know,

710
01:06:53.679 --> 01:06:57.039
do they care about even being secure? Because if they're not already on that,

711
01:06:57.079 --> 01:07:02.159
then it's the same challenge as marketing
to external customers. You what problems

712
01:07:02.199 --> 01:07:04.679
are they trying to solve? And
if security is not part of it,

713
01:07:04.760 --> 01:07:08.760
then you're really starting with an education
approach, right Like, here are the

714
01:07:08.800 --> 01:07:12.760
sorts of things that could happen because
of how you set up your services and

715
01:07:12.920 --> 01:07:16.480
if the organization hasn't aligned incentives actually
encourage them to be secure. Then it's

716
01:07:16.480 --> 01:07:20.079
going to be an uphill battle wait
for them to get hacked and then go

717
01:07:20.239 --> 01:07:24.840
oh oh okay, so now y'all
are concerned about security. Oh. I

718
01:07:24.840 --> 01:07:29.280
mean there were definitely there were definitely
some suspicious companies out there that were offering

719
01:07:29.320 --> 01:07:32.159
like DEDOS protection and as part of
their actual operation, I mean they were

720
01:07:32.239 --> 01:07:35.320
they were hugely malicious to start out
with, but uh, as part of

721
01:07:35.360 --> 01:07:39.599
their operations they would go out and
actually just dds customers and be like,

722
01:07:39.639 --> 01:07:42.320
hey, you know you got d
dos Because you don't, you're not using

723
01:07:42.320 --> 01:07:45.639
our product. And I mean it's
a little bit suspicious if after our security

724
01:07:45.679 --> 01:07:48.960
incident you immediately get someone showing up
your door saying, you know, hey,

725
01:07:49.000 --> 01:07:55.159
we could help you solve that problem. Though, it's like the mafia

726
01:07:55.280 --> 01:08:00.840
style approach they send and then go
so, hey, it looks like you

727
01:08:00.920 --> 01:08:06.840
need some protection. Right on.
So let's do some picks as we round

728
01:08:06.880 --> 01:08:11.800
this episode out, Warren, I've
been picking on you, so I won't

729
01:08:11.840 --> 01:08:15.760
pick on you this episode. I'll
actually start it off, and much to

730
01:08:15.960 --> 01:08:19.520
everyone who's a frequent listener, surprise, my pick this week is going to

731
01:08:19.600 --> 01:08:26.800
be platform con coming up this June
the five day virtual conference on Platform Engineering,

732
01:08:27.399 --> 01:08:31.640
where they will have some folks talking
about security topics too as they relate

733
01:08:31.680 --> 01:08:36.000
to platform engineering. And then my
favorite part of the conference is at the

734
01:08:36.199 --> 01:08:41.680
end, I am going to be
interviewing some of the speakers in a live

735
01:08:41.800 --> 01:08:46.760
Q and a session to close out
the conference. And as I mentioned last

736
01:08:46.800 --> 01:08:49.920
week, if they're specific people you
want me to talk to, or specific

737
01:08:50.000 --> 01:08:54.159
questions you want me to ask,
be sure and hit me up on Twitter

738
01:08:54.840 --> 01:09:00.840
or send me a DM or any
other contact method and I will filter and

739
01:09:00.920 --> 01:09:04.000
aggregate those and get those questions to
ask for you. So platform con dot

740
01:09:04.039 --> 01:09:09.199
com if you want to check that
out, and that's my pick. So

741
01:09:09.960 --> 01:09:12.880
Warren, what have you got?
Yeah, Actually, this is timely.

742
01:09:13.279 --> 01:09:15.720
It's going to be security related.
I just got back from a conference in

743
01:09:15.760 --> 01:09:20.199
Germany last week where I was actually
talking about the security journey we took at

744
01:09:20.239 --> 01:09:24.800
authors and I got asked, you
know, well, how do I get

745
01:09:24.840 --> 01:09:28.880
into security? How do I become
an expert? Is it just the do

746
01:09:28.920 --> 01:09:30.960
I am? I either completely don't
know anything or do I have to know

747
01:09:31.039 --> 01:09:33.960
everything? And the truth is,
you know, you just learn things over

748
01:09:34.039 --> 01:09:38.640
time from different sources and eventually,
one day you get to stand up on

749
01:09:38.680 --> 01:09:42.600
stage and start giving a presentation about
security, even though you believe you don't

750
01:09:42.720 --> 01:09:45.319
really know anything. But I will
say that there are a couple of great

751
01:09:45.359 --> 01:09:50.159
newsletters out there that I read myself. They may be too technical for some

752
01:09:50.319 --> 01:09:56.479
others may be way beneath them,
but I highly recommend the TLDR newsletters.

753
01:09:56.479 --> 01:10:00.720
Specifically, they have one Security and
there's also another one called the cloud Secklist,

754
01:10:00.760 --> 01:10:04.720
which is oriented towards cloud security infrastructure, and they've been great. They

755
01:10:04.800 --> 01:10:09.800
talking touching on a lot of different
topics, and you can go deep with

756
01:10:09.880 --> 01:10:12.439
the links that are in there,
and I can take you a long way,

757
01:10:12.600 --> 01:10:16.239
especially at the beginning of your security
journey. Right on Awesome, how

758
01:10:16.239 --> 01:10:18.520
did you talk? Go by the
way? Well, you know, like

759
01:10:18.640 --> 01:10:21.880
usual, I'm sure I did terrible, but then everyone tells me how great

760
01:10:21.960 --> 01:10:26.239
it went, so I have to
I'll have to watch the video once it

761
01:10:26.279 --> 01:10:30.720
comes out online, which will probably
be posted on the author's blog somewhere Right

762
01:10:30.760 --> 01:10:36.000
on awesome. All right, Johnathan, what you got for us for picks?

763
01:10:36.680 --> 01:10:43.399
Okay? So I had something else, But Warren, I think I

764
01:10:43.439 --> 01:10:48.720
can maybe connect to what you what
you said because something that I feared for

765
01:10:48.760 --> 01:10:55.439
a long time happened at my family
yesterday, where my son was a twelve

766
01:10:55.520 --> 01:11:01.199
year old came to me and said, Dad, I managed to hack the

767
01:11:01.600 --> 01:11:10.520
Google Dinosaur game and and made it
such that I can never lose. It's

768
01:11:10.520 --> 01:11:15.720
not that advanced. It's I think
it came to him through YouTube or Instagram

769
01:11:15.800 --> 01:11:20.039
or something like that where you just
override the game over function or something like

770
01:11:20.119 --> 01:11:26.319
that. She's really nice. Uh
so, so it came to me as

771
01:11:26.359 --> 01:11:32.079
a shock, but uh it got
me thinking and and I like alluding to

772
01:11:32.560 --> 01:11:36.800
when you said how to start in
the security business. Maybe uh so.

773
01:11:38.359 --> 01:11:43.680
I think my piak is is when
it comes to kids, maybe uh start,

774
01:11:43.800 --> 01:11:47.640
start from the fundamentals, not not. It might be cool to show

775
01:11:47.680 --> 01:11:55.199
your friends in class that you can
hack a game, but I I since

776
01:11:55.239 --> 01:12:00.920
then, I since I tried to
show him the fundamentals. What goes on

777
01:12:00.960 --> 01:12:05.239
there? What does it mean a
function? What does it mean to change

778
01:12:05.279 --> 01:12:10.720
it in run time? Like,
uh, maybe you should prevent that maybe

779
01:12:10.760 --> 01:12:15.399
not like like really have him understand
what goes on there. I think it's

780
01:12:15.560 --> 01:12:24.960
really important for kids that can see
YouTube or whatever TikTok, they're they're seeing

781
01:12:25.000 --> 01:12:29.479
really advanced things in life, not
only in security or coding, but they're

782
01:12:29.640 --> 01:12:33.880
really pushed to go fast and like
having them understand the fundamentals, understand for

783
01:12:33.880 --> 01:12:40.439
for a non native English speaker,
understand English, understand math, understand the

784
01:12:40.640 --> 01:12:45.640
like the concept, and then go
and hack the Pentagon or No, we're

785
01:12:45.680 --> 01:12:51.319
not recommending that anyone does anything.
I do not condone that sort of no.

786
01:12:51.399 --> 01:12:55.840
But that's a really great point actually, because there's security is so vague

787
01:12:55.880 --> 01:13:00.960
as an individual idea that really defining
for yourself what it even means to go

788
01:13:00.039 --> 01:13:04.199
into security, right, Like are
you interested in hacking things or even depending

789
01:13:04.239 --> 01:13:06.600
against attacks, which I think,
you know, we talked a lot about

790
01:13:06.600 --> 01:13:11.800
here, but or our products that
help you build up tools and whatnot.

791
01:13:11.880 --> 01:13:14.760
You know, these are all different, fundamentally different areas for sure. Yeah,

792
01:13:14.840 --> 01:13:18.239
And I think there's like just going
beyond that. I think there's huge

793
01:13:19.079 --> 01:13:26.000
understated value in just having a basic
understanding of how code works in a modern

794
01:13:26.039 --> 01:13:30.920
technology life that we live in now, because once you understand what's going on

795
01:13:31.359 --> 01:13:36.520
under the hood, I think you
get a lot of perspective in how you

796
01:13:36.600 --> 01:13:41.800
interact with different companies, you know, whether it's through their website or their

797
01:13:41.800 --> 01:13:45.399
application or their call center or whatever. Like. If you have that basic

798
01:13:45.479 --> 01:13:49.640
fundamental understanding, I think you start
to approach problems differently, even if you're

799
01:13:49.640 --> 01:13:55.199
not in a technical role. I
think when you're talking to a sales rep

800
01:13:55.239 --> 01:13:59.239
of a customer support agent of a
company and you get an error on your

801
01:13:59.239 --> 01:14:01.720
screen, that's as like you know, on unhandled exception, and you're trying

802
01:14:01.720 --> 01:14:11.199
to explain to them how their website
is broken, right exactly, all right?

803
01:14:11.359 --> 01:14:13.880
Cool, Jonathan, Thank you so
much for being on the show.

804
01:14:13.920 --> 01:14:17.079
This has been incredibly insightful, so
I really appreciate you taking the time to

805
01:14:17.159 --> 01:14:21.760
join us. Yeah, thank you
so much for inviting me. Yeah.

806
01:14:21.840 --> 01:14:25.359
Yeah. Happy to have you back
on at any point, so let us

807
01:14:25.359 --> 01:14:29.560
know if that's of interest to you. Qaarren, thank you again for joining

808
01:14:29.560 --> 01:14:33.479
me here and co host to miss
with me, and to all the listeners,

809
01:14:33.560 --> 01:14:36.640
thank y'all for listening. Love having
y'all out there, and we will

810
01:14:36.680 --> 01:14:38.680
see y'all next week.