---
layout: handbook-page-toc
title: "VUL.1.01 - Vulnerability Scans Control Guidance"
---

## On this page
{:.no_toc .hidden-md .hidden-lg}

- TOC
{:toc .hidden-md .hidden-lg}

# VUL.1.01 - Vulnerability Scans

## Control Statement
GitLab conducts vulnerability scans against the production environment; scan tools are updated prior to running scans.

## Context
This control is fairly straightforward. We have flexibility in how we perform these scans, but the burden of proof will be on GitLab to show that we are scanning all systems and that we are checking for the more relevant vulnerabilities. This control is meant to ensure we regularly assessing the state of all production systems. The update part of this control ensures we are always checking for the most recent vulnerabilities we know about. When properly applied, this control will help us generate a list of the risk associated with each GitLab system and help us prioritize security resources dedicated to remediation. This control can also be valuable in validating the device inventory (see control # [AM.1.01](/handbook/engineering/security/guidance/am.1.01-inventory-management.html)).

An auditor will look to validate whether or not the identified scope of systems are being scanned on a consistent basis by reviewing scan logs over multiple scanning periods (whatever the frequency of scanning is).

Additionally, the auditor will verify the scanning tool is up-to-date and how that is accomplished.

## Scope
This control applies to all systems within our [production environment](https://gitlab.com/gitlab-com/gl-security/secops/operations/issues/346). The production environment includes all endpoints and cloud assets used in hosting GitLab.com and its subdomains. This may include third-party systems that support the business of GitLab.com.


## Ownership
Control Owner: `Security Operations`
Process Owner: `Security Operations`

## Guidance
Depending on whether we use an agent-based scanner or an agentless scanner, the approach to implementation will differ. It's important to conduct these scans on a regular basis and to record all scan history so a timeline can be built. This timeline will be the way we prove patching timelines in order to satisfy other security controls.

## Additional control information and project tracking

Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the [Vulnerability Scans control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/936).

### Policy Reference
*  [Vulnerability Management Overview](https://about.gitlab.com/handbook/engineering/security/vulnerability_management/#vulnerability-management-overview)

## Framework Mapping
* ISO
  * A.12.6.1
* SOC2 CC
  * CC7.1
* PCI
  * 11.2
  * 11.2.1
  * 11.2.2
  * 11.2.3
  * 11.3.3
  * 5.1.2