1
00:00:00,000 --> 00:00:03,480
Welcome to another episode of the Cloud Native in 15 Minutes podcast.

2
00:00:04,260 --> 00:00:06,760
If you haven't listened before, the goal of the podcast is simple,

3
00:00:07,240 --> 00:00:11,580
to explain some complex but increasingly important and even strategic technologies

4
00:00:11,580 --> 00:00:15,780
and about the time it takes for a coffee break or a short commute or a walk or

5
00:00:15,780 --> 00:00:17,940
whatever it is you do to kill 15 or 20 minutes.

6
00:00:18,680 --> 00:00:24,860
So I'm Derek Harris from Pivotal and our guest today or my guest today is Guy Pajarni.

7
00:00:24,860 --> 00:00:30,800
Guy is the co-founder and president of a security startup called Sneak, S-N-Y-K,

8
00:00:31,240 --> 00:00:33,400
and host of the Secure Developer Podcast.

9
00:00:34,060 --> 00:00:39,900
And so in this episode, we talk all about security in the age of containers and open source

10
00:00:39,900 --> 00:00:41,600
and CICD and microservices.

11
00:00:41,780 --> 00:00:47,840
Guy talks about some of what Sneak does, but also just generally what good security hygiene

12
00:00:47,840 --> 00:00:52,080
and organization looks like within a company, whether it's what some people call DevSecOps

13
00:00:52,080 --> 00:00:59,520
or whether it's taking an SRE type approach to security and just kind of how that responsibility

14
00:00:59,520 --> 00:01:03,460
is split between developers and operations and security folks.

15
00:01:03,680 --> 00:01:08,020
And we talk about keeping up with the scale of containers you're running.

16
00:01:08,120 --> 00:01:13,820
If you're running 20 container images to one VM or one physical server in the monolithic world,

17
00:01:13,960 --> 00:01:21,400
I think it's a really insightful conversation on how it is that an organization and enterprise

18
00:01:21,400 --> 00:01:26,800
can try to keep up with not just new vulnerabilities, but really just get their security hygiene in place

19
00:01:26,800 --> 00:01:28,780
as the scale and speed of everything they're doing.

20
00:01:29,280 --> 00:01:32,900
And then their software development just keeps on increasing.

21
00:01:33,140 --> 00:01:34,120
So I think you should listen.

22
00:01:34,560 --> 00:01:39,900
And also, before we get into the interview, just a quick reminder, please subscribe to the podcast

23
00:01:39,900 --> 00:01:43,900
on Apple Podcasts or Spotify or Google Podcasts, wherever it is you listen.

24
00:01:44,140 --> 00:01:45,660
That's always a big help.

25
00:01:45,720 --> 00:01:51,560
And if you'd like to give it a rating on Apple Podcasts especially, please feel free to do so.

26
00:01:52,160 --> 00:01:55,600
And with that, here is Guy Pajarni of Sneak.

27
00:01:57,060 --> 00:01:58,920
Okay, Guy, so thanks for being on.

28
00:01:59,220 --> 00:02:05,000
To start, can you explain in about 30 seconds what Sneak does and why you think it's so necessary today?

29
00:02:05,740 --> 00:02:06,380
For sure.

30
00:02:06,600 --> 00:02:10,140
So Sneak is a developer tooling company that does security.

31
00:02:10,420 --> 00:02:14,180
So really, we try to think about security problems from a developer perspective

32
00:02:14,180 --> 00:02:20,480
because as the world, as software eats the world, everything's security is becoming software security.

33
00:02:20,480 --> 00:02:23,160
And we think that that's the domain of developers, really.

34
00:02:24,020 --> 00:02:27,360
That's the only way to scale security is to get developers to embrace it.

35
00:02:27,480 --> 00:02:31,160
We focus on open source security and container security.

36
00:02:31,740 --> 00:02:38,480
And we find and fix vulnerabilities in these open source components and container images

37
00:02:38,480 --> 00:02:44,440
in a way that is kind of continuous and elegant and embeds into your dev process without slowing you down.

38
00:02:45,500 --> 00:02:45,980
All right, cool.

39
00:02:46,380 --> 00:02:50,200
And at least from a software perspective, right, in the world that Sneak plays,

40
00:02:50,200 --> 00:02:53,480
how do you think security has changed over the past, I don't know, 10 to 15 years?

