Skip to content

Implementing FEA403 - Regularily Scan for Known Security Vulnerabilities

Document Implementing FEA403 - Regularily Scan for Known Security Vulnerabilities
Author: Noora Kuikka
Version: 0.8
Date: 25.03.2024

Description

This feature aims to implement continuous security scanning of both frontend and backend repository code, dependencies and containers for known vulnerabilities. Additionally we will implement Dynamic Application Security Testing (DAST) and OWASP ZAP into the CI/CD security pipeline scans in order to test the running application for vulnerabilities.

As this feature is heavily linked to FEA405, we recommend checking the referenced documentation for more details on how security pipelines and automated scans have been set up within the project.

Preparation

  • Before the majority of these vulnerability scans can be implemented, users will first need to establish an automated security pipeline within Gitlab. Additionally runners will need to be set up on the application server. See the documentation on FEA405 for more details on how to do this.

  • Additionally for DAST active scanning, the application site will need to be validated using either a text file, header, or meta tag token supplied by Gitlab. This is not required for passive scanning.

Implementation

Static Application Security Testing (SAST)

SAST is used to check the repository source code for known vulnerabilities. Results can be viewed within the Gitlab security dashboard under "Vulnerability report". Additionally, a JSON-formatted report can be downloaded for viewing detailed information.

  1. Set up and register a runner with the docker executor from within Gitlab and the application server. See the FEA405 user guide for information on how to do this.
  2. Create a .gitlab-ci.yml file and include the following line within it:

include:
    template: SAST.gitlab-ci.yml
3. Review the pipeline to see if it has run successfully. You should see the following if the pipeline has been successful:

SAST pipeline succesful

  1. Any issues found can be viewed either as a downloadable JSON file accessible via the Build -> Artifacts menu in Gitlab or from the Secure -> Vulnerability report dasboard.

While the template rules for SAST run in the test stage by default, any customization to the rules requires manually adding a test stage to the .gitlab-ci.yml file.

Dependency Scanning

Dependency scanning is used to analyze the application's dependencies for known vulnerabilities.

To enable dependency scanning, the following line was included in the .gitlab-ci.yml file:

include:
    - template: Jobs/SAST.gitlab-ci.yml

The dependency scan can now be seen as enabled in the dashboard:

Dependency scanning enabled

With results appearing in the vulnerability report:

Dependency scanning results

Secret Detection

Secret detection will scan committed files after they have been pushed to Gitlab to determine whether they are leaking private information such as passwords, personal access tokens or other unstructured secrets.

To enable secret detection, simply add the following line to the .gitlab-ci.yml file:

include:
    - template: Jobs/Secret-Detection.gitlab-ci.yml

Secret detection should now be enabled in the security dashboard configuration panel:

Secret detection enabled

Container Scanning

We plan to set up container scanning alongside the "Harden all containers" feature in the near future.

Dynamic Application Security Testing (DAST)

DAST runs automated penetration tests to find vulnerabilities within the web applications and APIs on the live server, simulating real-world attacks for critical threats such as cross-site scripting (XSS), SQL injection (SQLi), and cross-site request forgery (CSRF). Unlike SAST, which seeks for vulnerabilities within the code repository, DAST attempts to find application vulnerabilities from the outside in.

DAST offers several different analyzers, but for our purposes we will use the DAST browser-based analyzer.

A DAST scan performs the following steps:

  1. Authenticate (if authentication is configured)
  2. Craw the target application to discover the surface area of the application by emulating user actions such as following links, clicking buttons, and filling out forms
  3. Passive scan to search for vulnerabilities in HTTP messages and pages discovered while crawling
  4. Active scan to search for vulnerabilities by injecting payloads into HTTP requests recorded during the crawl phase (this needs to be enabled separately)

Prerequisites:

  • Gitlab Runner available - you can either create a new runner, or utilize the one made earlier for SAST
  • The application must be deployed and accessible from the browser

Implementation:

  1. In Gitlab's security dashboard, navigate to Security configuration -> DAST configuration.
  2. Under Scanner profile, click "Select scanner profile".
  3. Enter a name for the profile, and choose whether you wish to use active or passive scanning (we chose passive scanning for now). You can also optionally set the crawl timeout and target timeout, or leave them as the default. Save the profile.
  4. Under "Site profile", click on "select site profile" and add a name for the profile e.g. Tukko_DAST_Site. Select the site type (in our case: website) and in the "Target URL" box input the address used to access the site from the browser.
  5. In order to run active scanning, the site must first be validated. This can be achieved either by uploading a text file provided by Gitlab to the target site, adding the header Gitlab-On-Demand-DAST to the target site, or a meta tag named gitlab-dast-validation. We chose to use only passive scanning for now.
  6. Use "Generate code snippet" after you have configured all the options to receive the instructions to place in the .gitlab-ci.yml file. It should look similar to the example below:

DAST configuration in Gitlab yaml file

DAST should now show up as enabled in the security configuration dashboard:

DAST enabled

And the results of the scans can be viewed in the vulnerability report:

DAST scan results

ZAPROXY (ZAP)

We will set this up if we have time.

Sources

Source Description
Secret Detection GitLab documentation on secret detection.
Container Scanning GitLab documentation on container scanning.
Dependency Scanning GitLab documentation on dependency scanning.
Dynamic Application Security Testing (DAST) GitLab documentation on dynamic application security testing.
Static Application Security Testing (SAST) GitLab documentation on static application security testing.