 Hello, my name is Fernando, and I'm a Technical Marketing Manager here at GitLab. Today I'm going to go over GitLab security features and how they enable collaboration between developers and app stack engineers, while at the same time making each of their workflows more efficient. It starts with a developer creating a merge request from a feature branch they have been working on. The security scans are automatically run as part of the CI CD pipeline, detecting vulnerabilities and displaying them along with detailed information in a uniform interface. Developers can resolve and rerun the pipeline for regression testing. This shifts security left, catching vulnerabilities before the code is pushed to production. Here's a GitLab pipeline containing several stages. There's the build stage, which builds the application, containerizes it, and pushes it into a container registry. Then there's the test stage, which runs unit tests, as well as a variety of different security scans. These scans include SAST, or Static Application Security Testing, which searches the static code for known vulnerabilities. There's secret detection, which detects unintentionally committed secrets and credentials within your repository. Then there's container scanning, which searches the container images for known vulnerabilities. We also have dependency scanning, which searches through your dependency file versions for any known vulnerabilities. There's coverage guided fuzz testing, which helps you discover bugs and potential security issues that other QA processes may miss by sending random inputs to an instrumented version of your application. Then there's the deploy stage, which deploys our code into a staging environment. After the code has been deployed, we run DAST, or Dynamic Application Security Testing, on the running application. This sends malicious requests to the application, in order to detect vulnerabilities. That's a good idea. There's the deployment stage, which displays our code into a staging environment. Then there's the application, in order to detect vulnerabilities. DAST can also be run on ephemeral staging environments, spun up by GitLab CI. All the security scans are run on a feature branch, and find vulnerabilities before they are merged into the main branch. By finding vulnerabilities in the feature branch, we can resolve them before pushing to production, minimizing risk and enhancing security. These scans can be configured with the GitLab CI.yaml file, or using AutoDevOps. The pipeline we saw earlier runs on the feature branch and pushes all the scan results to the MR. As part of the developer workflow, the developer edits some code on a feature branch and pushes up a merge request, or MR. This MR has approval set up. There is a vulnerability check, which means that if there is a vulnerability of a certain severity detected, then an approval is required before this MR can be committed. There is also a license check, which requires approval if a denied license is detected. These checks can be configured in the CI CD section of the project settings. Now let's take a look at the results from the security scans. This is an example of a SAS vulnerability. It contains detailed information on the vulnerability, its severity, its location, as well as how to resolve it. In order to start a discussion around the vulnerability, a confidential issue can be created without alluding to the vulnerability. This enables developers and the security team to collaborate on finding a resolution. A confidential merge request can also be created, only allowing those with permissions to read. Open-to-issue status changes are tracked, which is great for compliance audit trails. Now let's take a look at a dependency scanning vulnerability. You can see that there is also detailed information on the vulnerability and how to resolve it. There are also relevant links to the CVE, which go in-depth on how the vulnerability affects the system. This is great for furthering an organization's security knowledge. Next we have a container scanning vulnerability. It provides detailed information as well and can be auto-remediated with a click of a button. A merge request will be created, which will re-run the pipeline, allowing for regression testing. This tests if the changes succeed. Then there's a DAS vulnerability, which shows information on the request sent and received, along with relevant links to the vulnerability. If a developer feels this vulnerability is not valid, they can dismiss it with a comment. This information is tracked and can be seen by the security team. The dismissed vulnerabilities are set aside for the project, but the security team can evaluate them within the dashboard. There is also license scanning, which detected a new license. A member of the security team can add the license to the denied licenses policy, and it will block the MR from being committed unless it is approved. We have seen how developers interact with vulnerabilities and how they can verify, dismiss, and resolve them. The security team is able to collaborate as well with the full overview of all the vulnerabilities within a project or group of projects. Security professionals use the security dashboard to obtain a high-level overview on all the vulnerabilities detected, enabling them to see the status of the detected security issues. They can sort through all the vulnerabilities and determine their status, severity, and which scanner detected them. The vulnerabilities can also be exported to CSV format, which is useful for consumption by outside applications. When clicking on a vulnerability, a member of the security team not only sees detailed information on the vulnerability, but can change its status to confirm, dismiss, or resolve it. This change is recorded in order to enable auditing. The security dashboard can also be seen at the group level, providing an overview of vulnerabilities in each project and grading each project by severity. You can also sort through all the vulnerabilities within the group by status, severity, scanner type, and project. For more information on GitLab's DevSecOps solution, check out the links in the description. Thanks for watching, and be sure to subscribe. Here at GitLab, everyone can contribute.