41
00:02:53,660 --> 00:02:55,560
And like, has open source been a big part of that?

42
00:02:56,280 --> 00:03:00,320
Yeah, I think, you know, open source is a component of DevOps, if you will,

43
00:03:00,380 --> 00:03:08,340
and a whole stack of changes that really transformed the way software is developed, developed faster.

44
00:03:08,700 --> 00:03:11,640
You know, software just sort of gets written and gets deployed.

45
00:03:11,780 --> 00:03:15,700
The path from writing a line of code to deploying it is much, much faster.

46
00:03:16,240 --> 00:03:18,200
And it is continuous, right?

47
00:03:18,200 --> 00:03:19,200
It doesn't stop.

48
00:03:19,200 --> 00:03:25,820
It's, you know, from CICD to a myriad of other technologies, including, you know, open source components and including containers.

49
00:03:26,340 --> 00:03:27,700
It just became continuous.

50
00:03:27,920 --> 00:03:35,000
And that really kind of rocks the boat for security because security's natural motion has been to work through gates, right?

51
00:03:35,020 --> 00:03:36,600
It's you stop here and you will audit.

52
00:03:37,540 --> 00:03:46,580
And so as software becomes fluid, right, becomes continuous, the opportunity to do those stops and to audit goes away.

53
00:03:46,580 --> 00:03:58,240
And that forces, that changes the world of security to need to embed itself more into the pipelines, into that continuous process, as that's really its opportunity.

54
00:03:59,040 --> 00:04:07,300
And so that creates, you know, a set of opportunities around, you know, policy enforcement and automated policy enforcement, but it's also hard.

55
00:04:07,400 --> 00:04:15,680
A lot of security tools don't work quickly enough, easily enough, self-serve enough to really fit into these environments.

56
00:04:16,000 --> 00:04:17,700
So they need to adapt.

57
00:04:17,800 --> 00:04:18,520
They need to change.

58
00:04:18,640 --> 00:04:20,420
You know, some do it more successfully than others.

59
00:04:20,840 --> 00:04:29,940
And then subsequently, that pace, that change in development pace, also means that there's no delay.

60
00:04:30,520 --> 00:04:35,420
And the security team, which is typically outnumbered, you know, 50 to 1, 100 to 1, can't keep up.

61
00:04:35,620 --> 00:04:45,660
So you need not only to move those tools to be embedded into the pipeline, you also need a lot of their operation, a lot of their daily use to move to be done by developers.

62
00:04:46,220 --> 00:04:51,440
So that's the DevSecOps, if you kind of choose a buzzword, you know, transition.

63
00:04:52,080 --> 00:05:00,500
And that's a change that very much impacts developers around the need to sort of embrace more responsibility, but also impact the security world.

64
00:05:00,500 --> 00:05:16,460
As, you know, they need to sort of shift how they handle it to be more of a, more like an SRE, like a reliability engineer or, you know, a guiding entity, but expect more of the operation to be done by the developers.

65
00:05:16,920 --> 00:05:22,740
So, yeah, all I would say, like pretty, pretty substantial changes that are, they're not in the last 10 to 15 years.

66
00:05:22,840 --> 00:05:24,800
They're very much kind of playing out right now.

67
00:05:25,400 --> 00:05:25,980
All right.

68
00:05:26,760 --> 00:05:34,040
And I mean, so you definitely touched on this, but I wanted to ask, you know, just kind of expressly, I mean, so, so open source, you know, being a big part of what you do, but how have these other things, right?

69
00:05:34,040 --> 00:05:40,880
You mentioned containers, but, you know, the idea of microservices architectures and cloud and, and, you know, software as a service, everything.

70
00:05:41,080 --> 00:05:41,920
I'm sorry, big bang there.

71
00:05:42,100 --> 00:05:52,580
Sorry, everything, you know, like all the, how have all these shifts and all these new kinds of prac architectures and tooling and stuff changed the way that that enterprises have to think about security?

72
00:05:52,580 --> 00:05:58,840
Yeah, so what they, what these different tools, what these different platforms do is they enable speed, right?

73
00:05:58,860 --> 00:06:08,000
Like fundamentally, you know, DevOps and all of those technologies that underline it are, are all about a faster time to value, right?

74
00:06:08,060 --> 00:06:20,020
Faster time from indeed a line of code being written to, to a customer or user being able to use it, a faster time to adapt to a new marketing, a new market need, a new customer need.

