1
00:00:00,000 --> 00:00:11,720
Welcome to the Talking Security podcast. We will talk about items related to Microsoft

2
00:00:11,720 --> 00:00:14,720
security.

3
00:00:14,720 --> 00:00:25,480
Hello, welcome again at a new Talking Security podcast.

4
00:00:25,480 --> 00:00:26,480
DevSecOps series.

5
00:00:26,480 --> 00:00:32,240
Within the DevSecOps series. This is the second recording. First time we talked about the

6
00:00:32,240 --> 00:00:39,000
developer security workplace, the developer workplace and what we should do from a security

7
00:00:39,000 --> 00:00:47,200
perspective. Today we're talking about complete and other aspect of DevSecOps. So within DevSecOps

8
00:00:47,200 --> 00:00:55,780
there are different aspects that we want to address in the next few recordings. So probably

9
00:00:55,780 --> 00:01:01,440
seven or eight or the next recording we will touch that. Today we are touching the code

10
00:01:01,440 --> 00:01:08,920
base but also security from a developer's perspective. The developer in-house standard.

11
00:01:08,920 --> 00:01:19,160
So what's your view on security within the developer's area?

12
00:01:19,160 --> 00:01:24,440
I think that when you're talking about developers, what we're really good at is writing code

13
00:01:24,440 --> 00:01:29,680
and that's kind of what we're paid to do. And I often see that security from a developer's

14
00:01:29,680 --> 00:01:35,640
standpoint is just not, there's not enough knowledge in a developer to actually do this

15
00:01:35,640 --> 00:01:42,720
sufficiently. I know how to write secure code, validate incoming data, stuff like that. It's

16
00:01:42,720 --> 00:01:46,360
just basic stuff. But when we're actually talking about deploying your applications

17
00:01:46,360 --> 00:01:51,200
to the cloud or scanning for vulnerabilities, all of scanning for vulnerabilities, stuff

18
00:01:51,200 --> 00:01:56,880
like this is something that developers often don't really know. And this is what you need

19
00:01:56,880 --> 00:02:02,720
specialists for, like you guys. And I think that is definitely something that scales nowadays

20
00:02:02,720 --> 00:02:07,240
when you're deploying your code, maybe multiple times per day. When are you actually checking

21
00:02:07,240 --> 00:02:11,660
if your application is secure? You can't just ask some security specialist to check that

22
00:02:11,660 --> 00:02:15,320
once a week. That's maybe not even enough. That's a difficult thing.

23
00:02:15,320 --> 00:02:23,960
And talking from a developer perspective, but DevSecOps, the world changes because you're

24
00:02:23,960 --> 00:02:30,240
developing applications and stuff. But we are doing with Infra, Infra-ASCO, we are also

25
00:02:30,240 --> 00:02:32,360
doing stuff with code.

26
00:02:32,360 --> 00:02:37,920
Yeah, definitely. Yeah. So that's also a big change, I think in the whole developers and

27
00:02:37,920 --> 00:02:43,160
the whole DevSecOps these days is the change that's not only about application, but it's

28
00:02:43,160 --> 00:02:50,120
also our infrastructure, how it will be deployed and created on a later moment in Azure or

29
00:02:50,120 --> 00:02:58,600
any other cloud provider, which is a big part of the whole DevSecOps. And also what you

30
00:02:58,600 --> 00:03:04,920
mentioned, I think, if you look at it, I think from an outside to the developer's perspective

31
00:03:04,920 --> 00:03:11,840
and see how many stages there are involved within developing a code or application or

32
00:03:11,840 --> 00:03:20,280
infrastructure part, that security cannot be just an additional stage that is added

33
00:03:20,280 --> 00:03:21,280
to that whole process.

34
00:03:21,280 --> 00:03:22,280
It's not like...

35
00:03:22,280 --> 00:03:23,280
It can't be an afterthought.

36
00:03:23,280 --> 00:03:30,320
No, right? And I think that's the whole idea behind DevSecOps, why they didn't add an additional

37
00:03:30,320 --> 00:03:36,960
pilot to it, but they said, no, security should be part of every stage in the whole process.

38
00:03:36,960 --> 00:03:44,000
Because I think the end goal is that, and we will touch that today a little, is to find

39
00:03:44,000 --> 00:03:51,880
that vulnerability as soon as possible. And I think that's what we are going to talk about

40
00:03:51,880 --> 00:03:58,760
in this series, more the shift left approach, which you are seeing, it's coming from developers,

41
00:03:58,760 --> 00:04:02,720
of course, but it's also now security is adopting that framework.

42
00:04:02,720 --> 00:04:07,960
Yeah. So it's like, you know, you need to... Like you already said, it's not like security

43
00:04:07,960 --> 00:04:11,560
is not an extra step in the chain. We're not adding a little, oh, we need to do security

44
00:04:11,560 --> 00:04:15,720
at some point. Now, every stage of developing an application, there are lots of stages that

45
00:04:15,720 --> 00:04:19,480
should all be done securely and all of them need different steps. So you're kind of, you

46
00:04:19,480 --> 00:04:23,600
know, shifting the approach of security more to the left, so more to the developer perspective

47
00:04:23,600 --> 00:04:27,800
and more to the planning perspective. When you're planning to build your application,

48
00:04:27,800 --> 00:04:32,280
when you're designing it, what do we need? We need to build an application that talks

49
00:04:32,280 --> 00:04:36,440
to the cloud. Okay. How does security play a role here? How are we going to talk about

50
00:04:36,440 --> 00:04:40,760
security? Not something that you do in the end. You really take it with you in all stages

51
00:04:40,760 --> 00:04:41,760
of developing it.

52
00:04:41,760 --> 00:04:48,840
It needs to be integrated in every step and every single piece that you're thinking of,

53
00:04:48,840 --> 00:04:50,000
security needs to be part of it.

54
00:04:50,000 --> 00:04:53,840
Yeah, because we're not nowadays writing like applications anymore and then deploying the

55
00:04:53,840 --> 00:04:59,680
files on an FTP server or something like that by hand. We're doing so much more. We're deploying,

56
00:04:59,680 --> 00:05:03,960
we're hosting our code somewhere like in GitHub, Azure DevOps, GitLab, stuff like this. And

57
00:05:03,960 --> 00:05:08,280
then we're using like CI-CD, like build pipelines, release pipelines. We're doing tests. We're

58
00:05:08,280 --> 00:05:13,280
doing monitoring. There's so many things that this works really well, but there's also so

59
00:05:13,280 --> 00:05:17,880
many things that can go wrong. And if you just ask a developer to fix all of this, you

60
00:05:17,880 --> 00:05:22,080
can't do it. You need security analysts, but this all needs to be done in a continuous

61
00:05:22,080 --> 00:05:23,080
way.

62
00:05:23,080 --> 00:05:28,280
Yeah, I think that that approach is adopted by developers for a really long time, right?

63
00:05:28,280 --> 00:05:35,520
Building, testing, unit testing, all the types of testing of your code. But I think less

64
00:05:35,520 --> 00:05:41,680
from the security mind, like, okay, are there vulnerabilities in my code or could there

