Updated and fixed Compliance ILT Labs

1. In the name, input `run scan`.

1. Add a relevant description in the description field.

1. Under 'Configuration Type', switch from "Template" to "Custom".

1. In the **Actions**, set the scan to run a **Secret Detection** scan. Leave all action configurations at default.

1. In the **Conditions** section, set to **Triggers:** for **all branches** with **No exceptions**.

1. In the **Conditions** section, set to **Triggers:** for **all branches** using **All pipeline sources** with **No exceptions**.

1. Select **Configure with a Merge Request**.

1. Select **Configure new project with the new policy**.

1. Select **Merge**.

1. Select **Commit changes**.

1. Select **Create Merge Request**.

1. Enter any commit message, or leave it as default.

1. Set the "Branch" option to **Commit to a new branch**

1. Enter any branch name, or leave it as default, and ensure that the **Create a merge request for the change** option is selected.

1. Select **Commit changes**.

1. On the Merge Request creation page that you are directed to, scroll down and select **Create merge request**.

1. Review the Merge Request pipeline. Note that there is now a secret detection scan job.

1. In the left sidebar, select **Settings > Repository** and expand **Push Rules**.

For this example, we want to ensure that every commit is targeted towards an issue in the project. Having the issue ID present in the commit message ensures that all activity related to the issue is logged in the issue. To do this, we can enforce an expression to ensure every commit message contains either an epic or an issue ID.

    > For this example, we want to ensure that every commit is targeted towards an issue in the project. Having the issue ID present in the commit message ensures that all activity related to the issue is logged in the issue. To do this, we can enforce an expression to ensure every commit message contains either an epic or an issue ID.

1. In the **Require expression in commit messages**, add the regular expression: `^.*(#\d+|&\d+).*`. The regular expression will match the string based on the pattern:

1. Select **Save push rules**.

To test this, let's first create a new issue in our project.

    > To test this, let's first create a new issue in our project.

1. In the left sidebar, select **Plan > Work items**.

1. Leave all other options as default and select **Create issue**.

Now, let's create a commit and see how our push rules impacts our commit messages.

    > Now, let's create a commit and see how our push rules impacts our commit messages.

1. In the left sidebar, select **Code > Repository**.

    > Notice here that you will get an error stating that the commit message does not follow the proper pattern.

1. Add the title `compliance_plan.txt` again.

1. In the **Commit message**, input the text `Starting work on issue #1`.

> You may need to re-enter the name of the file before committing.

1. Select **Commit changes**.

    > Now, your commit will complete successfully. From here, you can navigate back to your issues to see that the commit is tracked in the issue now.

1. Check the `No one` option, then select **Save changes**.

With this change, now no one can directly push to main. Only merges into main are allowed. To test this:

    > With this change, now no one can directly push to main. Only merges into main are allowed. To test this:

1. In the left sidebar, select **Code > Repository**.

1. Select **+ > New file**.

1. Note that the **Target Branch** is now set to a randomly generated branch name.

1. Add any **Filename** and add any content into the file body.

1. Add any **Filename**.

1. Select **Commit changes**.

1. Change the **Target Branch** to `main` and select **Commit changes**.

    > Note that you now don't have the option of pushing onto the main branch. 

1. Change the **Target Branch** field (which will currently have a generated branch name in) to `main` and select **Commit changes**.

    > You will see an error stating that you are not allowed to push into this branch.

1. *Optionally* add a different branch name and commit your new code.

## Task C. Cleaning Up Rules

Before proceeding to the next set of labs, it's recommended to remove the commit message rules in your repository, as well as the rule that prevents pushing on the main branch. This will prevent any issues of preventing commits due to violations.

1. Click on the **View Details** option to the right of the main branch.

1. Click on the **Edit details** option to the right of the 'Allowed to push and merge' section.

1. Click on the **Edit** option to the right of the 'Allowed to push and merge' section.

1. Change the setting from **No one** to **Developers and Maintainers**.

    #

    #    pip-compile --output-file=requirements.txt requirements.in

    #

    requests==2.27.1

    fastapi==0.135.1

    ```

1. Select **Commit changes**.

1. Add any commit message. Switch the **Branch** setting to **Commit to a new branch**.

1. In the **Target Branch** field, enter the name `add-deps`.

1. Ensure that **Start a new Merge Request with these changes** is checked.

1. Ensure that **Create a merge request for this change** is checked.

1. Select **Commit changes**.

1. Leave all options in the Merge Request as default and select **Create Merge Request**.

1. Select **Merge**.

    > **NOTE** The "Merge" button may instead say "Set to auto-merge" if your pipeline is still running. This is fine - click the button, and the MR will merge as soon as the pipeline successfully completes.

1. In the left sidebar, select **Code > Repository**.

      - component: ilt.gitlabtraining.cloud/components/dependency-scanning/main@main

    ```

1. Set the **Target Branch** to `add-scans`.

1. Select **Commit changes**

1. Ensure that **Start a new Merge Request with these changes** is checked.

1. Set the **Commit message** to "Added pipeline configuration file with Dependency Scanning" or something similar.

1. Select the **Commit to a new branch** option, and set the **Target Branch** to `add-scans`.

