Welcome to the Talking Security podcast. We will talk about items related to Microsoft security. Hello, welcome again at a new Talking Security podcast. DevSecOps series. Within the DevSecOps series. This is the second recording. First time we talked about the developer security workplace, the developer workplace and what we should do from a security perspective. Today we're talking about complete and other aspect of DevSecOps. So within DevSecOps
there are different aspects that we want to address in the next few recordings. So probably seven or eight or the next recording we will touch that. Today we are touching the code base but also security from a developer's perspective. The developer in-house standard. So what's your view on security within the developer's area? I think that when you're talking about developers, what we're really good at is writing code
and that's kind of what we're paid to do. And I often see that security from a developer's standpoint is just not, there's not enough knowledge in a developer to actually do this sufficiently. I know how to write secure code, validate incoming data, stuff like that. It's just basic stuff. But when we're actually talking about deploying your applications to the cloud or scanning for vulnerabilities, all of scanning for vulnerabilities, stuff
like this is something that developers often don't really know. And this is what you need specialists for, like you guys. And I think that is definitely something that scales nowadays when you're deploying your code, maybe multiple times per day. When are you actually checking if your application is secure? You can't just ask some security specialist to check that once a week. That's maybe not even enough. That's a difficult thing.
And talking from a developer perspective, but DevSecOps, the world changes because you're developing applications and stuff. But we are doing with Infra, Infra-ASCO, we are also doing stuff with code. Yeah, definitely. Yeah. So that's also a big change, I think in the whole developers and the whole DevSecOps these days is the change that's not only about application, but it's also our infrastructure, how it will be deployed and created on a later moment in Azure or
any other cloud provider, which is a big part of the whole DevSecOps. And also what you mentioned, I think, if you look at it, I think from an outside to the developer's perspective and see how many stages there are involved within developing a code or application or infrastructure part, that security cannot be just an additional stage that is added to that whole process. It's not like... It can't be an afterthought.
No, right? And I think that's the whole idea behind DevSecOps, why they didn't add an additional pilot to it, but they said, no, security should be part of every stage in the whole process. Because I think the end goal is that, and we will touch that today a little, is to find
that vulnerability as soon as possible. And I think that's what we are going to talk about in this series, more the shift left approach, which you are seeing, it's coming from developers, of course, but it's also now security is adopting that framework. Yeah. So it's like, you know, you need to... Like you already said, it's not like security is not an extra step in the chain. We're not adding a little, oh, we need to do security
at some point. Now, every stage of developing an application, there are lots of stages that should all be done securely and all of them need different steps. So you're kind of, you know, shifting the approach of security more to the left, so more to the developer perspective and more to the planning perspective. When you're planning to build your application, when you're designing it, what do we need? We need to build an application that talks
to the cloud. Okay. How does security play a role here? How are we going to talk about security? Not something that you do in the end. You really take it with you in all stages of developing it. It needs to be integrated in every step and every single piece that you're thinking of, security needs to be part of it. Yeah, because we're not nowadays writing like applications anymore and then deploying the
files on an FTP server or something like that by hand. We're doing so much more. We're deploying, we're hosting our code somewhere like in GitHub, Azure DevOps, GitLab, stuff like this. And then we're using like CI-CD, like build pipelines, release pipelines. We're doing tests. We're doing monitoring. There's so many things that this works really well, but there's also so many things that can go wrong. And if you just ask a developer to fix all of this, you
can't do it. You need security analysts, but this all needs to be done in a continuous way. Yeah, I think that that approach is adopted by developers for a really long time, right? Building, testing, unit testing, all the types of testing of your code. But I think less from the security mind, like, okay, are there vulnerabilities in my code or could there
be any vulnerabilities? I think that's the big change, right? Because developers are doing code testing for a really long time, but not always from a security perspective. It is really difficult for a developer to do all of that. Like one important thing is that you need to update your packages, update your dependencies and stuff like that. And not a lot of developers like doing that. It's boring work. It's just takes very time consuming.
And often you don't really have any time to do it. You know, the focus is on building those new features. It's not on like updating everything that you've already built. And if you have an application that you built on your own and it's completely your own code, you could scan your code and you're completely aware of what's in it. If you're using libraries or stuff like, for example, look for J, the issue that we have seen, if you're using some
other components like look for J, yeah, then you are relying on other stuff. And then it's more harder to check if you are having have any vulnerability or not. Exactly. Nowadays, I don't think any developer is building an application without any dependencies. It is probably possible if you're just writing HTML, CSS, maybe some JavaScript yourself.
It is possible, but I would say that 80, 90, even more percent of applications nowadays are built using a framework in a front end like React Angular view or you're building a server application in Java or.NET. Doesn't really matter. Anything is using libraries. And keeping up to date is one thing. But also what dependencies you're using in one package and that package in the front end land, in JavaScript land, has like a thousand dependencies
which have dependencies. If one of them in the chain gets a vulnerability somewhere, all the packages above are also vulnerable. And it's, you know, I need to build this feature, you know, I need to build this new checkout page, but I also need to ensure that dependency 6000 is still valid. It's impossible for me to do that alone. I cannot do that in the time that I have. Puyon, if we look at application development, dependencies are playing a big role. What
about infrastructure code? If we are deploying infrastructure on the Azure platform or on AWS or whatever, do we have that sort of dependencies also? Well, not so the dependencies to libraries. When it comes to infrastructure code, it's mainly where we focus is to find the misconfigurations, right? Something we can do on multiple levels,
right? We can do that when deploying the resources to our Azure cloud, for example. We can do that with Azure policies these days where we can say, okay, we are allowing users to create a virtual machine in Western Europe. They need to have certain disk encryption models configured and they are not allowed to have a public IP address. So that's something
we can do, but that's on the Azure side. And when we start doing infrastructure code, so the developer has done all the configuration, build the templates, commit that code, that code is merged and deployed and at the deployment, you find out that there's some restrictions. And I think that's something that's also a little too late because you want to find that
misconfiguration much earlier, like developers. From my understanding is that developers want to find preferably the bug or the misconfiguration in the code on their EDA, not even in the build and validation phase. That would, I guess, be the best thing. You definitely have code analyzers that check, hey, you're writing code here that might be insecure or you're
missing validation. And then something in your IDE would be very great. But the thing is, if you only do it in the IDE and you just kind of don't make all of this validation of your dependencies, vulnerability scanning, if you don't make that a part of your pipeline and you only do it in the IDE, then a developer on your team that doesn't use that IDE or doesn't have it configured is still going to let vulnerable packages in. You should be on two faces, right?
I guess. I see it most of the times. I see it just happen in the pipelines itself. And for me, that works enough. You do nowadays have it integrated in Visual Studio. You get a warning when it says, hey, when.NET package manager knew that, when it finds out that there's a vulnerable package, you actually get a notification nowadays. It's really, really useful. I never really thought about it. Last week, I started my Visual Studio
instance and I saw that Nougat told me, hey, you have vulnerable packages. That's extremely useful as a developer to know. And then you can just make work of it or you can tell your team, hey, next week or next sprint, we really need to start focusing on these packages and we need to update them.
Yeah, because Frans, for example, you mentioned Log4G. If you look at Log4G, and I think you had a similar experience, when the customers called us or when we were proactively searching customer environments, if you look, we were looking more on the infrastructure side, right, to find that. Defender, firewalls, Sentinel. It was on the infra side, but the infra side was detecting the applications that are using
that Log4G. So the detection was realized on the infra components, but the vulnerability was in the applications. So it's somewhat hard to search all the applications to see the vulnerabilities. And then you need a vulnerability scanner on a network or on an application server, whatever, to find if a certain library is installed and be used in that area. But that's the side from a customer perspective that we have. On the side of a developer,
a developer needs to know where his dependencies are. So if Log4G, if we take that example, if Log4G is coming up and there is a vulnerability in a specific package, then Sander, as a developer, he needs to check and he needs to know which applications do I have with that dependency, so I need to update that one.
Yeah, exactly. One thing that's really funny when we're talking about package vulnerabilities is when I talk to developers or managers and stuff like that about we need to improve our security because it's insecure and they're like, yeah, but we're just a small company. No one is going to hack us. They don't have anything to gain here. And that is maybe true
in the olden days where hackers could just target companies and stuff like this. But nowadays, when we're saying Log4J or when we're saying a package that has a dependency on a package, and I keep going like that, and somewhere in that chain is a vulnerability. You are hacked. You are suddenly vulnerable. And they did not target you. They just targeted one little package and suddenly millions of companies could be vulnerable.
I think from a hacker perspective, it doesn't matter what you're doing. If you have a small piece of software that is used by lots of other vendors, application developers and so on, then there's a potential bigger impact in the world and you have access to more machines if you can realize that that way. It makes sense for a hacker perspective as well. Why would you target one little company if you could potentially know how this company, this website is built in React or something
like that, or they're hosting their server with.NET. So we're just going to grab some popular.NET packages and we're going to try finding vulnerabilities in those and get some bad stuff going on in there. And I know that the company will install my package. It's so much easier. If we're talking about risks, what are, from your opinion, what are the common security risks and challenges that developers have? Developers I think number one would be from the code perspective, how you're managing
your secrets. So you're writing code to connect to services in Azure or just to connect to services from an external service like an invoice service or payment service, which you see often nowadays. How do you make sure that those credentials are kept safe? Lots of developers just, they don't really think about it much and it can be a difficult topic.
I see it often just, you see often that they're still being leaked. In 2019 I read that there was like a hundred thousand secrets or something were like leaked from GitHub, like a hundred thousand and that's just not going to stop. That it's just going to keep going.
We know a scenario in the Netherlands a couple of, yeah, well it's a year ago almost, of an IT admin which, from my understanding, he wanted to do something good and he wanted to share what he built on a code base and he published it on GitHub so that others can use it and it contained username and password. An admin, highly privileged admin account.
Oh, and I have a great story to tell on this. So it was a few years ago, there was in the Dutch tax services, so like part of the Dutch government, there was an employee there had a GitHub account and some Dutch citizen found that GitHub account and was just looking around at it and in there he found some credentials to that employee's private GitLab account.
He was like, okay, I'm just going to have a little look and take a look at that GitLab account and what he found was like a plain text file with like all the usernames and passwords of the Dutch tax services like Azure admin account. So what he did, he went in there, he went to the Azure portal, he logged in with username and password and it was correct but luckily of course there was two factor authentication installed so he was like, you know, out of luck. Of course he didn't want to log in,
he was a nice guy and a few seconds later he was logged in. So some employee at the Dutch tax company actually like clicked on yes, it is me trying to log in and this guy was logged in as the global admin in Azure and it's just, you can just see like even with these big governments, it is so easy to just leak a secret. It is very easy to do and developers definitely need help. We need to integrate this security perspective all the way into the development of the code and everything else.
Yeah and this guy was a white hacker so he informed the tax services that he was able to log in. But one thing I want to highlight on the story that you are describing is there was MFA. Yeah, there was MFA. And someone, because someone gets a notification on his phone and he put down a proof and the
hacker is in. So MFA fatigue that we are facing in this area. So I get a, there was one notification probably but how many times are admins are facing with a notification or an approval prompt that comes in multiple times and then in the end I'm fucked up. I'm approved. Yes, exactly. And then you have a potential big impact on, it was a test environment so it was not that big. It was a test, I'm pretty sure it was prod. I thought it was prod. Let's just say it was test to save the grace.
Let's hope it was. There was an environment. Exactly. Of a big environment, of a big company, a public company. And that was, it's potential, yeah, crucial that you have secured that sort of user credentials. So this brings us to, I think, a really nice summary of what is happening, right? Because we started with some code, some username password in a code which is published on a repository and all through the whole process that on the upside somebody used that account to log
in, right? And that's, I think, the whole gap that is there. So on the left side we had that code which contained the password and on the, all on the right side we had the Active Directory, MFA, whatever in place to try to stop it or try to detect it with things like SIEM Sentinel or Defender for Identity, Impossible, that kind of stuff. We have that in place. Yeah. But we shouldn't, and I think that's when it comes, if you see at the market, everybody
is so focused on that side. Everybody's trying to say, okay, how do I find anomalies in user logins? Yeah. Or how do I monitor my firewall? How do I monitor all kinds of operations? And we should also ask ourselves, that's good that we do that, but it's a complete blind spot for us or for companies often that they don't see where the vulnerability started. Yeah. That's a good point. And that's, I think, what brings us to the whole DevSecOps and let's touch on that for
today and that's going to be a topic that returns, I think, every session we have. That's the whole shift left model from security because on the right side, we should have everything in place to detect that, but we should also have our processes and our tooling and our things in place to detect that more on the left side. Yeah. Prevention is better than healing, right? You want to prevent all of these things from happening. Yeah. But we know we cannot prevent everything.
And that's why it's important. For LACP4G, so we need to have that detection as well on our operations side. Yeah, but also processes in that area that if something happens, what is the next step that we are going to do? So there is something that we do not have detected upfront. So there is an issue later on. So what are the steps to take? I want to get back at the security risk. The first thing that you mentioned was managing secrets. And then we had all discussion.
Are there any other topics from a security risk perspective? I think definitely, we already touched upon that. I think that's definitely the dependencies. Dependencies are a big thing. Another one that is still sadly still very common are things like OWASP. Does anyone know here what it stands for on top of their head? No. I don't remember on top of my head, but it's owasp.org. I think it's the list of all the
top 10 vulnerabilities that are still found. And number one that is still found, I think every year, is SQL injections and stuff like that. That is really we're talking about code here and how hackers can just get it. Cross-sight injections, that kind of stuff. Stuff like that as well. That's also on the list. Bing is helping me on that. It's the open web application security project.
Exactly. I'm not going to remember that, but exactly that. Yeah. So stuff like these, these are definitely things that are happening more often than things like the OWASP vulnerabilities. Like you already mentioned, your programming environment, they're still getting better and better in helping you detect these issues. But when we're looking at number one and two, vulnerabilities and leaking secrets, that is something that is currently not normal
for developers yet to think about. Like OWASP stuff is stuff that you learn. It is stuff that you, you know, kind of developers quickly learn when they're becoming a programmer because it's very important. But all of these other things that we just mentioned are newer. You know, they're modern problems for these things that we're building nowadays. And you need to use some products and stuff like that. You need to use tools to improve upon these processes.
Do we have any examples how we can address these kind of risks that we have? Well, tools, yeah. So for example, you have things like the dependable is very often used is what I'm trying to say. Sorry. On GitHub. So that's a tool that you can use to automatically get like package updates. And first of all, it's great because it makes your thing more secure. And second of all, it's going to save you so much time. So developers and security
people should just absolutely love using tools like this. So that every day you get like a pull request or it's even automatically merged into your code, like, hey, these packages should be updated, or hey, these packages contain vulnerabilities, you should update them or you should even migrate to a new package, stuff like this. Yeah, so maybe to explain a little for the listeners, I think dependable, what it does is it looks, you can define which libraries you're using your code.
I think it finds it does automatically. Does it even automatically? Oh, perfect. And based on that, it looks if there are any new versions available. Exactly. And if so, it will need, as you said, automatically integrate or create a pull request for you so that you know, okay, I need to change that to go to so that that's a really, really, really useful only feature, I believe, right?
Not dependent bot only runs on GitHub. Yes, but there's a thing called renovate bot, I learned about it like only like two or three weeks ago, and I still need to I need to start implementing that in the code base where I work. The renovate bot is the same idea. So you can self host that and you can use that I think even if you wanted to and like Git lab or Azure DevOps and stuff like that. So that's the same idea you could get the vulnerability updates, package updates, all that kind of stuff.
So we're talking about tools that can be helpful to address certain certain vulnerabilities, certain things and misconfigurations. But that are tools. What can we do regarding awareness on the developer side itself on the on the people? What can we do to improve the awareness and expertise on that side? I guess people should listen to this podcast. Definitely. That's a difficult one. That's
like I feel like, like a lot of these awareness things, it's a time driven thing. It takes time for people to learn more about this. Do we need do we need to educate them? Because we have security awareness on the end user side, giving people training materials. And so we have that also, from from from a management perspective. So consultants and people who are managing IT systems have also training
training stuff for that. But especially for developers, I don't have I don't think it's that that much. So we had a great talk on this with David, of course, the for regarding the fan of cloud focus on DevOps. And I think David Righano. Yeah. And I think the key is based is parsing training in these are people but I think it's mainly to bring those people together. Exactly. And I think that's that's that would be the best approach. Like if you look on like technologies like
the Fender for DevOps, right? Part of the defender for cloud stack. Depends on what kind of code scanning you have enabled. But regarding of that is you have features like pull request annotations. So what it does is it automatically scans your code based on passwords or anything else. And that shows an alarm. It goes to defend for cloud. And
that syncs back to your DevOps pull request. And it points out like on line three, you have used certain parameter or you use the password or we found that and that and that. But more information click here read more on that. And what it does is it creates a platform where security can take a look in the developers ecosystem finds vulnerabilities
that could be there and and give them feedback on their platform. Instead of saying no you developer you need to go to a security portal to see the information now bring that information back to where the developer works. It's like you're getting a taught automatically right? Like definitely learning about this is important. But like you know getting taught about it is important is even even like easier for everyone. The developer gets a notification
like hey you did it wrong. I just want to touch upon that product like you said the vendor for DevOps is what you said it. Yeah sorry yeah. Is it still the vendor for DevOps? Yeah it's part of the defender for cloud. Security I think it was something with security now in the name right? Like they're renaming it every month. Yeah so it's still something
that says there was something at Ignite. Yeah there was something. What's that? So what I saw is like there's also you know like an let's talk about talking to an external service like SendGrid or something to send emails. So you use an API key send it that way. What I learned some time ago is that that SendGrid's API key is a very specific API key. It's like
starts with SG and then something else. So when GitHub detects when GitHub detects a push to your repo and it contains a SendGrid API key it will automatically go and do a call to SendGrid to invalidate that API key. I find that a very very interesting approach. Even if you leak a secret like it is automatically invalidated. So it cannot be used by hackers anymore. I believe GitHub has that also for yourself so you can publish your keys in a
certain list and it will automatically scan all the other repositories. If it finds the key outside of your repository it will give you a signature as well. That is interesting. Because that shows if your key is leaked or not. Exactly that's really good. Like but it being invalidated is the next step compared to getting a notification. Getting a notification and you're on holiday for three weeks. Then you might have got hacked three weeks ago
when you come back. It getting invalidated immediately and stuff like that. That's the next big thing. The next question that I have was regarding collaboration and communication between developers and security analysts. You already touched a little bit on that. If we are touching a bit more on that perspective. Sending the stock analyst to the developer portal so they can communicate with each other and get feedback, give feedback on the code.
Is that the only thing that they can do? Or are there multiple information barriers that needs to be hacked between both of these groups? Because a security analyst is mostly involved if something happens or afterwards. A developer is at the very beginning. There is a lot of things in between. How can we bring them more and more together? That's the entire DevSecOps thing. That's really important. I feel like the tools are
definitely important but that's of course not the human. You want more human communication about this as well. You need to know there is also a security person working behind the scenes and stuff. You need to know them. What do they find important? What do I find important? What we are doing right now? What kind of problems do I see? What kind of things do you guys know? What kind of things do you guys recommend to solve this issue? I've seen
some places where they actually really make a security person part of the team. Part of the Scrum team. It's not like they are actually analyzing the product every hour of the day. They do actually participate in what the team is doing. When there is a question, they can always go to that security analyst and they can have a look around. Is that a security analyst or is that more engineer? Security engineer? I don't know the types. If it's part of the team, it's often an engineer.
Is that a SOC? An operating center analyst or engineer? Or is that more or less a security consultant that is involved into projects to bring the security analyst and the developers together? I think the security analyst is the person that reacts when there is an incident. A security engineer consultant is the one that guides the project and takes constantly with the security. It's more a different role in my opinion. Let's for example, if you look at DevOps,
DevOps starts with planning. The first stage is before you do any code, you have done anything. You start with planning and create a design diagram. That's your proposal. Without talking about any code. This is the application. To give you an example, I did a project with
a really big financial in the Netherlands. Before we even started doing any resource in Azure or any line of code, we needed to get an approval for our design, like the technical design, the functional design, from the cloud competence team, from the security team, and I believe from the operations team. The cloud competence was looking at are we using the right resources, are we deploying it the right way? Security was challenging us, what kind
of data are you processing? Based on that, you have this classification, so you need to do that kind of encryption at a minimum. Operation was like, okay, have you your backup in place? I think that's the first stage where it starts. Communication and talking to each other like reviewing that design, okay, this is the solution that we are going to work
on. From that three different perspectives. I definitely agree. The one thing is that I do, as a developer, I do see a bit of an issue there where I'm designing an application, right? I'm going to build a web shop API or something like that. It's important that we store our data securely because it's real customer data. We're handling credit card
info, stuff like this. It's really important to know. I like learning about security, so I'll notice all this kind of stuff, and I like focusing on how do we store GDPR data. A lot of developers don't, not because they don't know, they just don't really have the knowledge. Talking to those people is very important. I do think that when we're building this application over time, it's going to get new features, right? And we're going to
have new requirements. And then I definitely see people slipping and still at that point implementing something insecurely because they didn't involve all of these teams again. It was something that you did at the beginning, but doing that every time costs too much time or there is no time and stuff like that. So for that, I guess I'm a programmer and I love
automating so much things. So I really feel like using tools at least for the future here is going to help us the most using all of these tools like GitHub Advanced Security, Microsoft, the vendor for cloud security DevOps. I don't know the name anymore. Let's go with the defender for cloud. Defender for cloud. We're going to call it defender for cloud. That's what we agree with David, right?
Yeah, yeah, yeah. Definitely. Great. I think using all of these tools to make, to set up a design with actual with those teams, they really know what fits the company the best. And you need to use this product because that is what we use everywhere. So that's a good fit, stuff like that. And then we're going to start using these tools during development to get odd, to get like a signal like, hey, you're doing this wrong. Hey, this is insecure.
Your code has vulnerabilities. You committed a secret. You shouldn't have this package with vulnerabilities. Here's a PR to automate them. I think that is something that you can do to for developer to really keep your code secure over the time that you're working on it. Yeah. To finish this recording up, because we have touched a few different parts, to
finish up, we talk, still talking about co-pilots within the Microsoft area. Co-pilot, security co-pilots, what's helping us within defender for cloud, defender for, for, and defender, what is it? Defender XDR within, yeah, all the, all that names about. Just say it by date, right? Today it's defender XDR. Today. Yeah. And the recording is in the beginning of December. So, um, but we have also co-pilot for windows, co-pilot for productivity and
so on. So there are different co-pilots. Do you think that co-pilot or AI will, will, will play a role within the stuff while we're talking about having co-pilot? Yeah, I'm already using it like every, every day. Yeah. Yeah. But that's get up co-pilots. But also when talking about, um, defining, uh, finding vulnerabilities and stuff. So we are using, uh, software, uh, or solutions that scans, uh, code and, and, and much more. But does AI also play
a role in that area to detect, um, in other ways for developer? I mean, I know that there's now this security co-pilot. I don't really know yet what it is. Um, maybe that's a topic for later. Cause we, you know, maybe it's a topic for a new episode. Cause it, I think it definitely can play a big role, but I think for developers perspective, when we're using co-pilot, maybe it could learn, you know, from your code base, from your company's security
policies. And then when you ask it to generate code or when, when it's running in your program, it's like, Hey, you're writing code here that violates company policies or discovery stuff like this. So during development, you get the notification. This is what we already said in the beginning instead of later on in the pipeline, right? When you're writing the code, a new developer day one immediately gets to know, Oh, I'm doing something here. That's
insecure. And I think definitely there's a future in that. I think it's going to happen pretty soon. I believe. And I think you can already in your EDA, for example, in VS code already when you have co-pilot and then get a co-pilot, then you can already, when you have a code, you can already ask it, analyze this code to see if there are any vulnerabilities in there. That kind of features already there. So it's not maybe fully automated. That's
I think the answer to the question. But if the future is there, I think, yeah, it will play a bigger and bigger and bigger role in my opinion. So it will help. It doesn't replace anything because we still need to realize stuff and create stuff. AI can help. It doesn't take over in my opinion. Hopefully not. Otherwise we have, we are still starting a podcast. So probably we can extend that one. Maybe the next episode will be AI generated. I heard
Bing already a couple of times today. So exactly. That's Bing enterprise and Bing helps also in generating questions and doing stuff with it. So having a smooth conversation with that. Did we touch every single piece that we want to touch? I think we talked about some tools and I think I just want to call out a couple more tools for developers at least to start using. Like you from the, I think that's more from the operations perspective. If you might
a defender for cloud, right? I think that's a bit more for the operation side on the right side. So it gives the right side to the operation side, visibility into the left side, right? Because you can suddenly see the codes, scan the code, see what's for the village. It's all there. You can do it on multiple layers. So that's I think something we didn't touch
because when we are talking about repositories, right? Where you store your code, it's a vulnerability that can come, you can experience there, but you can also have like misconfiguration on your repository side like that you can do push to the main brain, for example. That's something we do. So the fan of a cloud and in combination definitely with GitHub and security, of course, as multiple layer, it's partially the infrastructure side, your configuration.
Like, do you have your project PRs? Do you have like code validation, that kind of sub configured and partially it's like your code, scanning your code and bringing the output to the fan for cloud where a security analyst is, you can look at these results. Yeah, exactly. So, so your security and your operation is completely on the right is seeing, okay, this
is coming towards the production, right? You are aware of what's coming. And so then you can choose to interact with things like pull request integrations and then send, okay, on line three, we see this and that and that. And that way create that, bring those two
worlds together. Yeah, so like stuff like, you know, like you already said, so GitHub security or the greatly named GitHub, GitHub security, GitHub advanced security for Azure DevOps, dependable is what we talked about renovate, all of these tools will help you like finding your vulnerabilities, it will help you like, it will stop you from pushing
code that contains leaked secret and stuff like that. And something that's really interesting, like you said, it's like it would also like send signals to these defender, like applications and really, you know, what we kind of started talking about to wrap, I guess, kind of things up. It really brings these things to together, right? The developers are, you know, we're automatically now stopping vulnerabilities, but we're still analyzing them, we're still
integrating the monitoring side with it. And you know, at least what is coming from the security side and the operations side, right? And those days a lot, what you see is that security and operation is surprised because there was a coaching, there was something, there was a vulnerability in the code, which where they weren't aware of. Yeah, no, that's true. Now you can still go with that vulnerability to production. It can be an accepted risk
for example. Yeah, exactly. But at least you know what's happening. You know what is happening. So, France. That was all. Yeah, I think that's all. Nice. I want to mention one thing, not from this recording, but from the previous recording to finish up. We mentioned Defender for WSL last time. What happens with that? Because there was no support, whatever, and probably there was a preview. That was the thing that I mentioned. But what happens after
our recording? Yeah, so last time, of course, we talked about containers and WSL and that it creates a black hole. WSL, yeah. WSL, sorry. And yeah, I think the same day, the same evening, they announced that it's going to public. I think it's not GA. I think it's public preview. Yeah. So what it does is it creates Defender for Endpoint. So if you have Defender for Endpoint on your machine, your server or your server, it also now scans your WSL environment
to see what you are doing there. So if you are doing some scary stuff and you think that's isolated, there's now visibility in that space as well. So I think it's a huge step for Microsoft. So if I'm activating WSL on my Windows machine, Defender can take care of that WSL. Exactly. It can see what you're doing in there and use all of these Defender features. Yeah, but we have Defender for Linux, but also the integration on Windows subsystem for Linux.
So that's great. Great. So to make that in order that we talked about the last time. Maybe the next time there are more changes that we are discussing. Does anyone want to do any predictions and then next episode will be out? What we already said in the beginning of this recording, we tried to touch some pieces of the DevSafcops framework. So today we talked more or less about code and code scanning, but also a security perspective
from a developer. What pieces do we have in the DevSafcops framework, Poojan? Yeah, so we started a little bit on the left side, right? We started with the endpoint of the developer. We started with the code repository. And I think we are going to partially build that up towards the operations side. So I heard you telling identity and authorization is going to be an awesome topic to discuss. How do you authenticate and how do your applications
authenticate your micro services? And co-pilot can be different recording in my opinion. Something like that. And also we're going to talk more about this. We're planning an application or I have a laptop here. How do we get the stuff that I built in it to prod? So the stages that you mentioned, like building, testing, releasing, monitoring, there's like loads of stages there and operations. All of these things I can think deserve their
own topic, deserve their own episodes. So lots of topics to cover in the next few months, because we want to try every month to do a recording. So keep posted and see if you can realize that. And if not, you can challenge us. So reach out to us at the different social media channels. We're on LinkedIn, on X, is it today? But also on Reddit and all the social media platforms. So reach out if you have questions or want to be part of this. If you like this recording, subscribe or do some-
Don't tell them to ring the bell. No, no, no, not ring the bell. But if you are giving feedback on a comment on the different platforms that helps to spread this podcast in the world. So that really helps us. And for now, thanks for listening and hopefully until another time and that was probably next year. So what is it? 2024? See you next year. Thank you. Thank you.