65
00:05:41,680 --> 00:05:46,520
be any vulnerabilities? I think that's the big change, right? Because developers are

66
00:05:46,520 --> 00:05:51,960
doing code testing for a really long time, but not always from a security perspective.

67
00:05:51,960 --> 00:05:58,240
It is really difficult for a developer to do all of that. Like one important thing is

68
00:05:58,240 --> 00:06:02,200
that you need to update your packages, update your dependencies and stuff like that. And

69
00:06:02,200 --> 00:06:08,240
not a lot of developers like doing that. It's boring work. It's just takes very time consuming.

70
00:06:08,240 --> 00:06:11,840
And often you don't really have any time to do it. You know, the focus is on building

71
00:06:11,840 --> 00:06:16,680
those new features. It's not on like updating everything that you've already built.

72
00:06:16,680 --> 00:06:22,920
And if you have an application that you built on your own and it's completely your own code,

73
00:06:22,920 --> 00:06:29,800
you could scan your code and you're completely aware of what's in it. If you're using libraries

74
00:06:29,800 --> 00:06:37,180
or stuff like, for example, look for J, the issue that we have seen, if you're using some

75
00:06:37,180 --> 00:06:44,400
other components like look for J, yeah, then you are relying on other stuff. And then it's

76
00:06:44,400 --> 00:06:51,560
more harder to check if you are having have any vulnerability or not.

77
00:06:51,560 --> 00:06:58,800
Exactly. Nowadays, I don't think any developer is building an application without any dependencies.

78
00:06:58,800 --> 00:07:03,040
It is probably possible if you're just writing HTML, CSS, maybe some JavaScript yourself.

79
00:07:03,040 --> 00:07:09,080
It is possible, but I would say that 80, 90, even more percent of applications nowadays

80
00:07:09,080 --> 00:07:13,160
are built using a framework in a front end like React Angular view or you're building

81
00:07:13,160 --> 00:07:17,940
a server application in Java or.NET. Doesn't really matter. Anything is using libraries.

82
00:07:17,940 --> 00:07:23,560
And keeping up to date is one thing. But also what dependencies you're using in one package

83
00:07:23,560 --> 00:07:29,960
and that package in the front end land, in JavaScript land, has like a thousand dependencies

84
00:07:29,960 --> 00:07:35,560
which have dependencies. If one of them in the chain gets a vulnerability somewhere,

85
00:07:35,560 --> 00:07:40,960
all the packages above are also vulnerable. And it's, you know, I need to build this feature,

86
00:07:40,960 --> 00:07:45,160
you know, I need to build this new checkout page, but I also need to ensure that dependency

87
00:07:45,160 --> 00:07:51,240
6000 is still valid. It's impossible for me to do that alone. I cannot do that in the

88
00:07:51,240 --> 00:07:52,240
time that I have.

89
00:07:52,240 --> 00:07:59,440
Puyon, if we look at application development, dependencies are playing a big role. What

90
00:07:59,440 --> 00:08:05,360
about infrastructure code? If we are deploying infrastructure on the Azure platform or on

91
00:08:05,360 --> 00:08:11,040
AWS or whatever, do we have that sort of dependencies also?

92
00:08:11,040 --> 00:08:18,960
Well, not so the dependencies to libraries. When it comes to infrastructure code, it's

93
00:08:18,960 --> 00:08:25,760
mainly where we focus is to find the misconfigurations, right? Something we can do on multiple levels,

94
00:08:25,760 --> 00:08:31,880
right? We can do that when deploying the resources to our Azure cloud, for example. We can do

95
00:08:31,880 --> 00:08:37,160
that with Azure policies these days where we can say, okay, we are allowing users to

96
00:08:37,160 --> 00:08:41,600
create a virtual machine in Western Europe. They need to have certain disk encryption

97
00:08:41,600 --> 00:08:48,000
models configured and they are not allowed to have a public IP address. So that's something

98
00:08:48,000 --> 00:08:53,280
we can do, but that's on the Azure side. And when we start doing infrastructure code, so

99
00:08:53,280 --> 00:09:00,960
the developer has done all the configuration, build the templates, commit that code, that

100
00:09:00,960 --> 00:09:09,040
code is merged and deployed and at the deployment, you find out that there's some restrictions.

101
00:09:09,040 --> 00:09:15,560
And I think that's something that's also a little too late because you want to find that

102
00:09:15,560 --> 00:09:21,920
misconfiguration much earlier, like developers. From my understanding is that developers want

103
00:09:21,920 --> 00:09:29,320
to find preferably the bug or the misconfiguration in the code on their EDA, not even in the

104
00:09:29,320 --> 00:09:34,800
build and validation phase. That would, I guess, be the best thing. You definitely have

105
00:09:34,800 --> 00:09:38,560
code analyzers that check, hey, you're writing code here that might be insecure or you're

106
00:09:38,560 --> 00:09:44,440
missing validation. And then something in your IDE would be very great. But the thing is,

107
00:09:44,440 --> 00:09:50,440
if you only do it in the IDE and you just kind of don't make all of this validation

108
00:09:50,440 --> 00:09:54,400
of your dependencies, vulnerability scanning, if you don't make that a part of your pipeline

109
00:09:54,400 --> 00:09:58,440
and you only do it in the IDE, then a developer on your team that doesn't use that IDE or

110
00:09:58,440 --> 00:10:01,000
doesn't have it configured is still going to let vulnerable packages in.

111
00:10:01,000 --> 00:10:04,560
You should be on two faces, right?

112
00:10:04,560 --> 00:10:09,520
I guess. I see it most of the times. I see it just happen in the pipelines itself. And

113
00:10:09,520 --> 00:10:13,840
for me, that works enough. You do nowadays have it integrated in Visual Studio. You get

114
00:10:13,840 --> 00:10:19,240
a warning when it says, hey, when.NET package manager knew that, when it finds out that

115
00:10:19,240 --> 00:10:22,320
there's a vulnerable package, you actually get a notification nowadays. It's really,

116
00:10:22,320 --> 00:10:27,440
really useful. I never really thought about it. Last week, I started my Visual Studio

117
00:10:27,440 --> 00:10:32,160
instance and I saw that Nougat told me, hey, you have vulnerable packages. That's extremely

118
00:10:32,160 --> 00:10:36,320
useful as a developer to know. And then you can just make work of it or you can tell your

119
00:10:36,320 --> 00:10:41,280
team, hey, next week or next sprint, we really need to start focusing on these packages and

120
00:10:41,280 --> 00:10:42,280
we need to update them.

121
00:10:42,280 --> 00:10:47,480
Yeah, because Frans, for example, you mentioned Log4G. If you look at Log4G, and I think you

122
00:10:47,480 --> 00:10:55,200
had a similar experience, when the customers called us or when we were proactively searching

123
00:10:55,200 --> 00:11:01,480
customer environments, if you look, we were looking more on the infrastructure side, right,

124
00:11:01,480 --> 00:11:08,960
to find that. Defender, firewalls, Sentinel.

125
00:11:08,960 --> 00:11:15,200
It was on the infra side, but the infra side was detecting the applications that are using

