GitLab GitLab Use Cases, 29 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Shifting Security Left - GitLab DevSecOps Overview

Description

Learn how GitLab shifts Security left with a variety of Different DevSecOps tools, which provide Vulnerability Scanning and enable collaboration between Developers and AppSec.

Follow @awkwardferny and @gitlab on twitter. 🐦
Application Security Overview: https://docs.gitlab.com/ee/user/application_security/
Use Cases: https://about.gitlab.com/handbook/marketing/product-marketing/usecase-gtm/devsecops/
Secure Direction: https://about.gitlab.com/direction/secure/
How to Configure: https://youtu.be/Fd5DhebtScg
Get in touch with Sales: http://bit.ly/2IygR7z

A

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 appsec engineers, while at the same time making each of their workflows more efficient.

A

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 cicd pipeline, detecting vulnerabilities and displaying them, along with detailed information in a uniform interface developers, can resolve and rerun the pipeline for regression testing.

A

This shifts security left catching vulnerabilities before the code is pushed to production.

A

Here is a gitlab pipeline containing several stages. There is the build stage which builds the application containerizes it and pushes it into a container registry.

A

Then there's the test stage, which runs unit tests, as well as a variety of different security scans. These scans include sas or static application security testing, which searches the static code for known vulnerabilities, their 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.

A

We also have dependency scanning, which searches through your dependency file versions for any known vulnerabilities.

A

There is 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 license scanning which scans the license against the policy.

A

If they are denied within the policy, then the merge request will not be allowed to be committed.

A

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 tasks can also be run on ephemeral, staging environments spun up by gitlab ci.

A

All the security scans are run on a feature branch and find vulnerabilities before they are merged into the main branch.

A

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.yamo file or using autodevops.

A

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 setup.

A

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 cicd section of the project settings.

A

Now, let's take a look at the results from the security.

A

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

A confidential, merge request can also be created only allowing those with permissions to view 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.

A

This is great for furthering an organization's security, knowledge.

A

Next, we have a container scanning vulnerability. It provides detailed information as well and can be autoremediated with a click of a button. A merge request will be created which will rerun the pipeline allowing for regression testing this tests. If the changes succeed, then there's a das vulnerability, which shows information on the requests sent and received, along with relevant links to the vulnerability.

A

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.

A

The dismissed vulnerabilities are set aside for the project, but the security team can evaluate them within the dashboard.

A

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.

A

We have seen how developers interactive 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.

A

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.

A

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.

A

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.

A

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.

A

You can also sort through all the vulnerabilities within the group by status, severity, scanner, type and project for more information on gitlab's devsec ops solution check out the links in the description thanks for watching and be sure to subscribe here at gitlab. Everyone can.

A