 Hey there, my name's Fernando and as you may know, AppSec engineers are plagued with managing many vulnerabilities across many different projects, which can be something that's very overwhelming. This is where my presentation comes into play. I'll be speaking on managing vulnerabilities and enabling separation of duties to enable for more efficient and easy to manage security workflows. Now, to give you a little bit more information on myself, I'm a technical marketing manager here at GitLab, and I work on developing content such as videos, demos, blogs, and more to showcase our security features. My background is in software engineering, where I previously worked on the Kubernetes Ingress Controller developing some of the security features, as well as OpenStack's Barbican, where I was a core contributor to the key management project. Aside from software development, some of my hobbies include powerlifting, mountain biking, and just getting out there and exploring nature. Now, let's take a look at some of the desired outcomes from this presentation. We want greater efficiency between both developers and AppSec engineers, and this is going to be done through strong collaboration, streamline processes, and having a single source of truth. We also want reduced security exposure with greater visibility into the application risks, and being able to effectively manage and triage these vulnerabilities. What this is going to do is, it's going to save us money because we'll be able to find vulnerabilities before they make it to production. It'll make us more compliant and thus reduce the risk of our company's reputation being harmed by information exposure, and it'll save lots of time because it will enable collaboration between AppSec engineers and developers. The topics I will be covering are, the developer life cycle with DevSecOps, security policies, merge request vulnerability views, vulnerability management, and then I'm going to put that all together and show you a demo with all these tools within the DevSecOps process. Here we see a standard software developer life cycle with DevSecOps integrated. You can see that an issue is created on the default branch, and from there we create a new merge request trying to align a feature branch with our default branch. What we can see as we commit the changes, the CI pipeline runs along with the security scans, and then we deploy our application to a review app, which is an ephemeral environment, or we can also deploy the staging and run DAS on that to find vulnerabilities within a deployed application, and then we can have a discussion, a code review, and security engineers can actually approve these changes before the code makes it into production, therefore allowing developers to continuously iterate resolving security bugs or vulnerabilities before this code changes, make it into our production environment, making it much more secure. And once that code is merged into production, which in this case is our default branch, security dashboards can be used as well as vulnerability management features in order to triage and manage and maintain these vulnerabilities, making their resolution much more efficient. And then here we can see how GitLab provides best practices across the entire software development lifecycle. Now let's take a little look at security policies. Here we can see the policy management dashboard, where you can enable, disable, create, delete, or edit policies. This makes it easy to actually disable the policies and change them as your application needs change and remember the history of what was once applied. Now we can see that there's two different types of policies. The first policy we have is the scan result policy. Now the way that this policy works is it will require approval for a merge request to actually be committed into the main branch depending on the results of the security scans. So what happens here is it's evaluated after the CI scanning job is fully executed, in this case being all the different types of security scans. And what you can see here is that you can define particular rules to determine which scanners will require approval, which securities will require approval, as well as on which branches approval will be required. This enables separation of duties. Then there's scan execution policies, which requires that security scans either run with the pipeline or within a particular schedule. And what this does is, no matter what the GitLab CI file contains, scans will always be run and set by either administrators or members with permissions, meaning that no matter what a developer does within the pipeline, whether they try to disable particular security jobs to merge the code, they will not be able to do that because scans are forced to run each time. And how does separation of duties come into play with these policies? Well, you can see that there are security policy projects which are inherited from development projects. And these security policy projects can actually have different permissions than the development projects. Therefore, we can have apps like engineers have access to security policy projects and manage these policies where developers were actually not be able to change this. So therefore, either approvals will be required when vulnerabilities are found or certain vulnerability scans will always be forced to run no matter what changes are made to the development project. And since there are different permissions, then the duties are therefore separated. Now let's go into the merge request vulnerability view. So every time you push up a merge request, you're gonna see a whole bunch of different security scans which we've integrated run. Once these scans complete, you're gonna see that there are eligible approvers required. And the reason why they're required is because of the policy that we've set up previously. Now note that these policies are not only for vulnerabilities detected, but they can also be done for incompatible licenses detected. So we can set which licenses will require approval. That way we're making sure that licenses that are too restrictive don't make it into our application. And these restrictive licenses can actually affect the legality of our code and possibly require us to open-source it or have some other types of restrictions on our code. So we wanna make sure that that's not something that happens to us. And next you'll see within the merge request view that once you click on a vulnerability, you'll get a box pop-up that gives us detailed information on that vulnerability such as where in the code it's contained, a link to the CVE, as well as how to result. And these vulnerabilities are actionable, meaning that you can either dismiss them with a note to AppSec engineer so that way they can see why it was dismissed and approve it if the reason is valid such as maybe it was a test file that you created or a test database where the vulnerability is present that you're actually using to test particular features or the security of the project, then that would be a valid reason for dismissal. You can also create a confidential issue to continue to work on this later if it's not something that can actually be resolved right away, but we need to push a hot fix. And that way we're not alluding malicious actors into seeing the vulnerability, that way we can resolve it in time before we actually release that this was a vulnerability and for everyone who's using this product to update it. And last, we're gonna go over vulnerability management. Now with vulnerability management, we have a dashboard which shows all the vulnerabilities within a group of projects or we can scale down to a single project. So this gives us all our vulnerabilities which we can sort by its status, its severity, what scanner found the vulnerability and even third-party scanners can be integrated into this view as well as if there's been any activity recently on the vulnerability. And when you click on one, you get the same pop-up that you would get in the merge request view with detailed information and you can go ahead and change the status and this particular screenshot, the status is currently detected but it can be moved to confirmed once that vulnerability has been validated. And in this view, AppSec engineers can collaborate, add comments and work together to find the resolution. And notice that it's a single source of truth because the same thing that developers see, AppSec engineers will see and that way they can work together to find resolution much faster. And now for the fun part, let's put this all together in a demo. First, I'm gonna create a scan result policy. I'm gonna give it a name and description and then I'm gonna go ahead and flip the policy status to enabled to make sure that it will be enabled for our project. Then I'm gonna select all the different scanner types to require approval for if they find more than zero vulnerabilities of all severities. And I'm gonna leave this to newly detected vulnerabilities. And this is gonna be targeted across all branches. Then I can go ahead and add who I want the approvers to be which I'm gonna select one person, Sam White, as well as members of compliance automation. Now that I've added the policy, we can see it right here requiring approval from the members which I previously added. The approval will be required if any vulnerability at all of any type or severity is detected. Then if we go down in the merge request view and expand the security scanning tab, we can see that each of the scanners have found vulnerabilities. They're separated by scanner type and severity. If I go ahead and click on a particular vulnerability, I'll have a popup with detailed information which includes the file where the vulnerability is present. And here we can see the line of code where I have an error with a file that's too permissive. From the same view, I can dismiss this vulnerability with a comment, alerting the app sec engineers the reason why it's being dismissed while they're reviewing for approval. And you can see it's been dismissed with a little tag on the vulnerability itself. And note that different vulnerabilities have different descriptive information such as this one for information exposure in Django which includes linked to the CVE or CWE as well as a solution. Some vulnerability views include a stack trace such as this one for coverage-based fuzzing which shows an uncaught exception. One other action present within vulnerabilities is the ability to create an issue. Here we click on the create issue button and we're presented with a confidential issue where developers and app sec engineers can together collaborate to find the resolution without letting malicious actors be aware. And then there's the vulnerability report which provides app sec engineers an oversight of all the vulnerabilities within a project or a group of projects. And we can go ahead and sort by status, severity, the tool, the project as well as if any activity has been performed. Here we're gonna sort on DAST as well as API fuzzing which are two dynamic types of scans. And we'll go ahead and change our project to the simple notes project. And we can see that all the vulnerabilities present for DAST and API fuzzing are displayed. And when we click on one, we can see detailed information similar to that within the merger quest view which creates a single source of truth. Making it easy for app sec engineers and developers to be aware of the same information and make a decision based off of that. The status can also be changed. Here I'll confirm the vulnerability and we can see that it was confirmed by me just now. I can also scroll to the bottom and add a comment as to why I confirmed it. Letting other app sec engineers know the reason for this vulnerability being confirmed. All right, y'all. Well, thanks for watching and I really hope you enjoyed this presentation. And if you want more information on GitLab and our security features, be sure to visit about.gitlab.com. Thank you.