126
00:11:15,200 --> 00:11:23,380
that Log4G. So the detection was realized on the infra components, but the vulnerability

127
00:11:23,380 --> 00:11:30,760
was in the applications. So it's somewhat hard to search all the applications to see

128
00:11:30,760 --> 00:11:38,280
the vulnerabilities. And then you need a vulnerability scanner on a network or on an application

129
00:11:38,280 --> 00:11:47,480
server, whatever, to find if a certain library is installed and be used in that area. But

130
00:11:47,480 --> 00:11:52,640
that's the side from a customer perspective that we have. On the side of a developer,

131
00:11:52,640 --> 00:11:59,640
a developer needs to know where his dependencies are. So if Log4G, if we take that example,

132
00:11:59,640 --> 00:12:06,600
if Log4G is coming up and there is a vulnerability in a specific package, then Sander, as a developer,

133
00:12:06,600 --> 00:12:13,120
he needs to check and he needs to know which applications do I have with that dependency,

134
00:12:13,120 --> 00:12:14,920
so I need to update that one.

135
00:12:14,920 --> 00:12:19,120
Yeah, exactly. One thing that's really funny when we're talking about package vulnerabilities

136
00:12:19,120 --> 00:12:23,020
is when I talk to developers or managers and stuff like that about we need to improve our

137
00:12:23,020 --> 00:12:27,920
security because it's insecure and they're like, yeah, but we're just a small company.

138
00:12:27,920 --> 00:12:31,680
No one is going to hack us. They don't have anything to gain here. And that is maybe true

139
00:12:31,680 --> 00:12:36,160
in the olden days where hackers could just target companies and stuff like this. But

140
00:12:36,160 --> 00:12:41,500
nowadays, when we're saying Log4J or when we're saying a package that has a dependency

141
00:12:41,500 --> 00:12:46,280
on a package, and I keep going like that, and somewhere in that chain is a vulnerability.

142
00:12:46,280 --> 00:12:50,560
You are hacked. You are suddenly vulnerable. And they did not target you. They just targeted

143
00:12:50,560 --> 00:12:55,360
one little package and suddenly millions of companies could be vulnerable.

144
00:12:55,360 --> 00:13:03,600
I think from a hacker perspective, it doesn't matter what you're doing. If you have a small

145
00:13:03,600 --> 00:13:10,840
piece of software that is used by lots of other vendors, application developers and

146
00:13:10,840 --> 00:13:22,520
so on, then there's a potential bigger impact in the world and you have access to more machines

147
00:13:22,520 --> 00:13:26,120
if you can realize that that way.

148
00:13:26,120 --> 00:13:30,600
It makes sense for a hacker perspective as well. Why would you target one little company

149
00:13:30,600 --> 00:13:34,920
if you could potentially know how this company, this website is built in React or something

150
00:13:34,920 --> 00:13:40,080
like that, or they're hosting their server with.NET. So we're just going to grab some

151
00:13:40,080 --> 00:13:44,200
popular.NET packages and we're going to try finding vulnerabilities in those and get some

152
00:13:44,200 --> 00:13:48,640
bad stuff going on in there. And I know that the company will install my package. It's

153
00:13:48,640 --> 00:13:49,640
so much easier.

154
00:13:49,640 --> 00:13:56,640
If we're talking about risks, what are, from your opinion, what are the common security

155
00:13:56,640 --> 00:14:01,920
risks and challenges that developers have?

156
00:14:01,920 --> 00:14:05,880
Developers I think number one would be from the code perspective, how you're managing

157
00:14:05,880 --> 00:14:12,640
your secrets. So you're writing code to connect to services in Azure or just to connect to

158
00:14:12,640 --> 00:14:16,320
services from an external service like an invoice service or payment service, which

159
00:14:16,320 --> 00:14:20,680
you see often nowadays. How do you make sure that those credentials are kept safe? Lots

160
00:14:20,680 --> 00:14:26,080
of developers just, they don't really think about it much and it can be a difficult topic.

161
00:14:26,080 --> 00:14:30,880
I see it often just, you see often that they're still being leaked. In 2019 I read that there

162
00:14:30,880 --> 00:14:36,120
was like a hundred thousand secrets or something were like leaked from GitHub, like a hundred

163
00:14:36,120 --> 00:14:39,520
thousand and that's just not going to stop. That it's just going to keep going.

164
00:14:39,520 --> 00:14:44,600
We know a scenario in the Netherlands a couple of, yeah, well it's a year ago almost, of

165
00:14:44,600 --> 00:14:52,040
an IT admin which, from my understanding, he wanted to do something good and he wanted

166
00:14:52,040 --> 00:14:58,440
to share what he built on a code base and he published it on GitHub so that others can

167
00:14:58,440 --> 00:15:03,920
use it and it contained username and password. An admin, highly privileged admin account.

168
00:15:03,920 --> 00:15:10,680
Oh, and I have a great story to tell on this. So it was a few years ago, there was in the

169
00:15:10,680 --> 00:15:16,600
Dutch tax services, so like part of the Dutch government, there was an employee there had

170
00:15:16,600 --> 00:15:22,560
a GitHub account and some Dutch citizen found that GitHub account and was just looking around

171
00:15:22,560 --> 00:15:27,200
at it and in there he found some credentials to that employee's private GitLab account.

172
00:15:27,200 --> 00:15:31,920
He was like, okay, I'm just going to have a little look and take a look at that GitLab

173
00:15:31,920 --> 00:15:36,280
account and what he found was like a plain text file with like all the usernames and

174
00:15:36,280 --> 00:15:40,680
passwords of the Dutch tax services like Azure admin account.

175
00:15:40,680 --> 00:15:44,040
So what he did, he went in there, he went to the Azure portal, he logged in with username

176
00:15:44,040 --> 00:15:48,200
and password and it was correct but luckily of course there was two factor authentication

177
00:15:48,200 --> 00:15:52,720
installed so he was like, you know, out of luck. Of course he didn't want to log in,

178
00:15:52,720 --> 00:15:57,440
he was a nice guy and a few seconds later he was logged in. So some employee at the

179
00:15:57,440 --> 00:16:02,000
Dutch tax company actually like clicked on yes, it is me trying to log in and this guy

180
00:16:02,000 --> 00:16:06,880
was logged in as the global admin in Azure and it's just, you can just see like even

181
00:16:06,880 --> 00:16:11,560
with these big governments, it is so easy to just leak a secret. It is very easy to

182
00:16:11,560 --> 00:16:16,560
do and developers definitely need help. We need to integrate this security perspective

183
00:16:16,560 --> 00:16:19,600
all the way into the development of the code and everything else.

184
00:16:19,600 --> 00:16:25,720
Yeah and this guy was a white hacker so he informed the tax services that he was able

185
00:16:25,720 --> 00:16:33,000
to log in. But one thing I want to highlight on the story that you are describing is there

186
00:16:33,000 --> 00:16:34,000
was MFA.

187
00:16:34,000 --> 00:16:35,360
Yeah, there was MFA.

188
00:16:35,360 --> 00:16:44,360
And someone, because someone gets a notification on his phone and he put down a proof and the

