 So, good morning and good afternoon everyone, and welcome to GitHub Commit at the QCon. My name is Icy Gigan Baruch. I'm a Senior Technical Marketing Manager here at GitHub, and I'm based in Israel, and I will be happy. This is my LinkedIn here, my LinkedIn account. Feel free to connect with me, and I will be happy to speak with you about anything CI and DevOps, and in today's session we will see a few demos. I will start first with the GitHub CI overview demo, and then my colleague Cesar will continue the next step, which is GitHub CD, continuous delivery and continuous deployment demo, and then Fern will complete with the DevSecOps demo. So, we will get three very, very cool demos. So, we will start with the first one, which is GitHub CI overview demo. So, in this demo, I will present three uses and three demo flows. One is for the developer, developer flow, the second day life of DevOps engineer, and the dev team needs. So, I chose those three personas in order to demonstrate a little bit about how GitHub can edit those three personas and how we can do how we do DevOps with GitHub. Once every day when you wake up in the morning and go to the office, you want to write this code. He likes to write code. This is what he knows, and he wants to make his application and releases as soon as possible into production. In order to achieve that, he wants that this code will be built and tested and get feedback as soon as possible, feedback on some bugs or feedback on some vulnerabilities that maybe he entered into the code or any compliance issues. So, if there are some issues, the developer will want to know that in advance they're not waiting a few weeks or sometimes even want to get a security, long security report with many things, while he even doesn't understand what it is, and he already working on another version of the code, and now we need to go back to the original code. So, this is what the developer wants, and let's see how the GitHub flow in this case and how the developer makes that. So, you see the GitHub screen, and I will create a new branch, and I will give it a name, and this is now my feature branch, and this is my source code. As you know, GitHub is a single application for CI, and version control, and CD, and monitor, and security building, everything in one application. So, currently we see the source code of my feature, and now if I return something, it will change only my feature branch, and I will not impact anything on the share repository, where is the main branch that goes to production. So, I will open from here my source code, and this is the file that I will want to change in this demonstration, and I will open the building web ID for that, and I will change this string to something else, and actually this is all the change that I do today, and I will commit this change into my branch, and I will add a commit message, and I want to commit it to a page up, and this is the branch we just created. GitHub offers me, by default, to start a new merge request, so I will accept that offer, and I will push the commit button, and the new merge request just opens for me, and by default the title is my commit message. I can assign the merge request to myself, and I will submit the merge request. So, what is this merge request? So, now I'm requesting to merge my feature branch into the main branch, and this will go to production, to our end users, and so merge request is like a form, requesting something, to merge something into the main, and in order to make sure that there are no vulnerabilities in it, or no compliance in it, we can treat the merge request as the quality security and compliance gate into production. So, via the merge request we will validate via other reviewers or stakeholders that what gets into the production should they get into the production, and if there are problems we will not merge into production. And if you notice here, this icon means that a new pipeline already started because I just committed the change, and this is the main thing of CI. For any change you will run a CI pipeline, so in GitHub it automatically you don't need to configure anything, as long as you when you commit a change, you push a change, the CI pipeline automatically will be started. I will click on that and it will open for me the pipeline graph of my CI, and the CI first will build my code and then create a document image in it, and push it to build in container registry. I will open the container registry and we can see the new image for my code that already pushed in the container registry. I click in and I can see the image tags of my change. I will go back to the pipeline to see what else we have here. So, we build the code and then I added a stage and a job to build for me a testing environment, and then another job to ping this environment just to validate that the environment is great. And then I added many tests, like quality tests, container scanning, functional tests, license scanning, mobile tests, impressions, and more tests in that. The next stage is the review. The review is to really deploy my feature branch, my code into Kubernetes, and then I will have a live preview of my code. In this preview, I will be able to send to my stakeholders, like designers, product manager, QA, everyone that are part of the review process will be able to see live instance of my changes before it goes to production. And because we have this review application, we have live instances, we don't have to just do static scans on the code. We're also running dynamic application security testing and even performance testing on the live preview of my feature branch. So, as you see, I just pushed the change and I will get all of that after a short time. It can be minutes, maybe a few minutes or 10 minutes. I can get feedback of my change. And this is the idea. For every change that you will make and commit, you will get such feedback. Now, I made my change via the default Web IDE, but developers usually like to work with their local IDE, which is great. And in that case, you will get a notification in email about the pipeline status. In this case, my pipeline is green. And I got the notification on that. But if I would get the error, I could see here a red pipeline. And I can from here click and get into the pipeline graph and see what is the failing job. I'm going back to GitLab. And I will go back to my mail request. And as you can see, the pipeline passed. On the right side, you see all of the pipeline stages, which is great. All of them are green. All of my jobs are passed. So I'm great. I'm in good shape. On the bottom of the page, you can see in the mail request, all of the test results, you see there are no changes to the quality, to the quality, which is great. You see the result of the browser performance test metrics can expand those reports, those results and see some metrics about the performance, according to what I defined in the test. I can see that there is some security vulnerabilities in my code. It's not because of dust change, because previous changes, we have some vulnerability in this Java code. And also, we got the license compliance. We didn't add any library, but the license scan scans all of the external libraries that we add and make sure that the license that developers adding in their code doesn't bring licenses, introduce licenses that are not approved by the company policy. And you can define it in GitLab, which license are approved and which licenses are rejected. You can see here, click here to see from here. You can see here a full report of the licenses detected in my code. All right. And so the last nice thing here, this button, which is very useful, we use it from GitLab always. This is the review application. So this is also in my mail request. I click here and I can see the preview of my application, which is deployed to Kubernetes. The link is external. I can send it to anyone. So after I've seen that everything is okay in my test, I reviewed the application. Usually, the best practice is to assign a reviewer that will review your code before you click this button, the merge button. And then other tabs, interesting tabs in the merge request is the commit tab, the pipeline and the changes. The changes shows you all of the code changes and the reviewer used that to edit their comments in the merge request in this tab. So once the review process passed, the developer can click the merge button and now it's called those into the main branch. And with the continuous delivery, hopefully it will go to staging environment and at some point it will deploy to production and deliver it to the end users. The developer now, happy can go for a break, for a coffee break, or he can go to the next feature that he wants to deliver. And so this was the developer of flow and the main flow of the developer. And now the CI helps him to make it very easy. Without context, which to other applications, we need to enter another logins, everything comes in a single flow and flow for the developer. So with that, I return to my colleague, the DevOps engineer. And the DevOps engineer's job is to make sure that everything is working. All of the CI is working, the organization, the developers can do their job to develop to develop application and they don't have any CI blockers and they're responsible for the cloud. So they're lucky they're using GitLab. And GitLab is a DevOps platform that built design for doing DevOps and CI CD. I will start with the CI CD configuration. So by clicking here, we see the CI CD ML file. So in GitLab, the CI CD configuration is done via code, which has a lot of benefits. And this is the example of a CI configuration file. So let's see what's existing. First, it starts with the global image. So this image will be used globally in each job, unless a specific job, in its definition, specify other image. And those are global variables that we can define for all jobs. And the definition of the stages and the order of the stages. So this will be the order of the stages and you can add or remove any stages that you need. And here you can include some templates. So in this example, those are built-in templates that they shipped in GitLab with templates for build, test, code quality, deploy, dust, container scanning, some of them used in the example of the developer. But you can also define your CI template and then users will be able to include them on their ML file. And those are some examples of jobs. Let's together add a job. And the job name is test26. And here I define the different image of it. That's mean that the runner machine, when it starts this job, first it will go to the Docker Hub. We download this image and that also we download this service and then it will run this script inside the image. So all of the jobs isolated. And the other benefit is that I don't have to install any build tools on my build machines because everything is inside the image. So the job is clean and when the job completes, the image removed from the runner machine and this way it's secured. We allow permissions to developers to change these configuration files. Of course, we can define a limited to specific people. But in our organization, if we want that we want the developers to be able to change this code in order to, for example, to add a test environment or change something in the CI configuration. So they will not be dependent on DevOps engineer or a specific person that will make those changes. So they can make the changes themselves and I'm as a DevOps engineer because it's on the code can track those changes by going to the commits and see all of the changes and the changes and when and what was the change. And if there is any configuration issue, it will be easy for me as a DevOps engineer to fix that and bring the system again quickly. So we discussed about the CI configuration, but how the jobs run. So I will open the CI CD settings and the runner configuration. So the build machines in GitLab, we call them GitLab runners and we have a few types of runners. We have specific runners that you can install on your prem locally and then you can enable them for your project. So for example, if you have you have in it for a Windows runner that connected to a mobile device, for example, so you can install this system and define it as a specific runner. And also you can add tags to those runners and then in the YAML file, you want to specify those tags and the job we pick only this runner. There is another option also to use shared runner on GitLab.com. So the runners will be on the cloud and it will pick a runner machine for you. Another benefit of the GitLab runners is the support auto scale mode, which means that this is the elastic way that we provision build machines on demand and we'll make sure that always developers will have a build machine available. So they will not have to wait in the queue for free build machines. So whenever there is a demand for machines, the system will provision machines with runners and then after a while, if there are no other jobs, they depend on the idle time they define in the configuration, the machine will be removed in order to save resources. So we a little bit understand how we configure the jobs and how the jobs run via the runners and for me as a DevOps engineer is the upgrade of the system because GitLab comes with a single application, single installation for all of the components, issue tracking, version control, CI, CD monitor. So when I need to upgrade something, I will just need to check if it's, if I'm using the Docker installation, for example, I need to place two Docker images and that's it. And once I replace those images, upgrade those images, it will upgrade the entire system. I will not have to handle the different applications and the integrations and to worry that something will break after I upgrade the one component and upgrade one is a single installation that everything, it will upgrade everything from it. And by the way, GitLab release, new version every month, every 20 seconds of a month we have a release and you can Google GitLab releases and see what is about all of those releases, which release comes with a post about all of the features. So and with that I will both to give the honor to my colleague, the dev team leader. So as a dev team leader, my job is to make sure that the team is productive. There are no any blockers and if there are any blockers, I will make sure to address them. So I will show you some reports, some analytics that I'm using. So what we see is the pipeline charts. And this shows me the productivity of the team. It shows me overall pipeline, what is the successful pipeline and the failed pipeline and the success ratio. And I can see pipelines for last week, for last month or even for last year. This report helps me to understand how the team is doing. And I see that the success ratio is good. Most of the pipeline are green, which is great. I hope the team will continue this way. Another useful report is the value stream analytics. Every organization wants to make the cycle time shorter to release the code to production to the end user as soon as possible. With the value stream analytics model in GitLab, we can show how much time took for each of the table stages, like planning, coding, testing, reviewing and staging. Because in GitLab, everything is a single application, we have this data. So we can analyze that how much time it took and you can even drill down and see which issues or mail requests were involved in each stage and if you find any bottleneck, you can understand where it is and try to fix that. Once you fix a specific stage, it will impact the global cycle time. So this is the value stream analytics. So the last report that I want to highlight and later on will deep dive into security, but I want to complete because as a dev team lead, we want to release fast, but we want to release without risk, without any vulnerabilities. So I will be using the security compliance dashboard to make sure that there are no any vulnerability in my dependencies and also make sure that the license compliance and all of the compliance issues are addressed so we are good and we don't do something that we are not enough. So with that, I conclude my part and just to quick recap before we move to the second part. So we've seen here three personas using GitLab. The first was the developer that created the code change and run CI pipeline, got all of the results into the merge request, reviewed the application with these colleagues and merged this code and was very happy to merge it to these users. Then we met the DevOps engineer that showed us the CI ML file where we can configure in a code all of the configuration of the CI CD. Also, we learned a little bit about the runners and that the upgrade of all of this system is very easy and we will get every month a new version of GitLab. And last we met the dev team lead and he used some analytics to measure and make sure the team is successful. So I hope you learned something new about GitLab and try it yourself and with that I will stop and try to stop sharing. Please share your screen. Thank you and have a wonderful QtCon and commit GitLab commit. Have a great day. Bye-bye. Hello, can you hear me? I think I'm next, right? I cannot hear you. Loud and, yeah, you're loud and clear. Okay, good. So I can start my portion. Very good. So thank you, Isik. Can you, I'm going to share my screen first right here and you should see a slide with my face on it. Can you confirm, Fern? Yeah, you're good. Okay, good. Thanks. All right. So I want to start my timer. Thank you for joining this portion of the presentation. My name is Cesar Saavedra and I'm a senior technical marketing manager here at GitLab. If you need to get a hold of me after this presentation, you can reach me on Twitter on my GitLab handle or through LinkedIn if you want. If there are any questions that you don't have time to ask during my portion of the presentation. So what I'm going to be covering is just like Isik covered the CI portion. The main focus of that presentation was the CI portion of the pipeline. I'm going to be covering the CD portion of the pipeline. So that's a continuous delivery portion. And specifically, I'm going to be talking about and showing you progressive delivery through feature flags, which is a feature within GitLab. So as you saw some pipeline examples already that Isik showed you, there were many jobs in each of the stages. And I will be focusing, like I said, on the latter part of it, which is the CD portion of the pipeline. And it's basically all about and all the jobs and tasks related to how to release software to production at any time. Whether it's VMs, virtual machines, whether it's Kubernetes, whether it's bare metal machines, or any other type of platform that you have. So what is progressive delivery? Progressive delivery is a continuous delivery with fine grain control over the blast radius. This is a quote from James Govner from Redmonk. And it basically means deploying something to production in a very controlled fashion. And with the ability to control also who the audience is going to be for that specific feature, for that specific functionality that you want to try out in production. Not too many years ago, testing in production was a big no-no. The production or the system administrators will not let developers touch the production machines. That has changed in the last few years. With the introduction of DevOps practices, best practices also developers are allowed, not allowed, but are comfortable now to do some testing in production. And to be able to deploy to production, there are many different strategies. For example, there are deployment techniques called, for example, AD testing. There is blue-green deployment. There is rolling upgrades. There's also canary deployment. And in this demo, I'm going to be showing you feature flags. So feature flags is basically, this is before doing an after picture of what production will look like. But basically the before picture is showing that there's an application with version one that is running in production. And you want to include a feature. You want to roll out a feature to production, feature A and feature B. And during the rollout, these features will be introduced in a B2 version of the application. And then after you feel comfortable and after doing some testing possibly and some validation of the feature is working well, you can actually make it permanent and get rid of the feature flag so that the feature is available to everyone. And that's basically the after picture that you see there. There are many ways to roll out features within GitLab. One of them is based on percent rollout. So the idea here is that you want to roll out the feature to a small group of users or basically to a small segment of the audience. And then as you feel more comfortable with it, you can increase it all the way up to 100%. This is a screen snapshot. We're going to go through this in the demo on what feature flags look like. The definition of them looks like in GitLab. All right. So let's jump into the demo. So here I have a project called product manager spring. This is similar to an inventory. So you have basically a table that is going to have products in it. And many people will be able to access that table. And they'll be able to delete and add line items to it. And each line item is basically a product. That's what it's called product manager. And let me show you first the feature flags in action. And then we'll go back and review how you set them up and how you define them. So let's see what they look like in action. So this is where you would define the feature flags. There is a feature flag here called products in alphabetical order feature flag. Okay. As the description says, it's going to list the products in alphabetical order. And here it says that in production, so we're going to have now two environments in this project. We have a staging environment and a production environment. And we're able to define two strategies. In fact, let's just go into it and show you what it looks like here. So this feature flag has two strategies. The first one is going to be applied to production. And in production, what it says here is it's going to be a percent rollout. So and it says 50% of the users using this application will see this specific feature. And it's based on a available ID. And then in the staging environment, only the users listed in this list will see this feature, no one else. And the way to define this list here of users is you go back to the previous page and you would say view feature lists. And here I've created a feature list, which is called products in alphabetical order user list. Excuse me. And there are two users there, Michael at CFLR.com and Mary at CFLR.com. So only these two users will be seeing the feature in the staging environment, like it was defined right here. Okay. All right. So let's now see, let's see how this works in the staging product and the staging environment and production environment. So let's just go back to there. So here I have the environments for this project, product manager spring. This is the production environment and staging environment. So let's review the staging. We can do staging first. So in staging, if I remember correctly, only two people could see the feature. And the feature is going to consist on the products being listed in alphabetical order. And you'll see what I mean when you see the product list. So I think it was Michael and Mary were the only ones that could see the feature. So let's log in as Michael. Okay. Here, as you can see here, the product ID, and there's a misspelling or misspell word there, sorry, is, is the product number four is listed first. And the reason is that this name is, this list is sorted alphabetical order. So graphics card happens to be the first, the first one in the order. And then the rest of them come after that. So this confirms to me that Michael is can actually see the feature in production. So let's log in as someone that cannot. Let's log in as Peter. And as you can see, Peter doesn't see this feature. And we can tell that he's not seeing the feature because the products are not listed in alphabetical order. They are listed by product ID number. Okay. And just to make sure the other person was Mary, right? Okay. That could see this feature. Mary, like Michael, she's getting the the feature, which is the products are ordered by name. Very good. So that's in staging. So let's see now production. In production, the strategy was a little different in production. We have 50% of available IDs. Okay. So half of the users should get the feature and or see the feature and half should not. So let's go to production. And I've created six users. So let's quickly log into the six users and see who gets the feature and who doesn't. So the first one is Peter. I remember this is a different environment. This is a production environment. So Peter does not get the feature. Let's see magic. Magic gets a feature. Let's look at as Michael next. Michael gets a feature. Let's look in as Henry and Rita's not get it. And we have two left. Let's look in as Mary. Mary does not get it. And let's look in as Thomas and Thomas got it. All right. So just to recap, if you've been taking notes like I have Peter got it. Henry got it. And Mary got it. That's three out of six. And then I'm sorry, Peter, Henry and Mary did not get it. So that's three out of six. And magic. Michael and Thomas got the feature. So that's three out of six. So 50 got it. 50 saw the feature and 50 did not. Very good. So now let's go behind the scenes. Let me do a quick time check. Okay. Let's go behind the scenes. So how do you define a feature? You saw how this was defined. But what's let's look at behind the scenes. What do we need to do before you can define one of these or declare one of these? So what needs to happen is number one, you need to instrument the feature flag within your code. So here is the source code of this application. And if we go into application controller Java, you will see here some logic to set up the feature flag APIs. And then here we're using this open source project called unleash. We're basically instantiating an unleash instance here. And then here, this is the important part. Because we are doing, we need authentication and session replication because we're keeping track of the user IDs. So this application has that. And here we're setting up, we're getting the username here that is logged on. And then we are checking here if this feature is enabled, which is the feature that we, this is a string that we used to define that feature flag earlier that you saw, then the list of products in alphabetical order. Okay. And this is basically is doing list all sorted sorted. Else, if the feature is basically not enabled, just list the products in or basically by the way that they are entered in the database, which is in not alphabetical order. So you need to do this first. And then the second thing you need to do is you need to go to, actually, let's just go back here. You need to come here. And you need to click on configure. And then you need to copy this URL and this instance ID, which happens to be the unleashed server. Think of it as a service basically, as a service. This is the way to get to the unleashed service that is running for this specific project. And you could declare two variables with those two values that you would copy somewhere. And the variables are defined here. Please ignore these other variables that I turn off so that my pipeline would run faster. Basically, you would define two variables here. This is where you would put in the instance ID of the unleashed server or service. And this is the unleashed URL, which are the basically the variables or the two values that came from this pop-up dialogue. And then after you've done that, you can actually define or configure a feature flag here by using the, you have to use this feature flag name has to match the string in the code that you saw. Lastly, I would like to invite you to visit. There is this project that is public called CD Labs instructions. And there's a variety of CD related labs listed in this project. The one that we just just showed you is called feature flags. And this basically takes you through all the steps that you need to do to be able to recreate what you just saw in this demo. Just like feature flags, there are other labs related to continuous delivery, about DevOps, about incremental rollouts, canary deployments, GitOps, auto deploy releases, et cetera, and rollbacks. So that's all I have for you today. Thank you very much. And at this moment, I'm going to pass it on to my colleague, Farn. Thank you. Awesome. Thanks, Cesar. So I'm here and I'm going to talk a little bit about security. So hope everyone's doing well. Hope you all had a good breakfast. And let me get started with sharing my screen. So I am going to share. And crazy news is happening. So I'm going to go out over there. And here we go. So my presentation is going to be on DevSecOps with GitLab. And my name is Fernando. I'm a technical marketing manager here. And just to say a little bit about me, like different animals, I worked a lot on security, Kubernetes, OpenStack in the past. I come from a software engineering background. And now I prepare these demos and kind of help all of other different security solutions and really show the value of them. And that's me with a goat. And that goat is trying to eat my paper. So before we get into it, let's just talk a little bit about the software developer life cycle. So initially, you'd create an issue and then developers would work on that issue. So there'd be a feature request or some type of bug. And then developers would work and they'd make a feature branch off of the default branch, commit the changes, then the CI will run, unit tasks, building the container. And then we have a whole set of different security scans that run. So these security scans run on that feature branch. Then there's a review app, which is once these scans run, we'll get all the vulnerabilities that were detected. And then there'll be a review app and then not included here. There's also additional security scanning that goes ahead and checks the running application. So we'll send a bunch of requests to try to break the running application. And we'll get all those results. And then there can be discussion and code reviews. And there'll be approval. So we can set for merge requests to need specific reviews from security team or legal if there's any vulnerable code or incompatible licenses detected. So we can add further restrictions on that. That's part of our security guardrail solution. Then once the issue is merged, it gets merged into the, or once the branch is merged on the issues closed, the continuous delivery pipeline runs. And we deploy that into either our staging environment and we can run for the test or we can have that deployed to production, depending on how we like to set that up. And then we'll have the security scans run again just to validate that they're not detected again and that there's nothing further within the default branch. And then we can analyze everything through the security dashboard and triage any vulnerabilities and go through anything that we had to release because it was a critical hot fix, but we still want to know that it's there to work on fixing that later. So what scans were actually run? What security scans were run? So there was SAST, which scans the static source code. There's dependency scanning, which scans all of our software dependencies. So that would be, for example, in Python, it would be the requirements.txt file, we'd check the versions and see if there's any vulnerabilities in those and we'd report that. Same thing with container scanning. We look at the different versions of your Docker container images and see, and all the items within it and see what's vulnerable or not. And we use a vulnerability database. So we use the CVE database. We use our own, we have our own security researchers as well that add to our own database. And we go from there to detect these different issues for all of our vulnerabilities. We also detect secrets, licenses, instead of just only, so these are all static analyzers that check our static source code. But we also want to check the running application just in case there's something like a, like bad authentication practices or cross-site scripting vulnerabilities that we can't really find within the static code. And we've also added fuzz testing for static code. So we have coverage-based fuzz testing, which will send a bunch of random data to our functions. So it's kind of like an extended form of unit testing to find where we're not just writing the unit test ourselves, we have random data being passed into our functions. And there's also web API fuzzing, which will send a bunch of random requests to our APIs. So that's our security scans. And we continuously enhance different things and add to our security scans. But you can check out that within the GitLab documentation. So now let's add the AppSec engineers or the security team and see what their role is within the software developer lifecycle. So the security team's role is to view the vulnerability dashboard, triage and assess vulnerabilities and see what their criteria is and what their, like how vulnerable the system is and how, if there are high, severe, critical vulnerability, we'll assess all of that. And we can triage and see what developers need to work on. And we can really collaborate. Developers can leave messages to the security team. The security team can approve or deny these messages, and they can really keep track of everything going on within a project or even a group of projects. So I'm going to give you a live demo of this, but just to kind of just give you an overview. There will be a merge request and you'll be able to see the eligible approvers. You'll be able to see the security scans and licenses detected. And you'll be able to have a license policy. It's like, went over this briefly. I'll go over this in more detail. And you can kind of see a developer can see everything within the merge request and be able to continuously push onto that feature branch, resolving vulnerabilities before they have a final product. So this doesn't need so many reviews and codes to see where the vulnerabilities are. We tell you where they are. And the security team can validate that, but your developers will be able to continuously push code until they're resolved and see the results. And once you see the vulnerabilities, you can actually click on them and see a lot more details. And you'll be able to dismiss them or create an issue on them further to work on it within the future. And the AppSec engineer workflow, you'll see that they can actually see the security dashboard and they can triage vulnerabilities. They get a bunch of information. They can change the status and also create issues to work on it later. And then I also want to note that these are confidential issues that only those with access can see. And the reason why that's something important is because we won't allude to any malicious actors that this is a vulnerability. We can fix it and then give an update on, hey, this is vulnerable, make sure you update your system. And then we also have the security dashboard to assess the security posture of a particular project or group of projects. So they get different ratings and this is something that we can show to the executive team, hey, we had this hackathon and we lowered the vulnerabilities. Maybe we should have this more often or we had to refactor all this code or to introduce these vulnerabilities so you can actually see events and what may have caused, what may have introduced vulnerabilities on the system. So now let's get to the fun part, the demo and check in my time. Okay, I got about five minutes or so. So here's a project that I have with all this, all these security scans set up and it's very easy to set up. Pretty much I'm including templates and then I can either configure these templates via variables or I can configure them with their own job. Like my first target will tell the fuzzer what to do. So here I'm pretty much building the container image. I'm doing coverage based buzzing, running my unit tests and security scans, deploying staging, then running my DAST and API fuzz testing. And you see that like SAS is just added with this template being included. And I'm also enabling scan Kubernetes manifest the truth so I can scan all my YAML files as well. And I'm adding extra information for the fuzzer and for DAST here. And that looks like this. So build stage, coverage fuzzing, all of our scanner tests and so SAS is per language. So you'll have a different SAS tests per language running, but they'll all aggregate into one place within the merge request. And then you see all the point of staging, then we run DAST on that staging environment and we run the API fuzzer. So if in a merge request, I added a new route. And first thing we see is that it requires two or more approvals for license check and vulnerability check. So you can see that we have, let's say, a lawyer here that's going to check our licenses to make sure they're compatible. And we have members of the security team here to make sure that if we detect something vulnerable or critical or high of vulnerability, then we can block it and one of these two members most approved before it can be merged. Same thing if we detect an incompatible license. So these scans as of recently, these vulnerability check and license check can be configured to anything like what branch vulnerabilities are detected on, what severity, what types. So you can fully configure this. And once we expand, we can see all the vulnerabilities. And I'm just going to show you when you click on the one, depending on the scanner that's used, there'll be different information like this one's Python bandit. So we'll have access to where in the file the vulnerability is. So here you can see that I'm giving too much permissions to the database file. So there's global permissions on this file. That's a bad practice. And I know that here. And why is that a bad practice? Well, I can go here to find out more information. And it's a bad practice because it's too permissive. And anyone can edit it and perform malicious activities on it. So there's more information on that. And that enhances developer education. So once I go on here, as a developer, I can actually dismiss this and say, hey, this is actually a test ID and need to need access for this particular reason. So I can add comment and dismiss it. And you see that there's a dismiss label here with information on it. So once this is merged, it'll actually go into the vulnerability dash of the vulnerability reports. And the security team can actually see this note. And they can approve it and say, oh, yeah, that is the test database. So let's go ahead and approve this because it's not really a vulnerability because of that. So that's one way that they collaborate. You see different information on, you know, Kubernetes manifests. And you can see like dependency scanning looks different. And you can see what the solution is. You can see links to the CDEs and details. And you can see a description. And different things like container scanning do the same thing. They give you lots of links and solutions, descriptions. And in DAFs, you'll actually be able to see the request that was sent and the actual response. And it'll provide you evidence to what happened. And the solution as well. So we also have coverage-based fuzzing exception. So we can see the stack trace and see that there was a not implemented error that came out when we were trying to fuzz something. And API fuzzing, you'll see the same thing. They sent a really weird request here to the API that we set up. And we received the 500 internal error. And this was our actual response. So we know that there's a problem there because it's a 500. And I did click on the create button issue on this one. And you can see that it did create an issue that's confidential to actually look deeper into this. And we can also create a confidential merge request to work on a fix without letting anyone know except those that need to know. So now let's go into security and compliance. Let's go into the vulnerability report. And this is everything within the default branch that was vulnerable. So we can see all of that. And we can actually click on one. And we see it's detected. It was detected five days ago. We can see the exact pipeline it was detected. And we can say, well, we know that this is a vulnerability. We've actually tested it. And what we can do is we can go ahead and confirm that, change the status, refresh the page. And you can see it was confirmed just now by being. And so everyone on the security team will be able to see this and they can add a bunch of different comments and it go through there. There's also the security dashboard. And this is what I was talking about when, you know, different vulnerabilities that were introduced over time. So you can see that there was 24 info introduced at this point and there was two mediums. So we can see why were they introduced and go to the date of the merger question and the commits and see when things were introduced. So it seems like we are out of time. So I'd like to leave y'all with that. And thank you for attending. I really hope you enjoyed this. And, you know, this was a great session. I really enjoyed being here with y'all and going over these security features. So for more information about that get lab.com is a great resource. And you can see all of our security features within there. And just be sure to access that. So I thank y'all for attending us.