Lesson 5 Appsec Workflow

Managing Vulnerabilities #

GitLab offers several Dashboards and Management tools in order to triage and track vulnerabilities. In this lesson, we will go over the Security Dashboard and Vulnerability Management Console.

Step 1: Viewing Vulnerability Reports #

Each vulnerability report contains vulnerabilities from the scans of the most recent branch merged into the default branch.

The vulnerability reports display the total number of vulnerabilities by severity. Below this, a table shows each vulnerabilities detected which includes:

  • date
  • status
  • severity
  • description
  • identifier
  • the scanner where it was detected
  • activity (including related issues or available solutions)

  1. In order to access vulnerability reports, navigate to Security & Compliance left navigation menu and selecting Vulnerability Reports

  2. Click on the any vulnerability within the list

  3. Select the Status box

  4. Select Confirm

  5. Press the Change Status button

Note: This allows for better filtering, enabling the security team to better triage security issues
  1. Now scroll to the bottom of the page, and add a comment in the text box and press the Save comment button
Note: This will save the comment in the Vulnerability page to enable collaboration between different members of the AppSec team
  1. Now click on Create Issue button
Note: This will take you to an issue creation prompt. This allows you to create an issue (confidential or not) in order to collaborate with developers on a resolution.
  1. Fill anything you want, scroll down, and click on the Create Issue button
Note: Now you have an issue which can be used for AppSec and Development teams to collaborate on resolving the vulnerability.

Step 2: Accessing the Security Dashboard #

At the project level, the Security Dashboard displays a chart with the number of vulnerabilities introduced to the default branch over time.

  1. Access the Security Dashboard by going to Security & Compliance left navigation menu and selecting Security Dashboard
Note: Nothing will be present, wait a day for it to be populated. Eventually over time with new commits introducing and resolving vulnerabilities, you’ll have something like this:

Step 3: Operational Container Scanning #

  1. Go to the the Security & Compliance left navigation menu and press Policies

  2. Click on the New policy button

  3. Press the Select policy button under the Scan execution policy section

  4. Fill out the following information:

  • Name: Policy Name
  • Description: Policy Description

  1. Check the Enabled button under Policy status

  2. Create a Rule

IF Schedule actions for the agent simplenotes in namespaces default,kube-system daily at 00:00

Note: Make sure that the agent-name (simplenotes) is typed in correctly, this will be the agent running in our cluster which we will use to scan our pods for vulnerabilities.

The namespaces we are scanning here are default and kube-system, where all our pods are loaded.

The 00:00 is measured in UTC time according to the system-time of the kubernetes agent (simplenotes) pod.

  1. Create an Action

THEN Require a Container Scanning scan to run

  1. Click on the Configure with a merge request button

  2. Merge the newly added code

Note: Now that the policy has been created, we must wait until the scheduled time for the scanner to run

  1. Go to the the Security & Compliance left navigation menu and press Vulnerability report

  2. Click on the Operational vulnerabilities tab

  3. View all the different vulnerabilities found in the cluster, there should be a good amount

Step 4: Viewing Audit Events #

Audit Events track important events, including who performed the related action and when. You can use audit events to track, for example:

  • Who changed the permission level of a particular user for a GitLab project, and when.
  • Who added a new user or removed a user, and when.

You can see a list of available Audit Events in the documentation.

  1. In order to access audit events, navigate to Security & Compliance left navigation menu and selecting Audit events
Note: You should see a few basic events around adding security policies

Step 5: Enabling and Testing Policy as Code #

Policy as Code is a way of creating policies by just editing code. In this section we will be using GitOps in order to deploy network policies which will limit access to our restricted-echo pods from other pods.

We can see the Network Policy we will be applying in the network-policies/restricted-echo.yaml file, which prevents any pod without the label access=true from accessing the restricted-echo pod.

  1. Open the WebIDE from the project page
Note: To learn more about the GitLab Web IDE and how to use/configure it, checkout the Web IDE documentation

  1. Open up .gitlab > agents > simplenotes > config.yaml

  2. Add the following to the file, updating the <your-full-project-path>:

gitops:
  manifest_projects:
  - id: <your-full-project-path>
    paths:
    - glob: '/network-policies/*.yaml'

It looks as follows for this particular project:

gitops:
  manifest_projects:
  - id: tech-marketing/devsecops/initech/simple-notes
    paths:
    - glob: '/network-policies/*.yaml'

  1. Click on the Source Control Tab on the left of the Web IDE. It looks as follows:

  2. Click on the Commit & Push Button

  3. In the Commit to new branch? dialog box, select No Use the current branch “main”

Now let’s wait for the pipeline to complete, this should take a few mins - so grab a coffee ☕️ or tea 🍵, or whatever you like! If the pipeline happens to fail, please checkout the troubleshooting documentation.

Testing Policy as Code #

  1. Open a terminal and connect to your cluster
$ gcloud container clusters get-credentials fern-initech --zone us-central1-c --project fdiaz-02874dfa

Fetching cluster endpoint and auth data.
kubeconfig entry generated for fern-initech.
Note: You should use the command, provided by GKE as seen in previous lessons
  1. Verify that the network policy has been installed
$ kubectl get networkpolicy

NAME                      POD-SELECTOR           AGE
access-restricted-nginx   app=restricted-nginx   35m
  1. Create a busybox container and try and access our restricted-echo pod
$ kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh

  If you don't see a command prompt, try pressing enter.
  / # wget --spider --timeout=1 restricted-nginx

  Connecting to restricted-nginx (10.4.5.28:80)
  wget: download timed out
Note: When performing a wget, we should timeout since we cannot access the pod without the label access=true

  1. Exit from the container by typing exit in the commandline

  2. Create a busybox container, with the access=true label, and try and access our restricted-echo pod

$ kubectl run busybox --rm -ti --labels="access=true" --image=busybox:1.28 -- /bin/sh

  If you don't see a command prompt, try pressing enter.
  / # wget --spider --timeout=1 restricted-nginx

  Connecting to restricted-nginx (10.4.5.28:80)
  remote file exists
Note: This time the wget should work since we have the label present

Congratulations, you are now able to use some of GitLab’s Security Tools within your AppSec Workflow and to better collaborate with others. Thanks for going through the Getting Started Documentation!

Previous Lesson Go Home

Calendar March 6, 2023
Edit