189
00:16:44,360 --> 00:16:52,800
hacker is in. So MFA fatigue that we are facing in this area. So I get a, there was one notification

190
00:16:52,800 --> 00:16:59,200
probably but how many times are admins are facing with a notification or an approval

191
00:16:59,200 --> 00:17:06,360
prompt that comes in multiple times and then in the end I'm fucked up.

192
00:17:06,360 --> 00:17:07,360
I'm approved.

193
00:17:07,360 --> 00:17:15,720
Yes, exactly. And then you have a potential big impact on, it was a test environment so

194
00:17:15,720 --> 00:17:17,640
it was not that big.

195
00:17:17,640 --> 00:17:20,600
It was a test, I'm pretty sure it was prod.

196
00:17:20,600 --> 00:17:21,600
I thought it was prod.

197
00:17:21,600 --> 00:17:24,600
Let's just say it was test to save the grace.

198
00:17:24,600 --> 00:17:25,600
Let's hope it was.

199
00:17:25,600 --> 00:17:28,600
There was an environment.

200
00:17:28,600 --> 00:17:29,600
Exactly.

201
00:17:29,600 --> 00:17:39,280
Of a big environment, of a big company, a public company. And that was, it's potential,

202
00:17:39,280 --> 00:17:46,400
yeah, crucial that you have secured that sort of user credentials.

203
00:17:46,400 --> 00:17:52,360
So this brings us to, I think, a really nice summary of what is happening, right? Because

204
00:17:52,360 --> 00:17:59,480
we started with some code, some username password in a code which is published on a repository

205
00:17:59,480 --> 00:18:05,780
and all through the whole process that on the upside somebody used that account to log

206
00:18:05,780 --> 00:18:11,840
in, right? And that's, I think, the whole gap that is there. So on the left side we

207
00:18:11,840 --> 00:18:17,960
had that code which contained the password and on the, all on the right side we had the

208
00:18:17,960 --> 00:18:24,800
Active Directory, MFA, whatever in place to try to stop it or try to detect it with things

209
00:18:24,800 --> 00:18:30,280
like SIEM Sentinel or Defender for Identity, Impossible, that kind of stuff. We have that

210
00:18:30,280 --> 00:18:31,280
in place.

211
00:18:31,280 --> 00:18:32,280
Yeah.

212
00:18:32,280 --> 00:18:38,480
But we shouldn't, and I think that's when it comes, if you see at the market, everybody

213
00:18:38,480 --> 00:18:45,800
is so focused on that side. Everybody's trying to say, okay, how do I find anomalies in user

214
00:18:45,800 --> 00:18:46,800
logins?

215
00:18:46,800 --> 00:18:47,800
Yeah.

216
00:18:47,800 --> 00:18:54,520
Or how do I monitor my firewall? How do I monitor all kinds of operations? And we should

217
00:18:54,520 --> 00:19:00,920
also ask ourselves, that's good that we do that, but it's a complete blind spot for us

218
00:19:00,920 --> 00:19:06,160
or for companies often that they don't see where the vulnerability started.

219
00:19:06,160 --> 00:19:07,920
Yeah. That's a good point.

220
00:19:07,920 --> 00:19:14,040
And that's, I think, what brings us to the whole DevSecOps and let's touch on that for

221
00:19:14,040 --> 00:19:23,320
today and that's going to be a topic that returns, I think, every session we have. That's

222
00:19:23,320 --> 00:19:30,600
the whole shift left model from security because on the right side, we should have everything

223
00:19:30,600 --> 00:19:35,760
in place to detect that, but we should also have our processes and our tooling and our

224
00:19:35,760 --> 00:19:38,400
things in place to detect that more on the left side.

225
00:19:38,400 --> 00:19:41,920
Yeah. Prevention is better than healing, right? You want to prevent all of these things from

226
00:19:41,920 --> 00:19:42,920
happening.

227
00:19:42,920 --> 00:19:44,720
Yeah. But we know we cannot prevent everything.

228
00:19:44,720 --> 00:19:46,400
And that's why it's important.

229
00:19:46,400 --> 00:19:51,080
For LACP4G, so we need to have that detection as well on our operations side.

230
00:19:51,080 --> 00:19:57,920
Yeah, but also processes in that area that if something happens, what is the next step

231
00:19:57,920 --> 00:20:05,200
that we are going to do? So there is something that we do not have detected upfront. So there

232
00:20:05,200 --> 00:20:12,640
is an issue later on. So what are the steps to take? I want to get back at the security

233
00:20:12,640 --> 00:20:18,600
risk. The first thing that you mentioned was managing secrets. And then we had all discussion.

234
00:20:18,600 --> 00:20:24,200
Are there any other topics from a security risk perspective?

235
00:20:24,200 --> 00:20:29,200
I think definitely, we already touched upon that. I think that's definitely the dependencies.

236
00:20:29,200 --> 00:20:34,000
Dependencies are a big thing. Another one that is still sadly still very common are

237
00:20:34,000 --> 00:20:39,240
things like OWASP. Does anyone know here what it stands for on top of their head?

238
00:20:39,240 --> 00:20:40,240
No.

239
00:20:40,240 --> 00:20:44,800
I don't remember on top of my head, but it's owasp.org. I think it's the list of all the

240
00:20:44,800 --> 00:20:50,040
top 10 vulnerabilities that are still found. And number one that is still found, I think

241
00:20:50,040 --> 00:20:55,120
every year, is SQL injections and stuff like that. That is really we're talking about code

242
00:20:55,120 --> 00:20:58,640
here and how hackers can just get it.

243
00:20:58,640 --> 00:21:01,040
Cross-sight injections, that kind of stuff.

244
00:21:01,040 --> 00:21:02,960
Stuff like that as well. That's also on the list.

245
00:21:02,960 --> 00:21:08,840
Bing is helping me on that. It's the open web application security project.

246
00:21:08,840 --> 00:21:13,920
Exactly. I'm not going to remember that, but exactly that. Yeah. So stuff like these, these

247
00:21:13,920 --> 00:21:22,320
are definitely things that are happening more often than things like the OWASP vulnerabilities.

248
00:21:22,320 --> 00:21:26,600
Like you already mentioned, your programming environment, they're still getting better

249
00:21:26,600 --> 00:21:32,600
and better in helping you detect these issues. But when we're looking at number one and two,

250
00:21:32,600 --> 00:21:42,440
vulnerabilities and leaking secrets, that is something that is currently not normal

251
00:21:42,440 --> 00:21:47,000
for developers yet to think about. Like OWASP stuff is stuff that you learn. It is stuff

252
00:21:47,000 --> 00:21:51,240
that you, you know, kind of developers quickly learn when they're becoming a programmer because

253
00:21:51,240 --> 00:21:55,280
it's very important. But all of these other things that we just mentioned are newer. You

254
00:21:55,280 --> 00:22:00,280
know, they're modern problems for these things that we're building nowadays. And you need

255
00:22:00,280 --> 00:22:05,840
to use some products and stuff like that. You need to use tools to improve upon these

256
00:22:05,840 --> 00:22:06,920
processes.

