Security Essentials Lab Updates

1. From your **My Test Group** training subgroup, click the **New project** button.

### Task B. Create a Project

## Task B. Create a Project

1. Click the **Create blank project** tile.

1. Click **Create project**.

## Task B. Turn Off Auto DevOps

> By default, projects in some GitLab environments will enable Auto DevOps when no CI configuration file is found in a project. To avoid any conflicts between our CI/CD configuration and Auto DevOps, you should confirm that Auto DevOps is disabled in your project.

1. In the left sidebar, navigate to **Settings > CI/CD**.

1. Click on the **Expand** button next to Auto DevOps.

1. Ensure that **Default to Auto DevOps pipeline** is unchecked.

1. Click the **Save changes** button.

1. In the left sidebar, navigate to **Code > Repository** to return to your code.

## Task C. Enable and Configure SAST

> Static Application Security Testing, or SAST, is the process of examining source code for vulnerabilities. You can use a SAST scan to automatically scan a code repository for known vulnerabilities. You can also use a SAST scan to check merge requests for vulnerabilities before merging the request. This process helps ensure that your code stays vulnerability free.

    - template: Security/SAST.gitlab-ci.yml

    ```

    > It is also possible to configure SAST through the GitLab UI by navigating to **Secure > Security configuration** and clicking the **Configure SAST** button. We will be configuring it by editing the CI file for this lab to help you learn more about how it works under the hood.

    > It is also possible to configure SAST through the GitLab UI by navigating to **Secure > Security configuration** and clicking the **Enable SAST** button. We will be configuring it by editing the CI file for this lab to help you learn more about how it works under the hood.

1. Add a variables section to the end of your `.gitlab-ci.yml` file and set the `SAST_EXCLUDED_PATHS: venv/`.

    >

    > As an example, Python projects often contain a `venv` directory that contains packages used by the project. Since this directory does not contain our own source code, we should exclude it from the SAST scan.

    >

    > A full list of SAST variables can be found in the <a target="_blank" href="https://docs.gitlab.com/ee/user/application_security/sast/#available-cicd-variables">documentation</a>.

    > A full list of SAST variables can be found in the [documentation](https://docs.gitlab.com/user/application_security/sast/#available-cicd-variables).

1. Add an appropriate commit message (ex. `Add SAST template to .gitlab-ci.yml`), set the **Target Branch** to `main`, then click the **Commit changes** button.

1. Click the **Commit changes** button, add an appropriate commit message (ex. `Add SAST template to .gitlab-ci.yml`),  and ensure that the 'Commit to the current `main` branch option is selected.

1. Click the **Commit changes** button.

1. Once complete, you will have a `.gitlab-ci.yml` file that looks like this:

    print("Application authentication was successful")

    ```

1. Add an appropriate commit message (Ex. `Add prompt for server authentication`), set the target branch to `add_auth`.

1. Click the **Commit changes** button, Add an appropriate commit message (Ex. `Add prompt for server authentication`), set the target branch to `add_auth`.

    > Setting the target branch to `add_auth` will create a new branch named `add_auth`, and open a merge request on the branch.

1. Make sure that the **Start a new merge request with these changes** checkbox is checked.

1. Make sure that the **Create a new merge request for this change** checkbox is checked.

1. Click the **Commit changes** button.

1. In the resulting merge request, set the name to `Add prompt for server authentication`, and leave all the fields as default.

1. In the resulting merge request, set the name to `Add prompt for server authentication`, and leave the rest of the fields as default.

1. Click the **Create merge request** button.

    > You may need to refresh the page to see the new security scan section.

1. In this example, the security scan will show 1 new high vulnerability. To view the details of the vulnerability report, click the **View all pipeline findings** button.

1. In this example, the security scan will show 1 new high vulnerability. To view the details of the vulnerability report, click the **View all pipeline findings** option.

