Security Scanning¶

This section will go over security scanning and how you can implement it into your GitLab application.

Relevant GitLab pages (for further reading):

How to implement¶

There are two ways in which to implement security scanning:

manually adding and editing your .gitlab-ci.yml file (recommended)
enabling via the security configuration menu (where GitLab updates .gitlab-ci.yml via merge requests)

Editing .gitlab-ci.yml directly is the recommended method because it is easier to customize the security scanning tools.

Add and edit .gitlab-ci.yml¶

In the top level of your directory, create a file called .gitlab-ci.yml; This file defines the pipeline and the jobs that will be run. Edit and add the following:

include:
- template: path/to/ci-template-1
- template: path/to/ci-template-2

The templates indicate which security scanners are implemented; replace the placeholder paths with the desired template paths. Here are a few provided by GitLab you might want to implement:

- template: Security/Secret-Detection.gitlab-ci.yml  # Identifies leaked secrets and passwords
- template: Jobs/Dependency-Scanning.gitlab-ci.yml  # Identifies vulnerable packages in the project
- template: Security/SAST.gitlab-ci.yml  # Static Application Security Testing (SAST), identifies vulnerabilities in source code
- template: Jobs/Container-Scanning.gitlab-ci.yml  # Identifies vulnerabilities on Docker-based applications

All of the available GitLab templates can be found here: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates.

Customize security scanner¶

To start, you can keep the security scannerss at their default configurations. However, you can customize the security scanners by setting their properties to new values, such as

excluded paths that jobs should not scan
stage in which scan jobs are run (e.g. build, test)
search maximum depth

Below are links to the full list of customizable variables for the above suggested security scanners:

Commit changes¶

When you're finished editing .gitlab-ci.yml, commit your changes and push it to your repository. If your .gitlab-ci.yml has been configured properly, security scanning will now be enabled, and it will automatically run whenever a new commit is pushed to the repository.

Enable security scanning via user interface¶

To enable security scanning through the GitLab user interface, on the left menu, go to Secure --> Security configuration. Here, you will find the security testing options that are available, and whether or not they are currently enabled on your project. Enable by clicking the appropriate button, which will take you to a merge request page that will automatically edit your repository's .gitlab-ci.yml file to enable the security scanning. The page also allows you to specify available options such as excluded paths, stage, and maximum search depth.

How to use¶

View pipeline and jobs¶

You can find the list of pipelines on the left menu Build --> Pipelines, or under https://git.ligo.org/<albert.einstein>/<your-project-name>/-/pipelines. Each pipeline is listed as an entry in the table. Clicking the pipeline number will take you to a page that gives a flow chart of the scanning jobs that were performed. Click the job to view its log and additional information, such as run duration and the commit that triggered it. Alternatively, you can find the list of jobs on the left menu Build --> Jobs, or under https://git.ligo.org/<albert.einstein>/<your-project-name>/-/jobs.

When should I worry?¶

The security dashboard provides a summary of your project's security vulnerabilities (Secure --> Security dashboard or https://git.ligo.org/<albert-einstein>/<your-project-name>/-/security/dashboard), and more details are provided in the vulnerability report (Secure --> Vulnerabaility report or https://git.ligo.org/<albert-einstein>/<your-project-name>/-/security/vulnerability_report).

For each vulnerability identified in the vulnerability report, you can click on them to get more information and GitLab's suggested solution. The most worrisome ones are:

severity of High and Critical
identified by Secret Detection and Dependency Scanning

These vulnerabilities are considered to be the highest priority and should be resolved before committing your changes into the production branch.