257
00:22:06,920 --> 00:22:14,680
Do we have any examples how we can address these kind of risks that we have?

258
00:22:14,680 --> 00:22:27,760
Well, tools, yeah. So for example, you have things like the dependable is very often used

259
00:22:27,760 --> 00:22:33,440
is what I'm trying to say. Sorry. On GitHub. So that's a tool that you can use to automatically

260
00:22:33,440 --> 00:22:37,440
get like package updates. And first of all, it's great because it makes your thing more

261
00:22:37,440 --> 00:22:41,120
secure. And second of all, it's going to save you so much time. So developers and security

262
00:22:41,120 --> 00:22:44,880
people should just absolutely love using tools like this. So that every day you get like

263
00:22:44,880 --> 00:22:48,720
a pull request or it's even automatically merged into your code, like, hey, these packages

264
00:22:48,720 --> 00:22:52,000
should be updated, or hey, these packages contain vulnerabilities, you should update

265
00:22:52,000 --> 00:22:55,480
them or you should even migrate to a new package, stuff like this.

266
00:22:55,480 --> 00:23:00,080
Yeah, so maybe to explain a little for the listeners, I think dependable, what it does

267
00:23:00,080 --> 00:23:03,640
is it looks, you can define which libraries you're using your code.

268
00:23:03,640 --> 00:23:05,000
I think it finds it does automatically.

269
00:23:05,000 --> 00:23:10,360
Does it even automatically? Oh, perfect. And based on that, it looks if there are any new

270
00:23:10,360 --> 00:23:15,280
versions available. Exactly. And if so, it will need, as you said, automatically integrate

271
00:23:15,280 --> 00:23:19,520
or create a pull request for you so that you know, okay, I need to change that to go to

272
00:23:19,520 --> 00:23:25,360
so that that's a really, really, really useful only feature, I believe, right?

273
00:23:25,360 --> 00:23:31,320
Not dependent bot only runs on GitHub. Yes, but there's a thing called renovate bot, I

274
00:23:31,320 --> 00:23:34,080
learned about it like only like two or three weeks ago, and I still need to I need to start

275
00:23:34,080 --> 00:23:40,080
implementing that in the code base where I work. The renovate bot is the same idea. So

276
00:23:40,080 --> 00:23:43,720
you can self host that and you can use that I think even if you wanted to and like Git

277
00:23:43,720 --> 00:23:50,640
lab or Azure DevOps and stuff like that. So that's the same idea you could get the vulnerability

278
00:23:50,640 --> 00:23:53,280
updates, package updates, all that kind of stuff.

279
00:23:53,280 --> 00:23:59,920
So we're talking about tools that can be helpful to address certain certain vulnerabilities,

280
00:23:59,920 --> 00:24:10,040
certain things and misconfigurations. But that are tools. What can we do regarding awareness

281
00:24:10,040 --> 00:24:18,000
on the developer side itself on the on the people? What can we do to improve the awareness

282
00:24:18,000 --> 00:24:20,320
and expertise on that side?

283
00:24:20,320 --> 00:24:26,440
I guess people should listen to this podcast. Definitely. That's a difficult one. That's

284
00:24:26,440 --> 00:24:32,480
like I feel like, like a lot of these awareness things, it's a time driven thing. It takes

285
00:24:32,480 --> 00:24:35,960
time for people to learn more about this.

286
00:24:35,960 --> 00:24:40,720
Do we need do we need to educate them? Because we have security awareness on the end user

287
00:24:40,720 --> 00:24:48,560
side, giving people training materials. And so we have that also, from from from a management

288
00:24:48,560 --> 00:24:56,920
perspective. So consultants and people who are managing IT systems have also training

289
00:24:56,920 --> 00:25:01,800
training stuff for that. But especially for developers, I don't have I don't think it's

290
00:25:01,800 --> 00:25:03,960
that that much.

291
00:25:03,960 --> 00:25:10,080
So we had a great talk on this with David, of course, the for regarding the fan of cloud

292
00:25:10,080 --> 00:25:13,480
focus on DevOps.

293
00:25:13,480 --> 00:25:20,240
And I think David Righano. Yeah. And I think the key is based is parsing training in these

294
00:25:20,240 --> 00:25:26,840
are people but I think it's mainly to bring those people together. Exactly. And I think

295
00:25:26,840 --> 00:25:33,760
that's that's that would be the best approach. Like if you look on like technologies like

296
00:25:33,760 --> 00:25:40,360
the Fender for DevOps, right? Part of the defender for cloud stack. Depends on what

297
00:25:40,360 --> 00:25:46,040
kind of code scanning you have enabled. But regarding of that is you have features like

298
00:25:46,040 --> 00:25:53,240
pull request annotations. So what it does is it automatically scans your code based

299
00:25:53,240 --> 00:26:02,000
on passwords or anything else. And that shows an alarm. It goes to defend for cloud. And

300
00:26:02,000 --> 00:26:08,280
that syncs back to your DevOps pull request. And it points out like on line three, you

301
00:26:08,280 --> 00:26:14,280
have used certain parameter or you use the password or we found that and that and that.

302
00:26:14,280 --> 00:26:20,600
But more information click here read more on that. And what it does is it creates a

303
00:26:20,600 --> 00:26:29,280
platform where security can take a look in the developers ecosystem finds vulnerabilities

304
00:26:29,280 --> 00:26:36,360
that could be there and and give them feedback on their platform. Instead of saying no you

305
00:26:36,360 --> 00:26:42,120
developer you need to go to a security portal to see the information now bring that information

306
00:26:42,120 --> 00:26:47,440
back to where the developer works. It's like you're getting a taught automatically right?

307
00:26:47,440 --> 00:26:53,680
Like definitely learning about this is important. But like you know getting taught about it

308
00:26:53,680 --> 00:26:57,440
is important is even even like easier for everyone. The developer gets a notification

309
00:26:57,440 --> 00:27:01,440
like hey you did it wrong. I just want to touch upon that product like you said the

310
00:27:01,440 --> 00:27:08,680
vendor for DevOps is what you said it. Yeah sorry yeah. Is it still the vendor for DevOps?

311
00:27:08,680 --> 00:27:13,120
Yeah it's part of the defender for cloud. Security I think it was something with security

312
00:27:13,120 --> 00:27:17,080
now in the name right? Like they're renaming it every month. Yeah so it's still something

313
00:27:17,080 --> 00:27:22,920
that says there was something at Ignite. Yeah there was something. What's that? So what

314
00:27:22,920 --> 00:27:28,040
I saw is like there's also you know like an let's talk about talking to an external service

315
00:27:28,040 --> 00:27:32,240
like SendGrid or something to send emails. So you use an API key send it that way. What

316
00:27:32,240 --> 00:27:38,120
I learned some time ago is that that SendGrid's API key is a very specific API key. It's like

317
00:27:38,120 --> 00:27:44,800
starts with SG and then something else. So when GitHub detects when GitHub detects a push

318
00:27:44,800 --> 00:27:49,400
to your repo and it contains a SendGrid API key it will automatically go and do a call