## Task E. Merge Request Vulnerability Report

    print("Application authentication was successful")

    ```

1. Click the **Commit changes** button.

1. Click the **Commit changes** button, then click the **Commit changes** again.

    > You may need to refresh the page to see the latest changes.

    - template: Security/Secret-Detection.gitlab-ci.yml

    ```

    > It is also possible to configure Secret Detection through the GitLab UI by navigating to **Secure > Security configuration** and clicking the **Configure Secret Detection** button. We will be configuring it by editing the CI file for this lab to help you learn more about how it works under the hood.

    > It is also possible to configure Secret Detection through the GitLab UI by navigating to **Secure > Security configuration** and clicking the **Configure with a merge request** button under **Pipeline Secret Detection**. We will be configuring it by editing the CI file for this lab to help you learn more about how it works under the hood.

1. Configure Secret Detection to ignore the test directory by pasting this job definition at the end of `.gitlab-ci.yml`. The first line should have no indent.

    > To configure Secret Detection to use non-default behavior, you can override the **secret_detection** job definition and add variables inside it.

    >

    > A full list of Secret Detection variables can be found in the <a target="_blank" href="https://docs.gitlab.com/ee/user/application_security/secret_detection/#available-cicd-variables">documentation</a>.

    > A full list of Secret Detection variables can be found in the [documentation](https://docs.gitlab.com/user/application_security/secret_detection/pipeline/configure/#customize-analyzer-behavior).

1. Your `.gitlab-ci.yml` file will now look like this.

> When the security scanners find vulnerabilities, you need to keep track of whether they should be fixed or ignored. You do this by setting a vulnerability's **status**. There are several ways to do so, but in this lab you'll set status inside the Vulnerability Report.

1. There is a vulnerability in the report with the description `RSA private key`. This vulnerability indicates that a RSA private key is written in our repository. By looking at the code, we can confirm that there is an RSA private key in the code.

1. The second vulnerability, `GitLab Personal Access Token` implies that a GitLab token is present in the code. By looking at the code, we can confirm that this is true as well.

1. There is a vulnerability in the report with the description `RSA private key`. This vulnerability indicates that a RSA private key is written in our repository. By looking at the code, we can confirm that there is an RSA private key in the code. The second vulnerability, `GitLab Personal Access Token` implies that a GitLab token is present in the code. By looking at the code, we can confirm that this is true as well.

1. Since the vulnerabilities do exist in the code, click the checkbox next to each vulnerability. In the **Set status** dropdown, click **Confirm**. Click **Change status**.

1. Name the branch `fix-rsa`.

1. Leave the **Create from** dropdown as the default value `main`.

1. Leave the **Create from** dropdown as the default value `main`, and click the **Create branch** button.

1. Click the **Create branch** button.

1. You'll be returned to the **Files** page for the `fix-rsa` branch. Click the file `main.py`.

1. You'll be returned to the **Repository** page for the `fix-rsa` branch. Click the file `main.py`.

1. In the top right above the code, navigate to **Edit > Edit single file**.

1. Click the **Commit changes** button.

1. At the top of the change confirmation page, click the **Create merge request** button.

1. Make sure the **Commit to the current fix-rsa branch** option is selected, then click **Commit changes**.

1. Click the **Create merge request** button.

1. Leave all of the fields at their default values, then click the **Create merge request** button.

1. Keep all the options as their default, and click **Create merge request**.

1. On the merge request page, wait for the pipeline to complete.

description: "This Hands-On Guide walks you through enabling and using a Dependency Scan in a GitLab project."

---

> Estimated time to complete: 15 to 30 minutes

> Estimated time to complete: 15 minutes

## Objectives

## Prerequisites

Before beginning this lab and all later labs, you should disable any scanners that you enabled in previous labs to speed up pipeline runtime.

Before beginning this lab and all later labs, you should remove any scanners that you enabled in previous labs to speed up pipeline runtime.

1. Open your browser to the **Security Labs** project that you created in Lab 1.

    > If you closed the tab or lost the link, open a browser tab and start typing https://gitlab.com/gitlab-learn-labs in your URL, and the project should appear in your history.

2. To disable a scanner, add a hash before the template that enables it in `.gitlab-ci.yml`. For example, the DAST scanner takes some time to run, so, to disable the DAST scanner configured in Lab 1, make these edits to your existing `.gitlab-ci.yml`.

2. Remove the lines that contain the DAST stage, and the DAST scanner. It should look similar to the example below.

    ```yml

    stages:

    - test

    #- dast

    include:

    - template: Security/SAST.gitlab-ci.yml

    - template: Security/Secret-Detection.gitlab-ci.yml

    #- template: DAST.gitlab-ci.yml

    variables:

      SAST_EXCLUDED_PATHS: venv/

      #DAST_WEBSITE: https://example.com

    secret_detection:

      variables:

        SECRET_DETECTION_EXCLUDED_PATHS: tests/

    ```

    > It is also possible to disable these features by setting CI variables on the project, such as `DAST_DISABLED=true` and `SECRET_DETECTION_DISABLED=true`. Learn more in the <a target="_blank" href="https://docs.gitlab.com/ee/topics/autodevops/cicd_variables.html#job-disabling-variables">documentation</a>.

    >

    > It is important to leave at least one job active in your `.gitlab-ci.yml` file. If there are no jobs defined in the pipeline, it will fail to run.

## Turn Off Auto DevOps

> Before proceeding with this section, to avoid any conflicts between our CI/CD configuration and Auto DevOps, you should confirm that Auto DevOps is disabled in your project.

1. In the left sidebar, navigate to **Settings > CI/CD**.

1. Click on the **Expand** button next to Auto DevOps.

1. Ensure that **Default to Auto DevOps pipeline** is unchecked.

1. Click the **Save changes** button.

1. In the left sidebar, navigate to **Code > Repository** to return to your code.

    > It is also possible to disable these features by setting CI variables on the project, such as `DAST_DISABLED=true` and `SECRET_DETECTION_DISABLED=true`. Learn more in the [documentation](https://docs.gitlab.com/ee/topics/autodevops/cicd_variables.html#job-disabling-variables).

## Task A. Add Project Dependencies

> Python-based projects often use pip for package management. With pip, developers will often provide a list of dependencies in a file called `requirements.txt`.

>

> Although this example uses Python with the pip package manager, GitLab supports various other package managers. For a full list of supported languages and package managers, click [here](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers).

> Python-based projects often use pip for package management. With pip, developers will often provide a list of dependencies in a file called `requirements.txt`. Although this example uses Python with the pip package manager, GitLab supports various other package managers. For a full list of supported languages and package managers, click [here](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers).

1. In your `Security Labs` project, navigate to **Code > Repository**.

1. Create a file by clicking **+ > This directory > New file**

1. Set the Filename to `requirements.txt` and add the following text.

1. Set the filename to `requirements.txt` and add the following text.

    ```text

    requests==2.27.1

## Task B. Enable Dependency Scanning

> The Dependency Scanner will traverse your project dependencies looking for security vulnerabilities.

>

> You'll enable Dependency Scanning by including a GitLab-provided template in your CI/CD configuration file. You can do this manually, or you can use the GitLab GUI to make a merge request that does it for you. Since you used the manual technique to enable SAST, Secret Detection, and DAST in the last lab, use the GUI to enable Dependency Scanning in this lab.

> The Dependency Scanner will traverse your project dependencies looking for security vulnerabilities. You'll enable Dependency Scanning by including a GitLab-provided template in your CI/CD configuration file. You can do this manually, or you can use the GitLab GUI to make a merge request that does it for you. Since you used the manual technique to enable SAST, Secret Detection, and DAST in the last lab, use the GUI to enable Dependency Scanning in this lab.

1. Navigate to **Secure > Security configuration**.

1. In the middle of the page, find the notification that a pipeline is running on the MR's branch.

    1. It could take a few minutes for the pipeline to finish, even if you've disabled scans from the previous lab.

    2. Do **not** click **Auto-merge** button since that can lead to unexpected behavior.

    3. Wait for the pipeline to finish. You can watch it by navigating to **Build > Pipelines** or clicking on the pipeline number in the merge request.

    * It could take a few minutes for the pipeline to finish, even if you've disabled scans from the previous lab.

    * Do **not** click **Auto-merge** button since that can lead to unexpected behavior.

    * Wait for the pipeline to finish. You can watch it by navigating to **Build > Pipelines** or clicking on the pipeline number in the merge request.

1. After the pipeline has finished, click the **Merge** button in the MR. You might need to refresh the page to see this button.

        SECURE_LOG_LEVEL: "info"

    ```

    > For a full list of variables available for dependency scanning, see the <a target="_blank" href="https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#available-cicd-variables">documentation</a>.

    > For a full list of variables available for dependency scanning, see the [documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#available-cicd-variables).

1. Commit this change to the **main** branch, using `Change log level for Python dependency scanner` as a commit message. Click **Commit changes**.

description: "This Hands-On Guide walks you through enabling and using Container Scanning in a GitLab project."

---

> Estimated time to complete: 15 to 20 minutes

> Estimated time to complete: 15 minutes

## Objectives

1. Above the repository file list, click **(+) > This directory > New file**.

1. In the **File name** field, type `Dockerfile`.

    > It is important that the first letter is capitalized for industry standards.

1. In the **File name** field, type `Dockerfile`. It is important that the first letter is capitalized for industry standards.

1. The `Dockerfile` must specify which Linux image to install your application on. For this lab you'll use an old version of Python that has security vulnerabilities for the Container Scanner to find. Paste this into `Dockerfile`:

    ```dockerfile

    ```Dockerfile

    FROM python:3.4-alpine

    ```

1. The Dockerfile must add your application to the Linux image specified above. Paste this at the bottom of `Dockerfile`:

    ```dockerfile

    ```Dockerfile

    ADD main.py .

    ```

1. Your completed `Dockerfile` should look like this. Make any corrections necessary.

    ```dockerfile

    ```Dockerfile

    FROM python:3.4-alpine

    ADD main.py .

    ```

1. Edit the `.gitlab-ci.yml` file.

1. Copy and paste this to overwrite all of the contents of your `.gitlab-ci.yml` file. This has commented out sections of jobs and scanners that we won't be using for the rest of the class to speed up our pipeline.

1. Copy and paste this to overwrite all of the contents of your `.gitlab-ci.yml` file. This is to ensure that we do not have any unnessescary scanners running that would slow down our pipeline. We are keeping the SAST job in order to maintain the `.gitlab-ci.yml` file's formatting.

    ```yml

    stages:

    # - build

    - test

    # - dast

    include:

    - template: Security/SAST.gitlab-ci.yml

    # - template: Security/Secret-Detection.gitlab-ci.yml

    # - template: DAST.gitlab-ci.yml

    # - template: Security/Container-Scanning.gitlab-ci.yml

    # variables:

    #  SAST_EXCLUDED_PATHS: venv/

    #  DAST_WEBSITE: https://example.com

    #secret_detection:

    #  variables:

    #    SECRET_DETECTION_EXCLUDED_PATHS: tests/

    #build-and-push-docker-image:

    #  stage: build

    #  image: docker:20.10.17

    #  services:

    #    - docker:20.10.17-dind

    #  variables:

    #    IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA

    #    DOCKER_TLS_CERTDIR: ""

    #  script:

    #    - docker build --tag $IMAGE .

    #    - docker login --username $CI_REGISTRY_USER --password $CI_REGISTRY_PASSWORD $CI_REGISTRY

    #    - docker push $IMAGE

    ```

    > Note that we need to keep at least one job enabled for the pipeline to succeed. In this example, the SAST job is left enabled since it is the quickest to complete.

1. Set the commit message to `Lab 3 pipeline reset` and commit your changes to the `main` branch.

## Lab Guide Complete

1. Return to the merge reqest overview.

1. Click **Full report**.

1. The license compliance report will list all of the licenses that are no longer in compliance with the project policy Note that the merge status will appear stating **Requires 1 approval from policy**.

1. The license compliance report will list all of the licenses that are no longer in compliance with the project policy. Note that the merge status will appear stating **Requires 1 approval from policy**.

1. A new comment is also added to the activity of the merge request, stating that a policy violation was detected.

1. Navigate to **Secure > Policies**.

2. Click on the policy you created. Click **Edit policy**.

1. Click on the policy you created. Click **Edit policy**.

3. Click **Delete Policy**.

1. Click **Delete Policy**.

4. Click **Merge** on the resulting merge request.

1. Click **Merge** on the resulting merge request.

## Lab Guide Complete