75
00:06:20,020 --> 00:06:22,800
So it's really all about, all about speed.

76
00:06:23,440 --> 00:06:31,980
And really, when I, when I think about, about this transition to, to, to DevOps, to security, you can think about it in, in three levels.

77
00:06:31,980 --> 00:06:34,020
You can think about DevOps technologies.

78
00:06:34,700 --> 00:06:40,340
And, you know, these are indeed the ones you mentioned, microservice, actually like less microservices, more of the cloud, the containers.

79
00:06:40,340 --> 00:06:47,100
And then you have DevOps methodologies like microservices or, or the continuous processes, the CICD.

80
00:06:48,040 --> 00:06:55,100
And both of those are very important in terms of, of their sort of impact on how you do security.

81
00:06:55,200 --> 00:07:01,820
You have to change your security to tackle, you know, these new technologies and to tackle these new methodologies.

82
00:07:01,820 --> 00:07:04,000
Because both of those accelerate development.

83
00:07:04,600 --> 00:07:09,940
But more than anything, it really kind of goes back to the DevOps shared ownership mindset.

84
00:07:10,840 --> 00:07:17,220
Because really these, so these methodologies, you know, microservices and CICD are a means to an end, right?

85
00:07:17,280 --> 00:07:27,100
They're a, they're a, they're a mechanism to allow small developers teams, development teams to take ownership and go through the pipeline and, and take on ops responsibility.

86
00:07:27,300 --> 00:07:29,980
And security basically needs to be embedded into that.

87
00:07:29,980 --> 00:07:38,400
So, so definitely these technologies and methodologies matter and they impact and they contribute to the acceleration of development.

88
00:07:39,200 --> 00:07:42,260
But I think sometimes it's wrong to think of them as the source.

89
00:07:42,360 --> 00:07:49,020
It's not that they contribute to it, it's the DevOps shared ownership mindset that drove the evolution, right?

90
00:07:49,060 --> 00:07:54,320
And the adoption of these technologies and methodologies, which in turn create the security need.

91
00:07:54,600 --> 00:07:55,580
I hope that makes sense.

92
00:07:56,140 --> 00:07:56,620
Yeah, definitely.

93
00:07:56,620 --> 00:08:03,580
So, so it sounds like what you're saying, and correct me if I'm wrong here, is it's, yeah, it's not like, because some people argue open source, for example, is more secure for various reasons, right?

94
00:08:03,600 --> 00:08:06,840
It's not like that is inherently a vulnerability, right?

95
00:08:06,920 --> 00:08:14,860
But like, so it sounds like we were saying is, you know, maybe it's, maybe it's just the, the pace of things, the scale of the number of components, the scale of everything, right?

96
00:08:14,920 --> 00:08:27,680
That's, it sounds like that, and maybe even some more obfuscation in terms of what's being used, whereas you're embedding components inside containers, you're, you're, you know, you're building applications that are comprised of, you know, various different services and whatnot.

97
00:08:27,680 --> 00:08:36,000
I mean, is that kind of like the, we're saying, the, all the tech, the technological stuff, some of it just like picks, ramps up what's expected.

98
00:08:36,760 --> 00:08:37,040
Yeah.

99
00:08:37,180 --> 00:08:37,700
It kind of makes.

100
00:08:38,140 --> 00:08:38,300
Yeah.

101
00:08:38,420 --> 00:08:39,200
So I, I agree.

102
00:08:39,280 --> 00:08:41,540
I think that's, that's, that's, that's a, that's a good statement.

103
00:08:41,640 --> 00:08:47,460
Definitely open source is not less secure, nor more secure than, than closed source code.

104
00:08:48,120 --> 00:08:52,240
And, and it's not, you know, nor is, you know, a DevOps methodology, right?

105
00:08:52,240 --> 00:08:56,460
Or a continuous pipeline more or less secure, you know, than a different approach.

106
00:08:56,780 --> 00:08:58,400
They just have different properties.

107
00:08:58,840 --> 00:09:02,340
Specifically, specifically, I do come back to people.

108
00:09:02,680 --> 00:09:05,720
So when you think about open source, for instance, it does two things.

109
00:09:05,780 --> 00:09:07,660
One is, is prevalence.