319
00:27:49,400 --> 00:27:54,520
to SendGrid to invalidate that API key. I find that a very very interesting approach.

320
00:27:54,520 --> 00:27:59,080
Even if you leak a secret like it is automatically invalidated. So it cannot be used by hackers

321
00:27:59,080 --> 00:28:05,080
anymore. I believe GitHub has that also for yourself so you can publish your keys in a

322
00:28:05,080 --> 00:28:10,280
certain list and it will automatically scan all the other repositories. If it finds the

323
00:28:10,280 --> 00:28:15,520
key outside of your repository it will give you a signature as well. That is interesting.

324
00:28:15,520 --> 00:28:19,480
Because that shows if your key is leaked or not. Exactly that's really good. Like but

325
00:28:19,480 --> 00:28:26,920
it being invalidated is the next step compared to getting a notification. Getting a notification

326
00:28:26,920 --> 00:28:31,320
and you're on holiday for three weeks. Then you might have got hacked three weeks ago

327
00:28:31,320 --> 00:28:36,120
when you come back. It getting invalidated immediately and stuff like that. That's the

328
00:28:36,120 --> 00:28:43,260
next big thing. The next question that I have was regarding collaboration and communication

329
00:28:43,260 --> 00:28:48,280
between developers and security analysts. You already touched a little bit on that.

330
00:28:48,280 --> 00:28:58,040
If we are touching a bit more on that perspective. Sending the stock analyst to the developer

331
00:28:58,040 --> 00:29:05,160
portal so they can communicate with each other and get feedback, give feedback on the code.

332
00:29:05,160 --> 00:29:11,640
Is that the only thing that they can do? Or are there multiple information barriers that

333
00:29:11,640 --> 00:29:21,840
needs to be hacked between both of these groups? Because a security analyst is mostly involved

334
00:29:21,840 --> 00:29:30,440
if something happens or afterwards. A developer is at the very beginning. There is a lot of

335
00:29:30,440 --> 00:29:36,120
things in between. How can we bring them more and more together?

336
00:29:36,120 --> 00:29:46,360
That's the entire DevSecOps thing. That's really important. I feel like the tools are

337
00:29:46,360 --> 00:29:50,360
definitely important but that's of course not the human. You want more human communication

338
00:29:50,360 --> 00:29:54,200
about this as well. You need to know there is also a security person working behind the

339
00:29:54,200 --> 00:29:59,320
scenes and stuff. You need to know them. What do they find important? What do I find important?

340
00:29:59,320 --> 00:30:04,000
What we are doing right now? What kind of problems do I see? What kind of things do

341
00:30:04,000 --> 00:30:09,200
you guys know? What kind of things do you guys recommend to solve this issue? I've seen

342
00:30:09,200 --> 00:30:14,440
some places where they actually really make a security person part of the team. Part of

343
00:30:14,440 --> 00:30:23,480
the Scrum team. It's not like they are actually analyzing the product every hour of the day.

344
00:30:23,480 --> 00:30:29,080
They do actually participate in what the team is doing. When there is a question, they can

345
00:30:29,080 --> 00:30:33,360
always go to that security analyst and they can have a look around.

346
00:30:33,360 --> 00:30:38,440
Is that a security analyst or is that more engineer? Security engineer? I don't know

347
00:30:38,440 --> 00:30:42,600
the types. If it's part of the team, it's often an engineer.

348
00:30:42,600 --> 00:30:49,040
Is that a SOC? An operating center analyst or engineer? Or is that more or less a security

349
00:30:49,040 --> 00:31:00,640
consultant that is involved into projects to bring the security analyst and the developers

350
00:31:00,640 --> 00:31:06,200
together? I think the security analyst is the person

351
00:31:06,200 --> 00:31:14,600
that reacts when there is an incident. A security engineer consultant is the one that guides

352
00:31:14,600 --> 00:31:20,400
the project and takes constantly with the security. It's more a different role in my

353
00:31:20,400 --> 00:31:27,720
opinion. Let's for example, if you look at DevOps,

354
00:31:27,720 --> 00:31:34,800
DevOps starts with planning. The first stage is before you do any code, you have done anything.

355
00:31:34,800 --> 00:31:43,080
You start with planning and create a design diagram. That's your proposal. Without talking

356
00:31:43,080 --> 00:31:50,160
about any code. This is the application. To give you an example, I did a project with

357
00:31:50,160 --> 00:31:58,880
a really big financial in the Netherlands. Before we even started doing any resource

358
00:31:58,880 --> 00:32:06,320
in Azure or any line of code, we needed to get an approval for our design, like the technical

359
00:32:06,320 --> 00:32:16,000
design, the functional design, from the cloud competence team, from the security team, and

360
00:32:16,000 --> 00:32:22,960
I believe from the operations team. The cloud competence was looking at are we using the

361
00:32:22,960 --> 00:32:28,480
right resources, are we deploying it the right way? Security was challenging us, what kind

362
00:32:28,480 --> 00:32:32,800
of data are you processing? Based on that, you have this classification, so you need

363
00:32:32,800 --> 00:32:38,480
to do that kind of encryption at a minimum. Operation was like, okay, have you your backup

364
00:32:38,480 --> 00:32:45,000
in place? I think that's the first stage where it starts. Communication and talking to each

365
00:32:45,000 --> 00:32:49,680
other like reviewing that design, okay, this is the solution that we are going to work

366
00:32:49,680 --> 00:33:02,040
on. From that three different perspectives. I definitely agree. The one thing is that

367
00:33:02,040 --> 00:33:07,480
I do, as a developer, I do see a bit of an issue there where I'm designing an application,

368
00:33:07,480 --> 00:33:12,760
right? I'm going to build a web shop API or something like that. It's important that we

369
00:33:12,760 --> 00:33:15,880
store our data securely because it's real customer data. We're handling credit card

370
00:33:15,880 --> 00:33:20,560
info, stuff like this. It's really important to know. I like learning about security, so

371
00:33:20,560 --> 00:33:26,040
I'll notice all this kind of stuff, and I like focusing on how do we store GDPR data.

372
00:33:26,040 --> 00:33:31,840
A lot of developers don't, not because they don't know, they just don't really have the

373
00:33:31,840 --> 00:33:36,160
knowledge. Talking to those people is very important. I do think that when we're building

374
00:33:36,160 --> 00:33:39,520
this application over time, it's going to get new features, right? And we're going to

375
00:33:39,520 --> 00:33:45,080
have new requirements. And then I definitely see people slipping and still at that point

376
00:33:45,080 --> 00:33:49,520
implementing something insecurely because they didn't involve all of these teams again.

377
00:33:49,520 --> 00:33:53,760
It was something that you did at the beginning, but doing that every time costs too much time

378
00:33:53,760 --> 00:33:59,320
or there is no time and stuff like that. So for that, I guess I'm a programmer and I love

379
00:33:59,320 --> 00:34:06,560
automating so much things. So I really feel like using tools at least for the future here

380
00:34:06,560 --> 00:34:10,800
is going to help us the most using all of these tools like GitHub Advanced Security,

381
00:34:10,800 --> 00:34:15,880
Microsoft, the vendor for cloud security DevOps. I don't know the name anymore.

