Removed GitLab possessive

Minor updates to protect content to remove future tense & possessives.

doc/development/integrations/secure.md

@@ -217,7 +217,7 @@ then `artifacts:reports:dependency_scanning` must be set to `depscan.json`.
 
 ### Exit code
 
-Following the POSIX exit code standard, the scanner will exit with 0 for success and any number from 1 to 255 for anything else.
+Following the POSIX exit code standard, the scanner exits with 0 for success and any number from 1 to 255 for anything else.
 Success also includes the case when vulnerabilities are found.
 
 When executing a scanning job using the [Docker-in-Docker privileged mode](../../user/application_security/sast/index.md#requirements),
@@ -397,7 +397,7 @@ Not all vulnerabilities have CVEs, and a CVE can be identified multiple times. A
 isn't a stable identifier and you shouldn't assume it as such when tracking vulnerabilities.
 
 The maximum number of identifiers for a vulnerability is set as 20. If a vulnerability has more than 20 identifiers,
-the system will save only the first 20 of them. Note that vulnerabilities in the [Pipeline
+the system saves only the first 20 of them. Note that vulnerabilities in the [Pipeline
 Security](../../user/application_security/security_dashboard/#pipeline-security)
 tab do not enforce this limit and will show all identifiers present in the report artifact.
 

doc/topics/web_application_firewall/index.md

@@ -18,7 +18,7 @@ much more.
 GitLab provides a WAF out of the box after Ingress is deployed. All you need to do is deploy your
 application along with a service and Ingress resource. In GitLab's [Ingress](../../user/clusters/applications.md#ingress)
 deployment, the [ModSecurity](https://modsecurity.org/)
-module is loaded into Ingress-NGINX by default and monitors the traffic going to the applications
+module is loaded into Ingress-NGINX by default and monitors the traffic to the applications
 which have an Ingress. The ModSecurity module runs with the [OWASP Core Rule Set (CRS)](https://coreruleset.org/)
 by default. The OWASP CRS detects and logs a wide range of common attacks.
 

doc/topics/web_application_firewall/quick_start_guide.md

@@ -6,25 +6,25 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Getting started with the Web Application Firewall
 
-This is a step-by-step guide that will help you use GitLab's [Web Application Firewall](index.md) after
+This is a step-by-step guide to help you use the GitLab [Web Application Firewall](index.md) after
 deploying a project hosted on GitLab.com to Google Kubernetes Engine using [Auto DevOps](../autodevops/index.md).
 
-We will use GitLab's native Kubernetes integration, so you will not need
+GitLab's native Kubernetes integration is used, so you do not need
 to create a Kubernetes cluster manually using the Google Cloud Platform console.
-We will create and deploy a simple application that we create from a GitLab template.
+A simple application is created and deployed based on a GitLab template.
 
-These instructions will also work for a self-managed GitLab instance. However, you will
+These instructions also work for a self-managed GitLab instance. However, you
 need to ensure your own [runners are configured](../../ci/runners/README.md) and
 [Google OAuth is enabled](../../integration/google.md).
 
 GitLab's Web Application Firewall is deployed with [Ingress](../../user/clusters/applications.md#ingress),
-so it will be available to your applications no matter how you deploy them to Kubernetes.
+so it is available to your applications no matter how you deploy them to Kubernetes.
 
 ## Configuring your Google account
 
 Before creating and connecting your Kubernetes cluster to your GitLab project,
 you need a Google Cloud Platform account. If you do not already have one,
-sign up at <https://console.cloud.google.com>. You will need to either sign in with an existing
+sign up at <https://console.cloud.google.com>. You need to either sign in with an existing
 Google account (for example, one that you use to access Gmail, Drive, etc.) or create a new one.
 
 1. To enable the required APIs and related services, follow the steps in the ["Before you begin" section of the Kubernetes Engine docs](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin).
@@ -37,14 +37,14 @@ Google Kubernetes Engine integration. All you have to do is [follow this link](h
 
 ## Creating a new project from a template
 
-We will use one of GitLab's project templates to get started. As the name suggests,
+We use a GitLab project templates to get started. As the name suggests,
 those projects provide a barebones application built on some well-known frameworks.
 
 1. In GitLab, click the plus icon (**+**) at the top of the navigation bar and select
    **New project**.
 1. Go to the **Create from template** tab where you can choose for example a Ruby on
    Rails, Spring, or NodeJS Express project.
-   We will use the Ruby on Rails template.
+   Use the Ruby on Rails template.
 
    ![Select project template](../autodevops/img/guide_project_template_v12_3.png)
 
@@ -57,7 +57,7 @@ those projects provide a barebones application built on some well-known framewor
 1. Click **Create project**.
 
 Now that the project is created, the next step is to create the Kubernetes cluster
-under which this application will be deployed.
+to deploy this application under.
 
 ## Creating a Kubernetes cluster from within GitLab
 
@@ -111,14 +111,14 @@ auditing anomalous traffic, blocking mode ensures the traffic doesn't reach past
 
 After Ingress is installed, wait a few seconds and copy the IP address that
 is displayed in order to add in your base **Domain** at the top of the page. For
-the purpose of this guide, we will use the one suggested by GitLab. Once you have
+the purpose of this guide, we use the one suggested by GitLab. Once you have
 filled in the domain, click **Save changes**.
 
 ![Cluster Base Domain](../autodevops/img/guide_base_domain_v12_3.png)
 
 Prometheus should also be installed. It is an open-source monitoring and
-alerting system that we will use to supervise the deployed application.
-We will not install GitLab Runner as we will use the shared runners that
+alerting system that is used to supervise the deployed application.
+We will not install GitLab Runner as we use the shared runners that
 GitLab.com provides.
 
 ## Enabling Auto DevOps (optional)
@@ -162,7 +162,7 @@ deploys the application in Kubernetes ([Auto Deploy](../autodevops/stages.md#aut
 
 The **production** stage creates Kubernetes objects
 like a Deployment, Service, and Ingress resource. The
-application will be monitored by the WAF automatically.
+application is monitored by the WAF automatically.
 
 ## Validating Ingress is running ModSecurity
 

doc/user/application_security/container_scanning/index.md

@@ -299,7 +299,7 @@ For details on saving and transporting Docker images as a file, see Docker's doc
 
 It can be worthwhile to set up a [scheduled pipeline](../../../ci/pipelines/schedules.md) to
 build a new version of the vulnerabilities database on a preset schedule. Automating
-this with a pipeline means you won't have to do it manually each time. You can use the following
+this with a pipeline means you do not have to do it manually each time. You can use the following
 `.gitlab-yml.ci` as a template:
 
 ```yaml
@@ -319,7 +319,7 @@ build_latest_vulnerabilities:
     - docker push $CI_REGISTRY/namespace/clair-vulnerabilities-db
 ```
 
-The above template works for a GitLab Docker registry running on a local installation, however, if you're using a non-GitLab Docker registry, you'll need to change the `$CI_REGISTRY` value and the `docker login` credentials to match the details of your local registry.
+The above template works for a GitLab Docker registry running on a local installation, however, if you're using a non-GitLab Docker registry, you need to change the `$CI_REGISTRY` value and the `docker login` credentials to match the details of your local registry.
 
 ## Running the standalone container scanning tool