diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md
index 96e201e6ce706b59153d2b2b61d5629591e06941..234ca5105d4632d9838997f466e2e009b9edca46 100644
--- a/doc/development/integrations/secure.md
+++ b/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.
 
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 062b0d3e5b01c8335b94550091ce7a27f405deea..3e28855eb5a5b25a1687128919d2bf5a351408cd 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/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