Hey everyone. Welcome to the com 42 DevSecOps 2025 conference. Thank you for joining my session on GitHub Advanced Security. A lap around GitHub depend upon code, QL and other built-in security features. I'll start the session with a quick introduction to DevSecOps, followed by different GitHub security features, starting from sharing several repositories, security best practices. You'll learn about secret scanning, vulnerability scanning, and advanced code scanning. All available within GitHub today. Each topic, we'll have several live demos to illustrate how this all works. So my name is Peter Deten, originally from Belgium, but managed to move to the red area, close to the Microsoft campus almost four years ago to continue my role as a lead technical trainer in the West US team. What we're doing out of the role is helping our top larger customers across the globe in virtual workshops learning about Azure and in meantime, a lot of DevOps as well as AI and co-pilot. You got my contact details here on the slide, and I would say don't hesitate reaching out if you have any questions related to the session or maybe broader GitHub DevOps or psych DevOps. So I think with that, let's get started with the first section, the what and Why of DevSecOps. While DevOps is primarily focusing on the collaborative culture between developers and operations teams, the ultimate goal is really automating everything. Automating yourself. Now the flow looks a bit like this. Developers write code. Where the code gets validated and from there gets packaged during what we call the build stage. And if you automate this a bit more, it's what we call the ci continuous integration part of the pipelines. From there, the application code gets moved into what I describe as a running state. This could be across different environments, dev and tests, staging, production to ultimately get taken over, managed by the operations team. And again, trying to automate as much as possible now if we follow this stream, but now integrating security, that's DevSecOps now where it means that we will try and integrate as many security capabilities as possible in each and every stage of the cycle. The list is getting pretty long and obviously I'm gonna talk about some of these features throughout my session. Now talking about security features, let's have a look at GitHub repositories, security best practices. Building applications usually starts with source control or version control, using, in this case, GitHub repositories. Even on repo level, there's already quite some security best practices that I can share. For example, use security policies to guide collaborators on maintaining code set security policies on branches, protecting Maine as we call it. And you can add security features on organization and enterprise level. Another recommendation is using secret variables instead of storing secrets in code. But if you do, I got a solution for that later on. While not immediately security related from a secure your code perspective, it is recommended to provide security documentation inside your repos. Now, what this means is that you're gonna add details, for example, in the Read me Markdown, adding a code of contact markdown, and overall adding the contributing markdown files, especially for open source projects. But I could also recommend this. For private repos if you are using that inner sourcing concept as well. And maybe another recommendation here is creating that security markdown file containing how your project handles security overall. It'll also show up in that navigator menu to the right of each and every repo. That's pretty much it for best practices. I hope I teased your interest. From here, I'm gonna jump into my demo environment and walk you through a couple of those features. So for this first demo, I'm gonna walk you through some of those repository security best practices. Now I created a sample repo that is publicly available, so you can go in and maybe validate some settings or copy the code and then maybe replicating it. In your own environment. So I call this super original, the com 42 DevSecOps demo repo. Now, one of the first things that we talked about in, in like security best practices is probably permissions. Now the first level is a public people pre. A public repo or a private repo. So from there, I assume that's pretty clear, but then next we go in our settings. And over here, since this is a public repo, we might define who can collaborate, who we're gonna invite, and what are some of the other moderation options. So if we move to collaborators, you can see over here that it expects like direct access. It's a public repo, as you can see over here. And down here, I could explicitly invite people who could now collaborate. Now you could think wait a minute, Peter, it's a public repo. Doesn't it mean that everyone can just contribute? Contributing is not exactly the same as collaborating. So this means, for example, they can manage repost, they can manage permissions depending what permissions you're gonna give them. And then underneath the moderation options. I think another interesting one is defining who can perform some code reviews, where maybe limiting users to read or higher access could be a good one. So that's just mainly the user permissions. Another interesting one is, if I go back to my code level, is that as mentioned in the presentation. GitHub is now detecting that the branch is not protected. So what that means is that basically anyone with the correct permissions obviously could now move in and not taking security into consideration and maybe forcing a push overriding code, which I don't want. Maybe deleting the repo or changing anything else that, again, we are not really seeing as a good security, best practice. So what we can do is go into protecting the branch, and then from there we're bumping into that rule sets or what I call branch policies. I got an extensive multi-year Azure DevOps platform background, still using it. Mainly training now on the two platforms and somehow I still call this branch policies. So what we can do here is obviously, for example, what I would recommend is protect main, and that means we're gonna protect the main branch. We're not allowing any bypass, and we're gonna identify the target branch. Now, just a little piece of advice here is, whoops. You would typically do protect the default branch, but there might be scenarios where if you have multiple branches, that although the main branch should be considered default, that's not always the case. So that's where I would recommend using both default branch and including by pattern where then I would add the main branch into it. So from here, just adding like main into it would be good enough if you're wondering what the difference is with the default branch. Since I do have a few here, if I go into branches and actually from here, I go into my branch view, this is what we need. For any of my branches, you can see that we can change the default. So right now my default is up here and it's the main branch, but nothing would stop me to go in any of my other branches. And then from here flagging it and defining it as the default. So that's where in the rule set, I actually like the two options to not only protect the default, but also protect, any other branch based on the naming. Now let me go back to those rules and show you a few of, I would say the common settings. So we create a new branch rule set. You could add tagging as well, where the difference is that not every tag is linked to a branch or the other way around. So once we define the setting. As you can see here, by default, we have restrict deletions and block force push, but obviously there are a whole bunch of other options and it's not up to me to tell you which ones you should enable or not, because I think. It's pretty specific, but for example a few ones that I usually enable is restricting creations, which means that not just everyone can create a new branch, which might not be exactly following the open source mindset, but there might be valid scenario. And then the other one I like that I'll talk about a little bit later on is requiring code scanning results and code quality results. And another pretty cool one. If you are already using GitHub, copilot generative FAI is automatically requesting a code review, and I'll show you some outcome of that later on. Which, by the way, if you do not use GitHub copilot yet, it's one of those magical tools I call them in meantime. So I could definitely recommend you to start looking into it. If you have a personal GitHub account, you can enable copilot for free. If you have an enterprise account, you need to talk to your business and trying to convince them to invest in GitHub copilot. I would say another option that could be pretty useful is back in the settings, moving into the security section over here and selecting actions. Inside actions, you can now create secret. You can now create secret environment variables. So pretty cool. Again, we try to avoid having any secrets or any other strings if you want, inside our code where you could use traditional variables, which means they're not protected, they're not encrypted. But if you move them into the secret tab here, they will be encrypted. We're almost there with secret recommendations, but the last one I would recommend is creating any of those additional files where one of the files we would add here is the security, and the way it works is you define it, security MD. In here you provide best practices for security, which probably should be a little bit more extensive. You commit your changes and from here, the nice thing is that now everyone moving just to the repo gets this little link here to your security policy. It's the same for the code of the conduct and some of the other system files. And then down here you also, whoops. You also have the, sorry for that. You also have the security placeholder over here, and again, in open source, but inner source projects I think it's pretty useful to have those. So that's I would say hopefully a pretty cool demo for over all of you. Quick introduction to some security best practices. Permissions using collaborators, the rule sets or branch policies, secret variables, and security markdown file. With that, I'm gonna move on with the presentation. Now, as mentioned earlier, a pretty, pretty powerful feature GitHub provides is secret scanning. So I would say, let's have a look what that actually is about in this next section. Now, as you can imagine from the title, this feature allows you to scan your repositories for secret strengths. There's a pretty long list in the GitHub documentation, listing up all the supported. Partners and platforms of which secret strings are getting detected. So you can think of AWS S3 storage keys, Azure Access Keys, API, keys Connection Strings, but also Broader Secrets using SSH Keys and the like. The GitHub documentation, again, has a pretty long list. I don't memorize any of them, but I typically check them out. And they're partly embedded in the setup as well. So by default, the secret protection scans the repo. So basically when your secret's already in the repo, now there is an additional setting, and I'll show you in the demo that we call push protection, which can be prevented uploading secrets as part of your synchronization tasks. And obviously avoiding that any secrets arrive in the repo, which means you don't really have to scan for them anymore. And I've talked about it. Let's say, I'm gonna jump to my next demo here and it just because I wanna show you actually how this works. So for the secret scanning here, were backend, the repo, still in the same repo as before. MyCom 42 DevSecOps demo. And we're gonna enable secret scanning. So how does it work? We move to the security tab and down here. Although it's the last one in the list, I always like to start with this one, where now we have secret scanning enabled. You could go into secrets and then from here you would enable it. Now, when you enable it, it's gonna offer you the setting to use the push protection as well. And I'll show you in another part what that means. Now. If I move into my code and let me add something, little web app, I go in my index and all the way down. I already have a little string, but it's not a hundred percent secret. This is GitHub token, where if you do anything with GitHub tokens they have the GitHub Pat Personal Access Token as the syntax. Where now, if I commit my changes. As you can see, I'm using copilot pretty frequently. It's pretty convenient here because it's already helping me with my commit messages. I tried to commit and now here you can see that my secret scanning found is GitHub personal access token on line 35 in my code. Now from here, we could move on with a couple of different settings, which I guess are pretty straightforward. You can flag like it's a false positive. I'm using it in a test or why not in a demo, or it's fine. I know that I shouldn't do this, but I'll fix it later, which is an interesting one to me because it's bypassing the baseline. Of having security protection in the first place. So I wouldn't recommend that one, but I can still see like maybe some of you might look into it and even then, if you do this, I'll fix it later, which means the secret string will go into the repo. I'll talk about some other scanning mechanism later on that allows you to still detect it. I'm not gonna save it for now, but I hope that makes sense. Now you might think, okay, Peter, you are editing files from within. GitHub directly. Who's actually developing code from this view? Maybe you might use code spaces. Maybe you do vs code. Maybe you do something else on your local machine. So what we can do, and that's the push protection. If I shift to my exact same view, this is the same code, nothing's changing. I could now try and inject. Again, that secret string. So I'm gonna grab it. I have it here on the site. I move into my index file. I add it in my code somewhere in any possible file, doesn't matter. And then go in my source control. I'm gonna sync my changes. And as you can see here, it tells me like, whoops, something is not working. But now if we check the comment output, it's telling me here whoops. The push feature cannot contain secrets. So instead of trying to update your code from the repo perspective, this is now happening before you try to push, which I think is definitely convenient. So that's, I would say, pretty much it on secret scanning. So showed you the secret scanning, how to enable it. Showed you the impact from the GitHub view, little popup message, warning you with a couple of options, and then showing you the same from the code view in my VS code as well. So with that, let's move on with the presentation. So with that, let me move to the next section, covering dependency and vulnerability scanning using GitHub. Depend Bott. So GitHub Depend. Bot is a built-in service for any repost public private, which allows for scanning repo package dependencies and corresponding vulnerabilities. Now, by default, it's using the cve.org public database of already publicly known vulnerabilities, together with obviously GitHub advanced security patterns itself. You can enable Pena Bot from the security settings, and I'll show you in a demo of that repo in basically just a couple of seconds and after a few minutes it starts running GitHub actions pipeline, providing you detailed overview of any detected vulnerabilities, listing up the criticality, and even including a possible fix to mitigate the problem. And as obviously another demo is coming up for it. So this next one is the depend bot code scanning. So we move again once more to the security tab over here and we move to depend bot. As you can see, once we move into the security options, I would enable depend about here. And then maybe some other options if you want to use them, is the private vulnerability reporting. It's not the scanning, it's pretty obvious out of the naming, it's the reporting itself. So we would move in, enable, depend bot, and from here again, we have a whole bunch of options. The ones that I recommend most, and I'll show you a little bit of that, is the dependency graph. Then obviously within depend bot. It's not just enabling all or nothing. You have a lot of flexibility here. So we would enable the depend bot alerts, and then it tells me like, oh, pretty cool. We also need to enable the dependency graphs so I don't have to worry about it. We can define specific depend bot rules, meaning if you don't like to use just the ones you get from the built in GitHub, advanced security. You could now add your own rules. You could focus on specific security updates, like as part of pull requests, you can do version updates, and then it's gonna integrate some little task that's called depend Bot inside your github.com system folder. So again, pretty flexible. I'm not gonna walk you through all options because we don't really have the time for that. But what happens from here if. You enable, it's gonna trigger a scanning where for now we don't see the outcome yet, but that's where I can switch to another demo repo. And again, it's a public one, so feel free to have a look into it. It's called the bot demo. I enabled just the exact same settings couple of days ago, as you can see. Where now if I move back to security, I select the pan bot. This task was already completed where now it's telling me like, whoops, Peter, in your sample code here, you have a few security issues. The security issue, I'm just gonna grab one of these, is again, based on those public CVEs together with GitHub advisory database as well. It usually looks into your development package. It is aware about any versioning challenges or versioning issues, and in this case, it also tells me that there is a potential solution to move up my package version to a later one, and that should fix the problem here on the site. Pretty relevant information. What is the attack vector? What is the complexity? What is the severity? And if we move down a little bit more, we can see the C-V-E-I-D. I'll talk about that in a second. And down here we could also pick up the GitHub advisory database information. So this specific example, and again, it's just a demo, right? But it's related to comment, injection in low dash, which is like a specific package that we used for the demo. And we can list up all the references from different security and non-security vendors I talked about@cve.org. And if you've never seen that before, let me grab this CVE number. You can do c v.org. In this example, which I used in another demo couple of days ago to test. Was searching for SQL injection, and as you can see, it's listing up all the 2025 security problems. And obviously it goes all the way back since my previous example was 2021 and a specific number here in the sequence. You can also find all details here, so it's partly coming from that public CVE database, and then maybe additional information from the GitHub advisory. Last part, if I switch back to my code view and I go into insights and I navigate to the pendency graph over here. Since we enabled the pan bot, remember, it tells me it'll also enable dependency graph. It's now not only showing me the individual problematic package, but it's also showing any other dependencies where for some of you it might also be relevant to export the sbo, and that's gonna give you a JSO file with all details from all your packages. Looks a little bit weird here, but. You can say that it's a pretty extensive, detailed JSO file. So pretty useful, pretty cool I would say. And that's in short what Pena Bot was about, at least the part that I wanted to show you in just a couple of minutes. So with that, let's move on with the last part of the presentation, talking about code ql. Awesome. This brings me to the last section for this presentation detailing GitHub code QL proprietary code security scanning tool from GitHub itself. Code QL tries to treat your repository code like data, starting from creating a database and using what I call queryable data that you extract from your code base. You can create your own custom queries or rely on a set of standard queries provided by GitHub research teams, as well as community contributions for any common possible development language. Using Code ql, you can detect security issues, coding errors, and overall using custom que. Another cool feature is using code QL comment line on your development workstation, or what I'll show you in the demo is integrating code QL as a visual studio code extension, which means that now your developers, or maybe you, yourself as a developer, can perform scanning tasks before even merging code into the repo. Which brings me to my last demo for the presentation, showing you how to set up code QL in GitHub, first of all. And then from there I'm gonna jump into some vs code extension configuration settings. And what I did here is once more go into security, selecting code scanning, and then here also obviously enabling code scanning. Now what that's doing is actually building an actions pipeline so we can go into code. If you know a bit about GitHub actions pipelines, you should know that they're stored in the dot GitHub workflows folder, and inside we have a code ql. You can modify this because it's following obviously a lot of the traditional common pipeline. Syntax and use cases. So we have the on keyword, which means it's a trigger, automatic trigger whenever we have any of these operations. And you can make this a lot more filtered, not just the main branch, but any branch. Or you could also use a schedule task or use the workflow dispatch. And that means it's a manual trigger. Now in this case, again, it's based on the built-in capability. So it means whenever we have some PR push-pull operations against the main branch, we gonna run the code scanning. Then the code scanning itself. If it's the first time you use it, I would heavily recommend you to look into those details where it's becoming part of a pipeline. This is a separate pipeline, but in a real world scenario, I could imagine. That you're integrating the syntax into your build pipeline. When someone is committing code out of a pr, out of the PR review, you would run a CI built pipeline. And part of that is obviously validating code, like a dotnet run.net dotnet restore.net publish to create the artifact. And then maybe from there, integrating the code scanning or like in this example, running it as a scheduled task would also be beneficial. Since we talked about some security best practices, one of the things I didn't mention, but inside your pipeline you could actually also define permission limitations. So in this case, the read action items here means that the pipeline runs cannot change anything in code. The actual scanning is happening a little bit more below where Over here we identify what is the language. And again, code QL supports most common languages. So you can read through the, read me here to identify which language you wanna scan. And then a little bit more down, we have the actual code actions. So it starts with code, ql, action, initializing it. So that's basically recognizing the language, the build mode, and then a little bit further, it's running. I'm challenged a bit with my view. I'm gonna try and zoom in again. Where then after the initialization, it's running the actual code scanning, so that's the analysis. So nothing really different from any other pipeline syntax, I would say. Where then if we look into the actions view itself, we have code QL advanced, and then here you can see based on my operations, like adding my security file, it's triggering and scanning code. If you look inside the code itself, then there's two tasks. Why? Because this sample has two different code frameworks, one for net C sharp, another one for JavaScript, and it's obviously looping through them. And then inside we can see the code QL initialized, and then performing the analysis and then basically wrapping up. If we look inside the code analysis, it's gonna show you the details. And that brings us back into the security tab, code scanning. And then here you can see for the different languages what got detected. And I just like a, I would say a clean or a green view, which means there are no security issues detected, but I was assuming that it's pretty straightforward. So you can look into the scanning results. You can open up the. More detailed view for any of these running the queries. And this is where you can see like what code is actually getting scanned. Now what you see here is those QLX files. So those are the query language, code, query code, QL query language. And the nice thing is that although this is all running from within the GitHub backend, what if we wanna move this a little bit more to the left in the DevSecOps story. What I'm leaning into is what if we can move code QL to our development workstation? And that's exactly what we can do. Where if I switch back to my code application here, this is still from our secrets, so not gonna use that anymore. But now I can go into VS code and installing the code QL extension. There's also code QL command line if. You don't have yes code or you don't use the extensions that much. You could do similar tasks using command line. So after installing the extension and navigating to it, it's gonna give you a few options. Like what development language you already know. I'm using T net C sharp. I'm gonna download a cloud-based, GitHub based database, which is called the Rest Sharp, at least for C Sharp code. And it comes with a sample query and I can pull up some other top 10 repositories if I would like to use that. What I did is navigating to my example query, and then, as you can see here, I'm searching for a secret. Not really, I would say necessary, but just an example. Where we already know that we have that secret. But if you don't have that secret scanning enabled or you don't have the push enabled, or you flag it as, I'll fix it later, which I did in one of my demos, you could now go I'm gonna rely on code QL to actually detect it for me. So from here, we're gonna run the query. It's probably not gonna take all that long, and I could actually navigate to. My previous scan in prep for the demo, and you can see that out of the code QL database, it's not finding that text string 115 times. It's detected by 115 different prebuilt C sharp queries where all of them recognize the secret string. That's the main thing. Where the cool thing is that it's not just scanning for secrets, it's scanning for pretty much anything. So you could obviously do a lot more with the code QL language. Just wanted to bring an easy example that's probably relatable to any kind of scenario. But with that, I think I'm gonna wrap it up to make sure I'm not running out of time too much. But let's switch back to the presentation. Whew. I'm quite happy with all this, especially because all my demos worked as expected. Now we're close to the end of my session where I shared information about DevSecOps give you a set of repository security best practices, followed by more detailed insights on GitHub's. Security features like secret scanning depend about vulnerability scanning and advanced code scanning using code ql. All those features are part of GitHub Advanced Security capabilities. I hope you enjoyed learning about GitHub security features. As much as I enjoyed presenting on the topic, I would like to thank you for having joined the com 42 conference on DevSecOps and even more so thanks for joining my session today. Enjoy the rest of the conference and again, don't hesitate reaching out by email Connect on LinkedIn. If you should have any further questions on anything I presented on broader DevSecOps in GitHub, in Azure DevOps, and apart from that, I would say enjoy the conference and have a great day. Thank you so much. Okay.