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,760 Hello, welcome again to the new recording of the Talking Security Podcast. This time 4 00:00:25,760 --> 00:00:34,040 again in the Defender for DevSecOps series and we're back with Pouyan and Sander. What 5 00:00:34,040 --> 00:00:35,640 are we going to do today? 6 00:00:35,640 --> 00:00:40,720 Today we're going to talk about the build section of DevSecOps. So last episode we talked 7 00:00:40,720 --> 00:00:46,120 about code and this episode we're going to talk all about the build environment and build 8 00:00:46,120 --> 00:00:47,120 process. 9 00:00:47,120 --> 00:00:58,400 How to build such piece of software or some infrastructure for example to enroll that. 10 00:00:58,400 --> 00:01:06,960 So let's dive in. Do we have, first of all, do we have anything to announce? It's almost 11 00:01:06,960 --> 00:01:14,400 MVP Summit, so we're both, all three of us, we are moving to America for a week. So we 12 00:01:14,400 --> 00:01:17,680 will do some recordings there, I guess. 13 00:01:17,680 --> 00:01:18,680 Hopefully. 14 00:01:18,680 --> 00:01:24,280 We'll take our gear, not this gear, but we'll take the gear with us and then let's see if 15 00:01:24,280 --> 00:01:29,360 we can talk to some people over there. So really looking forward. It will be my first 16 00:01:29,360 --> 00:01:33,320 time so hopefully it will be awesome. First time in Seattle. 17 00:01:33,320 --> 00:01:35,080 Your first time at the Summit as well? 18 00:01:35,080 --> 00:01:36,080 Yes. 19 00:01:36,080 --> 00:01:39,400 Oh really? I thought you were gone there for like a million times already. 20 00:01:39,400 --> 00:01:41,920 I think I'm the youngest MVP in this room. 21 00:01:41,920 --> 00:01:44,600 You're certainly not the youngest person in the room. 22 00:01:44,600 --> 00:01:53,200 No, no, no, no, definitely not. But let's dive into the DevSecOps build process. What 23 00:01:53,200 --> 00:01:57,360 is it? What things do we need to cover? 24 00:01:57,360 --> 00:02:02,720 Well I kind of see this in two different sections. So you have like the build process and you 25 00:02:02,720 --> 00:02:07,000 have the build environment. And I think it's really, really important to talk about security 26 00:02:07,000 --> 00:02:11,520 aspect here because in the normal DevOps flow, when someone talks about DevOps they usually 27 00:02:11,520 --> 00:02:16,120 talk about CI, CD, like building your software when something changes and then releasing 28 00:02:16,120 --> 00:02:21,960 it automatically instead of doing it by hand with FTP or just doing stuff by hand. But 29 00:02:21,960 --> 00:02:26,480 with DevSecOps it's all about the security aspect. So how do we make sure that this building 30 00:02:26,480 --> 00:02:31,520 process is very secure? Because it's very easy to introduce security issues with this. 31 00:02:31,520 --> 00:02:37,720 Yeah, first, first dive in the process and the environment, but first the process. Let's 32 00:02:37,720 --> 00:02:46,160 see what kind of things do we need to cover? Like the secure build, you talk already about 33 00:02:46,160 --> 00:02:54,160 security. What kind of aspects around security do we need to look into? 34 00:02:54,160 --> 00:03:01,000 Well I think it's good before we dive in into the aspects is to define what we mean when 35 00:03:01,000 --> 00:03:06,520 we are talking about build, right? Because when we are doing build on an infrastructure 36 00:03:06,520 --> 00:03:11,800 project, it's completely different than when we are talking about build, when we are about 37 00:03:11,800 --> 00:03:18,240 a.NET application where you need to generate stuff. So I think that's initially because 38 00:03:18,240 --> 00:03:24,280 after that we can start thinking, okay, there are multiple parallels that we can discuss 39 00:03:24,280 --> 00:03:30,040 and see, okay, what are the security challenges on that aspect? Is that a good intro? 40 00:03:30,040 --> 00:03:34,540 Yeah, that sounds good. I think it's a good thing that you're saying, Clique. We're not 41 00:03:34,540 --> 00:03:40,160 just releasing source code onto a machine. Also if we're talking about stuff like infrastructure 42 00:03:40,160 --> 00:03:46,000 as code or like bicep or stuff like this, you're not sending the bicep files to Azure. 43 00:03:46,000 --> 00:03:50,140 You're actually sending the result. So I think the build process could really be summed up 44 00:03:50,140 --> 00:03:55,080 as taking the source of a project and turning it into an artifact, turning it into something 45 00:03:55,080 --> 00:03:59,160 that will eventually run on a machine somewhere. And that can take many forms. Like in.NET 46 00:03:59,160 --> 00:04:04,400 you're compiling an application with a normal website. You're maybe just minifying it, but 47 00:04:04,400 --> 00:04:08,760 the HTML, the CSS and JavaScript stays the same. And with bicep, well, bicep is just 48 00:04:08,760 --> 00:04:11,560 turning it into ARM templates in the end. 49 00:04:11,560 --> 00:04:18,800 Yeah. I think what we also were discussing on before the start is how the build is also 50 00:04:18,800 --> 00:04:24,280 changing, right? Because with the introduction of the infrastructure as code, for example, 51 00:04:24,280 --> 00:04:28,320 what I told you guys earlier, in the early days when we did the infrastructure as code 52 00:04:28,320 --> 00:04:32,200 in Azure DevOps, we needed to do build and then create an artifact which we could use 53 00:04:32,200 --> 00:04:36,920 in the release deployed, which is now not the case anymore as well, right? 54 00:04:36,920 --> 00:04:44,120 Kinda, kinda. So now you use, yeah, you used to like click ops kind of the pipeline together 55 00:04:44,120 --> 00:04:48,400 with your by hand and it worked and it was really nice to begin with, but you didn't 56 00:04:48,400 --> 00:04:52,400 really have any backups. It wasn't in your Git repository or something like that. Nowadays, 57 00:04:52,400 --> 00:04:56,120 exactly what you say, you had like, well, you had, you used to have like a build section 58 00:04:56,120 --> 00:05:00,220 and a release section. And nowadays the modern approach is to use like a YAML file with your 59 00:05:00,220 --> 00:05:05,000 pipeline in it. And in there you define all of the build steps and then you can also define 60 00:05:05,000 --> 00:05:08,200 your release steps in there. Usually you do that in a separate stage or in a separate 61 00:05:08,200 --> 00:05:12,840 file. So it's nicely separated, but now it's a whole more, it's a, it's a different approach 62 00:05:12,840 --> 00:05:15,640 to building and releasing your application. 63 00:05:15,640 --> 00:05:20,880 Yeah. So if you focus on the, let's start with the infrastructure as code, for example, 64 00:05:20,880 --> 00:05:27,000 if you take a look when we are doing infrastructure as code or we are doing conditional access 65 00:05:27,000 --> 00:05:33,880 deployment through DevOps processes, right? Things, configuration as code. How do you 66 00:05:33,880 --> 00:05:40,920 see, how do we see the build stage and do we see any security issues in there as well? 67 00:05:40,920 --> 00:05:48,080 When only having infrastructure as code and deploying workplace related items, identity 68 00:05:48,080 --> 00:05:55,000 related items like conditional access, for example, can we deploy that in a secure way 69 00:05:55,000 --> 00:05:59,120 and how should we do that? 70 00:05:59,120 --> 00:06:03,800 So the authentication part you mean, or is it for example, for example, 71 00:06:03,800 --> 00:06:09,720 you need to connect to a certain Azure actor and try the environment. You need to deploy 72 00:06:09,720 --> 00:06:16,560 within the entire ID. You need to deploy the conditional access policies. And in this case 73 00:06:16,560 --> 00:06:24,800 we need an app rack that app rack needs some permissions, right? How do we secure that 74 00:06:24,800 --> 00:06:30,160 optimally? So nowadays we're using Key Vault. Is that the right way or do we store that 75 00:06:30,160 --> 00:06:31,320 in another way? 76 00:06:31,320 --> 00:06:36,800 So I think what you're going to is like, for this is of course kind of Azure DevOps specific, 77 00:06:36,800 --> 00:06:41,720 but I think you're leaning into like the service connections bit. Like how do we connect our 78 00:06:41,720 --> 00:06:46,840 Azure DevOps environment to our Azure environment to make the changes and how do we create a 79 00:06:46,840 --> 00:06:48,040 secure connection? 80 00:06:48,040 --> 00:06:56,880 It could be that that could be the way, but you can also run a script on a PowerShell 81 00:06:56,880 --> 00:07:02,080 script for example, or whatever. So there needs to be a connection and that connection 82 00:07:02,080 --> 00:07:05,080 can be established in different ways in my opinion. 83 00:07:05,080 --> 00:07:07,480 Yeah, yeah. You can definitely do multiple things. Yeah. 84 00:07:07,480 --> 00:07:13,120 So what you often see is I think at the moment that in Azure DevOps or people, you can create 85 00:07:13,120 --> 00:07:18,840 service connection, which you can use in your pipelines for example. But we had also seen 86 00:07:18,840 --> 00:07:25,520 scenarios where people hijacked the connection or the deployment process and then got the 87 00:07:25,520 --> 00:07:32,280 token out of the connectivity. And then through that they hopped through. So I think that's 88 00:07:32,280 --> 00:07:36,720 what you're meaning with the authentication part. But GitHub it's different. I think you 89 00:07:36,720 --> 00:07:42,800 need to store, you cannot define connections. You need to define credentials, which you 90 00:07:42,800 --> 00:07:45,120 can use to connect. 91 00:07:45,120 --> 00:07:48,080 Not really sure. I think under the hood, it kind of works the same in Azure DevOps where 92 00:07:48,080 --> 00:07:51,960 you create like a service connection to Azure. You can like use like an app registration, 93 00:07:51,960 --> 00:07:55,720 for example, like a service principle under the hood. But more modern approaches are like 94 00:07:55,720 --> 00:08:02,040 using a managed identity or a workload federation, something. Does someone here know the correct 95 00:08:02,040 --> 00:08:03,840 term? Some workload federation. 96 00:08:03,840 --> 00:08:09,240 Federated credential. That's something new. And that's really changing it because it's 97 00:08:09,240 --> 00:08:13,960 like managed identity, but it's so you don't have a secret anymore. 98 00:08:13,960 --> 00:08:18,080 Yeah, something like that. Yeah. And I think using, I mean, you can definitely use a PowerShell 99 00:08:18,080 --> 00:08:21,960 script, right? To like in your pipeline, say I want to connect to Azure. And instead of 100 00:08:21,960 --> 00:08:26,080 using a service connection, I'm just going to do it myself. You could, but I think this 101 00:08:26,080 --> 00:08:30,400 is going to come up often more in this episode is why would you do it yourself if you can 102 00:08:30,400 --> 00:08:35,400 use like a cloud hosted, Microsoft hosted or provider hosted option, like a service 103 00:08:35,400 --> 00:08:36,400 connection. 104 00:08:36,400 --> 00:08:40,760 And if we want, if we want to use that service connection, for example, what do we need to 105 00:08:40,760 --> 00:08:47,880 do to secure that optimally? Because last days I talked to a few customers regarding 106 00:08:47,880 --> 00:08:54,880 phishing resistant MFA that is more user based. From a user perspective, there are multiple 107 00:08:54,880 --> 00:09:03,440 challenges regarding MFA and phishing regard with the MFA token and so on. Is that, is 108 00:09:03,440 --> 00:09:07,840 that the same in the area with the service connection and using a managed, a managed 109 00:09:07,840 --> 00:09:14,680 identity of service principle, whatever, do we face the same challenges as well in, in 110 00:09:14,680 --> 00:09:20,480 creating connections between a DevOps environment, the Git em environment and a backend system, 111 00:09:20,480 --> 00:09:26,520 for example, Azure Active Directory or the, the, the build environment where you are publishing 112 00:09:26,520 --> 00:09:28,200 your, your software. 113 00:09:28,200 --> 00:09:33,960 I think, I think definitely, I think then it's more like, I don't, if you're using 114 00:09:33,960 --> 00:09:38,520 service connections, what I'm trying to say is that then it really depends on how much 115 00:09:38,520 --> 00:09:43,200 access you give that Azure resource, right? Like in the end you're using somewhere in 116 00:09:43,200 --> 00:09:49,160 Azure is defined a service principle, a user, let's just say it's like a user and that user 117 00:09:49,160 --> 00:09:52,800 is the thing that you're using in Azure DevOps to connect to your Azure environment. And 118 00:09:52,800 --> 00:09:55,560 I've seen a lot of cases where then they're like, Oh, it's really difficult to manage 119 00:09:55,560 --> 00:09:59,880 that. So we're just going to give that, give that service principle global admin and there 120 00:09:59,880 --> 00:10:04,800 we go. And then like what you said, like if you get your bill process hijacked, for example, 121 00:10:04,800 --> 00:10:11,020 you're using like a task that you don't know is malicious, then that of course could misuse 122 00:10:11,020 --> 00:10:15,960 that Azure credential and like hijack your systems. I think it's really important that 123 00:10:15,960 --> 00:10:18,760 you then know if I'm going to use service connections, if I'm going to use a PowerShell 124 00:10:18,760 --> 00:10:22,760 script, how much can I do? Like I want a minimal access. 125 00:10:22,760 --> 00:10:27,720 And I thought that we, in the last few months, we saw a few of these, these kinds of cases 126 00:10:27,720 --> 00:10:33,160 that a certain user, a developer is hacked and that the password and the multi-factor 127 00:10:33,160 --> 00:10:40,120 token was stolen and then they are into a DevSecOps pipeline or whatever. And then 128 00:10:40,120 --> 00:10:45,880 they running the software and then the software with malicious code in it is deployed to customers. 129 00:10:45,880 --> 00:10:53,200 So that is, if a user, a developer has access to that managed instance that apprack with 130 00:10:53,200 --> 00:11:02,760 a lot of rights in a certain environment, that could be potential big damage could be 131 00:11:02,760 --> 00:11:03,760 there. 132 00:11:03,760 --> 00:11:11,280 Yeah. Well then definitely in cases like this is of course, how do you say that? Like if, 133 00:11:11,280 --> 00:11:15,920 for example, I was hijacked, right? And I have a lot, I can have administrator rights 134 00:11:15,920 --> 00:11:20,160 somewhere, then that is bad, but hopefully at least my credentials are not used in the 135 00:11:20,160 --> 00:11:24,160 automated build pipeline. That is hopefully exactly. You see something you shouldn't do. 136 00:11:24,160 --> 00:11:28,040 You should definitely have like a separate entity or separate identity that connects 137 00:11:28,040 --> 00:11:31,880 to your Azure environment automatically. Of course, if someone has my token, they could 138 00:11:31,880 --> 00:11:35,000 probably go to the Azure portal. And if I have a lot of administrator, I can still delete 139 00:11:35,000 --> 00:11:40,080 stuff or delete the code, but at least it could not really be automated that much anymore. 140 00:11:40,080 --> 00:11:43,960 And then we're definitely going to have to talk about the, like exactly what you say, 141 00:11:43,960 --> 00:11:49,800 phishing resistant MFA, pass keys, passwordless authentication and that kind of stuff. But 142 00:11:49,800 --> 00:11:52,600 don't know how well that fits in the build process here. 143 00:11:52,600 --> 00:11:59,760 No, no, no. Now we are looking a little bit broader than only the build pipeline, but 144 00:11:59,760 --> 00:12:08,600 let's go back to the build process. What do we need to, we talked to some points. What 145 00:12:08,600 --> 00:12:16,120 do we need to cover next? Because we have, we have a built and then I've tried to deploy 146 00:12:16,120 --> 00:12:21,240 that built. What do we need to do in that, in that kind of steps? What do we need to 147 00:12:21,240 --> 00:12:27,160 do to secure? What do we store the credentials that are using? Are we only using a service 148 00:12:27,160 --> 00:12:35,880 connection or what is more within the build? So I think also pointing a little bit to the 149 00:12:35,880 --> 00:12:43,240 last question, I think it's a great topic. And I think if you zoom out on that topic, 150 00:12:43,240 --> 00:12:47,880 it's the whole reason why we are having this podcast, right? Because it's not in one process 151 00:12:47,880 --> 00:12:53,720 where we can solve that kind of issue. So the whole DevSecOps, it's the idea is to build 152 00:12:53,720 --> 00:12:59,400 that checks and controls in every stage and every phase. So for example, let's say we 153 00:12:59,400 --> 00:13:04,720 have that connection and if we have the right permission, we can use that connection. And 154 00:13:04,720 --> 00:13:11,760 we have, as you mentioned, our workflow instead of just somebody clicking it through the portal, 155 00:13:11,760 --> 00:13:16,720 but code defined stored in our repository. And like we discussed last time, we have our 156 00:13:16,720 --> 00:13:23,640 branch policies and repo protection in place. It minimizes the impact, the chance that somebody 157 00:13:23,640 --> 00:13:34,640 can hijack our workflow to build steps into it without checks being done ahead. So I think 158 00:13:34,640 --> 00:13:38,360 yes, there are possibilities, and I think there are a couple of big challenges when 159 00:13:38,360 --> 00:13:43,800 it comes to authentication side of the build or even release, because you're always working 160 00:13:43,800 --> 00:13:50,320 with service principles or user accounts or API keys, which have permanent permission 161 00:13:50,320 --> 00:13:51,320 basis. 162 00:13:51,320 --> 00:13:55,200 Exactly. Are you talking really a lot like minimizing the chances that your build process 163 00:13:55,200 --> 00:13:59,840 gets corrupted, gets attacked? 164 00:13:59,840 --> 00:14:08,640 Regarding on first time we talked about artifacts that we are not using anymore and we're still 165 00:14:08,640 --> 00:14:18,880 using it, but not for infrastructure scope. If we look at nowadays, should we use DevOps, 166 00:14:18,880 --> 00:14:24,200 GitHub, whatever, and why should we do that in a certain way? What are tools that we can 167 00:14:24,200 --> 00:14:32,680 use to optimally use it in the build process and to see how we can move forward on that? 168 00:14:32,680 --> 00:14:36,240 I got a couple of notes for this. One of the things, the tools, we're talking about toolings 169 00:14:36,240 --> 00:14:40,240 and how to optimize the security for your build and your build pipeline. There's definitely 170 00:14:40,240 --> 00:14:44,240 things that we also talked about in the last episode. We talked about vulnerability scanning. 171 00:14:44,240 --> 00:14:48,640 We talked about container scanning. There's definitely still a mention here for code QL, 172 00:14:48,640 --> 00:14:52,880 which is checking your code quality and stuff like that, maybe also vulnerabilities. You 173 00:14:52,880 --> 00:14:57,280 want to use those tools and those tools are best used in a build environment. Before you 174 00:14:57,280 --> 00:15:02,520 do a deployment to your production environment, there's going to be some vulnerability scanning 175 00:15:02,520 --> 00:15:07,920 happening. They're like, hey, in this version of the SQL that you're using in the package, 176 00:15:07,920 --> 00:15:11,360 we found a vulnerability and the deployment will be stopped. 177 00:15:11,360 --> 00:15:20,180 Stuff like this is really how you can secure your code deployment process. That is definitely 178 00:15:20,180 --> 00:15:24,200 something that with a DevSecOps approach, you want to automate. You don't want someone 179 00:15:24,200 --> 00:15:28,280 to say, oh no, let's just take a look at the vulnerabilities. We'll look at the vulnerabilities 180 00:15:28,280 --> 00:15:32,720 each sprint. No one actually does that. That needs to be automated. 181 00:15:32,720 --> 00:15:37,200 We had a great session on this topic with David, of course, on the DefSecOps, on the 182 00:15:37,200 --> 00:15:46,440 Defender for DevOps, sorry. How Microsoft is also helping to bring visibility into that 183 00:15:46,440 --> 00:15:52,600 process of the build and release. For example, what you exactly said is you want to see which 184 00:15:52,600 --> 00:16:00,520 vulnerabilities are coming in the code maybe, but also in the configuration-wise. Maybe 185 00:16:00,520 --> 00:16:07,280 secret scanning, we know GitHub has it already or the advanced security has it in house. 186 00:16:07,280 --> 00:16:12,760 With tools as Defender for DevOps, you can integrate, for example, with GitHub or with 187 00:16:12,760 --> 00:16:23,760 Azure DevOps. Then you step in into the build process and into the PR process. Then we can 188 00:16:23,760 --> 00:16:30,360 say, okay, if you create a PR to make certain changes, then this pipeline needs to run and 189 00:16:30,360 --> 00:16:37,280 then do some checks before we allow it to be merged. If there are any findings like 190 00:16:37,280 --> 00:16:43,520 there is a static password in your code or you are creating for... If we go back to 191 00:16:43,520 --> 00:16:51,520 the infrastructure scope, you are doing storage account with weak encryption or with a VM 192 00:16:51,520 --> 00:16:58,680 with a public IP address. You see that kind of configuration or at least which can end 193 00:16:58,680 --> 00:17:04,080 up into being vulnerable already into that build process. That will be integrated to 194 00:17:04,080 --> 00:17:10,640 Defender for DevOps as well, so in Defender for Cloud. What I really love about the Defender 195 00:17:10,640 --> 00:17:19,040 for DevOps is it has a feature. They call it PR integration where the feedback goes 196 00:17:19,040 --> 00:17:26,320 back to your PR. As a developer, you see, okay, I have a PR. Oh, on line 13, there was 197 00:17:26,320 --> 00:17:33,200 a static password found. On line 15, I had an adjacent template for a storage account, 198 00:17:33,200 --> 00:17:40,160 but I had a weak encryption model configured. As a developer, you don't need to escape your 199 00:17:40,160 --> 00:17:44,240 environment for that build phase, but they can bring it back to you. 200 00:17:44,240 --> 00:17:55,800 You're talking now about Defender to secure your code and the tools that you're using. 201 00:17:55,800 --> 00:18:01,320 Defender is integrating in GitHub and Azure DevOps. Are they the only tools that we are 202 00:18:01,320 --> 00:18:07,400 still using at the moment or are there any other tools that we are using to create a 203 00:18:07,400 --> 00:18:12,520 build environment? 204 00:18:12,520 --> 00:18:14,400 To create a build environment? 205 00:18:14,400 --> 00:18:17,240 To create your build, to create your code. 206 00:18:17,240 --> 00:18:22,760 I think there's definitely, I mentioned CodeCube a little bit. Things like SonarCube and SonarCloud 207 00:18:22,760 --> 00:18:28,000 that will also do a lot of code scanning for you. That will also make sure that the thing 208 00:18:28,000 --> 00:18:33,480 that you are going to deploy is secure or is at least secure enough according to the 209 00:18:33,480 --> 00:18:36,360 policies that you've set up. 210 00:18:36,360 --> 00:18:43,000 In the other end, the question is more or less, we are still using GitHub at the moment. 211 00:18:43,000 --> 00:18:48,040 I don't know exactly, are you still using GitHub as well? 212 00:18:48,040 --> 00:18:52,600 I use Azure DevOps and Azure DevOps Pipeline for work. 213 00:18:52,600 --> 00:18:59,280 Both are within the Microsoft ecosystem, more or less general products that we are using. 214 00:18:59,280 --> 00:19:06,320 Are there other tools like GitHub, like Azure DevOps that people in the wild are using to 215 00:19:06,320 --> 00:19:07,320 create code? 216 00:19:07,320 --> 00:19:10,520 Sure. To deploy their applications, maybe you mean. 217 00:19:10,520 --> 00:19:11,520 For example? 218 00:19:11,520 --> 00:19:17,200 Yeah, there's things like Jenkins, right? Which used to be GitLab, CircleCI, I believe 219 00:19:17,200 --> 00:19:20,720 GitLab definitely. CircleCI is a really famous one. 220 00:19:20,720 --> 00:19:22,840 GitLab is an on-prem environment. 221 00:19:22,840 --> 00:19:26,640 I don't know, it's also served. It's also hosted for you. 222 00:19:26,640 --> 00:19:30,000 It's hosted, but you can also build it by yourself. 223 00:19:30,000 --> 00:19:32,600 GitHub as well, I believe. I think a part of it. 224 00:19:32,600 --> 00:19:33,600 Not GitHub. 225 00:19:33,600 --> 00:19:36,720 I know Azure DevOps in the past, you could have it on-prem. 226 00:19:36,720 --> 00:19:37,720 Yeah, yeah, yeah. 227 00:19:37,720 --> 00:19:38,720 DevOps Foundation. 228 00:19:38,720 --> 00:19:39,720 DevOps Foundation. 229 00:19:39,720 --> 00:19:41,560 Yeah, yeah, yeah, exactly. 230 00:19:41,560 --> 00:19:44,040 But Jenkins is in the cloud service? 231 00:19:44,040 --> 00:19:45,040 Not sure, actually. 232 00:19:45,040 --> 00:19:46,040 Why is that? 233 00:19:46,040 --> 00:19:48,440 I'm happy to not really use it that often. 234 00:19:48,440 --> 00:19:55,680 For me, it's either. But if we are using tools like Defender or SonoCube or whatever to secure 235 00:19:55,680 --> 00:19:59,520 your code, is it possible to have that on the other tools as well? 236 00:19:59,520 --> 00:20:06,000 Because in my opinion, Defender is only available at the moment for GitHub and Azure DevOps. 237 00:20:06,000 --> 00:20:10,880 So within the Microsoft ecosystem, it's okay. But if we extend that, and we want to extend 238 00:20:10,880 --> 00:20:15,680 that to other developers, probably we can make a switch there as well. 239 00:20:15,680 --> 00:20:20,080 Yeah, I think the good thing about GitHub and Azure DevOps and that kind of stuff is 240 00:20:20,080 --> 00:20:24,800 that all of these things like vulnerability scanning, secret scanning, and hopefully in 241 00:20:24,800 --> 00:20:30,360 the future things like automatic package updates, it's just all integrated into GitHub, into 242 00:20:30,360 --> 00:20:32,440 Azure DevOps. 243 00:20:32,440 --> 00:20:37,400 For other platforms like GitLab and what we talked about also, you can definitely still 244 00:20:37,400 --> 00:20:42,500 install SonoCube, but it's more of a manual job. But I think, regardless of the platform 245 00:20:42,500 --> 00:20:46,360 you're using, you should be using these kind of tools to ensure that what you're going 246 00:20:46,360 --> 00:20:49,560 to deploy is secure and meets your expectations. 247 00:20:49,560 --> 00:20:54,320 Yeah, and in the modern world, we're using GitHub, for example, or Azure DevOps. And 248 00:20:54,320 --> 00:21:01,040 we try to, within the build process, we want to do everything within GitHub, like credentials, 249 00:21:01,040 --> 00:21:03,920 like a service connection, like code scanning, everything. 250 00:21:03,920 --> 00:21:09,320 Yeah, definitely use the tools and the options that your provider gives you. Don't start 251 00:21:09,320 --> 00:21:13,480 building stuff yourself. There's nothing really wrong with building stuff yourself. Who's 252 00:21:13,480 --> 00:21:17,280 going to maintain it? Who's going to maintain that PowerShell script that might be using 253 00:21:17,280 --> 00:21:21,120 an old version of the Azure API? Just use Azure DevOps service connections and Microsoft 254 00:21:21,120 --> 00:21:22,120 will host it for you. 255 00:21:22,120 --> 00:21:25,560 Another thing I might want to bring up into this process thing to kind of move away from 256 00:21:25,560 --> 00:21:31,720 the tooling. So as a developer, if I think about securing the build process, for me it's 257 00:21:31,720 --> 00:21:37,200 really important to also make sure that what you are trying to build and trying to publish 258 00:21:37,200 --> 00:21:44,760 is secure. There's a lot of articles online about people that accidentally also commit 259 00:21:44,760 --> 00:21:49,280 and build their Git folder. So they actually deploy their.git folder to a website. And 260 00:21:49,280 --> 00:21:52,960 then if you visit the website, you can just go to slash.git and steal all of the source 261 00:21:52,960 --> 00:21:53,960 code. 262 00:21:53,960 --> 00:21:57,480 So that's also definitely a thing that you, when you're going to build something, really 263 00:21:57,480 --> 00:22:02,440 inspect what is the result of that build. And am I deploying, for example, stuff like 264 00:22:02,440 --> 00:22:07,800 the Git ignore file that's really not necessary? Am I deploying some files that should actually 265 00:22:07,800 --> 00:22:12,720 be in the Git ignore? Where is my Git folder in there? Because it really shouldn't be. 266 00:22:12,720 --> 00:22:14,800 You want to make sure that your build is optimized. 267 00:22:14,800 --> 00:22:16,520 So let's search the internet. 268 00:22:16,520 --> 00:22:21,000 Yeah, there's tools for that. There's tools for that. You can just, you know, it will 269 00:22:21,000 --> 00:22:25,160 just go through tons of websites on the internet and just go to slash.git and bam, you got 270 00:22:25,160 --> 00:22:26,160 all the source code. 271 00:22:26,160 --> 00:22:27,160 You have the whole Git history then from there. 272 00:22:27,160 --> 00:22:29,600 Yeah, you have the entire, you have all the source code. And that's also the thing that 273 00:22:29,600 --> 00:22:33,480 I always tell people, like sometimes they commit a secret into their repo and they're 274 00:22:33,480 --> 00:22:37,320 like, oh no, I'm just going to put another commit on top of it to revert that. But I'm 275 00:22:37,320 --> 00:22:41,640 like, no, if someone has access to your Git history, they can just go back to last month 276 00:22:41,640 --> 00:22:43,760 and they'll find the original thing again. 277 00:22:43,760 --> 00:22:51,240 The same is for PRs. So some people say, okay, I have multiple commits in my PR and that contains 278 00:22:51,240 --> 00:22:56,400 a secret and then, but I merge it and I smash it to one. It's still in the history of your 279 00:22:56,400 --> 00:22:58,080 PR, you can find it. 280 00:22:58,080 --> 00:23:01,880 Just a bit of self-promotion. I have a blog post on my web page. No, but exactly. You 281 00:23:01,880 --> 00:23:03,440 want to, but if you're using... 282 00:23:03,440 --> 00:23:06,000 But how do you control that then? 283 00:23:06,000 --> 00:23:09,440 So what you do is you, if you're using stuff like GitHub or if you're using stuff like 284 00:23:09,440 --> 00:23:14,180 Azure DevOps, there's this feature called GitHub advanced security or GitHub advanced 285 00:23:14,180 --> 00:23:18,720 security for Azure DevOps. And this contains tools that you can just click with one click. 286 00:23:18,720 --> 00:23:22,880 You can enable it and then it will actually like every time you, when you will try to 287 00:23:22,880 --> 00:23:28,240 push code to Azure DevOps or to GitHub, it will scan all of your code. And if there's 288 00:23:28,240 --> 00:23:32,120 a secret in there, which it just learns machine learning, it's just smart. And then it will 289 00:23:32,120 --> 00:23:35,400 just reject your push. And there's it was... 290 00:23:35,400 --> 00:23:36,400 That's what GitHub has, right? 291 00:23:36,400 --> 00:23:37,400 Yeah. But also Azure DevOps. 292 00:23:37,400 --> 00:23:40,600 Yeah. That's pre-commit checking if there's a password. 293 00:23:40,600 --> 00:23:45,760 On the server as well. On the server it checks it. So the server receives a request with 294 00:23:45,760 --> 00:23:49,720 the new code and then before it accepts it, it scans it for secrets. And there's also 295 00:23:49,720 --> 00:23:54,440 really, really interesting where GitHub does is if it, for example, there's services like 296 00:23:54,440 --> 00:23:59,240 SendGrid, right? For email sending. And those API keys, like you said, they are just like 297 00:23:59,240 --> 00:24:05,460 permanently valid, which is a big problem. If that leaks, you have a really big issue. 298 00:24:05,460 --> 00:24:09,840 So a lot of companies are now doing that. The API key starts with like a prefix, like 299 00:24:09,840 --> 00:24:16,000 for SendGrid, I think it's SG and then a colon. And then what GitHub does is it when it detects 300 00:24:16,000 --> 00:24:21,120 a secret, starting with SG and colon, it will automatically send us a request to SendGrid 301 00:24:21,120 --> 00:24:27,200 to invalidate that API key. Which is like, even if you leak the secret, it will be immediately 302 00:24:27,200 --> 00:24:28,200 invalidated. 303 00:24:28,200 --> 00:24:32,920 You can do that as well for your own projects. You can define your own keys, which it will 304 00:24:32,920 --> 00:24:36,280 search in other repositories, I believe. 305 00:24:36,280 --> 00:24:40,880 That is useful, but it is scary because like if the secret just doesn't meet that regular 306 00:24:40,880 --> 00:24:44,720 expression or something, or doesn't meet the filters, then it will leak through. But yeah, 307 00:24:44,720 --> 00:24:49,320 you definitely want to make sure that your code. And also what I do in my pull requests, 308 00:24:49,320 --> 00:24:52,840 I have a pull request template set up. So every time one of my team members has a pull 309 00:24:52,840 --> 00:24:56,000 request, I have like a little checklist that you can just create in GitHub and then should 310 00:24:56,000 --> 00:25:02,120 develop. So like, did you add documentation? Does the project requirements need to be updated? 311 00:25:02,120 --> 00:25:05,520 For example, if you add a connection to a new database, you need to update so people 312 00:25:05,520 --> 00:25:06,520 can use that. 313 00:25:06,520 --> 00:25:10,200 Also in there, it's a bit of a manual thing, but like, did you leak any secrets? And I 314 00:25:10,200 --> 00:25:13,480 hope to make people think twice. Like first of all, I always tell people, don't put them 315 00:25:13,480 --> 00:25:16,800 in your repo and all that kind of stuff. I try to teach them about it, but also make 316 00:25:16,800 --> 00:25:21,200 it part of the PR flow that you actually have to visually check that checkbox. 317 00:25:21,200 --> 00:25:27,540 It's a check mark that you need to check. And it's visible. So you see it, it's visible 318 00:25:27,540 --> 00:25:31,960 and you think twice. That's what you realize with that one. 319 00:25:31,960 --> 00:25:35,920 You definitely want to automate it, but it's also just good to teach people. Just don't, 320 00:25:35,920 --> 00:25:39,960 you know, don't rely on tooling too much. Like then people are just not going to think 321 00:25:39,960 --> 00:25:42,720 about it anymore. They're going to work in an environment where these tools are not in 322 00:25:42,720 --> 00:25:45,360 place and then things are going to go unstuck. 323 00:25:45,360 --> 00:25:50,440 In the normal user environment, we have security awareness to educate people with phishing, 324 00:25:50,440 --> 00:25:57,080 with clicking on URLs and so on and so on. Within the Defender for DevOps, often in the 325 00:25:57,080 --> 00:26:03,040 DevOps, DevSecOps world, we need to create awareness regarding these kinds of stuff. 326 00:26:03,040 --> 00:26:10,400 So do you have a secret stored in your code or do you use other stuff that is malicious, 327 00:26:10,400 --> 00:26:14,960 that you can do stuff that you don't want to know that it does? 328 00:26:14,960 --> 00:26:20,560 I think awareness is one of the key aspects within a DevSecOps world. 329 00:26:20,560 --> 00:26:24,080 Yeah, definitely. That's also the thing that we're trying to integrate, right? Like the 330 00:26:24,080 --> 00:26:27,600 DevOps thing, it kind of exists. Lots of companies are doing it. It's so much better than doing 331 00:26:27,600 --> 00:26:32,160 stuff manually or Lisa's computer is the production release machine. You know, that's just that 332 00:26:32,160 --> 00:26:35,400 you don't want to work like that. You want an automated system and making it secure is 333 00:26:35,400 --> 00:26:36,400 very important. 334 00:26:36,400 --> 00:26:40,800 What I really love that I think I mentioned a couple of times on the PR integration of 335 00:26:40,800 --> 00:26:45,880 the Defender for DevOps. I mean, it doesn't force the developer to come to a security 336 00:26:45,880 --> 00:26:51,400 environment and the phish and phersa. But they talk the same on the same platform that 337 00:26:51,400 --> 00:26:56,760 they need to intend. But if we take a look on the build, right? So on the build side, 338 00:26:56,760 --> 00:27:01,400 there are credentials involved. And I think from our perspective, it's often about some 339 00:27:01,400 --> 00:27:05,300 ARM templates, PowerShell coding and that kind of, but I think when you are building 340 00:27:05,300 --> 00:27:13,100 an application, you have more requirement to that agent where you do the build, right? 341 00:27:13,100 --> 00:27:20,920 So bring us to that. What, if you are doing a build of an application, what are the requirements 342 00:27:20,920 --> 00:27:25,880 often that you are meet? Because I can imagine that organizations say, well, you can do this, 343 00:27:25,880 --> 00:27:34,400 but it's an, it needs a certain version of Java or net or it needs a certain network 344 00:27:34,400 --> 00:27:41,000 connectivity. Do you use like the GitHub runners and Azure DevOps runners or do you use your 345 00:27:41,000 --> 00:27:42,000 own stuff? 346 00:27:42,000 --> 00:27:46,000 Oh, we can talk about that. That's really interesting. One little thing that I wanted, 347 00:27:46,000 --> 00:27:49,360 we talked kind of about this yesterday and you triggered me about something. So one thing 348 00:27:49,360 --> 00:27:53,500 that I want to, I want to talk about really, really, it's really interesting is that there's 349 00:27:53,500 --> 00:27:57,920 also now, instead of like building your own CI CD pipeline and having to think about what 350 00:27:57,920 --> 00:28:02,400 version of Java you're using, are we using Ubuntu 20 or are we using Ubuntu 18? A lot 351 00:28:02,400 --> 00:28:05,360 of people are still using Ubuntu 18. They shouldn't do that anymore. There's also these 352 00:28:05,360 --> 00:28:10,200 approaches in Azure where you can just say, Hey, this is my GitHub link and this is a 353 00:28:10,200 --> 00:28:14,680 react project. Go release it. And again, Azure will just figure it out for you. So there's 354 00:28:14,680 --> 00:28:17,940 not even, you don't even need to think about it anymore. Just when there's a new commit 355 00:28:17,940 --> 00:28:21,680 on main, when some code is finished, Azure will automatically detect it kind of in a 356 00:28:21,680 --> 00:28:26,040 GitOps approach, just push it to the server. And then it's even more secure because you 357 00:28:26,040 --> 00:28:28,080 don't even need to think about the builds anymore. 358 00:28:28,080 --> 00:28:32,760 Yeah, we have the same with Sentinel for example, where it's a little bit different what they 359 00:28:32,760 --> 00:28:37,920 are doing. Sentinel is a Microsoft SIEM solution. So it's where they bring all the alerts and 360 00:28:37,920 --> 00:28:41,760 incidents together to create an overview, which we use often for our SOC and that kind 361 00:28:41,760 --> 00:28:47,600 of services. But what they do is you have also repository integration. And if you go 362 00:28:47,600 --> 00:28:52,280 and you say click and say, yeah, is it on DevOps or on GitHub? You say it's on GitHub, 363 00:28:52,280 --> 00:28:58,080 just as authenticated GitHub. And what they do is they install an extension, which creates 364 00:28:58,080 --> 00:29:05,880 a deployment workflow for you on the show. I think even there, there are multiple version 365 00:29:05,880 --> 00:29:11,640 because it looks like that Sentinel is pulling that. But because you created that connection, 366 00:29:11,640 --> 00:29:14,440 you installed an extension, which is doing... 367 00:29:14,440 --> 00:29:18,920 Yeah, it's pushing it. Yeah, yeah, something like that. Yeah, yeah. But that just, it's 368 00:29:18,920 --> 00:29:23,880 just another thing that could be automated and could be secured by Microsoft. But let's 369 00:29:23,880 --> 00:29:26,680 go back to what you're like, let's go back a step to what you're saying about like as 370 00:29:26,680 --> 00:29:31,240 a developer, what do I need? Because if we're thinking about deploying a bicep or deploying 371 00:29:31,240 --> 00:29:35,080 ARM or deploying Terraform, we usually don't need that much, right? I think you, like I'm 372 00:29:35,080 --> 00:29:39,400 just saying you guys probably need stuff like, you still need, your only thing you need is 373 00:29:39,400 --> 00:29:41,800 probably like some Linux machine with like the... 374 00:29:41,800 --> 00:29:42,800 PowerShell. 375 00:29:42,800 --> 00:29:43,800 With PowerShell. 376 00:29:43,800 --> 00:29:44,800 Azure PowerShell. 377 00:29:44,800 --> 00:29:47,800 I feel like that is all you need. But for like a developer for me, so I'm like deploying 378 00:29:47,800 --> 00:29:51,960 maybe an application with a backend that's written in.NET, a front-end written in React. 379 00:29:51,960 --> 00:29:56,880 So I'm probably, I'm gonna use modern.NET, so I'm running on Linux. But I definitely 380 00:29:56,880 --> 00:30:02,480 need a specific.NET version installed. I need a version of NPM installed, maybe yarn, 381 00:30:02,480 --> 00:30:06,800 maybe a lot of project dependencies that it all needs to pull in. And yeah, there's a 382 00:30:06,800 --> 00:30:11,120 lot more dependencies to build. Luckily with stuff like Docker, which we also kind of mentioned 383 00:30:11,120 --> 00:30:14,120 this, some of this pain goes away because you can just let Docker do all of this. But 384 00:30:14,120 --> 00:30:17,640 yeah, you definitely need more dependencies, which you also hope are secure. 385 00:30:17,640 --> 00:30:26,200 So do you use, even when you need to have certain specific version of software tooling, 386 00:30:26,200 --> 00:30:32,640 the public hosted, the managed versions of GitHub or Azure DevOps, or do you use your 387 00:30:32,640 --> 00:30:37,280 own? Because there has been, I think definitely in the past, there has been a lot of discussions 388 00:30:37,280 --> 00:30:43,980 like sharing and build agent with multiple organization. And there were some scenarios 389 00:30:43,980 --> 00:30:47,200 that people could see things that they shouldn't be able to see. 390 00:30:47,200 --> 00:30:51,560 Oh yeah, yeah, yeah. I remember it. So yeah, yeah, you're right. I always use that's a 391 00:30:51,560 --> 00:30:58,200 true risk, right? If you are talking about build, seeing, being able. So if you're running 392 00:30:58,200 --> 00:31:04,000 your program and I'm running my program on the same build agent and I find a way to escape 393 00:31:04,000 --> 00:31:09,240 and then pull your code out there as well, we talked about the connection, right? To 394 00:31:09,240 --> 00:31:14,800 take over the connection. But maybe instead of connection, we can step in and change the 395 00:31:14,800 --> 00:31:18,080 code or pull some of the code away. 396 00:31:18,080 --> 00:31:22,920 I think it's like, you know, there's this security thing where if you're securing your 397 00:31:22,920 --> 00:31:26,800 house, the only thing you need to care about is that your house is more secure than your 398 00:31:26,800 --> 00:31:30,580 neighbor because then the robbers will rob your neighbor and not you. And if I'm thinking 399 00:31:30,580 --> 00:31:37,960 about like setting up my, either my own like a hosted agent where my code is built on, 400 00:31:37,960 --> 00:31:42,340 like I have a VM in Azure somewhere that runs and builds all my code, I have the agent installed 401 00:31:42,340 --> 00:31:48,680 on it or I'm just using the Microsoft agent. I prefer to use the cloud version. We at the 402 00:31:48,680 --> 00:31:54,520 company I work in the beginning, we did use the, we just had our own VM. And then, I don't 403 00:31:54,520 --> 00:31:57,280 know, there was one guy that always took care of it, right? He was a great guy. He was really 404 00:31:57,280 --> 00:32:01,240 good at what he did. And at some point he was working with some other stuff. Four years 405 00:32:01,240 --> 00:32:05,560 later we discovered that there were no updates. That's like, and that's the thing. Like if 406 00:32:05,560 --> 00:32:08,720 you're working depends really on the company, on the company culture as well. If there's 407 00:32:08,720 --> 00:32:13,400 actually security specialists in there, if there's ops people on there and they, and 408 00:32:13,400 --> 00:32:17,640 you're building really important code that really needs to stay in your environment and 409 00:32:17,640 --> 00:32:20,560 your people are specialized in keeping that stuff up to date. 410 00:32:20,560 --> 00:32:26,040 Yeah. But if you are self hosting staff, then you need to take care of life cycle management. 411 00:32:26,040 --> 00:32:35,640 Exactly. And update, not only updating, but also, also like from a security perspective 412 00:32:35,640 --> 00:32:41,280 on day one, we have, I have zero days or you need to update on the second day. There's 413 00:32:41,280 --> 00:32:47,200 an open port that is discovered because you need to connect to an agent on a specific 414 00:32:47,200 --> 00:32:53,080 port and that's in that specific scenario needed. But two months later, that specific 415 00:32:53,080 --> 00:32:59,640 scenario has changed. Yeah. You need to change that port, close it, open another one or whatever, 416 00:32:59,640 --> 00:33:05,680 that you need to, you need to take care of all the stuff on prem. And if you're using 417 00:33:05,680 --> 00:33:11,440 a cloud agent, for example, then yeah, Microsoft or someone else is taking care of all that 418 00:33:11,440 --> 00:33:19,840 kind of stuff. And you have it on about your own house, secure it more than your neighbor 419 00:33:19,840 --> 00:33:24,520 because otherwise you're robbed. But what if you are living in an apartment where you 420 00:33:24,520 --> 00:33:29,600 have one house with 10 apartments and the main entrance, the main entrance should be 421 00:33:29,600 --> 00:33:37,120 secured. And that's the people from the apartment building that are securing that entrance. So 422 00:33:37,120 --> 00:33:43,760 in that case, it's the same for the cloud agent where I use the same agent as you do 423 00:33:43,760 --> 00:33:50,800 with your own company and Microsoft or another vendor needs to take care of the security 424 00:33:50,800 --> 00:33:58,440 on top of that agent that is running. But also if it's multi-threat, so I have multiple 425 00:33:58,440 --> 00:34:02,920 organizations that are using the same agent and so on. So Microsoft is taking care of 426 00:34:02,920 --> 00:34:06,760 that. Yeah. But the thing is for me that, you know, I'm not a security specialist. I 427 00:34:06,760 --> 00:34:12,480 do like to think that I know a bit about security, otherwise I might not be sitting here. But 428 00:34:12,480 --> 00:34:16,800 my job is to develop applications. It's to kind of, you know, come up with architecture 429 00:34:16,800 --> 00:34:23,240 for applications. My job is not to secure stuff. So I really, I can't, I can't, I cannot 430 00:34:23,240 --> 00:34:27,000 in good conscience use a self-hosted agent because I know that Microsoft will do a much 431 00:34:27,000 --> 00:34:30,920 better job securing it. And it's, you know, this is, it's, if you're working at a company, 432 00:34:30,920 --> 00:34:35,520 like what is your core thing that you're working on? Like a web shops core thing is building 433 00:34:35,520 --> 00:34:38,720 a web shop. So should they also be building their own identity provider? No, they should 434 00:34:38,720 --> 00:34:42,840 use a built one. Are you, are you in a very, are you working in like, I don't know, like 435 00:34:42,840 --> 00:34:46,800 an airline or like at a bank, you might be using your own agents because it's really 436 00:34:46,800 --> 00:34:50,840 important to you that you need to manage it yourself for normal companies. This is just 437 00:34:50,840 --> 00:34:56,760 not their thing. So I really advocate for using the cloud version and Microsoft has 438 00:34:56,760 --> 00:35:01,280 people working there 24 seven to keep that stuff secure and any zero days should be fixed 439 00:35:01,280 --> 00:35:03,440 immediately and you don't even need to think about it. 440 00:35:03,440 --> 00:35:09,880 From a life cycle perspective, I totally agree. But if you, let's, let's look in that apartment 441 00:35:09,880 --> 00:35:15,040 house where Microsoft needs to close that, that, that the first door, if you are running 442 00:35:15,040 --> 00:35:23,400 multi-threat agents and you are running on the same agent as I do, how do I, how do I 443 00:35:23,400 --> 00:35:30,120 know that is secured, that I can access your code in case of, I think, I think that's more 444 00:35:30,120 --> 00:35:34,080 of an implementation detail, if I'm honest. Like I know that there's probably like, let's 445 00:35:34,080 --> 00:35:38,320 say there's 10 VMs, right? And you're thinking that you're working on the same VM. It's probably 446 00:35:38,320 --> 00:35:43,440 some Docker host. It's probably some hyper V stuff. Maybe it's running on the same machine, 447 00:35:43,440 --> 00:35:47,240 but the only thing you may be sharing is a kernel underwater. I'm not sure even how it 448 00:35:47,240 --> 00:35:48,640 works. I don't need to think about it. 449 00:35:48,640 --> 00:35:55,040 Well, I think it's, it's, they are changing. Definitely with GitHub, um, it hasn't been 450 00:35:55,040 --> 00:36:01,480 a big shift on Azure DevOps. It was mainly on, uh, I hear myself very weird. Is it me 451 00:36:01,480 --> 00:36:08,000 or no, no, no. Okay. Um, on Azure DevOps, it was always a hosted windows and the agent 452 00:36:08,000 --> 00:36:15,600 just run that. Um, but when we went to the migration to GitHub, GitHub's all, uh, hosted, 453 00:36:15,600 --> 00:36:22,560 uh, uh, containers. Um, and I believe Azure DevOps is also now using mainly because they 454 00:36:22,560 --> 00:36:28,120 share that backend. I mean, I've been using hosted Linux agents on Azure DevOps for at 455 00:36:28,120 --> 00:36:34,000 least six years, I think. But are there now really VMs or are there already changed to 456 00:36:34,000 --> 00:36:35,600 a container? I believe. 457 00:36:35,600 --> 00:36:41,320 I'm pretty sure you can run a Docker container with the Azure DevOps agent in it. You can 458 00:36:41,320 --> 00:36:45,160 definitely do that. So that would already make it easier, right? You can just kind of 459 00:36:45,160 --> 00:36:49,760 get the latest version of that agent and it will update all of the vulnerabilities. Again, 460 00:36:49,760 --> 00:36:50,760 something you have to manage yourself. 461 00:36:50,760 --> 00:36:58,240 Yeah. But if I want to deploy that to an Azure subscription or I deploy that, that specific 462 00:36:58,240 --> 00:37:04,000 application on a certain environment, do I need to integrate that agent within my own 463 00:37:04,000 --> 00:37:07,000 environment or is what are you? 464 00:37:07,000 --> 00:37:11,520 That's a good question. I mean, one of the, where do you actually, where do you put it 465 00:37:11,520 --> 00:37:15,520 in your infrastructure somewhere? Where do you put it in your landscape? One of the most, 466 00:37:15,520 --> 00:37:19,600 um, like most often attacked environments, I think, or one of the most popular things 467 00:37:19,600 --> 00:37:23,520 to attack in an, in a company is the build server. Cause sometimes people don't really 468 00:37:23,520 --> 00:37:27,360 care about it. They don't keep it up to date. So if you can just hijack that, you can just 469 00:37:27,360 --> 00:37:30,480 find all the source code there. You can find all the credentials there. So maybe you want 470 00:37:30,480 --> 00:37:36,920 to sandbox it, I guess. I feel like you really do not want it to have access to all of your 471 00:37:36,920 --> 00:37:43,160 own premise or all the other servers. At the other hand, if you're deploying to virtual 472 00:37:43,160 --> 00:37:49,160 machines from the build agent, it has to have access to the VMs, right? Cause it needs to 473 00:37:49,160 --> 00:37:51,560 be able to come to put the artifacts on there. 474 00:37:51,560 --> 00:37:56,760 Yeah. So that's, I think, um, in my opinion, one of the biggest re, uh, wall, one of the 475 00:37:56,760 --> 00:38:01,960 reasons why we see, uh, that people are, or customers ask for having hosted self hosted 476 00:38:01,960 --> 00:38:09,880 agents. It's often, it has to do with networking because they have like networks, databases 477 00:38:09,880 --> 00:38:15,040 or something in the on-prem environment or in a cloud environment, which is not the same 478 00:38:15,040 --> 00:38:20,600 is you will get the same issue when, for example, if you go into cloud, right? If you go to, 479 00:38:20,600 --> 00:38:25,800 let's say you have Azure web app, uh, where you have everything, Fina integrated and you 480 00:38:25,800 --> 00:38:33,320 have Azure SQL as a backend. Um, so your Azure SQL is not publicly accessible anymore. And 481 00:38:33,320 --> 00:38:38,680 then you are going to do a build, uh, you are going to push the changes to your, uh, 482 00:38:38,680 --> 00:38:41,600 SQL database. That's not accessible anymore. 483 00:38:41,600 --> 00:38:46,680 True. I had a little note about that because some time ago I read that GitHub now does 484 00:38:46,680 --> 00:38:51,320 support this. So GitHub supports using a cloud hosted agent. So you don't need to think about 485 00:38:51,320 --> 00:38:57,080 it anymore, but you can then talk to V net integrated stuff on Azure. I'm like 99% sure 486 00:38:57,080 --> 00:39:00,240 I'm sure I'm right that I read about this. And then of course the first million comments 487 00:39:00,240 --> 00:39:04,400 were when will this be released for Azure devils? So I just looked that up because I 488 00:39:04,400 --> 00:39:08,760 believe, I believed it was completely impossible to use like a Microsoft cloud hosted agent 489 00:39:08,760 --> 00:39:13,360 and deployed to V net in Azure. And it kind of is the thing that Microsoft says on their 490 00:39:13,360 --> 00:39:18,960 documentation is that you just need to whitelist some IPs from that. And they change every 491 00:39:18,960 --> 00:39:22,200 week. They say they could change every week. So every week they upload a new list and then 492 00:39:22,200 --> 00:39:25,640 you need to upload those and whitelist those every week. But you can automate that. Yeah. 493 00:39:25,640 --> 00:39:31,880 But that's not new. That's the same as whitelisting the whole Western Europe data center IP address 494 00:39:31,880 --> 00:39:36,280 space. I mean, I had once a customer that said, yeah, give me the, I'm not going to 495 00:39:36,280 --> 00:39:40,280 whitelist that. Give me, I'm not going to open a firewall. Give me the IP address that 496 00:39:40,280 --> 00:39:44,320 I need to whitelist. You can download it. It's thousands and thousands of IP addresses 497 00:39:44,320 --> 00:39:51,800 and the changes that they remove. They remove IP addresses and so on. So changes are. So 498 00:39:51,800 --> 00:39:57,720 one of the, one of the other reasons we use ourselves, we use a self hosted containers 499 00:39:57,720 --> 00:40:03,980 on Kubernetes. And one of the reasons why we did that is because through that model, 500 00:40:03,980 --> 00:40:12,360 we have now the option to use the manage identity. You can do the same as well with the self 501 00:40:12,360 --> 00:40:17,240 hosted. So in Azure DevOps, you have like two versions of VM agent, but the one that's 502 00:40:17,240 --> 00:40:21,440 with the manage identity, I believe, I don't know. You can create like an Azure service 503 00:40:21,440 --> 00:40:25,440 connection with a managed identity and that will be used by the cloud hosted agent. Yeah. 504 00:40:25,440 --> 00:40:32,440 So you, what you do is you use the manage identity of the agent to authenticate to your 505 00:40:32,440 --> 00:40:39,160 Azure subscription, for example, to do some activities. Yes, exactly. So that's also a 506 00:40:39,160 --> 00:40:43,720 really awesome. Well, that's kind of the same thing you're doing, right? You just have a 507 00:40:43,720 --> 00:40:46,840 container. Yeah. You have the kind of the same thing. I want to ask you a question about 508 00:40:46,840 --> 00:40:51,520 this. So let's say that we need to, let's think in a modern way. So GitHub, if I'm correct, 509 00:40:51,520 --> 00:40:55,320 has the option to use a cloud hosted agent, which you don't need to update, which you 510 00:40:55,320 --> 00:40:59,880 don't need to maintain Microsoft or GitHub cares about all the security aspects of it, 511 00:40:59,880 --> 00:41:03,920 which is great. I can sleep at night. And let's say that it's correct that they can 512 00:41:03,920 --> 00:41:08,720 just talk to a V net integrated resources. So things that the internet cannot access, 513 00:41:08,720 --> 00:41:12,640 let's say Azure DevOps gets this as well, which you then still want to use self hosted 514 00:41:12,640 --> 00:41:21,560 agents. So for us it's double. Um, we do it partially for, so we use the build agents 515 00:41:21,560 --> 00:41:27,400 partially to use the manage identity, for example, to configure and maintain our own solutions, 516 00:41:27,400 --> 00:41:34,400 right? So our own platform and that kind of stuff, which are not internet facing. Um, 517 00:41:34,400 --> 00:41:40,800 but we also use that manage identity to do other stuff, uh, other resources, for example, 518 00:41:40,800 --> 00:41:45,080 without going too deep in it. So, um, how do I say it without saying too much about 519 00:41:45,080 --> 00:41:49,920 this? That's the fun part. But what you can do is for example, if you're in a scenario 520 00:41:49,920 --> 00:41:54,920 that you are, you're an MSP, right? You're not doing nothing with security. You're an 521 00:41:54,920 --> 00:42:00,200 MSP and you are using Azure Lighthouse to manage your customers. Normally you need to 522 00:42:00,200 --> 00:42:05,840 have a service principle which is going there. So you have always an epi registration with 523 00:42:05,840 --> 00:42:11,400 a secret, which is vulnerable for that. So in that scenarios, you can also decide to 524 00:42:11,400 --> 00:42:16,840 go to manage identities of your containerized solution. So when you are doing something 525 00:42:16,840 --> 00:42:21,840 as infrastructure scope to your customer or you are doing as your lending zone configuration, 526 00:42:21,840 --> 00:42:28,440 you can use those connections, right? Um, to do the proficienting of that. So in our 527 00:42:28,440 --> 00:42:35,320 opinion, being able to using that manager identity, um, but it solves a lot of the problem 528 00:42:35,320 --> 00:42:38,400 that you initially mentioned. 529 00:42:38,400 --> 00:42:43,920 I don't really understand the difference though between using a, like I configure like a managed 530 00:42:43,920 --> 00:42:50,160 identity in Azure for my Azure DevOps or GitHub action build, right? Build agents. The one 531 00:42:50,160 --> 00:42:55,520 that's made by Microsoft in the cloud somewhere. Um, and I only use that one for pro deployment 532 00:42:55,520 --> 00:42:58,760 permissions. It's not going to be able, it's not going to be allowed to like, I don't know, 533 00:42:58,760 --> 00:43:02,640 change Azure settings, you know, that as little access as possible. You're doing kind of the 534 00:43:02,640 --> 00:43:08,960 same thing. You're hosting your, uh, build agent yourself, but you're also talking about 535 00:43:08,960 --> 00:43:12,400 the managed identity access. But how does that differ from what I'm saying with the 536 00:43:12,400 --> 00:43:16,160 service connection and managed identity? 537 00:43:16,160 --> 00:43:21,200 Um, service connection with the managed identity. 538 00:43:21,200 --> 00:43:27,280 Yeah. You're saying like on your Kubernetes environment, you can like configure, uh, it 539 00:43:27,280 --> 00:43:32,720 can be a VM as well. It can be a Docker, uh, container. Yeah. Your pod in Kubernetes has 540 00:43:32,720 --> 00:43:37,360 a managed identity associated with it. And in my Azure DevOps cloud hosted agent also 541 00:43:37,360 --> 00:43:43,540 has a managed identity because of the service connection. Yeah. But it's on the VM, right? 542 00:43:43,540 --> 00:43:48,520 On the cloud hosted. Yeah. So, okay. So is your, your, your, you don't have on the cloud 543 00:43:48,520 --> 00:43:50,600 hosted one. You don't have managed identity, right? 544 00:43:50,600 --> 00:43:54,880 No, no, no. But the cloud hosted one uses a service connection to talk to Azure. Yeah. 545 00:43:54,880 --> 00:44:00,960 And that service connection uses a managed identity. 546 00:44:00,960 --> 00:44:06,840 That is not possible. All right. Pretty sure it is a federated connection. I mean, I'm 547 00:44:06,840 --> 00:44:11,480 pretty sure it is possible. Okay. Let's just say service principle because the idea behind 548 00:44:11,480 --> 00:44:19,260 managed identity is that the identity is not managed by you. Exactly. So you don't know 549 00:44:19,260 --> 00:44:24,160 the secret of it. Exactly. And I, I, um, maybe we need to take this offline podcast, have 550 00:44:24,160 --> 00:44:26,840 a look around. Maybe we can put it in the show notes or something like that. Something 551 00:44:26,840 --> 00:44:32,000 like that. That would be awesome. In any case, what the thing that, um, let's say that the 552 00:44:32,000 --> 00:44:36,840 security aspect would also be managed by Microsoft. Yeah. So the, the, the update parts would 553 00:44:36,840 --> 00:44:40,200 be managed by Microsoft. I could integrate with V net. I could integrate with my private 554 00:44:40,200 --> 00:44:45,320 resources. Would there still be benefits to using self hosted agents? If the security 555 00:44:45,320 --> 00:44:49,040 aspect was handled by Microsoft in the cloud and if the V net integration was handled by 556 00:44:49,040 --> 00:45:02,880 Microsoft. Um, well, um, depends on your level of security, I think. And the, the application 557 00:45:02,880 --> 00:45:07,720 and how much risk you accept. For example, if you are doing some infrastructure code 558 00:45:07,720 --> 00:45:14,240 and deploying some resources, it's way different than if you are building databases and application 559 00:45:14,240 --> 00:45:19,400 and which are doing financial stuff or true. Yeah. That's a good point. So I think it's 560 00:45:19,400 --> 00:45:27,160 an, there's always a risk with the public hosted by someone else. Um, from a modern 561 00:45:27,160 --> 00:45:31,520 way I do accept it. Like if you're a small organization, you don't have the resources, 562 00:45:31,520 --> 00:45:36,280 don't start with it. Right. I do completely because you need to manage it. You have lifecycle 563 00:45:36,280 --> 00:45:41,400 management, you need to patch it, you need to monitor it. You need to have the fender 564 00:45:41,400 --> 00:45:47,960 on it. You need to alert, react on it. So yeah, on that sense, I do agree with you guys 565 00:45:47,960 --> 00:45:55,120 that that if you don't have the resources and the capacity to do it well, um, then don't 566 00:45:55,120 --> 00:46:01,880 do it. But if you have like, but I think that's in always the case. If you have the resources, 567 00:46:01,880 --> 00:46:06,520 the budgets and to make, if it makes fun, if it makes sense financially, if there's 568 00:46:06,520 --> 00:46:09,400 like, if you did like your risk assessment and you're saying, well, this is a pretty 569 00:46:09,400 --> 00:46:13,240 big risk for organization. It depends on the user. It depends. That's a great consultant 570 00:46:13,240 --> 00:46:20,040 answer here. Definitely. I have one last thing. Um, we talked about to build process, the 571 00:46:20,040 --> 00:46:27,560 built environment, but if we want to access from that development, a developer perspective, 572 00:46:27,560 --> 00:46:36,440 if I want to access that, uh, that the built environment, the, to, to create code and so 573 00:46:36,440 --> 00:46:41,200 on, you're doing that on your own laptop. I'm creating code on my own laptop is what 574 00:46:41,200 --> 00:46:44,680 you're saying, right? Yeah. I'm using my local digital studio or rider, stuff like that. 575 00:46:44,680 --> 00:46:51,120 How can, how can, and maybe we, we, we need to take another episode on that, but how does 576 00:46:51,120 --> 00:46:58,520 dev box within Azure Azure dev box? How does that come into place regarding the things 577 00:46:58,520 --> 00:47:05,840 that we're talking about? Because securing your build, uh, stuff, right. It's also securing 578 00:47:05,840 --> 00:47:10,200 the entrance, how you access your build. Yeah. I think that's, I think, I think we talked 579 00:47:10,200 --> 00:47:15,400 a bit about this in the first episode about workspace and management a bit. Yeah. I talked 580 00:47:15,400 --> 00:47:19,040 to a colleague yesterday cause they were working for a client and I was like, so what kind 581 00:47:19,040 --> 00:47:22,640 of environment are you using? He said, like, I'm using, I'm using the, uh, the Microsoft, 582 00:47:22,640 --> 00:47:25,920 what was it called? Microsoft box in Microsoft or Azure dev box or something. And he said 583 00:47:25,920 --> 00:47:30,520 that works really, really well, which we talked in the first episode about it, that I've heard 584 00:47:30,520 --> 00:47:34,480 of people were using it or like stuff like GitHub code spaces, which is even more like 585 00:47:34,480 --> 00:47:38,800 as a sauce platform. I think it is definitely very interesting. And we could maybe dedicate 586 00:47:38,800 --> 00:47:44,080 another episode to this. Maybe I miss it. And maybe what that also our listeners, can 587 00:47:44,080 --> 00:47:50,600 you maybe, uh, what is that? That's a great point. Yeah. Let's talk about that. The, the 588 00:47:50,600 --> 00:47:58,600 dev box is, um, more or less a workplace within Azure that you can spin up a sort of an ACD 589 00:47:58,600 --> 00:48:04,720 environment. Um, it's not AVD. Don't don't go to virtual desktop. Yeah. It's, it's not 590 00:48:04,720 --> 00:48:10,200 an AVD environment, but it's a virtual workplace that you run in Azure. So you can connect 591 00:48:10,200 --> 00:48:18,400 it remotely, but it's dedicated to a subscription or a, a, a, an environment that is used to 592 00:48:18,400 --> 00:48:23,140 develop stuff. All the, all the software needed for program software development is already 593 00:48:23,140 --> 00:48:26,840 installed on it. So instead of like getting a new laptop from your work and spending two 594 00:48:26,840 --> 00:48:32,920 days configuring visual studio, official leader code, GitHub, get crack. It's already all 595 00:48:32,920 --> 00:48:36,760 done for you. So you can just, you know, click on start or there's a new developer. It's 596 00:48:36,760 --> 00:48:41,840 a VM still it's under the hood. It's a VM AVD probably as well. It's just AVD on steroids, 597 00:48:41,840 --> 00:48:47,800 I guess. Yeah. It's not AVD, but it's, it's a VM where you can, yeah. But otherwise, I 598 00:48:47,800 --> 00:48:54,760 hear people are complaining dedicated decision about definitely, but for interesting about 599 00:48:54,760 --> 00:49:00,640 the dev box and that's, that's one of the nicest experiences that it's dedicated to 600 00:49:00,640 --> 00:49:06,700 a subscription. And with that, from a cost perspective, that subscription belongs to 601 00:49:06,700 --> 00:49:11,840 one project. So you have a project, you're running that project and what are the costs 602 00:49:11,840 --> 00:49:15,680 of that for the prep, the running costs for that project. So you have a subscription, 603 00:49:15,680 --> 00:49:19,280 all the costs are on that subscription. So you have a one project with that, with that 604 00:49:19,280 --> 00:49:25,920 costs. So it helps also when you hire externally, external people, they can get access to the 605 00:49:25,920 --> 00:49:35,200 dev box and exactly. And only if you are running a bill pipeline or whatever, it's only based 606 00:49:35,200 --> 00:49:40,520 on that specific Azure subscription or multiple Azure subscription that you are attached to 607 00:49:40,520 --> 00:49:46,320 the dev box. You can access other resources in your environment. So it's really specific. 608 00:49:46,320 --> 00:49:50,800 But I think it's definitely, I definitely have some more questions or things to say 609 00:49:50,800 --> 00:49:53,400 about this. I think it's definitely good to talk more about this later, but one little 610 00:49:53,400 --> 00:49:59,840 question about this. So how the build process, how is this related to dev box? 611 00:49:59,840 --> 00:50:08,920 Now if we, the thought that was in my head was if we are building a, an application and 612 00:50:08,920 --> 00:50:15,560 so you're running a pipeline or whatever, we can secure that on an optimal way, but 613 00:50:15,560 --> 00:50:21,480 accessing that bill pipeline, if you don't secure the access to your bill pipeline. And 614 00:50:21,480 --> 00:50:25,800 we talked a little bit about in the first episode regarding a workplace, right? But 615 00:50:25,800 --> 00:50:33,640 on the other hand, you can access a GitHub environment, you do authentication and multi-factor 616 00:50:33,640 --> 00:50:40,520 and so on. But if you have your source code, source code within a official study, your 617 00:50:40,520 --> 00:50:43,560 local machine. Yeah. So yeah, exactly. 618 00:50:43,560 --> 00:50:46,000 That was the reason why it pops up in my head. 619 00:50:46,000 --> 00:50:49,600 Exactly. You could, you could definitely secure and like put all the security measures in 620 00:50:49,600 --> 00:50:55,520 place to make sure that your code is deployed securely onto your, well, the thing you're 621 00:50:55,520 --> 00:51:00,360 your, your landing zone, wherever you're putting it. But yeah, then we kind of go back to the 622 00:51:00,360 --> 00:51:05,480 question of how do you secure the access to the thing that is being built. And that could 623 00:51:05,480 --> 00:51:09,240 be exactly something like dev box, like where at the other hand, I feel like you could, 624 00:51:09,240 --> 00:51:13,160 you know, pry this laptop from my cold dead hands. Like don't, I love having a laptop, 625 00:51:13,160 --> 00:51:16,720 but that you're completely right. If I left the company somewhere, I could still have 626 00:51:16,720 --> 00:51:20,880 that code on my laptop. I could take that with me with dev box. Yeah. You could just, 627 00:51:20,880 --> 00:51:25,680 you know, delete, disable my Azure account and you don't have, you don't need to format 628 00:51:25,680 --> 00:51:29,760 my computer anymore. It doesn't need to collect dust for five years in a closet somewhere. 629 00:51:29,760 --> 00:51:36,840 I think I know someone from, from the Microsoft team who is on, on that box. So we probably 630 00:51:36,840 --> 00:51:43,840 can invite a special guest to have a specific scenario or a specific episode on that box. 631 00:51:43,840 --> 00:51:49,040 Let's do that. Sure. It's really good. And regarding the build process environment and 632 00:51:49,040 --> 00:51:56,600 stuff that we do, do we need to take another thing or did we miss something? Maybe, maybe 633 00:51:56,600 --> 00:52:00,560 a simple thing that I sometimes see people do. I think we, we definitely talked a lot 634 00:52:00,560 --> 00:52:05,040 about making sure that your build process is secure, making sure that you have like 635 00:52:05,040 --> 00:52:12,320 a well fitting build environment, like either self hosted or like cloud hosted, making sure 636 00:52:12,320 --> 00:52:16,200 that it fits. One little thing that I sometimes see people do is that they're kind of new 637 00:52:16,200 --> 00:52:20,280 to this build process and they're like, Oh, I need a specific task. Right. And then they're 638 00:52:20,280 --> 00:52:26,880 looking on the marketplace for like GitHub actions or Azure DevOps tasks. You really 639 00:52:26,880 --> 00:52:32,000 want to make sure that the tasks you're using are okay tasks. Like there's even settings 640 00:52:32,000 --> 00:52:38,340 in Azure DevOps, I believe to not allow marketplace tasks. If you could have everything secured, 641 00:52:38,340 --> 00:52:43,280 but then you download a task that just copies all of the source code and sends it to Russia. 642 00:52:43,280 --> 00:52:50,880 You could, so you definitely want to make sure that the tasks you're using are secure. 643 00:52:50,880 --> 00:52:55,060 They are, they're trusted. And yeah, cause you don't know, you don't know the source 644 00:52:55,060 --> 00:52:58,200 code of the task. You don't know what they're doing. So the things that are happening in 645 00:52:58,200 --> 00:53:02,040 your build, you want to make sure that those are okay. Those are secure. That's a really 646 00:53:02,040 --> 00:53:06,600 good one because I think that's happening more often than people. Yeah, exactly. I need 647 00:53:06,600 --> 00:53:11,000 to replace some tokens. Oh, and I know that this one has a 600 downloads and the last 648 00:53:11,000 --> 00:53:14,440 update was four years ago, but it does what it needs to do. So I'm just going to use that 649 00:53:14,440 --> 00:53:19,640 one. Like, ah, so we spoke about the technology and I think the last one was great, but is 650 00:53:19,640 --> 00:53:26,800 there also a human interaction that we can discuss if it comes to our bark, more role 651 00:53:26,800 --> 00:53:34,560 based access requirements? Other, what do we expect from, um, our team when it comes 652 00:53:34,560 --> 00:53:39,320 to, I think if you're like running a build pipeline, it's also definitely, you want to 653 00:53:39,320 --> 00:53:43,920 make sure that it's only specific people can run specific pipelines where like deploying 654 00:53:43,920 --> 00:53:48,920 your cloud resources in a really big corporate environment. Maybe only the, you know, the, 655 00:53:48,920 --> 00:53:52,880 the ops people need to be able to deploy actual Azure production resources. There needs to 656 00:53:52,880 --> 00:53:58,640 be the four I principle where if I want to change the connectivity, uh, stuff in Azure, 657 00:53:58,640 --> 00:54:02,360 you know, all of the V net stuff, all the connections of Azure firewall, you want to 658 00:54:02,360 --> 00:54:06,040 make sure that your colleague Steve, that is also really good and you know, works with 659 00:54:06,040 --> 00:54:10,400 the, is specialized in this. He also needs to have a look at it. That's kind of, I guess 660 00:54:10,400 --> 00:54:13,740 the human aspect. You want to automate your, automate your build process. That's the entire 661 00:54:13,740 --> 00:54:20,300 thing about DevOps and kind of, but you want to also make sure that when specific and important 662 00:54:20,300 --> 00:54:23,840 things are happening, that's, I think where you need a human to double check. 663 00:54:23,840 --> 00:54:30,000 Yeah. But also a role based, you have a pull request. It need to be approved and so on 664 00:54:30,000 --> 00:54:36,480 just before the belt is actually running for ice principle, maybe six eyes that you want 665 00:54:36,480 --> 00:54:41,800 to cover. I think that's, that's important. And also what you mentioned a few minutes 666 00:54:41,800 --> 00:54:48,240 earlier regarding the, the, the, the list that you need to approve the check mark that 667 00:54:48,240 --> 00:54:56,640 you need to do before moving into PR. I think that are things that awareness we talked a 668 00:54:56,640 --> 00:55:01,640 little bit about that, the awareness also within the DevSecOps, the DevOps people. Yeah. 669 00:55:01,640 --> 00:55:05,200 That needs to be, that, that needs to be raised in my opinion. 670 00:55:05,200 --> 00:55:09,200 Yeah. We want to make sure we want to know what we're deploying. Like the, I think that's, 671 00:55:09,200 --> 00:55:12,740 I think that's a good way to say we want to know what we're deploying and we, the deployment 672 00:55:12,740 --> 00:55:15,480 should have an automatically, that is what we're doing all of this for. We just want 673 00:55:15,480 --> 00:55:20,440 to have code and we want it to run on production and we don't want to use Lisa's computer to 674 00:55:20,440 --> 00:55:24,840 do that. We want to use a cloud hosted agent, a self hosted agent, just let it happen. But 675 00:55:24,840 --> 00:55:28,080 what is being deployed? So you don't know that thing. It's like a whole, it's a whole 676 00:55:28,080 --> 00:55:34,360 old joke about, you know, I don't know. I don't know. Introduce her to me. No, but I 677 00:55:34,360 --> 00:55:40,200 don't, it's on the flight and the eight. Sure thing. So like one specific, one team 678 00:55:40,200 --> 00:55:45,000 members laptop is always used to like, deploy to production and that's an old man, whatever 679 00:55:45,000 --> 00:55:50,080 we all know that scenario with customers that there's all always one server that has enough 680 00:55:50,080 --> 00:55:54,200 permission to do the deployment. Exactly. I have faced that personally with a, with a 681 00:55:54,200 --> 00:55:58,680 really big enterprise customer when it came, every need, everything needed to be dev ops 682 00:55:58,680 --> 00:56:03,160 and everything needed to be infrastructure scope. But then you needed to email the code 683 00:56:03,160 --> 00:56:07,920 to somebody and then that person went to an SSH to an Ubuntu server because that server 684 00:56:07,920 --> 00:56:14,720 had the right login already to the Azure site. So they run it manually then and they, oh, 685 00:56:14,720 --> 00:56:19,920 nice. I can add one more thing to add one more thing on top of that. I used to do an 686 00:56:19,920 --> 00:56:23,800 internship and I also like finished my studies at the Dutch tax services to the blessing 687 00:56:23,800 --> 00:56:27,320 needs. And it was also, I worked at like a very modern department there where they built 688 00:56:27,320 --> 00:56:31,760 a mobile app. So it was really fun. And they also started doing like deploy and build agency 689 00:56:31,760 --> 00:56:36,040 ICD in there. So, you know, the code was built and quality was tested, like all the stuff 690 00:56:36,040 --> 00:56:41,280 we talked about today. And then there was a step to go to a specific Bali, you know, 691 00:56:41,280 --> 00:56:45,880 to go to a specific place in the company where you had to fill in an A4 paper. And then afterwards 692 00:56:45,880 --> 00:56:49,360 the process would continue, which I just found really, really funny. It's all super automated 693 00:56:49,360 --> 00:56:52,600 until you get to the deeper and deeper parts where you actually need to write a piece of 694 00:56:52,600 --> 00:56:59,040 paper and go somewhere. And yeah, it's not, it's not, it's not particularly wrong. It's, 695 00:56:59,040 --> 00:57:02,800 it's good that you have to sign off, I guess in a government environment. Yeah. Yeah. On 696 00:57:02,800 --> 00:57:09,320 the other hand, we want to try to digitalize everything. And then if you need to sign a 697 00:57:09,320 --> 00:57:15,360 paper, it could be good. It could be weird for some people, but on the other hand, if 698 00:57:15,360 --> 00:57:20,040 you have, you need to take that step. So you edit for awareness perspective, I think is 699 00:57:20,040 --> 00:57:23,880 really good. Yeah. Okay. I guess. Yeah. I mean, everything could of course be optimized 700 00:57:23,880 --> 00:57:27,000 better, but you do definitely have a point, especially that's more to cover the change 701 00:57:27,000 --> 00:57:31,200 management than I think. Right. I guess a little bit like who is, who is authorizing 702 00:57:31,200 --> 00:57:37,360 the deployment, you know, that kind of stuff. Yeah. Because that's fun to me. Big important 703 00:57:37,360 --> 00:57:40,880 thing, I think in our next step, because I believe the next one is going to be about 704 00:57:40,880 --> 00:57:45,280 release then. I'm not really sure. We'll have to, we'll have to take a look. Yeah. Okay. 705 00:57:45,280 --> 00:57:51,800 But because the change management is going to be a big one, I think, because when it 706 00:57:51,800 --> 00:58:01,720 comes to build and deployment, we deploy more often than we did previously. Right. So maybe 707 00:58:01,720 --> 00:58:05,680 in the past we did collect all the changes and then we did a deployment once a month 708 00:58:05,680 --> 00:58:13,680 or something. But now we are doing multiple ones. So, um, and this is a really, uh, challenge 709 00:58:13,680 --> 00:58:18,640 for this with a couple of customers of mine that say, okay, we need to be in control. 710 00:58:18,640 --> 00:58:24,760 We need to see how much deployments we need to the production environment. Um, but I think 711 00:58:24,760 --> 00:58:31,000 we'll take that for the next episode. Let's close this one. Yeah. We are almost an hour 712 00:58:31,000 --> 00:58:40,840 or so. We make that. Um, let, let's look a little bit back. Um, we covered the build 713 00:58:40,840 --> 00:58:48,680 pro the build process, the built environments. Um, we talked about a little bit dev box, 714 00:58:48,680 --> 00:58:54,040 make a little bit, a little step outside. Um, we talked about securing code, uh, also 715 00:58:54,040 --> 00:59:00,320 within this episode. So, uh, we, I think there are lots of aspects within the build that 716 00:59:00,320 --> 00:59:07,640 comes into place. Um, and that's make the mix. This one of the interesting topics, the 717 00:59:07,640 --> 00:59:14,720 steps within creating, uh, an application or building, um, an infrastructure, uh, you 718 00:59:14,720 --> 00:59:22,040 need to take care of your build because a lot can go wrong within this step. Yeah, definitely. 719 00:59:22,040 --> 00:59:28,000 So we talked about it, about the defender for DevOps, um, in a few episodes earlier 720 00:59:28,000 --> 00:59:39,560 on the, uh, what was it? The defender for service, uh, of the, uh, and for series. So 721 00:59:39,560 --> 00:59:43,480 if you want to have, you are interested in that one, uh, take a, have a look at that 722 00:59:43,480 --> 00:59:50,200 episode. Um, on the other end, that was it for today built and that let's look into the 723 00:59:50,200 --> 00:59:56,280 next one and probably release or something in that, uh, maybe at summit we'll see. Yeah, 724 00:59:56,280 --> 01:00:00,320 let's see if we can connect with, uh, with, with some people over there and see if we 725 01:00:00,320 --> 01:00:06,000 can create, uh, some other content, uh, on the other side of the ocean. Definitely. Let's 726 01:00:06,000 --> 01:00:11,000 do that. So thanks for today. If you liked this, uh, this podcast series, um, like and 727 01:00:11,000 --> 01:00:19,080 subscribe, um, and also, um, let us know if you want to know more about a specific scenario 728 01:00:19,080 --> 01:00:24,360 or what else, uh, we will take care of that and see if we can create, um, an, an next 729 01:00:24,360 --> 01:00:28,920 episode on that. So reach out to us on the socials and, uh, I see you next time. Thank 730 01:00:28,920 --> 01:00:55,920 you guys. Thank you. Thank you.