110
00:09:08,180 --> 00:09:15,980
So because open source is there, because you don't want to reinvent the wheel, then you go off, you have a piece of code that is very, very useful, and everybody embraces it.

111
00:09:15,980 --> 00:09:25,000
So it's not that that piece of code, OpenSSL or Bash or, you know, the Docker engine or whatever it is, is, is more or less secure.

112
00:09:25,220 --> 00:09:30,260
It's just that it's amazingly prevalent, you know, just far more so than any commercial software.

113
00:09:30,260 --> 00:09:37,960
So when a vulnerability does get found in one of those components, it has a whole world of victims available to it.

114
00:09:38,020 --> 00:09:47,300
So its implication on, on the entire internet ecosystem could be seismic, could be far more substantial than, than commercial software.

115
00:09:47,780 --> 00:09:53,120
So in that sense, open source is not more or less secure, but its security is more important.

116
00:09:53,120 --> 00:09:59,340
The likelihood of an attacker exploiting a vulnerability in an open source component is just higher.

117
00:09:59,620 --> 00:10:09,120
And you can kind of make the argument that a cloud application versus one that is just sort of hidden in the data center, if it is more exposed to the world, it provides more value, but it also increases its attack surface.

118
00:10:09,540 --> 00:10:16,500
So that's one aspect, but the other, maybe a very people oriented aspect of open source is one of ownership, right?

119
00:10:16,560 --> 00:10:25,300
And it has to do with, with the fact that an organization that uses open source is getting a piece of value for free.

120
00:10:26,180 --> 00:10:31,500
But they're downloading it from the internet, and their use of it is at their responsibility.

121
00:10:32,000 --> 00:10:34,840
So organizations need to, need to build a new muscle, right?

122
00:10:34,860 --> 00:10:45,780
They need to understand how do they, how do they use this software that they did not write and take ownership of securing it, even though it's, it's not their developers that wrote it.

123
00:10:46,080 --> 00:10:52,260
And that's, you know, I think that's a very substantial change to how, how companies think about managing their software.

124
00:10:53,040 --> 00:10:57,820
And, and frankly, kind of an area where I think solutions like Snicker, that's the notion, right?

125
00:10:57,820 --> 00:11:07,840
You need a new tooling ecosystem, whether it itself is open source or commercial, to allow you to just cope with this new world of ownership that you have to have around securing your open source components.

126
00:11:08,540 --> 00:11:09,460
All right. Yeah, that makes a lot of sense.

127
00:11:09,460 --> 00:11:17,700
And I think, you know, if anyone's listening and isn't aware, right, I mean, the Equifax breach a couple years ago was famously an unsecured, unpatched open source.

128
00:11:17,800 --> 00:11:19,280
Yeah, absolutely. Absolutely.

129
00:11:19,460 --> 00:11:36,320
And I think, so for open source security, you know, Equifax was kind of the poster boy, you know, so the poster child of, you know, a Java vulnerability, you know, a Java struts vulnerability that wasn't sophisticated, wasn't fancy, was very severe, and was very prevalent, that was discovered and tripped up Equifax.

130
00:11:36,320 --> 00:11:46,960
So it's really about, you know, and that resulted in the cascading kind of a breach, and they've had a whole bunch of other security mistakes, but the linchpin, sort of the core of it was this vulnerable, unpatched Java library.

131
00:11:47,420 --> 00:12:03,160
If you look at the Capital One case right now, more recently, the Capital One breach, where it was a configuration mistake, from all we can tell, you know, and again, not a fancy configuration mistake, just, you know, overly permissive access control.

132
00:12:03,580 --> 00:12:08,880
All of those things are, they're not about, you know, a super sophisticated tool.

133
00:12:09,080 --> 00:12:13,420
They're about usability, they're about security hygiene at scale, right?

134
00:12:13,480 --> 00:12:21,820
They're about developers operating it at speed, without slowing down, and just owning, you know, owning all of those changes as an organization.

135
00:12:22,420 --> 00:12:25,860
Yeah, definitely. I think the, like you said, the at scale part, I think is key.

136
00:12:26,260 --> 00:12:33,860
Yeah, absolutely. Each of them, securing, exactly. Securing a server or a library is easy. Securing 10,000 of them or a million of them, that gets hard.

137
00:12:34,360 --> 00:12:48,360
Right. Are there things happening right now that you see opening, you know, new, that are kind of new avenues for vulnerabilities or new challenges to doing this aside from just, you know, aside from some of the stuff we talked about, if I looked at, you know, serverless or functions, right?