382
00:34:15,880 --> 00:34:18,600
Let's go with the defender for cloud. Defender for cloud. We're going to call it defender

383
00:34:18,600 --> 00:34:21,480
for cloud. That's what we agree with David, right?

384
00:34:21,480 --> 00:34:26,680
Yeah, yeah, yeah. Definitely. Great. I think using all of these tools to make, to set up

385
00:34:26,680 --> 00:34:31,240
a design with actual with those teams, they really know what fits the company the best.

386
00:34:31,240 --> 00:34:34,680
And you need to use this product because that is what we use everywhere. So that's a good

387
00:34:34,680 --> 00:34:39,240
fit, stuff like that. And then we're going to start using these tools during development

388
00:34:39,240 --> 00:34:42,960
to get odd, to get like a signal like, hey, you're doing this wrong. Hey, this is insecure.

389
00:34:42,960 --> 00:34:46,640
Your code has vulnerabilities. You committed a secret. You shouldn't have this package

390
00:34:46,640 --> 00:34:50,960
with vulnerabilities. Here's a PR to automate them. I think that is something that you can

391
00:34:50,960 --> 00:34:56,560
do to for developer to really keep your code secure over the time that you're working on

392
00:34:56,560 --> 00:35:04,360
it. Yeah. To finish this recording up, because we have touched a few different parts, to

393
00:35:04,360 --> 00:35:12,920
finish up, we talk, still talking about co-pilots within the Microsoft area. Co-pilot, security

394
00:35:12,920 --> 00:35:19,840
co-pilots, what's helping us within defender for cloud, defender for, for, and defender,

395
00:35:19,840 --> 00:35:26,040
what is it? Defender XDR within, yeah, all the, all that names about. Just say it by

396
00:35:26,040 --> 00:35:30,640
date, right? Today it's defender XDR. Today. Yeah. And the recording is in the beginning

397
00:35:30,640 --> 00:35:37,080
of December. So, um, but we have also co-pilot for windows, co-pilot for productivity and

398
00:35:37,080 --> 00:35:45,440
so on. So there are different co-pilots. Do you think that co-pilot or AI will, will,

399
00:35:45,440 --> 00:35:52,220
will play a role within the stuff while we're talking about having co-pilot? Yeah, I'm already

400
00:35:52,220 --> 00:35:58,480
using it like every, every day. Yeah. Yeah. But that's get up co-pilots. But also when

401
00:35:58,480 --> 00:36:06,680
talking about, um, defining, uh, finding vulnerabilities and stuff. So we are using, uh, software,

402
00:36:06,680 --> 00:36:15,480
uh, or solutions that scans, uh, code and, and, and much more. But does AI also play

403
00:36:15,480 --> 00:36:22,520
a role in that area to detect, um, in other ways for developer? I mean, I know that there's

404
00:36:22,520 --> 00:36:27,480
now this security co-pilot. I don't really know yet what it is. Um, maybe that's a topic

405
00:36:27,480 --> 00:36:30,480
for later. Cause we, you know, maybe it's a topic for a new episode. Cause it, I think

406
00:36:30,480 --> 00:36:34,960
it definitely can play a big role, but I think for developers perspective, when we're using

407
00:36:34,960 --> 00:36:38,360
co-pilot, maybe it could learn, you know, from your code base, from your company's security

408
00:36:38,360 --> 00:36:42,200
policies. And then when you ask it to generate code or when, when it's running in your program,

409
00:36:42,200 --> 00:36:46,680
it's like, Hey, you're writing code here that violates company policies or discovery stuff

410
00:36:46,680 --> 00:36:49,800
like this. So during development, you get the notification. This is what we already said

411
00:36:49,800 --> 00:36:53,920
in the beginning instead of later on in the pipeline, right? When you're writing the code,

412
00:36:53,920 --> 00:36:57,440
a new developer day one immediately gets to know, Oh, I'm doing something here. That's

413
00:36:57,440 --> 00:37:01,920
insecure. And I think definitely there's a future in that. I think it's going to happen

414
00:37:01,920 --> 00:37:07,080
pretty soon. I believe. And I think you can already in your EDA, for example, in VS code

415
00:37:07,080 --> 00:37:11,680
already when you have co-pilot and then get a co-pilot, then you can already, when you

416
00:37:11,680 --> 00:37:16,360
have a code, you can already ask it, analyze this code to see if there are any vulnerabilities

417
00:37:16,360 --> 00:37:20,680
in there. That kind of features already there. So it's not maybe fully automated. That's

418
00:37:20,680 --> 00:37:26,120
I think the answer to the question. But if the future is there, I think, yeah, it will

419
00:37:26,120 --> 00:37:31,840
play a bigger and bigger and bigger role in my opinion. So it will help. It doesn't replace

420
00:37:31,840 --> 00:37:41,920
anything because we still need to realize stuff and create stuff. AI can help. It doesn't

421
00:37:41,920 --> 00:37:49,560
take over in my opinion. Hopefully not. Otherwise we have, we are still starting a podcast.

422
00:37:49,560 --> 00:37:55,200
So probably we can extend that one. Maybe the next episode will be AI generated. I heard

423
00:37:55,200 --> 00:38:00,720
Bing already a couple of times today. So exactly. That's Bing enterprise and Bing helps also

424
00:38:00,720 --> 00:38:09,560
in generating questions and doing stuff with it. So having a smooth conversation with that.

425
00:38:09,560 --> 00:38:16,760
Did we touch every single piece that we want to touch? I think we talked about some tools

426
00:38:16,760 --> 00:38:20,960
and I think I just want to call out a couple more tools for developers at least to start

427
00:38:20,960 --> 00:38:24,640
using. Like you from the, I think that's more from the operations perspective. If you might

428
00:38:24,640 --> 00:38:28,960
a defender for cloud, right? I think that's a bit more for the operation side on the right

429
00:38:28,960 --> 00:38:39,480
side. So it gives the right side to the operation side, visibility into the left side, right?

430
00:38:39,480 --> 00:38:44,760
Because you can suddenly see the codes, scan the code, see what's for the village. It's

431
00:38:44,760 --> 00:38:51,440
all there. You can do it on multiple layers. So that's I think something we didn't touch

432
00:38:51,440 --> 00:38:56,200
because when we are talking about repositories, right? Where you store your code, it's a vulnerability

433
00:38:56,200 --> 00:39:03,120
that can come, you can experience there, but you can also have like misconfiguration on

434
00:39:03,120 --> 00:39:09,880
your repository side like that you can do push to the main brain, for example. That's

435
00:39:09,880 --> 00:39:14,920
something we do. So the fan of a cloud and in combination definitely with GitHub and

436
00:39:14,920 --> 00:39:19,400
security, of course, as multiple layer, it's partially the infrastructure side, your configuration.

437
00:39:19,400 --> 00:39:24,120
Like, do you have your project PRs? Do you have like code validation, that kind of sub

438
00:39:24,120 --> 00:39:31,440
configured and partially it's like your code, scanning your code and bringing the output

