#1 Shifting Left

Create a merge request to add security scans to our pipeline

Theme

This section focuses on shifting left as a security practice and how your code changes will display security results after a commit rather than months down the line

  • Step 1: Adding Security Scans
    • First make sure that you are on the main page of the project you just forked in. It is best if you have these issues open in a separate tab/screen while completing the tasks.

    • Once ready use the left hand navigation menu to click through CI/CD > Editor. Here you will see the current set up of our main branch pipeline. Notice that only there is only the build stage, which is further defined lower to outline how we build our application from docker.

    • This pipeline does very little in terms of security scanning, so lets go ahead and create a new branch to add out changes. Go ahead and use the left hand navigation menu to click through Repository > Branches then click New branch. Name the branch completed-pipeline and make sure it is based off of main, then click Create Branch.

    • Once again use the left hand navigation menu to click through CI/CD > Editor to get back to the editor page. Then in the top left of the editor view you can click the branch dropdown to then select completed-pipeline. We then want to change the pipeline yaml to be the code below:

      image: docker:latest
      
      services:
        - docker:dind
      
      variables:
        DOCKER_DRIVER: overlay2
        DOCKER_TLS_CERTDIR: ""  # https://gitlab.com/gitlab-org/gitlab-runner/issues/4501
      
      # adding the test and dast & fuzz stages allow for the OOTB (out of the box) security scans to run
      stages:
        - build
        - unit
        - test
        - cleanup
      
      include:  
        - template: Jobs/Build.gitlab-ci.yml
        - template: Jobs/Code-Quality.gitlab-ci.yml
        - template: Security/Container-Scanning.gitlab-ci.yml
        - template: Security/Dependency-Scanning.gitlab-ci.yml
        - template: Jobs/SAST.gitlab-ci.yml
        - template: License-Scanning.gitlab-ci.yml
        - template: Jobs/Secret-Detection.gitlab-ci.yml
        - template: Jobs/SAST-IaC.gitlab-ci.yml
      semgrep-sast:
        variables:
          SAST_ANALYZER_IMAGE_TAG: "3.12.0"
          SEARCH_MAX_DEPTH: 50
          SECURE_LOG_LEVEL: "debug"
      
      build:
        stage: build
        variables:
          IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
        script:
          - docker info
          - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
          - docker build -t $IMAGE .
          - docker push $IMAGE
      
      unit:
        image: python:alpine3.12
        stage: unit
        script:
          - apk update
          - apk add gcc sqlite-dev musl-dev
          - pip install --upgrade pip
          - pip3 install -r requirements.txt
          - python -m unittest tests/test_db.py
      
      gemnasium-python-dependency_scanning:
        variables:
          SECURE_LOG_LEVEL: "debug"
          RUNNER_GENERATE_ARTIFACTS_METADATA: "true"
          CI_DEBUG_TRACE: “true”
          DS_REMEDIATE: "true"
          GIT_STRATEGY: fetch
        before_script:
          - apt update -y
          - apt install gcc sqlite3 libsqlite3-dev musl-dev -y
    • First looking at the include section you can see that a number of security templates have been brought into our project. These define different scans and jobs that will now be ran based off of our stages. To get a better look into the templates you can click View merged YAML which will show the true pipeline yaml with all of the templates brought in. You can also click the branch icon in the top left to then click into a specific template to get its definition.

    • Click Edit again to be brought back to our normal editor. Notice that we have defined an additional 2 extra jobs at the end of the yaml that will take place during both the unit & test stages.

    • Now that our changes are in lets click Commit changes at the bottom of the page.

  • Step 2: Creating the Merge Request
    • Now to actually merge in the code we want to use the left hand navigation menu to click through Repository > Branches & then click Merge request in the completed-pipeline section. ENSURE YOU HAVE REMOVED THE FORK RELATIONSHIP BEFORE DOING THIS
    • On the resulting page scroll down to the Merge options and uncheck Delete source branch when merge request is accepted. You can leave the rest of the settings as is then click Create merge request.
    • first resolve any merge conflicts that may exist, but you should see a pipeline kick off. If you click the hyperlink it will bring you to the pipeline view where you can see all of the various jobs that we added to our yaml file. While this runs we are going to move forward to set up our compliance framework pipeline but we will check back in a bit to see the results of our scanners.
    • Next we want to kick off the pipeline for the MR. Use the left hand navigation menu to click through CICD > Pipelines then click Run pipeline in the top right of the screen. From there change the branch to completed-pipeline and click Run pipeline again.