138
00:12:48,360 --> 00:12:57,540
Or are there other things that are kind of coming around that, that might, that people aren't thinking about that, that could, that shift this or make it even more difficult to, to manage?

139
00:12:57,540 --> 00:13:06,140
I think, so every new technology introduces some elements of risks, but I don't think that those are the, the, the primary ones, right?

140
00:13:06,160 --> 00:13:21,680
If you look at, at serverless, there is a certain risk around, you know, the fact that people assume that serverless are, are immutable, that you run, that an instance gets spun up every time a function call is invoked, and then runs and then gets killed.

141
00:13:21,680 --> 00:13:27,320
When in fact, that's not correct, you know, oftentimes, probably practically all frameworks will keep an instance warm.

142
00:13:27,460 --> 00:13:32,400
So the next function invocation might run in an environment where the previous one ran.

143
00:13:33,060 --> 00:13:43,680
And therefore, if you left any sensitive data on the server, that might leak, you know, and due to another security flaw, you know, similarly with containers, you talk about sandbox escaping and breaking them out.

144
00:13:43,680 --> 00:13:47,900
So they do introduce some security risks, but I don't think those are the primary ones.

145
00:13:49,080 --> 00:13:53,820
The, the, the primary security challenge comes back to that element of scale.

146
00:13:54,280 --> 00:14:05,880
So it comes back in serverless to, again, vulnerable libraries or, or access to data, but doing that across, you know, just a sprawling and fast moving set of functions that anybody can deploy.

147
00:14:06,640 --> 00:14:16,980
So really, really, really what I would say is that all of those technologies, while you should care about their, their new introduced security risk, you really mostly, mostly should think about them at scale.

148
00:14:17,120 --> 00:14:23,180
And to think about, you know, how do you replicate that within also your existing staffing constraints?

149
00:14:23,680 --> 00:14:24,220
All right.

150
00:14:25,540 --> 00:14:25,860
Yeah.

151
00:14:25,860 --> 00:14:28,860
Well, I want to get to that, but you might, I mean, we haven't talked too much about containers.

152
00:14:29,120 --> 00:14:47,200
The one thing I do want to ask specifically about containers is, and to the scale question is, do you have a sense of, like, when you look at your customers, the number of, you know, if you're saying like, okay, you know, maybe in the, in the physical or VM world, you know, they were running this number of, I mean, not that it's a one-to-one comparison, right?

153
00:14:47,200 --> 00:14:48,860
But they're trying to manage this number of things.

154
00:14:48,960 --> 00:14:53,460
Now the container world they're managing, like, do you have a sense of what that scale difference is in terms of volume?

155
00:14:54,360 --> 00:14:54,480
Yeah.

156
00:14:54,500 --> 00:15:05,740
I think the number of, of images is oftentimes roughly 10 to one, sometimes even more like 50 to one as companies go from the monolith mindsets to the microservices.

157
00:15:06,040 --> 00:15:08,620
So typically it would only do that transition if you're 10 to one.

158
00:15:08,660 --> 00:15:15,440
And oftentimes you see as the evolution comes along, there might be 50 microservices and every microservice is kind of its own image, right?

159
00:15:15,440 --> 00:15:18,860
So it's kind of its own kind of a flavor type of a server that gets deployed.

160
00:15:19,360 --> 00:15:33,300
In terms of running instances, it's actually even far greater because in the, in the VM world, it still tends to be, even when you're elastic on the clouds and things like that, you still tend to use your servers for a longer period of time to beef them up.

161
00:15:33,340 --> 00:15:37,520
While the containers tend to be very purpose-built, much more elastically scaling.

162
00:15:37,720 --> 00:15:39,560
So they get spun up, they get spun down.

163
00:15:39,980 --> 00:15:48,180
So there it's not uncommon to see a hundred to one or 500 to one ratios in terms of how many, how many virtual machines, if you will, right?

164
00:15:48,220 --> 00:15:53,540
If you call it a container machine that's running an instance, a virtual machine that run.

165
00:15:53,840 --> 00:15:59,540
So it's definitely at least one and sometimes two or more orders of magnitude, more different machines.

166
00:15:59,600 --> 00:16:03,040
And it was already hard to deal with a number of VMs when we went to the cloud.