439
00:39:31,440 --> 00:39:39,800
to the fan for cloud where a security analyst is, you can look at these results. Yeah, exactly.

440
00:39:39,800 --> 00:39:45,680
So, so your security and your operation is completely on the right is seeing, okay, this

441
00:39:45,680 --> 00:39:52,120
is coming towards the production, right? You are aware of what's coming. And so then you

442
00:39:52,120 --> 00:40:00,600
can choose to interact with things like pull request integrations and then send, okay,

443
00:40:00,600 --> 00:40:08,440
on line three, we see this and that and that. And that way create that, bring those two

444
00:40:08,440 --> 00:40:13,120
worlds together. Yeah, so like stuff like, you know, like you already said, so GitHub

445
00:40:13,120 --> 00:40:20,800
security or the greatly named GitHub, GitHub security, GitHub advanced security for Azure

446
00:40:20,800 --> 00:40:25,640
DevOps, dependable is what we talked about renovate, all of these tools will help you

447
00:40:25,640 --> 00:40:30,800
like finding your vulnerabilities, it will help you like, it will stop you from pushing

448
00:40:30,800 --> 00:40:34,720
code that contains leaked secret and stuff like that. And something that's really interesting,

449
00:40:34,720 --> 00:40:40,280
like you said, it's like it would also like send signals to these defender, like applications

450
00:40:40,280 --> 00:40:44,200
and really, you know, what we kind of started talking about to wrap, I guess, kind of things

451
00:40:44,200 --> 00:40:49,640
up. It really brings these things to together, right? The developers are, you know, we're

452
00:40:49,640 --> 00:40:53,080
automatically now stopping vulnerabilities, but we're still analyzing them, we're still

453
00:40:53,080 --> 00:41:00,240
integrating the monitoring side with it. And you know, at least what is coming from the

454
00:41:00,240 --> 00:41:06,360
security side and the operations side, right? And those days a lot, what you see is that

455
00:41:06,360 --> 00:41:10,920
security and operation is surprised because there was a coaching, there was something,

456
00:41:10,920 --> 00:41:17,120
there was a vulnerability in the code, which where they weren't aware of. Yeah, no, that's

457
00:41:17,120 --> 00:41:22,280
true. Now you can still go with that vulnerability to production. It can be an accepted risk

458
00:41:22,280 --> 00:41:27,120
for example. Yeah, exactly. But at least you know what's happening. You know what is happening.

459
00:41:27,120 --> 00:41:37,520
So, France. That was all. Yeah, I think that's all. Nice. I want to mention one thing, not

460
00:41:37,520 --> 00:41:43,500
from this recording, but from the previous recording to finish up. We mentioned Defender

461
00:41:43,500 --> 00:41:54,320
for WSL last time. What happens with that? Because there was no support, whatever, and

462
00:41:54,320 --> 00:41:58,640
probably there was a preview. That was the thing that I mentioned. But what happens after

463
00:41:58,640 --> 00:42:05,600
our recording? Yeah, so last time, of course, we talked about containers and WSL and that

464
00:42:05,600 --> 00:42:13,400
it creates a black hole. WSL, yeah. WSL, sorry. And yeah, I think the same day, the same evening,

465
00:42:13,400 --> 00:42:19,560
they announced that it's going to public. I think it's not GA. I think it's public preview.

466
00:42:19,560 --> 00:42:26,360
Yeah. So what it does is it creates Defender for Endpoint. So if you have Defender for

467
00:42:26,360 --> 00:42:34,600
Endpoint on your machine, your server or your server, it also now scans your WSL environment

468
00:42:34,600 --> 00:42:40,520
to see what you are doing there. So if you are doing some scary stuff and you think that's

469
00:42:40,520 --> 00:42:48,000
isolated, there's now visibility in that space as well. So I think it's a huge step for Microsoft.

470
00:42:48,000 --> 00:42:55,080
So if I'm activating WSL on my Windows machine, Defender can take care of that WSL. Exactly.

471
00:42:55,080 --> 00:43:01,520
It can see what you're doing in there and use all of these Defender features. Yeah,

472
00:43:01,520 --> 00:43:10,520
but we have Defender for Linux, but also the integration on Windows subsystem for Linux.

473
00:43:10,520 --> 00:43:16,880
So that's great. Great. So to make that in order that we talked about the last time.

474
00:43:16,880 --> 00:43:20,480
Maybe the next time there are more changes that we are discussing. Does anyone want to

475
00:43:20,480 --> 00:43:27,520
do any predictions and then next episode will be out? What we already said in the beginning

476
00:43:27,520 --> 00:43:35,680
of this recording, we tried to touch some pieces of the DevSafcops framework. So today

477
00:43:35,680 --> 00:43:40,440
we talked more or less about code and code scanning, but also a security perspective

478
00:43:40,440 --> 00:43:51,520
from a developer. What pieces do we have in the DevSafcops framework, Poojan? Yeah, so

479
00:43:51,520 --> 00:43:55,200
we started a little bit on the left side, right? We started with the endpoint of the

480
00:43:55,200 --> 00:43:59,680
developer. We started with the code repository. And I think we are going to partially build

481
00:43:59,680 --> 00:44:07,480
that up towards the operations side. So I heard you telling identity and authorization

482
00:44:07,480 --> 00:44:14,400
is going to be an awesome topic to discuss. How do you authenticate and how do your applications

483
00:44:14,400 --> 00:44:23,640
authenticate your micro services? And co-pilot can be different recording in my opinion.

484
00:44:23,640 --> 00:44:28,600
Something like that. And also we're going to talk more about this. We're planning an

485
00:44:28,600 --> 00:44:33,280
application or I have a laptop here. How do we get the stuff that I built in it to prod?

486
00:44:33,280 --> 00:44:39,440
So the stages that you mentioned, like building, testing, releasing, monitoring, there's like

487
00:44:39,440 --> 00:44:44,260
loads of stages there and operations. All of these things I can think deserve their

488
00:44:44,260 --> 00:44:50,480
own topic, deserve their own episodes. So lots of topics to cover in the next few months,

489
00:44:50,480 --> 00:44:57,960
because we want to try every month to do a recording. So keep posted and see if you can

490
00:44:57,960 --> 00:45:03,840
realize that. And if not, you can challenge us. So reach out to us at the different social

491
00:45:03,840 --> 00:45:12,720
media channels. We're on LinkedIn, on X, is it today? But also on Reddit and all the social

492
00:45:12,720 --> 00:45:19,600
media platforms. So reach out if you have questions or want to be part of this. If you

493
00:45:19,600 --> 00:45:25,520
like this recording, subscribe or do some-

494
00:45:25,520 --> 00:45:30,640
Don't tell them to ring the bell. No, no, no, not ring the bell. But if you are giving

495
00:45:30,640 --> 00:45:37,800
feedback on a comment on the different platforms that helps to spread this podcast in the world.

496
00:45:37,800 --> 00:45:45,680
So that really helps us. And for now, thanks for listening and hopefully until another

497
00:45:45,680 --> 00:45:53,400
time and that was probably next year. So what is it? 2024? See you next year. Thank you.

498
00:45:53,400 --> 00:46:12,960
Thank you.