1. Ensure that **Create a merge request for this change** is checked.

1. Select **Commit changes**.

## Task B. License Compliance Scans

1. Navigate to **Secure > Dependency list**.

1. Navigate to **Build > Pipelines**. Open your newly created pipeline by clicking on its status. You should see the **dependency-scanning** job running.

1. Once your pipeline has successfully completed, navigate to **Secure > Dependency list**.

1. Click any of the licenses to view more details about the license and the compliance requirements.

1. Set the **Policy status** to **Enabled**.

1. Set the **Policy enforcement** to **Strictly enforced**.

1. In **Rules**, set the **Select scan type** dropdown menu to **License Scan**. Ensure that `all protected branches` with `No exceptions` is selected for the Merge Request target.

1. Set the **Status is** dropdown menu to **Newly Detected**.

1. Set the first dropdown in the **License is** section to **Except**.

    > Next, we want to add the MIT License to our `Allow list`. There are a couple of ways to do this. Firstly, you **could** use allowlists and denylists through clicking on the link which says **allowlist (0 licenses)**. However, we are going to use a slightly different method which will help us more closely control which licenses are allowed and denied.

1. On the right-hand side of the **License is** section, click on the delete button (which looks like a bin icon).

1. Select **Add new criteria** and choose **License type** from the dropdown.

    > To exit the multi-select dropdown, click anywhere outside of it.

1. In the dropdown that currently says **Matching**, change this to **Except**.

    > Doing this will mean that every license requires MR approval *except* the one we are about to choose, meaning that this specific license is `allowed`.

1. In the **Select license types** dropdown, click `MIT License`. There are several licenses with similar names, so be sure to pick the right one.

1. In the **Select license types** dropdown, search for `MIT License` and select it. There are a couple of licenses that share a similar name, so make sure you select the correct one.

1. In the **Actions** section, require 1 approval from an individual user. Click your username as the approval user.

1. Leave the **Override project approval settings** checkboxes selected and click **Configure with a Merge Request**.

1. Expand out the **Advanced** settings. 

1. Deselect the **Prevent approval by merge request's author** and **Prevent approval by commit author** settings.

1. Click **Configure with a Merge Request**.

1. In the resulting Merge Request, click the **Merge** button.

1. In the left sidebar, select **Build > Pipelines**.

1. Select the **Run pipeline** button at the top right of the page.

1. Select the **New pipeline** button at the top right of the page.

1. Leave all of the options at their default values, then select **Run pipeline**.

1. Leave all of the options at their default values, then select **New pipeline**.

1. Monitor your pipeline and wait for each job to complete successfully.

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

3. Click **Delete Policy**.

3. Click **Delete Policy** at the bottom of the page.

4. Click **Merge** on the resulting Merge Request.

    include:

        component: ilt.gitlabtraining.cloud/components/sast/sast@main

    semgrep-sast:

        rules:

            - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

    ```

1. Select **Commit changes**.

1. Commit these changes to the main branch of the project.

This CI/CD configuration contains a SAST scanner. By adding this in a pipeline execution policy, we can ensure that our project always runs a SAST scan. Let's see how to configure this for our project.

1. Point the file path to your `.gitlab-ci.yml` file.

1. Leave all options as default and select **Update via merge request**.

1. Leave all options as default and select **Configure with merge request**.

1. Select **Merge**.

1. Return to the `Compliance project` project.

To test these changes, let's create a change in the project.

    > To test these changes, let's create a change in the project.

1. In the left sidebar, select **Code > Repository**.

1. Select **Commit changes**.

1. Select **Create merge request**.

1. For the commit message, add something similar to "Added some python code for security scanning to test". 

1. Change the **Branch** selection to **Commit to a new branch** and title the new branch **add-code-for-sast**.

1. Ensure **Create a merge request for this change** is selected and click **Commit changes**.

1. Leave all options as default in the Merge Request and click **Create merge request**.

1. Review the pipeline created from the merge request. Notice that it has a `semgrep-sast` job even though it's not defined in `Compliance Project`. This job comes from our pipeline execution policy. Note that we were able to *add* a job into the pipeline because we used the 'inject' keyword when setting up our policy. If we instead used the 'override' keyword, it would run this job *instead of* the jobs in your pipeline.

1. Review the branch pipeline created. Notice that it has a `semgrep-sast` job even though it's not defined in `Compliance Project`. This job comes from our pipeline execution policy. Note that we were able to *add* a job into the pipeline because we used the 'inject' keyword when setting up our policy. If we instead used the 'override' keyword, it would run this job *instead of* the jobs in your pipeline.

1. Return to your merge request. You will see that there is one new vulnerability, detected by the SAST scanner.

1. In the left sidebar, select **Secure > Compliance Center**.

In this section, you will see three failed checks in your project. In cases where the **Status** is `Fail`, you will see `View details (fix available)` in the **More information** column. Let's see what information is shown in this section.

    > In this section, you will see three failed checks in your project. In cases where the **Status** is `Fail`, you will see `View details (fix available)` in the **More information** column. Let's see what information is shown in this section.

1. Select `View details (fix available)` in the `At least one non-author approval` row of your Compliance Center report.