167
00:16:03,260 --> 00:16:06,200
So it's not like this was built on, on stable foundation.

168
00:16:06,880 --> 00:16:07,000
Right.

169
00:16:07,140 --> 00:16:07,440
Okay.

170
00:16:07,960 --> 00:16:08,940
And, and get, yeah.

171
00:16:08,960 --> 00:16:17,220
So getting back to the, the, the people part of it, I mean, where do you, in the organizational part, where do you think, or, you know, where should this security responsibility lie within an organization?

172
00:16:17,220 --> 00:16:25,780
I mean, we, you know, we talk about baking it everywhere, but like, I think the question is how much can, can you, can you rely on developers or should, you know, should developers have to be security experts?

173
00:16:25,860 --> 00:16:25,960
Right.

174
00:16:25,960 --> 00:16:30,100
So like, where do you, how, how do you see a modern security organization looking?

175
00:16:30,900 --> 00:16:31,140
Yeah.

176
00:16:31,200 --> 00:16:32,860
So I think, I think that's a great question.

177
00:16:32,860 --> 00:16:38,300
And I think a lot of, a lot of security organizations are, are shifting or changing the way they work.

178
00:16:38,300 --> 00:16:45,580
I find the best analogy is really the sort of system reliability engineers or DevOps automation type teams that got created.

179
00:16:46,080 --> 00:17:01,500
So what you want is you want an end state in which the security team sees themselves as a, is a governing organization that is responsible to, to being experts in the field and knowing what's right and bringing in tooling and automation and putting them in place.

180
00:17:01,500 --> 00:17:04,660
To help developers do the daily job.

181
00:17:05,320 --> 00:17:19,680
So, you know, when you think about DevOps, you think about a developer, you know, needing to use build and needing to, you know, log activities that they do and being on call and being responsible when, when one of the systems that they operate go down.

182
00:17:19,800 --> 00:17:24,500
But you expect the system reliability engineer to understand what it means to do high availability.

183
00:17:25,020 --> 00:17:32,960
You expect them to be, to, to put in place good tooling around, you know, indeed log aggregation and around dashboards and alerts.

184
00:17:32,960 --> 00:17:35,080
And, and then the developers are the users of it.

185
00:17:35,080 --> 00:17:44,180
So the same, the same flow, the same guidance should happen here in the security teams, which is the security teams need to be more service providers and guiders.

186
00:17:44,180 --> 00:17:58,300
And you see security teams in the likes of, if I give a shout out to like Auth0 or Segment or really a variety or one medical, a lot of them are shifting there.

187
00:17:58,380 --> 00:18:15,540
So they're hiring more engineers into the security team and those, those people build, sometimes literally they operate microservices to run it, but otherwise they think about building automations into the pipelines, building technology to make it easier for developers to do it.

188
00:18:15,540 --> 00:18:17,920
And then the developers, they need to adopt it.

189
00:18:17,920 --> 00:18:19,320
They need to accept the responsibility.

190
00:18:19,900 --> 00:18:22,440
And that's really the, the chase, right?

191
00:18:22,460 --> 00:18:30,600
And it's not an, unlike a very different chase to the one that is happening in the, in the world of reliability and safety.

192
00:18:30,600 --> 00:18:41,060
So a lot of, of similar lines and, and I guess, I don't know what the name is, but we're looking for like that security SRE type role as we evolve.

193
00:18:41,400 --> 00:18:44,380
I like that better than DevSecOps security SRE.

194
00:18:44,880 --> 00:18:47,540
DevSecOps is a tricky, it's a really, really tricky word.

195
00:18:47,680 --> 00:18:54,220
You know, it's a, you know, it's DevEverythingOps, but, but, but it is about security kind of coming into the fold of, of the DevOps movement.

196
00:18:54,300 --> 00:18:54,560
All right.

197
00:18:54,740 --> 00:18:58,900
And then finally, Guy, I think you answered this question, but I mean, I'm just going to answer this correctly.

198
00:18:58,900 --> 00:19:06,600
Maybe, you know, if you, if you have something else to add, like, like, like what can organizations, especially large enterprises do to keep secure going forward?

199
00:19:06,660 --> 00:19:08,440
Like, it sounds like organization is a big part of it, right?

200
00:19:08,440 --> 00:19:12,320
Without just kind of, you know, historically, like, like you said, locking down security, right?

201
00:19:12,320 --> 00:19:19,680
And making it a roadblock, but actually, you know, scaling, you know, or keeping secure, you know, keeping that security function fluid as, as everything evolves, right?

202
00:19:19,700 --> 00:19:24,020
Is this organized, as the organizational part, you think automation plus organization, is that kind of the.

203
00:19:24,680 --> 00:19:27,460
Yeah, there's kind of the, the tactics and the strategy.

204
00:19:27,600 --> 00:19:42,640
So I think on the tactical front, I think automation is, is your friend, you know, and you want to find security solutions that you can put into your pipelines, into your developers' hands that automate a lot of that activity, both for efficiency and to make it easy for developers.

205
00:19:42,640 --> 00:19:56,840
You want developer adoption, so you want, you know, you know, developers, there's, there's how much they care, and there's how much effort it is to use a security solution, and it needs to be, they need to care more than it is hard, right?

206
00:19:56,960 --> 00:19:58,860
You know, and then they would mobilize to act.

207
00:19:59,400 --> 00:20:01,640
So I think that's the, that's the low hanging fruit.

208
00:20:01,640 --> 00:20:15,860
That's the immediate thing is around find those, put those together, and focus on security hygiene, focus on vulnerable libraries, on vulnerable container images, on cloud configuration, focus on those elements, because those are the ones that, that can kind of come back and bite you the most.

209
00:20:15,860 --> 00:20:31,360
And then long term, think about your security team's location inside your org, can you affiliate them more with the engineering organization, think about, about the individuals and the competencies inside your security teams and how they're divided, make sure that there's enough.

210
00:20:31,640 --> 00:20:46,960
Understanding and affinity to, to, to, to the software engineering teams and ability to build tools, and to be, be a supporting entity, right, be an entity whose, whose job is not to say no, but rather to make the business and specifically the technology teams thrive.

211
00:20:47,820 --> 00:20:50,980
All right, great. Sounds like a great place to end. Thanks a lot, Guy. I appreciate it.

212
00:20:51,420 --> 00:20:53,120
Well, thanks for having me, Horne. Thanks for the questions.

213
00:20:53,600 --> 00:20:55,220
There you have it. I hope you learned something.

214
00:20:55,640 --> 00:21:01,540
For more information about Snyk, you can visit Snyk, S-N-Y-K dot I-O.

215
00:21:01,740 --> 00:21:09,400
And you can listen to Guy's podcast, the Secure Developer Podcast at, wait for it, thesecuredeveloper.com. Easy enough.

216
00:21:09,900 --> 00:21:15,260
For more information about Pivotal's broad suite of products and services for building and managing cloud-native applications,

217
00:21:15,820 --> 00:21:20,520
as well as, I should note, some of the automation hygiene we talked about in this,

218
00:21:20,520 --> 00:21:26,580
in this podcast around making sure components and stuff are, are up to date and patched in a timely manner.

219
00:21:26,840 --> 00:21:28,740
You can check us out at Pivotal.io.

220
00:21:28,940 --> 00:21:33,940
If you want to know what I think is a really interesting user story, Google Pivotal Wells Fargo.

221
00:21:34,040 --> 00:21:40,720
And you'll, you'll probably, some of the top results will be, uh, uh, some stories about how Wells Fargo is updating and repaving its,

222
00:21:40,820 --> 00:21:43,300
its, its platform on a regular basis.

223
00:21:43,300 --> 00:21:45,380
I think one or one or multiple times a week at this point.

224
00:21:45,380 --> 00:21:51,400
Um, and you know, it's an interesting story about, uh, how you can automate security in this, uh, fast, fast moving world.

225
00:21:51,740 --> 00:21:56,040
Um, and then, anyhow, if you like this podcast and you want to keep up with more content on all things,

226
00:21:56,080 --> 00:22:00,100
let's say digital transformation, but, you know, educational stuff, cloud native, whatever you call it,

227
00:22:00,100 --> 00:22:03,380
without, without too much of a vendor spin, you can check it out.

228
00:22:03,760 --> 00:22:08,180
Check out the home of this podcast, which is Pivotal.io slash intersect.

229
00:22:08,620 --> 00:22:14,080
That's Pivotal.io slash intersect as in the intersection of business and technology.

230
00:22:14,400 --> 00:22:15,620
So thanks for listening.