diff options
Diffstat (limited to 'doc/user/application_security')
28 files changed, 598 insertions, 814 deletions
diff --git a/doc/user/application_security/api_fuzzing/index.md b/doc/user/application_security/api_fuzzing/index.md index 96236f60417..80e4700c34c 100644 --- a/doc/user/application_security/api_fuzzing/index.md +++ b/doc/user/application_security/api_fuzzing/index.md @@ -1677,7 +1677,7 @@ For more information, see [Offline environments](../offline_deployments/index.md ## Troubleshooting -### Error waiting for API Security 'http://127.0.0.1:5000' to become available +### `Error waiting for API Security 'http://127.0.0.1:5000' to become available` A bug exists in versions of the API Fuzzing analyzer prior to v1.6.196 that can cause a background process to fail under certain conditions. The solution is to update to a newer version of the DAST API analyzer. @@ -1690,7 +1690,7 @@ If the issue is occurring with versions v1.6.196 or greater, please contact Supp 1. The `gl-api-security-scanner.log` file available as a job artifact. In the right-hand panel of the job details page, select the **Browse** button. 1. The `apifuzzer_fuzz` job definition from your `.gitlab-ci.yml` file. -### Error, the OpenAPI document is not valid. Errors were found during validation of the document using the published OpenAPI schema +### `Error, the OpenAPI document is not valid. Errors were found during validation of the document using the published OpenAPI schema` At the start of an API Fuzzing job the OpenAPI Specification is validated against the [published schema](https://github.com/OAI/OpenAPI-Specification/tree/master/schemas). This error is shown when the provided OpenAPI Specification has validation errors. Errors can be introduced when creating an OpenAPI Specification manually, and also when the schema is generated. @@ -1719,7 +1719,7 @@ For OpenAPI Specifications that are generated automatically validation errors ar 1. Alternatively, you can check the log output and look for schema validation warnings. They are prefixed with messages such as `OpenAPI 2.0 schema validation error` or `OpenAPI 3.0.x schema validation error`. Each failed validation provides extra information about `location` and `description`. Correct each of the validation failures and then resubmit the OpenAPI doc. Note that JSON Schema validation message might not be easy to understand. This is why we recommend the use of editors to validate document. 1. Once the validation issues are resolved, re-run your pipeline. -### Failed to start scanner session (version header not found) +### `Failed to start scanner session (version header not found)` The API Fuzzing engine outputs an error message when it cannot establish a connection with the scanner application component. The error message is shown in the job output window of the `apifuzzer_fuzz` job. A common cause of this issue is changing the `FUZZAPI_API` variable from its default. @@ -1733,7 +1733,7 @@ The API Fuzzing engine outputs an error message when it cannot establish a conne - Remove the `FUZZAPI_API` variable from the `.gitlab-ci.yml` file. The value will be inherited from the API Fuzzing CI/CD template. We recommend this method instead of manually setting a value. - If removing the variable is not possible, check to see if this value has changed in the latest version of the [API Fuzzing CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/API-Fuzzing.gitlab-ci.yml). If so, update the value in the `.gitlab-ci.yml` file. -### Application cannot determine the base URL for the target API +### `Application cannot determine the base URL for the target API` The API Fuzzing analyzer outputs an error message when it cannot determine the target API after inspecting the OpenAPI document. This error message is shown when the target API has not been set in the `.gitlab-ci.yml`file, it is not available in the `environment_url.txt` file, and it could not be computed using the OpenAPI document. @@ -1802,7 +1802,7 @@ To detect and correct elements that don't comply with the OpenAPI specifications | Editor | OpenAPI 2.0 | OpenAPI 3.0.x | OpenAPI 3.1.x | | -- | -- | -- | -- | | [Swagger Editor](https://editor.swagger.io/) | **{check-circle}** YAML, JSON | **{check-circle}** YAML, JSON | **{dotted-circle}** YAML, JSON | -| [Stoplight Studio](https://stoplight.io/studio/) | **{check-circle}** YAML, JSON | **{check-circle}** YAML, JSON | **{check-circle}** YAML, JSON | +| [Stoplight Studio](https://stoplight.io/studio) | **{check-circle}** YAML, JSON | **{check-circle}** YAML, JSON | **{check-circle}** YAML, JSON | If your OpenAPI document is generated manually, load your document in the editor and fix anything that is non-compliant. If your document is generated automatically, load it in your editor to identify the issues in the schema, then go to the application and perform the corrections based on the framework you are using. @@ -1826,7 +1826,7 @@ API Security can still try to consume an OpenAPI document that does not fully co FUZZAPI_OPENAPI_RELAXED_VALIDATION: On ``` -### No operation in the OpenAPI document is consuming any supported media type +### `No operation in the OpenAPI document is consuming any supported media type` API Security uses the specified media types in the OpenAPI document to generate requests. If no request can be created due to the lack of supported media types, then an error will be thrown. @@ -1844,7 +1844,7 @@ API Security uses the specified media types in the OpenAPI document to generate To get support for your particular problem please use the [getting help channels](https://about.gitlab.com/get-help/). The [GitLab issue tracker on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues) is the right place for bugs and feature proposals about API Security and API Fuzzing. -Please use `~"Category:API Security"` [label](../../../development/contributing/issue_workflow.md#labels) when opening a new issue regarding API fuzzing to ensure it is quickly reviewed by the right people. Please refer to our [review response SLO](../../../development/code_review.md#review-response-slo) to understand when you should receive a response. +Please use `~"Category:API Security"` [label](../../../development/contributing/issue_workflow.md#labels) when opening a new issue regarding API fuzzing to ensure it is quickly reviewed by the right people. Please refer to our [review response SLO](https://about.gitlab.com/handbook/engineering/workflow/code-review/#review-response-slo) to understand when you should receive a response. [Search the issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues) for similar entries before submitting your own, there's a good chance somebody else had the same issue or feature proposal. Show your support with an award emoji and or join the discussion. diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md index cf864068e44..7bb3cb4f64c 100644 --- a/doc/user/application_security/container_scanning/index.md +++ b/doc/user/application_security/container_scanning/index.md @@ -7,7 +7,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Container Scanning **(FREE)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3672) in GitLab 10.4. +> - Improved support for FIPS [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/263482) in GitLab 13.6 by upgrading `CS_MAJOR_VERSION` from `2` to `3`. +> - Integration with Trivy [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/322656) in GitLab 13.9 by upgrading `CS_MAJOR_VERSION` from `3` to `4`. +> - Integration with Clair [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/321451) in GitLab 13.9. +> - Default container scanning with Trivy [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61850) in GitLab 14.0. +> - Integration with Grype as an alternative scanner [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/326279) in GitLab 14.0. +> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86092) the major analyzer version from `4` to `5` in GitLab 15.0. +> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86783) from GitLab Ultimate to GitLab Free in 15.0. Your application's Docker image may itself be based on Docker images that contain known vulnerabilities. By including an extra Container Scanning job in your pipeline that scans for those @@ -19,7 +25,7 @@ aspects of inspecting the items your code uses. These items typically include ap dependencies that are almost always imported from external sources, rather than sourced from items you wrote yourself. -GitLab offers both Container Scanning and [Dependency Scanning](../dependency_scanning/) +GitLab offers both Container Scanning and [Dependency Scanning](../dependency_scanning/index.md) to ensure coverage for all of these dependency types. To cover as much of your risk area as possible, we encourage you to use all of our security scanners. @@ -68,7 +74,7 @@ information directly in the merge request. To enable container scanning in your pipeline, you need the following: -- Container Scanning runs in the `test` stage, which is available by default. If you redefine the stages in the `.gitlab-ci.yml` file, the `test` stage is required. +- GitLab CI/CD pipeline must include the `test` stage, which is available unless overridden with the [`stages`](../../../ci/yaml/index.md#stages) keyword. - [GitLab Runner](https://docs.gitlab.com/runner/) with the [`docker`](https://docs.gitlab.com/runner/executors/docker.html) or [`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html) executor on Linux/amd64. - Docker `18.09.03` or higher installed on the same computer as the runner. If you're using the @@ -79,7 +85,6 @@ To enable container scanning in your pipeline, you need the following: - If you're using a third-party container registry, you might need to provide authentication credentials through the `DOCKER_USER` and `DOCKER_PASSWORD` [configuration variables](#available-cicd-variables). For more details on how to use these variables, see [authenticate to a remote registry](#authenticate-to-a-remote-registry). -- GitLab CI/CD pipeline must include the `test` stage, which is available unless overridden with the [`stages`](../../../ci/yaml/index.md#stages) keyword. ## Configuration @@ -224,7 +229,7 @@ container_scanning: CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN: "false" ``` -When you enable this feature, you may see [duplicate findings](../terminology/#duplicate-finding) +When you enable this feature, you may see [duplicate findings](../terminology/index.md#duplicate-finding) in the [Vulnerability Report](../vulnerability_report/) if [Dependency Scanning](../dependency_scanning/) is enabled for your project. This happens because GitLab can't automatically deduplicate findings @@ -680,7 +685,7 @@ It's possible to run the [GitLab container scanning tool](https://gitlab.com/git against a Docker container without needing to run it within the context of a CI job. To scan an image directly, follow these steps: -1. Run [Docker Desktop](https://www.docker.com/products/docker-desktop) +1. Run [Docker Desktop](https://www.docker.com/products/docker-desktop/) or [Docker Machine](https://github.com/docker/machine). 1. Run the analyzer's Docker image, passing the image and tag you want to analyze in the @@ -700,101 +705,21 @@ The results are stored in `gl-container-scanning-report.json`. ## Reports JSON format -The container scanning tool emits a JSON report file. For more information, see the -[schema for this report](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/container-scanning-report-format.json). - -Here's an example container scanning report: - -```json-doc -{ - "version": "14.0.0", - "vulnerabilities": [ - { - "id": "df52bc8ce9a2ae56bbcb0c4ecda62123fbd6f69b", - "category": "container_scanning", - "message": "CVE-2019-3462 in apt-1.4.8", - "description": "Incorrect sanitation of the 302 redirect field in HTTP transport method of apt versions 1.4.8 and earlier can lead to content injection by a MITM attacker, potentially leading to remote code execution on the target machine.", - "severity": "High", - "confidence": "Unknown", - "solution": "Upgrade apt from 1.4.8 to 1.4.9", - "scanner": { - "id": "trivy", - "name": "trivy" - }, - "location": { - "dependency": { - "package": { - "name": "apt" - }, - "version": "1.4.8" - }, - "operating_system": "debian:9.4", - "image": "registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256:bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e", - "default_branch_image": "registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0:latest" - }, - "identifiers": [ - { - "type": "cve", - "name": "CVE-2019-3462", - "value": "CVE-2019-3462", - "url": "http://www.securityfocus.com/bid/106690" - } - ], - "links": [ - { - "url": "http://www.securityfocus.com/bid/106690" - }, - { - "url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3462" - }, - { - "url": "https://lists.apache.org/thread.html/8338a0f605bdbb3a6098bb76f666a95fc2b2f53f37fa1ecc89f1146f@%3Cdevnull.infra.apache.org%3E" - }, - { - "url": "https://lists.debian.org/debian-lts-announce/2019/01/msg00013.html" - }, - { - "url": "https://lists.debian.org/debian-lts-announce/2019/01/msg00014.html" - }, - { - "url": "https://security.netapp.com/advisory/ntap-20190125-0002/" - }, - { - "url": "https://usn.ubuntu.com/3863-1/" - }, - { - "url": "https://usn.ubuntu.com/3863-2/" - }, - { - "url": "https://usn.ubuntu.com/usn/usn-3863-1" - }, - { - "url": "https://usn.ubuntu.com/usn/usn-3863-2" - }, - { - "url": "https://www.debian.org/security/2019/dsa-4371" - } - ] - } - ], - "remediations": [] - "scan": { - "scanner": { - "id": "trivy", - "name": "Trivy", - "url": "https://github.com/aquasecurity/trivy/", - "vendor": { - "name": "GitLab" - }, - "version": "0.16.0" - }, - "type": "container_scanning", - "start_time": "2021-04-14T19:45:58", - "end_time": "2021-04-14T19:46:18", - "status": "success" - } -} -``` +The container scanning tool emits JSON reports which the [GitLab Runner](https://docs.gitlab.com/runner/) +recognizes through the [`artifacts:reports`](../../../ci/yaml/#artifactsreports) +keyword in the CI configuration file. + +Once the CI job finishes, the Runner uploads these reports to GitLab, which are then available in +the CI Job artifacts. In GitLab Ultimate, these reports can be viewed in the corresponding [pipeline](../vulnerability_report/pipeline.md) +and become part of the [Vulnerability Report](../vulnerability_report/). + +These reports must follow a format defined in the +[security report schemas](https://gitlab.com/gitlab-org/security-products/security-report-schemas/). See: + +- [Latest schema for the container scanning report](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/container-scanning-report-format.json). +- [Example container scanning report](https://gitlab.com/gitlab-examples/security/security-reports/-/blob/master/samples/container-scanning.json) + +For more information, see [Security scanner integration](../../../development/integrations/secure.md). ## Security Dashboard @@ -878,27 +803,5 @@ For information on this, see the [general Application Security troubleshooting s ## Changes -- GitLab 13.6 [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/263482) better support for - [FIPS](https://csrc.nist.gov/publications/detail/fips/140/2/final) by upgrading the - `CS_MAJOR_VERSION` from `2` to `3`. Version `3` of the `container_scanning` Docker image uses - [`centos:centos8`](https://hub.docker.com/_/centos) - as the new base. It also removes the use of the [start.sh](https://gitlab.com/gitlab-org/security-products/analyzers/klar/-/merge_requests/77) - script and instead executes the analyzer by default. Any customizations made to the - `container_scanning` job's [`before_script`](../../../ci/yaml/index.md#before_script) - and [`after_script`](../../../ci/yaml/index.md#after_script) - blocks may not work with the new version. To roll back to the previous [`alpine:3.11.3`](https://hub.docker.com/_/alpine)-based - Docker image, you can specify the major version through the [`CS_MAJOR_VERSION`](#available-cicd-variables) - variable. -- GitLab 13.9 [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/322656) integration with - [Trivy](https://github.com/aquasecurity/trivy) by upgrading `CS_MAJOR_VERSION` from `3` to `4`. -- GitLab 13.9 [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/321451) the integration with - [Clair](https://github.com/quay/clair/). -- GitLab 14.0 [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61850) - an integration with [Trivy](https://github.com/aquasecurity/trivy) - as the default for container scanning, and also [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/326279) - an integration with [Grype](https://github.com/anchore/grype) - as an alternative scanner. -- GitLab 15.0 changed the major analyzer version from `4` to `5`. - -Other changes to the container scanning analyzer can be found in the project's +Changes to the container scanning analyzer can be found in the project's [changelog](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/blob/master/CHANGELOG.md). diff --git a/doc/user/application_security/coverage_fuzzing/index.md b/doc/user/application_security/coverage_fuzzing/index.md index ac3b266ad48..154884c16e7 100644 --- a/doc/user/application_security/coverage_fuzzing/index.md +++ b/doc/user/application_security/coverage_fuzzing/index.md @@ -367,12 +367,12 @@ vulnerability: ## Troubleshooting -### Error "Unable to extract corpus folder from artifacts zip file" +### Error `Unable to extract corpus folder from artifacts zip file` If you see this error message, and `COVFUZZ_USE_REGISTRY` is set to `true`, ensure that the uploaded corpus file extracts into a folder named `corpus`. -### Error "400 Bad request - Duplicate package is not allowed" +### Error `400 Bad request - Duplicate package is not allowed` If you see this error message when running the fuzzing job with `COVFUZZ_USE_REGISTRY` set to `true`, ensure that duplicates are allowed. For more details, see diff --git a/doc/user/application_security/dast/browser_based.md b/doc/user/application_security/dast/browser_based.md index ffcd496e2c3..e8373b0c0b7 100644 --- a/doc/user/application_security/dast/browser_based.md +++ b/doc/user/application_security/dast/browser_based.md @@ -5,34 +5,42 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: reference, howto --- -# DAST browser-based crawler **(ULTIMATE)** +# DAST browser-based analyzer **(ULTIMATE)** > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/323423) in GitLab 13.12. WARNING: This product is in an early-access stage and is considered a [beta](../../../policy/alpha-beta-support.md#beta-features) feature. -GitLab DAST's new browser-based crawler is a crawl engine built by GitLab to test Single Page Applications (SPAs) and traditional web applications. -Due to the reliance of modern web applications on JavaScript, handling SPAs or applications that are dependent on JavaScript is paramount to ensuring proper coverage of an application for Dynamic Application Security Testing (DAST). +GitLab DAST's browser-based analyzer was built by GitLab to test Single Page Applications (SPAs) and +traditional web applications. It both crawls the web application and analyzes the resulting output +for vulnerabilities. Analysis of modern applications, heavily reliant on JavaScript, is vital to +ensuring DAST coverage. -The browser-based crawler works by loading the target application into a specially-instrumented Chromium browser. A snapshot of the page is taken before a search to find any actions that a user might perform, -such as clicking on a link or filling in a form. For each action found, the crawler executes it, takes a new snapshot, and determines what in the page changed from the previous snapshot. -Crawling continues by taking more snapshots and finding subsequent actions. +The browser-based scanner works by loading the target application into a specially-instrumented +Chromium browser. A snapshot of the page is taken before a search to find any actions that a user +might perform, such as clicking on a link or filling in a form. For each action found, the +browser-based scanner executes it, takes a new snapshot, and determines what in the page changed +from the previous snapshot. Crawling continues by taking more snapshots and finding subsequent +actions. The benefit of scanning by following user actions in a browser is that the crawler can +interact with the target application much like a real user would, identifying complex flows that +traditional web crawlers don't understand. This results in better coverage of the website. -The benefit of crawling by following user actions in a browser is that the crawler can interact with the target application much like a real user would, identifying complex flows that traditional web crawlers don't understand. This results in better coverage of the website. +The browser-based scanner should provide greater coverage for most web applications, compared +with the current DAST AJAX crawler. While both crawlers are +used together with the current DAST scanner, the combination of the browser-based crawler with the +current DAST scanner is much more effective at finding and testing every page in an application. -Using the browser-based crawler should provide greater coverage for most web applications, compared with the current DAST AJAX crawler. The new crawler replaces the AJAX crawler and is specifically designed to maximize crawl coverage in modern web applications. While both crawlers are currently used in conjunction with the existing DAST scanner, the combination of the browser-based crawler with the current DAST scanner is much more effective at finding and testing every page in an application. +## Enable browser-based analyzer -## Enable browser-based crawler - -The browser-based crawler is an extension to the GitLab DAST product. DAST should be included in the CI/CD configuration and the browser-based crawler enabled using CI/CD variables: +To enable the browser-based analyzer: 1. Ensure the DAST [prerequisites](index.md#prerequisites) are met. -1. Include the [DAST CI template](index.md#include-the-dast-template). -1. Set the target website using the `DAST_WEBSITE` CI/CD variable. +1. Include the [DAST CI/CD template](index.md#include-the-dast-template). +1. Set the target website using the [`DAST_WEBSITE` CI/CD variable](index.md#available-cicd-variables). 1. Set the CI/CD variable `DAST_BROWSER_SCAN` to `true`. -An example configuration might look like the following: +Example extract of `.gitlab-ci.yml` file: ```yaml include: @@ -77,13 +85,20 @@ The [DAST variables](index.md#available-cicd-variables) `SECURE_ANALYZERS_PREFIX ## Vulnerability detection -While the browser-based crawler crawls modern web applications efficiently, vulnerability detection is still managed by the standard DAST/Zed Attack Proxy (ZAP) solution. +Vulnerability detection is gradually being migrated from the default Zed Attack Proxy (ZAP) solution +to the browser-based analyzer. For details of the vulnerability detection already migrated, see +[browser-based vulnerability checks](checks/index.md). -The crawler runs the target website in a browser with DAST/ZAP configured as the proxy server. This ensures that all requests and responses made by the browser are passively scanned by DAST/ZAP. -When running a full scan, active vulnerability checks executed by DAST/ZAP do not use a browser. This difference in how vulnerabilities are checked can cause issues that require certain features of the target website to be disabled to ensure the scan works as intended. +The crawler runs the target website in a browser with DAST/ZAP configured as the proxy server. This +ensures that all requests and responses made by the browser are passively scanned by DAST/ZAP. When +running a full scan, active vulnerability checks executed by DAST/ZAP do not use a browser. This +difference in how vulnerabilities are checked can cause issues that require certain features of the +target website to be disabled to ensure the scan works as intended. -For example, for a target website that contains forms with Anti-CSRF tokens, a passive scan works as intended because the browser displays pages and forms as if a user is viewing the page. -However, active vulnerability checks that run in a full scan cannot submit forms containing Anti-CSRF tokens. In such cases, we recommend you disable Anti-CSRF tokens when running a full scan. +For example, for a target website that contains forms with Anti-CSRF tokens, a passive scan works as +intended because the browser displays pages and forms as if a user is viewing the page. However, +active vulnerability checks that run in a full scan cannot submit forms containing Anti-CSRF tokens. +In such cases, we recommend you disable Anti-CSRF tokens when running a full scan. ## Managing scan time diff --git a/doc/user/application_security/dast/checks/16.7.md b/doc/user/application_security/dast/checks/16.7.md index a02fb3a451f..2e6607575db 100644 --- a/doc/user/application_security/dast/checks/16.7.md +++ b/doc/user/application_security/dast/checks/16.7.md @@ -25,8 +25,8 @@ Only three directives are applicable for the `Strict-Transport-Security` header. Note that invalid directives, or the `Strict-Transport-Security` header appearing more than once (if the values are different) is considered invalid. -Prior to adding to this security configuration to your website, it is recommended you review the hstspreload.org [Deployment -Recommendations](https://hstspreload.org/#deployment-recommendations). +Prior to adding to this security configuration to your website, it is recommended you review the hstspreload.org +[Deployment Recommendations](https://hstspreload.org/#deployment-recommendations). ## Details diff --git a/doc/user/application_security/dast/checks/601.1.md b/doc/user/application_security/dast/checks/601.1.md index 60249c2562d..c51b00cdd36 100644 --- a/doc/user/application_security/dast/checks/601.1.md +++ b/doc/user/application_security/dast/checks/601.1.md @@ -30,5 +30,5 @@ then be used to redirect the user, using the 301 response code and `Location` he ## Links -- [OWASP](https://owasp.org/www-project-cheat-sheets/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html) +- [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html) - [CWE](https://cwe.mitre.org/data/definitions/601.html) diff --git a/doc/user/application_security/dast/checks/798.45.md b/doc/user/application_security/dast/checks/798.45.md deleted file mode 100644 index a800063f15d..00000000000 --- a/doc/user/application_security/dast/checks/798.45.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -stage: Secure -group: Dynamic Analysis -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments ---- - -# Exposure of confidential secret or token Finicity Public Key - -## Description - -The response body contains content that matches the pattern of a Finicity Public Key. -Exposing this value could allow attackers to gain access to all resources granted by this token. - -## Remediation - -Review the response body content and remove any exposed values. - -## Details - -| ID | Aggregated | CWE | Type | Risk | -|:---|:--------|:--------|:--------|:--------| -| 798.45 | false | 798 | Passive | High | - -## Links - -- [CWE](https://cwe.mitre.org/data/definitions/798.html) diff --git a/doc/user/application_security/dast/checks/798.51.md b/doc/user/application_security/dast/checks/798.51.md deleted file mode 100644 index f131d31ae65..00000000000 --- a/doc/user/application_security/dast/checks/798.51.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -stage: Secure -group: Dynamic Analysis -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments ---- - -# Exposure of confidential secret or token GCP API key - -## Description - -The response body contains content that matches the pattern of a GCP API key. -Exposing this value could allow attackers to gain access to all resources granted by this token. - -## Remediation - -Review the response body content and remove any exposed values. - -## Details - -| ID | Aggregated | CWE | Type | Risk | -|:---|:--------|:--------|:--------|:--------| -| 798.51 | false | 798 | Passive | High | - -## Links - -- [CWE](https://cwe.mitre.org/data/definitions/798.html) diff --git a/doc/user/application_security/dast/checks/798.71.md b/doc/user/application_security/dast/checks/798.71.md deleted file mode 100644 index f0bcc43940d..00000000000 --- a/doc/user/application_security/dast/checks/798.71.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -stage: Secure -group: Dynamic Analysis -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments ---- - -# Exposure of confidential secret or token Lob Publishable API Key - -## Description - -The response body contains content that matches the pattern of a Lob Publishable API Key. -Exposing this value could allow attackers to gain access to all resources granted by this token. - -## Remediation - -Review the response body content and remove any exposed values. - -## Details - -| ID | Aggregated | CWE | Type | Risk | -|:---|:--------|:--------|:--------|:--------| -| 798.71 | false | 798 | Passive | High | - -## Links - -- [CWE](https://cwe.mitre.org/data/definitions/798.html) diff --git a/doc/user/application_security/dast/checks/798.73.md b/doc/user/application_security/dast/checks/798.73.md deleted file mode 100644 index eae41a49782..00000000000 --- a/doc/user/application_security/dast/checks/798.73.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -stage: Secure -group: Dynamic Analysis -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments ---- - -# Exposure of confidential secret or token Mailgun public validation key - -## Description - -The response body contains content that matches the pattern of a Mailgun public validation key. -Exposing this value could allow attackers to gain access to all resources granted by this token. - -## Remediation - -Review the response body content and remove any exposed values. - -## Details - -| ID | Aggregated | CWE | Type | Risk | -|:---|:--------|:--------|:--------|:--------| -| 798.73 | false | 798 | Passive | High | - -## Links - -- [CWE](https://cwe.mitre.org/data/definitions/798.html) diff --git a/doc/user/application_security/dast/checks/798.76.md b/doc/user/application_security/dast/checks/798.76.md deleted file mode 100644 index 87e6364184f..00000000000 --- a/doc/user/application_security/dast/checks/798.76.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -stage: Secure -group: Dynamic Analysis -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments ---- - -# Exposure of confidential secret or token MapBox API token - -## Description - -The response body contains content that matches the pattern of a MapBox API token. -Exposing this value could allow attackers to gain access to all resources granted by this token. - -## Remediation - -Review the response body content and remove any exposed values. - -## Details - -| ID | Aggregated | CWE | Type | Risk | -|:---|:--------|:--------|:--------|:--------| -| 798.76 | false | 798 | Passive | High | - -## Links - -- [CWE](https://cwe.mitre.org/data/definitions/798.html) diff --git a/doc/user/application_security/dast/checks/798.79.md b/doc/user/application_security/dast/checks/798.79.md deleted file mode 100644 index 9a580658a72..00000000000 --- a/doc/user/application_security/dast/checks/798.79.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -stage: Secure -group: Dynamic Analysis -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments ---- - -# Exposure of confidential secret or token MessageBird client ID - -## Description - -The response body contains content that matches the pattern of a MessageBird client ID. -Exposing this value could allow attackers to gain access to all resources granted by this token. - -## Remediation - -Review the response body content and remove any exposed values. - -## Details - -| ID | Aggregated | CWE | Type | Risk | -|:---|:--------|:--------|:--------|:--------| -| 798.79 | false | 798 | Passive | High | - -## Links - -- [CWE](https://cwe.mitre.org/data/definitions/798.html) diff --git a/doc/user/application_security/dast/checks/798.85.md b/doc/user/application_security/dast/checks/798.85.md deleted file mode 100644 index 0726bdc7fd8..00000000000 --- a/doc/user/application_security/dast/checks/798.85.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -stage: Secure -group: Dynamic Analysis -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments ---- - -# Exposure of confidential secret or token Nytimes Access Token - -## Description - -The response body contains content that matches the pattern of a Nytimes Access Token. -Exposing this value could allow attackers to gain access to all resources granted by this token. - -## Remediation - -Review the response body content and remove any exposed values. - -## Details - -| ID | Aggregated | CWE | Type | Risk | -|:---|:--------|:--------|:--------|:--------| -| 798.85 | false | 798 | Passive | High | - -## Links - -- [CWE](https://cwe.mitre.org/data/definitions/798.html) diff --git a/doc/user/application_security/dast/checks/index.md b/doc/user/application_security/dast/checks/index.md index cdfebc07ef2..387682318e6 100644 --- a/doc/user/application_security/dast/checks/index.md +++ b/doc/user/application_security/dast/checks/index.md @@ -81,13 +81,11 @@ The [DAST browser-based crawler](../browser_based.md) provides a number of vulne | [798.42](798.42.md) | Exposure of confidential secret or token Finicity API token | High | Passive | | [798.43](798.43.md) | Exposure of confidential secret or token Flickr Access Token | High | Passive | | [798.44](798.44.md) | Exposure of confidential secret or token Finnhub Access Token | High | Passive | -| [798.45](798.45.md) | Exposure of confidential secret or token Finicity Public Key | High | Passive | | [798.46](798.46.md) | Exposure of confidential secret or token Flutterwave Secret Key | High | Passive | | [798.47](798.47.md) | Exposure of confidential secret or token Flutterwave Encryption Key | High | Passive | | [798.48](798.48.md) | Exposure of confidential secret or token Frame.io API token | High | Passive | | [798.49](798.49.md) | Exposure of confidential secret or token Freshbooks Access Token | High | Passive | | [798.50](798.50.md) | Exposure of confidential secret or token GoCardless API token | High | Passive | -| [798.51](798.51.md) | Exposure of confidential secret or token GCP API key | High | Passive | | [798.52](798.52.md) | Exposure of confidential secret or token GitHub Personal Access Token | High | Passive | | [798.53](798.53.md) | Exposure of confidential secret or token GitHub OAuth Access Token | High | Passive | | [798.54](798.54.md) | Exposure of confidential secret or token GitHub App Token | High | Passive | @@ -107,21 +105,16 @@ The [DAST browser-based crawler](../browser_based.md) provides a number of vulne | [798.68](798.68.md) | Exposure of confidential secret or token LinkedIn Client ID | High | Passive | | [798.69](798.69.md) | Exposure of confidential secret or token LinkedIn Client secret | High | Passive | | [798.70](798.70.md) | Exposure of confidential secret or token Lob API Key | High | Passive | -| [798.71](798.71.md) | Exposure of confidential secret or token Lob Publishable API Key | High | Passive | | [798.72](798.72.md) | Exposure of confidential secret or token Mailchimp API key | High | Passive | -| [798.73](798.73.md) | Exposure of confidential secret or token Mailgun public validation key | High | Passive | | [798.74](798.74.md) | Exposure of confidential secret or token Mailgun private API token | High | Passive | | [798.75](798.75.md) | Exposure of confidential secret or token Mailgun webhook signing key | High | Passive | -| [798.76](798.76.md) | Exposure of confidential secret or token MapBox API token | High | Passive | | [798.77](798.77.md) | Exposure of confidential secret or token Mattermost Access Token | High | Passive | | [798.78](798.78.md) | Exposure of confidential secret or token MessageBird API token | High | Passive | -| [798.79](798.79.md) | Exposure of confidential secret or token MessageBird client ID | High | Passive | | [798.80](798.80.md) | Exposure of confidential secret or token Netlify Access Token | High | Passive | | [798.81](798.81.md) | Exposure of confidential secret or token New Relic user API Key | High | Passive | | [798.82](798.82.md) | Exposure of confidential secret or token New Relic user API ID | High | Passive | | [798.83](798.83.md) | Exposure of confidential secret or token New Relic ingest browser API token | High | Passive | | [798.84](798.84.md) | Exposure of confidential secret or token npm access token | High | Passive | -| [798.85](798.85.md) | Exposure of confidential secret or token Nytimes Access Token | High | Passive | | [798.86](798.86.md) | Exposure of confidential secret or token Okta Access Token | High | Passive | | [798.87](798.87.md) | Exposure of confidential secret or token Plaid Client ID | High | Passive | | [798.88](798.88.md) | Exposure of confidential secret or token Plaid Secret key | High | Passive | diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md index f8aa2e3d1c6..a49dd8fd646 100644 --- a/doc/user/application_security/dast/index.md +++ b/doc/user/application_security/dast/index.md @@ -351,7 +351,7 @@ include: - template: DAST-API.gitlab-ci.yml variables: - DAST_API_OPENAPI: http://my.api/api-specification.yml + DAST_API_SPECIFICATION: http://my.api/api-specification.yml ``` #### Import API specification from a file @@ -366,7 +366,7 @@ dast: - cp api-specification.yml /zap/wrk/api-specification.yml variables: GIT_STRATEGY: fetch - DAST_API_OPENAPI: api-specification.yml + DAST_API_SPECIFICATION: api-specification.yml ``` #### Full API scan @@ -402,7 +402,7 @@ include: - template: DAST-API.gitlab-ci.yml variables: - DAST_API_OPENAPI: http://api-test.host.com/api-specification.yml + DAST_API_SPECIFICATION: http://api-test.host.com/api-specification.yml DAST_API_HOST_OVERRIDE: api-test.host.com ``` @@ -417,7 +417,7 @@ include: - template: DAST-API.gitlab-ci.yml variables: - DAST_API_OPENAPI: http://api-test.api.com/api-specification.yml + DAST_API_SPECIFICATION: http://api-test.api.com/api-specification.yml DAST_REQUEST_HEADERS: "Authorization: Bearer my.token" ``` @@ -633,8 +633,7 @@ including a large number of false positives. | `DAST_ADVERTISE_SCAN` | boolean | Set to `true` to add a `Via` header to every request sent, advertising that the request was sent as part of a GitLab DAST scan. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/334947) in GitLab 14.1. | | `DAST_AGGREGATE_VULNERABILITIES` | boolean | Vulnerability aggregation is set to `true` by default. To disable this feature and see each vulnerability individually set to `false`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/254043) in GitLab 14.0. | | `DAST_API_HOST_OVERRIDE` <sup>1</sup> | string | Used to override domains defined in API specification files. Only supported when importing the API specification from a URL. Example: `example.com:8080`. | -| `DAST_API_OPENAPI` | URL or string | The API specification to import. The specification can be hosted at a URL, or the name of a file present in the `/zap/wrk` directory. The variable `DAST_WEBSITE` must be specified if this is omitted. | -| `DAST_API_SPECIFICATION` <sup>1</sup> | URL or string | **{warning}** **[Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/290241)** in GitLab 15.0. Replaced by `DAST_API_OPENAPI`. The API specification to import. The specification can be hosted at a URL, or the name of a file present in the `/zap/wrk` directory. The variable `DAST_WEBSITE` must be specified if this is omitted. | +| `DAST_API_SPECIFICATION` <sup>1</sup> | URL or string | The API specification to import. The specification can be hosted at a URL, or the name of a file present in the `/zap/wrk` directory. The variable `DAST_WEBSITE` must be specified if this is omitted. | | `DAST_AUTH_REPORT` <sup>2</sup> | boolean | Used in combination with exporting the `gl-dast-debug-auth-report.html` artifact to aid in debugging authentication issues. | | `DAST_AUTH_EXCLUDE_URLS` <sup>2</sup> | URLs | **{warning}** **[Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/289959)** in GitLab 14.0. Replaced by `DAST_EXCLUDE_URLS`. The URLs to skip during the authenticated scan; comma-separated. Regular expression syntax can be used to match multiple URLs. For example, `.*` matches an arbitrary character sequence. Not supported for API scans. | | `DAST_AUTH_URL` <sup>1,2</sup> | URL | The URL of the page containing the sign-in HTML form on the target website. `DAST_USERNAME` and `DAST_PASSWORD` are submitted with the login form to create an authenticated scan. Not supported for API scans. Example: `https://login.example.com`. | @@ -671,7 +670,7 @@ including a large number of false positives. | `DAST_USERNAME` <sup>1,2</sup> | string | The username to authenticate to in the website. Example: `admin` | | `DAST_USERNAME_FIELD` <sup>1,2</sup> | string | The selector of username field at the sign-in HTML form. Example: `name:username` | | `DAST_XML_REPORT` | string | The filename of the XML report written at the end of a scan. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12652) in GitLab 13.1. | -| `DAST_WEBSITE` <sup>1</sup> | URL | The URL of the website to scan. The variable `DAST_API_OPENAPI` must be specified if this is omitted. | +| `DAST_WEBSITE` <sup>1</sup> | URL | The URL of the website to scan. The variable `DAST_API_SPECIFICATION` must be specified if this is omitted. | | `DAST_ZAP_CLI_OPTIONS` | string | ZAP server command-line options. For example, `-Xmx3072m` would set the Java maximum memory allocation pool size. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12652) in GitLab 13.1. | | `DAST_ZAP_LOG_CONFIGURATION` | string | Set to a semicolon-separated list of additional log4j properties for the ZAP Server. Example: `logger.httpsender.name=org.parosproxy.paros.network.HttpSender;logger.httpsender.level=debug;logger.sitemap.name=org.parosproxy.paros.model.SiteMap;logger.sitemap.level=debug;` | | `SECURE_ANALYZERS_PREFIX` | URL | Set the Docker registry base address from which to download the analyzer. | @@ -995,8 +994,7 @@ An on-demand scan can be run in active or passive mode: - _Passive mode_ is the default and runs a ZAP Baseline Scan. - _Active mode_ runs a ZAP Full Scan which is potentially harmful to the site being scanned. To - minimize the risk of accidental damage, running an active scan requires a [validated site - profile](#site-profile-validation). + minimize the risk of accidental damage, running an active scan requires a [validated site profile](#site-profile-validation). ### View on-demand DAST scans diff --git a/doc/user/application_security/dast_api/index.md b/doc/user/application_security/dast_api/index.md index fdca02267e4..1f86f2ffa49 100644 --- a/doc/user/application_security/dast_api/index.md +++ b/doc/user/application_security/dast_api/index.md @@ -1524,7 +1524,7 @@ For more information, see [Offline environments](../offline_deployments/index.md ## Troubleshooting -### Error waiting for API Security 'http://127.0.0.1:5000' to become available +### `Error waiting for API Security 'http://127.0.0.1:5000' to become available` A bug exists in versions of the DAST API analyzer prior to v1.6.196 that can cause a background process to fail under certain conditions. The solution is to update to a newer version of the DAST API analyzer. @@ -1537,7 +1537,7 @@ If the issue is occurring with versions v1.6.196 or greater, please contact Supp 1. The `gl-api-security-scanner.log` file available as a job artifact. In the right-hand panel of the job details page, select the **Browse** button. 1. The `dast_api` job definition from your `.gitlab-ci.yml` file. -### Failed to start scanner session (version header not found) +### `Failed to start scanner session (version header not found)` The DAST API engine outputs an error message when it cannot establish a connection with the scanner application component. The error message is shown in the job output window of the `dast_api` job. A common cause of this issue is changing the `DAST_API_API` variable from its default. @@ -1551,7 +1551,7 @@ The DAST API engine outputs an error message when it cannot establish a connecti - Remove the `DAST_API_API` variable from the `.gitlab-ci.yml` file. The value will be inherited from the DAST API CI/CD template. We recommend this method instead of manually setting a value. - If removing the variable is not possible, check to see if this value has changed in the latest version of the [DAST API CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/DAST-API.gitlab-ci.yml). If so, update the value in the `.gitlab-ci.yml` file. -### Application cannot determine the base URL for the target API +### `Application cannot determine the base URL for the target API` The DAST API engine outputs an error message when it cannot determine the target API after inspecting the OpenAPI document. This error message is shown when the target API has not been set in the `.gitlab-ci.yml` file, it is not available in the `environment_url.txt` file, and it could not be computed using the OpenAPI document. @@ -1612,7 +1612,7 @@ To detect and correct elements that don't comply with the OpenAPI specifications | Editor | OpenAPI 2.0 | OpenAPI 3.0.x | OpenAPI 3.1.x | | -- | -- | -- | -- | | [Swagger Editor](https://editor.swagger.io/) | **{check-circle}** YAML, JSON | **{check-circle}** YAML, JSON | **{dotted-circle}** YAML, JSON | -| [Stoplight Studio](https://stoplight.io/studio/) | **{check-circle}** YAML, JSON | **{check-circle}** YAML, JSON | **{check-circle}** YAML, JSON | +| [Stoplight Studio](https://stoplight.io/studio) | **{check-circle}** YAML, JSON | **{check-circle}** YAML, JSON | **{check-circle}** YAML, JSON | If your OpenAPI document is generated manually, load your document in the editor and fix anything that is non-compliant. If your document is generated automatically, load it in your editor to identify the issues in the schema, then go to the application and perform the corrections based on the framework you are using. @@ -1636,7 +1636,7 @@ API Security can still try to consume an OpenAPI document that does not fully co DAST_API_OPENAPI_RELAXED_VALIDATION: On ``` -### No operation in the OpenAPI document is consuming any supported media type +### `No operation in the OpenAPI document is consuming any supported media type` API Security uses the specified media types in the OpenAPI document to generate requests. If no request can be created due to the lack of supported media types, then an error will be thrown. @@ -1654,7 +1654,7 @@ API Security uses the specified media types in the OpenAPI document to generate To get support for your particular problem please use the [getting help channels](https://about.gitlab.com/get-help/). The [GitLab issue tracker on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues) is the right place for bugs and feature proposals about API Security and DAST API. -Please use `~"Category:API Security"` [label](../../../development/contributing/issue_workflow.md#labels) when opening a new issue regarding DAST API to ensure it is quickly reviewed by the right people. Please refer to our [review response SLO](../../../development/code_review.md#review-response-slo) to understand when you should receive a response. +Please use `~"Category:API Security"` [label](../../../development/contributing/issue_workflow.md#labels) when opening a new issue regarding DAST API to ensure it is quickly reviewed by the right people. Please refer to our [review response SLO](https://about.gitlab.com/handbook/engineering/workflow/code-review/#review-response-slo) to understand when you should receive a response. [Search the issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues) for similar entries before submitting your own, there's a good chance somebody else had the same issue or feature proposal. Show your support with an award emoji and or join the discussion. diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md index d0a91ab664e..521bb6adbf0 100644 --- a/doc/user/application_security/dependency_scanning/index.md +++ b/doc/user/application_security/dependency_scanning/index.md @@ -109,6 +109,8 @@ maximum of two directory levels from the repository's root. For example, the `gemnasium-dependency_scanning` job is enabled if a repository contains either `Gemfile`, `api/Gemfile`, or `api/client/Gemfile`, but not if the only supported dependency file is `api/v1/client/Gemfile`. +For Java and Python, when a supported depedency file is detected, Dependency Scanning attempts to build the project and execute some Java or Python commands to get the list of dependencies. For all other projects, the lock file is parsed to obtain the list of dependencies without needing to build the project first. + When a supported dependency file is detected, all dependencies, including transitive dependencies are analyzed. There is no limit to the depth of nested or transitive dependencies that are analyzed. The following languages and dependency managers are supported: @@ -148,14 +150,13 @@ table.supported-languages ul { <th>Language Versions</th> <th>Package Manager</th> <th>Supported files</th> - <th>Analyzer</th> <th><a href="#how-multiple-files-are-processed">Processes multiple files?</a></th> </tr> </thead> <tbody> <tr> <td>Ruby</td> - <td>Not applicable</td> + <td>All versions</td> <td><a href="https://bundler.io/">Bundler</a></td> <td> <ul> @@ -163,23 +164,20 @@ table.supported-languages ul { <li><code>gems.locked</code></li> </ul> </td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>Y</td> </tr> <tr> <td>PHP</td> - <td>Not applicable</td> + <td>All versions</td> <td><a href="https://getcomposer.org/">Composer</a></td> <td><code>composer.lock</code></td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>Y</td> </tr> <tr> <td>C</td> - <td rowspan="2">Not applicable</td> + <td rowspan="2">All versions</td> <td rowspan="2"><a href="https://conan.io/">Conan</a></td> <td rowspan="2"><a href="https://docs.conan.io/en/latest/versioning/lockfiles.html"><code>conan.lock</code></a></td> - <td rowspan="2"><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td rowspan="2">Y</td> </tr> <tr> @@ -187,10 +185,9 @@ table.supported-languages ul { </tr> <tr> <td>Go</td> - <td>Not applicable</td> + <td>All versions</td> <td><a href="https://go.dev/">Go</a></td> <td><code>go.sum</code></td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>Y</td> </tr> <tr> @@ -211,41 +208,36 @@ table.supported-languages ul { <li><code>build.gradle.kts</code></li> </ul> </td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>N</td> </tr> <tr> <td><a href="https://maven.apache.org/">Maven</a></td> <td><code>pom.xml</code></td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>N</td> </tr> <tr> <td rowspan="2">JavaScript</td> - <td>Not applicable</td> + <td>All versions</td> <td><a href="https://www.npmjs.com/">npm</a></td> <td> <ul> - <li><code>package-lock.json</code></li> + <li><code>package-lock.json</code><sup><b><a href="#notes-regarding-supported-languages-and-package-managers-3">3</a></b></sup></li> <li><code>npm-shrinkwrap.json</code></li> </ul> </td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>Y</td> </tr> <tr> - <td>Not applicable</td> + <td>All versions</td> <td><a href="https://classic.yarnpkg.com/en/">yarn</a></td> <td><code>yarn.lock</code></td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>Y</td> </tr> <tr> <td>.NET</td> - <td rowspan="2">Not applicable</td> + <td rowspan="2">All versions</td> <td rowspan="2"><a href="https://www.nuget.org/">NuGet</a></td> <td rowspan="2"><a href="https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#enabling-lock-file"><code>packages.lock.json</code></a></td> - <td rowspan="2"><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td rowspan="2">Y</td> </tr> <tr> @@ -256,7 +248,6 @@ table.supported-languages ul { <td rowspan="4">3.9</td> <td><a href="https://setuptools.readthedocs.io/en/latest/">setuptools</a></td> <td><code>setup.py</code></td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>N</td> </tr> <tr> @@ -268,7 +259,6 @@ table.supported-languages ul { <li><code>requires.txt</code></li> </ul> </td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>N</td> </tr> <tr> @@ -276,24 +266,21 @@ table.supported-languages ul { <td> <ul> <li><a href="https://pipenv.pypa.io/en/latest/basics/#example-pipfile-pipfile-lock"><code>Pipfile</code></a></li> - <li><a href="https://pipenv.pypa.io/en/latest/basics/#example-pipfile-pipfile-lock"><code>Pipfile.lock</code></a><sup><b><a href="#notes-regarding-supported-languages-and-package-managers-3">3</a></b></sup></li> + <li><a href="https://pipenv.pypa.io/en/latest/basics/#example-pipfile-pipfile-lock"><code>Pipfile.lock</code></a><sup><b><a href="#notes-regarding-supported-languages-and-package-managers-4">4</a></b></sup></li> </ul> </td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>N</td> </tr> <tr> <td><a href="https://python-poetry.org/">Poetry</a><sup><b><a href="#notes-regarding-supported-languages-and-package-managers-5">5</a></b></sup></td> <td><code>poetry.lock</code></td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>N</td> </tr> <tr> <td>Scala</td> - <td>Not applicable</td> - <td><a href="https://www.scala-sbt.org/">sbt</a><sup><b><a href="#notes-regarding-supported-languages-and-package-managers-4">4</a></b></sup></td> + <td>All versions</td> + <td><a href="https://www.scala-sbt.org/">sbt</a><sup><b><a href="#notes-regarding-supported-languages-and-package-managers-6">6</a></b></sup></td> <td><code>build.sbt</code></td> - <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td> <td>N</td> </tr> </tbody> @@ -311,12 +298,18 @@ table.supported-languages ul { <p> Although Gradle with Java 8 is supported, there are other issues such that Android project builds are not supported at this time. Please see the backlog issue <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/336866">Android support for Dependency - Scanning (gemnasium-maven)</a> for more details. Also, Gradle is not supported when [FIPS mode](../../../development/fips_compliance.md#enable-fips-mode) is enabled. + Scanning (gemnasium-maven)</a> for more details. Also, Gradle is not supported when <a href="https://docs.gitlab.com/ee/development/fips_compliance.html#enable-fips-mode">FIPS mode</a> is enabled. </p> </li> <li> <a id="notes-regarding-supported-languages-and-package-managers-3"></a> <p> + npm is only supported when `lockfileVersion = 1` or `lockfileVersion = 2`. Work to add support for `lockfileVersion = 3` is being tracked in issue <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/365176">GitLab#365176</a>. + </p> + </li> + <li> + <a id="notes-regarding-supported-languages-and-package-managers-4"></a> + <p> The presence of a <code>Pipfile.lock</code> file alone will <i>not</i> trigger the analyzer; the presence of a <code>Pipfile</code> is still required in order for the analyzer to be executed. However, if a <code>Pipfile.lock</code> file is found, it will be used by <code>Gemnasium</code> to scan the exact package versions listed in this file. @@ -328,12 +321,6 @@ table.supported-languages ul { </p> </li> <li> - <a id="notes-regarding-supported-languages-and-package-managers-4"></a> - <p> - Support for <a href="https://www.scala-sbt.org/">sbt</a> 1.3 and above was added in GitLab 13.9. - </p> - </li> - <li> <a id="notes-regarding-supported-languages-and-package-managers-5"></a> <p> Support for <a href="https://python-poetry.org/">Poetry</a> projects with a <code>poetry.lock</code> file was <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/7006">added in GitLab 15.0</a>. @@ -341,6 +328,12 @@ table.supported-languages ul { <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/32774">Poetry's pyproject.toml support for dependency scanning.</a> </p> </li> + <li> + <a id="notes-regarding-supported-languages-and-package-managers-6"></a> + <p> + Support for <a href="https://www.scala-sbt.org/">sbt</a> 1.3 and above was added in GitLab 13.9. + </p> + </li> </ol> <!-- markdownlint-enable MD044 --> @@ -601,7 +594,7 @@ The following variables allow configuration of global dependency scanning settin | `ADDITIONAL_CA_CERT_BUNDLE` | Bundle of CA certs to trust. The bundle of certificates provided here is also used by other tools during the scanning process, such as `git`, `yarn`, or `npm`. See [Using a custom SSL CA certificate authority](#using-a-custom-ssl-ca-certificate-authority) for more details. | | `DS_EXCLUDED_ANALYZERS` | Specify the analyzers (by name) to exclude from Dependency Scanning. For more information, see [Dependency Scanning Analyzers](analyzers.md). | | `DS_DEFAULT_ANALYZERS` | This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/287691) in GitLab 14.0 and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/333299) in 15.0. Use `DS_EXCLUDED_ANALYZERS` instead. | -| `DS_EXCLUDED_PATHS` | Exclude files and directories from the scan based on the paths. A comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. Default: `"spec, test, tests, tmp"`. | +| `DS_EXCLUDED_PATHS` | Exclude files and directories from the scan based on the paths. A comma-separated list of patterns. Patterns can be globs (see [`doublestar.Match`](https://pkg.go.dev/github.com/bmatcuk/doublestar/v4@v4.0.2#Match) for supported patterns), or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. Default: `"spec, test, tests, tmp"`. | | `DS_IMAGE_SUFFIX` | Suffix added to the image name. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/354796) in GitLab 14.10.) Automatically set to `"-fips"` when FIPS mode is enabled. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/357922) in GitLab 15.0.) | | `SECURE_ANALYZERS_PREFIX` | Override the name of the Docker registry providing the official default images (proxy). Read more about [customizing analyzers](analyzers.md). | | `SECURE_LOG_LEVEL` | Set the minimum logging level. Messages of this logging level or higher are output. From highest to lowest severity, the logging levels are: `fatal`, `error`, `warn`, `info`, `debug`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1. Default: `info`. | @@ -924,8 +917,7 @@ Please check the [Release Process documentation](https://gitlab.com/gitlab-org/s ## Contributing to the vulnerability database -You can search the [`gemnasium-db`](https://gitlab.com/gitlab-org/security-products/gemnasium-db) project -to find a vulnerability in the GitLab Advisory Database. +To find a vulnerability, you can search the [`GitLab Advisory Database`](https://advisories.gitlab.com/). You can also [submit new vulnerabilities](https://gitlab.com/gitlab-org/security-products/gemnasium-db/blob/master/CONTRIBUTING.md). ## Running dependency scanning in an offline environment diff --git a/doc/user/application_security/get-started-security.md b/doc/user/application_security/get-started-security.md new file mode 100644 index 00000000000..4c2b971b5fa --- /dev/null +++ b/doc/user/application_security/get-started-security.md @@ -0,0 +1,34 @@ +--- +stage: DevSecOps +group: Technical writing +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +--- + +# Get started with GitLab application security **(ULTIMATE)** + +Complete the following steps to get the most from GitLab application security tools. + +1. Enable [Secret Detection](secret_detection/index.md) scanning for your default branch. +1. Enable [Dependency Scanning](dependency_scanning/index.md) for your default branch so you can start identifying existing + vulnerable packages in your codebase. +1. Add security scans to feature branch pipelines. The same scans should be enabled as are running + on your default branch. Subsequent scans will show only new vulnerabilities by comparing the feature branch to the default branch results. +1. Let your team get comfortable with [vulnerability reports](vulnerability_report/index.md) and + establish a vulnerability triage workflow. +1. Consider creating [labels](../project/labels.md) and [issue boards](../project/issue_board.md) to + help manage issues created from vulnerabilities. Issue boards allow all stakeholders to have a + common view of all issues. +1. Create a [scan result policy](policies/index.md) to limit new vulnerabilities from being merged + into your default branch. +1. Monitor the [Security Dashboard](security_dashboard/index.md) trends to gauge success in + remediating existing vulnerabilities and preventing the introduction of new ones. +1. Enable other scan types such as [SAST](sast/index.md), [DAST](dast/index.md), + [Fuzz testing](coverage_fuzzing/index.md), or [Container Scanning](container_scanning/index.md). + Be sure to add the same scan types to both feature pipelines and default branch pipelines. +1. Use [Compliance Pipelines](../../user/project/settings/index.md#compliance-pipeline-configuration) + or [Scan Execution Policies](policies/scan-execution-policies.md) to enforce required scan types + and ensure separation of duties between security and engineering. +1. Consider enabling [Review Apps](../../development/testing_guide/review_apps.md) to allow for DAST + and [Web API fuzzing](api_fuzzing/index.md) on ephemeral test environments. +1. Enable [operational container scanning](../../user/clusters/agent/vulnerabilities.md) to scan + container images in your production cluster for security vulnerabilities. diff --git a/doc/user/application_security/iac_scanning/index.md b/doc/user/application_security/iac_scanning/index.md index 35968a6361f..16f08de738b 100644 --- a/doc/user/application_security/iac_scanning/index.md +++ b/doc/user/application_security/iac_scanning/index.md @@ -64,7 +64,7 @@ variables: SAST_IMAGE_SUFFIX: '-fips' include: - - template: Security/SAST-IaC.latest.gitlab-ci.yml + - template: Jobs/SAST-IaC.gitlab-ci.yml ``` ### Making IaC analyzers available to all GitLab tiers @@ -98,11 +98,11 @@ To configure IaC Scanning for a project you can: ### Configure IaC Scanning manually To enable IaC Scanning you must [include](../../../ci/yaml/index.md#includetemplate) the -[`SAST-IaC.latest.gitlab-ci.yml template`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST-IaC.latest.gitlab-ci.yml) provided as part of your GitLab installation. Here is an example of how to include it: +[`SAST-IaC.gitlab-ci.yml template`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST-IaC.gitlab-ci.yml) provided as part of your GitLab installation. Here is an example of how to include it: ```yaml include: - - template: Security/SAST-IaC.latest.gitlab-ci.yml + - template: Jobs/SAST-IaC.gitlab-ci.yml ``` The included template creates IaC scanning jobs in your CI/CD pipeline and scans @@ -130,3 +130,24 @@ The IaC tool emits a JSON report file in the existing SAST report format. For mo The JSON report file can be downloaded from the CI pipelines page, or the pipelines tab on merge requests by [setting `artifacts: paths`](../../../ci/yaml/index.md#artifactspaths) to `gl-sast-report.json`. For more information see [Downloading artifacts](../../../ci/pipelines/job_artifacts.md). + +## Troubleshooting + +### IaC debug logging + +To help troubleshoot IaC jobs, you can increase the [Secure scanner log verbosity](../sast/index.md#logging-level) +by using a global CI/CD variable set to `debug`: + +```yaml +variables: + SECURE_LOG_LEVEL: "debug" +``` + +### IaC Scanning findings show as `No longer detected` unexpectedly + +If a previously detected finding unexpectedly shows as `No longer detected`, it might +be due to an update to the scanner. An update can disable rules that are found to +be ineffective or false positives, and the findings are marked as `No longer detected`: + +- In GitLab 15.3, [secret detection in the KICS SAST IaC scanner was disabled](https://gitlab.com/gitlab-org/gitlab/-/issues/346181), + so IaC findings in the "Passwords and Secrets" family show as `No longer detected`. diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md index e3a419ea771..7c7d5380a24 100644 --- a/doc/user/application_security/index.md +++ b/doc/user/application_security/index.md @@ -149,19 +149,8 @@ base address for Docker images. You can override this for most scanners by setti The [Container Scanning](container_scanning/index.md) analyzer is an exception, and it does not use the `SECURE_ANALYZERS_PREFIX` variable. To override its Docker image, see -the instructions for [Running container scanning in an offline -environment](container_scanning/index.md#running-container-scanning-in-an-offline-environment). - -### Use security scanning tools with merge request pipelines - -By default, the application security jobs are configured to run for branch pipelines only. -To use them with [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md), -you may need to override the default `rules:` configuration to add: - -```yaml -rules: - - if: $CI_PIPELINE_SOURCE == "merge_request_event" -``` +the instructions for +[Running container scanning in an offline environment](container_scanning/index.md#running-container-scanning-in-an-offline-environment). ## Default behavior of GitLab security scanning tools @@ -401,8 +390,10 @@ Validation depends on the schema version declared in the security report artifac - If your security report specifies a supported schema version, GitLab uses this version to validate. - If your security report uses a deprecated version, GitLab attempts validation against that version and adds a deprecation warning to the validation result. -- If your security report uses a version that is not supported, GitLab attempts to validate it against the latest schema version available in GitLab. -- If your security report does not specify a schema version, GitLab attempts to validate it against the lastest schema version available in GitLab. Since the `version` property is required, validation always fails in this case, but other validation errors may also be present. +- If your security report uses a supported MAJOR-MINOR version of the report schema but the PATCH version doesn't match any vendored versions, GitLab attempts to validate it against latest vendored PATCH version of the schema. + - Example: security report uses version 14.1.1 but the latest vendored version is 14.1.0. GitLab would validate against schema version 14.1.0. +- If your security report uses a version that is not supported, GitLab attempts to validate it against the latest schema version available in your installation but doesn't ingest the report. +- If your security report does not specify a schema version, GitLab attempts to validate it against the latest schema version available in GitLab. Because the `version` property is required, validation always fails in this case, but other validation errors may also be present. You can always find supported and deprecated schema versions in the [source code](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/parsers/security/validators/schema_validator.rb). diff --git a/doc/user/application_security/policies/index.md b/doc/user/application_security/policies/index.md index 81a9cef885d..53f9c400259 100644 --- a/doc/user/application_security/policies/index.md +++ b/doc/user/application_security/policies/index.md @@ -137,3 +137,13 @@ See [Scan result policies](scan-result-policies.md). See the [Category Direction page](https://about.gitlab.com/direction/protect/security_orchestration/) for more information on the product direction of security policies within GitLab. + +## Troubleshooting + +### `Branch name does not follow the pattern 'update-policy-<timestamp>'` + +When you create a new security policy or change an existing policy, a new branch is automatically created with the branch name following the pattern `update-policy-<timestamp>`. For example: `update-policy-1659094451`. + +If you have group or instance push rules that do not allow branch name patterns that contain the text `update-policy-<timestamp>`, you will get an error that states `Branch name does not follow the pattern 'update-policy-<timestamp>'`. + +The workaround is to amend your group or instance push rules to allow branches following the pattern `update-policy-` followed by an integer timestamp. diff --git a/doc/user/application_security/sast/analyzers.md b/doc/user/application_security/sast/analyzers.md index 0f9e3343072..cbd64e278c8 100644 --- a/doc/user/application_security/sast/analyzers.md +++ b/doc/user/application_security/sast/analyzers.md @@ -47,7 +47,7 @@ For an analyzer to be considered Generally Available, it is expected to minimall support the following features: - [Customizable configuration](index.md#available-cicd-variables) -- [Customizable rulesets](index.md#customize-rulesets) +- [Customizable rulesets](customize_rulesets.md#customize-rulesets) - [Scan projects](index.md#supported-languages-and-frameworks) - [Multi-project support](index.md#multi-project-support) - [Offline support](index.md#running-sast-in-an-offline-environment) diff --git a/doc/user/application_security/sast/customize_rulesets.md b/doc/user/application_security/sast/customize_rulesets.md new file mode 100644 index 00000000000..919a3565d88 --- /dev/null +++ b/doc/user/application_security/sast/customize_rulesets.md @@ -0,0 +1,381 @@ +--- +stage: Secure +group: Static Analysis +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +--- + +# Customize rulesets **(ULTIMATE)** + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/235382) in GitLab 13.5. +> - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/339614) support for +> passthrough chains. Expanded to include additional passthrough types of `file`, `git`, and `url` in GitLab 14.6. +> - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/235359) support for overriding rules in GitLab 14.8. + +You can customize the default scanning rules provided by our SAST analyzers. +Ruleset customization supports the following that can be used +simultaneously: + +- [Disabling predefined rules](#disable-predefined-analyzer-rules). Available for all analyzers. +- [Overriding predefined rules](#override-predefined-analyzer-rules). Available for all analyzers. +- Modifying the default behavior of a given analyzer by [synthesizing and passing a custom configuration](#synthesize-a-custom-configuration). Available for only `nodejs-scan`, `gosec`, and `semgrep`. + +To customize the default scanning rules, create a file containing custom rules. These rules +are passed through to the analyzer's underlying scanner tools. + +To create a custom ruleset: + +1. Create a `.gitlab` directory at the root of your project, if one doesn't already exist. +1. Create a custom ruleset file named `sast-ruleset.toml` in the `.gitlab` directory. + +## Disable predefined analyzer rules + +To disable analyzer rules: + +1. Set the `disabled` flag to `true` in the context of a `ruleset` section + +1. In one or more `ruleset.identifier` sub sections, list the rules that you want disabled. Every `ruleset.identifier` section has: + +- a `type` field, to name the predefined rule identifier that the targeted analyzer uses. +- a `value` field, to name the rule to be disabled. + +### Example: Disable predefined rules of SAST analyzers + +In the following example, the disabled rules are assigned to `eslint` +and `sobelow` by matching the `type` and `value` of identifiers: + +```toml +[eslint] + [[eslint.ruleset]] + disable = true + [eslint.ruleset.identifier] + type = "eslint_rule_id" + value = "security/detect-object-injection" + + [[eslint.ruleset]] + disable = true + [eslint.ruleset.identifier] + type = "cwe" + value = "185" + +[sobelow] + [[sobelow.ruleset]] + disable = true + [sobelow.ruleset.identifier] + type = "sobelow_rule_id" + value = "sql_injection" +``` + +Those vulnerabilities containing the provided type and value are now disabled, meaning +they won't be displayed in Merge Request nor the Vulnerability Report. + +## Override predefined analyzer rules + +To override analyzer rules: + +1. In one or more `ruleset.identifier` subsections, list the rules that you want to override. Every `ruleset.identifier` section has: + + - a `type` field, to name the predefined rule identifier that the targeted analyzer uses. + - a `value` field, to name the rule to be overridden. + +1. In the `ruleset.override` context of a `ruleset` section, + provide the keys to override. Any combination of keys can be + overridden. Valid keys are: + + - description + - message + - name + - severity (valid options are: Critical, High, Medium, Low, Unknown, Info) + +### Example: Override predefined rules of SAST analyzers + +Before adding a ruleset, we verify which vulnerability will be overwritten by viewing the [`gl-sast-report.json`](index.md#reports-json-format): + +```json +"identifiers": [ + { + "type": "gosec_rule_id", + "name": "Gosec Rule ID G307", + "value": "G307" + }, + { + "type": "CWE", + "name": "CWE-703", + "value": "703", + "url": "https://cwe.mitre.org/data/definitions/703.html" + } + ] +``` + +In the following example, rules from `gosec` are matched by the `type` +and `value` of identifiers and then overridden: + +```toml +[gosec] + [[gosec.ruleset]] + [gosec.ruleset.identifier] + type = "CWE" + value = "703" + [gosec.ruleset.override] + severity = "Critical" +``` + +If a vulnerability is found with a type `CWE` with a value of `703` then +the vulnerability severity is overwritten to `Critical`. + +## Synthesize a custom configuration + +To create a custom configuration, you can use passthrough chains. + +A passthrough is a single step in a passthrough chain. The passthrough is evaluated +in a sequence to incrementally build a configuration. The configuration is then +passed to the target analyzer. + +A configuration section for an analyzer has the following +parameters: + +| Parameter | Explanation | +| ------------- | ------ | +| `description` | Description about the analyzer configuration section. | +| `targetdir` | The `targetdir` parameter defines the directory where the final configuration is located. If `targetdir` is empty, the analyzer uses a random directory. The maximum size of `targetdir` is 100MB. | +| `validate` | If set to `true`, the target files for passthroughs (`raw`, `file` and `url`) are validated. The validation works for `yaml`, `xml`, `json` and `toml` files. The proper validator is identified based on the extension of the target file. By default, `validate` is set to `false`. | +| `interpolate` | If set to `true`, environment variable interpolation is enabled so that the configuration uses secrets/tokens. We advise using this feature with caution to not leak any secrets. By default, `interpolate` is set to `false`. | +| `timeout` | The total `timeout` for the evaluation of a passthrough chain is set to 60 seconds. If `timeout` is not set, the default timeout is 60 seconds. The timeout cannot exceed 300 seconds. | + +A configuration section can include one or more passthrough sections. The maximum number of passthrough sections is 20. +There are several types of passthroughs: + +| Type | Description | +| ------ | ------ | +| `file` | Use a file that is already available in the Git repository. | +| `raw` | Provide the configuration inline. | +| `git` | Pull the configuration from a remote Git repository. | +| `url` | Fetch the analyzer configuration through HTTP. | + +If multiple passthrough sections are defined in a passthrough chain, their +position in the chain defines the order in which they are evaluated. + +- Passthroughs listed later in the chain sequence have a higher precedence. +- Passthroughs with a higher precedence overwrite (default) and append data + yielded by previous passthroughs. This is useful for cases where you need to + use or modify an existing configuration. + +Configure a passthrough these parameters: + +| Parameter | Explanation | +| ------------ | ----------- | +| `type` | One of `file`, `raw`, `git` or `url`. | +| `target` | The target file that contains the data written by the passthrough evaluation. If no value is provided, a random target file is generated. | +| `mode` | `overwrite`: if `target` exists, overwrites the file; `append`: append to file instead. The default is `overwrite`. | +| `ref` | This option only applies to the `git` passthrough type and contains the name of the branch or the SHA to be used. | +| `subdir` | This option only applies to the `git` passthrough type and can be used to only consider a certain subdirectory of the source Git repository. | +| `value` | For the `file` `url` and `git` types, `value` defines the source location of the file/Git repository; for the `raw` type, `value` carries the raw content to be passed through. | +| `validator` | Can be used to explicitly invoke validators (`xml`, `yaml`, `json`, `toml`) on the target files after the application of a passthrough. Per default, no validator is set. | + +The amount of data generated by a single passthrough is limited to 1MB. + +## Passthrough configuration examples + +### Raw passthrough for nodejs-scan + +Define a custom analyzer configuration. In this example, customized rules are +defined for the `nodejs-scan` scanner: + +```toml +[nodejs-scan] + description = 'custom ruleset for nodejs-scan' + + [[nodejs-scan.passthrough]] + type = "raw" + value = ''' +- nodejs-extensions: + - .js + + template-extensions: + - .new + - .hbs + - '' + + ignore-filenames: +- skip.js + + ignore-paths: + - __MACOSX + - skip_dir + - node_modules + + ignore-extensions: + - .hbs + + ignore-rules: + - regex_injection_dos + - pug_jade_template + - express_xss + +''' +``` + +### File passthrough for Gosec + +Provide the name of the file containing a custom analyzer configuration. In +this example, customized rules for the `gosec` scanner are contained in the +file `gosec-config.json`: + +```toml +[gosec] + description = 'custom ruleset for gosec' + + [[gosec.passthrough]] + type = "file" + value = "gosec-config.json" +``` + +### Passthrough chain for Semgrep + +In the below example, we generate a custom configuration under the `/sgrules` +target directory with a total `timeout` of 60 seconds. + +Several passthrouh types generate a configuration for the target analyzer: + +- Two `git` passthrough sections pull the head of branch + `refs/remotes/origin/test` from the `myrules` Git repository, and revision + `97f7686` from the `sast-rules` Git repository. From the `sast-rules` Git + repository, only data from the `go` subdirectory is considered. + - The `sast-rules` entry has a higher precedence because it appears later in + the configuration. + - If there is a filename collision between files in both repositories, files + from the `sast` repository overwrite files from the `myrules` repository, + as `sast-rules` has higher precedence. +- The `raw` entry creates a file named `insecure.yml` under `/sgrules`. The + full path is `/sgrules/insecure.yml`. +- The `url` entry fetches a configuration made available through a URL and + stores it in the `/sgrules/gosec.yml` file. + +Afterwards, Semgrep is invoked with the final configuration located under +`/sgrules`. + +```toml +[semgrep] + description = 'semgrep custom rules configuration' + targetdir = "/sgrules" + timeout = 60 + + [[semgrep.passthrough]] + type = "git" + value = "https://gitlab.com/user/myrules.git" + ref = "refs/remotes/origin/test" + + [[semgrep.passthrough]] + type = "git" + value = "https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/playground/sast-rules.git" + ref = "97f7686db058e2141c0806a477c1e04835c4f395" + subdir = "go" + + [[semgrep.passthrough]] + type = "raw" + target = "insecure.yml" + value = """ +rules: +- id: "insecure" + patterns: + - pattern: "func insecure() {...}" + message: | + Insecure function insecure detected + metadata: + cwe: "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor" + severity: "ERROR" + languages: + - "go" + """ + + [[semgrep.passthrough]] + type = "url" + value = "https://semgrep.dev/c/p/gosec" + target = "gosec.yml" +``` + +### Interpolation + +The code snippet below shows an example configuration that uses an environment +variable `$GITURL` to access a private repositories with a Git URL. The variable contains +a username and token in the `value` field (for example `https://user:token@url`). +It does not explicitly store credentials in the configuration file. To reduce the risk of leaking secrets through created paths and files, use this feature with caution. + +```toml +[semgrep] + description = 'semgrep custom rules configuration' + targetdir = "/sgrules" + interpolate = true + + [[semgrep.passthrough]] + type = "git" + value = "$GITURL" + ref = "refs/remotes/origin/main" +``` + +### Configure the append mode for passthroughs + +To append data to previous passthroughs, use the `append` mode for the +passthrough types `file`, `url`, and `raw`. + +Passthroughs in `override` mode overwrite files +created when preceding passthroughs in the chain find a naming +collision. If `mode` is set to `append`, a passthrough appends data to the +files created by its predecessors instead of overwriting. + +In the below Semgrep configuration,`/sgrules/insecure.yml` assembles two passthroughs. The rules are: + +- `insecure` +- `secret` + +These rules add a search pattern to the analyzer and extends Semgrep capabilities. + +For passthrough chains we recommend that you enable validation. To enable validation, +you can either: + +- set `validate` to `true` + +- set a passthrough `validator` to `xml`, `json`, `yaml`, or `toml`. + +```toml +[semgrep] + description = 'semgrep custom rules configuration' + targetdir = "/sgrules" + validate = true + + [[semgrep.passthrough]] + type = "raw" + target = "insecure.yml" + value = """ +rules: +- id: "insecure" + patterns: + - pattern: "func insecure() {...}" + message: | + Insecure function insecure detected + metadata: + cwe: "... + severity: "ERROR" + languages: + - "go" +""" + + [[semgrep.passthrough]] + type = "raw" + mode = "append" + target = "insecure.yml" + value = """ +- id: "secret" + patterns: + - pattern-either: + - pattern: "$MASK = \"...\"" + - metavariable-regex: + metavariable: "$MASK" + regex: "(password|pass|passwd|pwd|secret|token)" + message: | + Use of Hard-coded Password + cwe: "..." + severity: "ERROR" + languages: + - "go" +""" +``` diff --git a/doc/user/application_security/sast/img/sast_vulnerability_page_fp_detection_v15_2.png b/doc/user/application_security/sast/img/sast_vulnerability_page_fp_detection_v15_2.png Binary files differnew file mode 100644 index 00000000000..2a3e6e7e45f --- /dev/null +++ b/doc/user/application_security/sast/img/sast_vulnerability_page_fp_detection_v15_2.png diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md index 92dc795afe5..d4b0d5b972c 100644 --- a/doc/user/application_security/sast/index.md +++ b/doc/user/application_security/sast/index.md @@ -176,18 +176,18 @@ All open source (OSS) analyzers have been moved to the GitLab Free tier as of Gi Different features are available in different [GitLab tiers](https://about.gitlab.com/pricing/), as shown in the following table: -| Capability | In Free & Premium | In Ultimate | -|:----------------------------------------------------------------|:--------------------|:-------------------| -| [Configure SAST scanners](#configuration) | **{check-circle}** | **{check-circle}** | -| [Customize SAST settings](#available-cicd-variables) | **{check-circle}** | **{check-circle}** | -| Download [JSON Report](#reports-json-format) | **{check-circle}** | **{check-circle}** | -| See new findings in merge request widget | **{dotted-circle}** | **{check-circle}** | -| [Manage vulnerabilities](../vulnerabilities/index.md) | **{dotted-circle}** | **{check-circle}** | -| [Access the Security Dashboard](../security_dashboard/index.md) | **{dotted-circle}** | **{check-circle}** | -| [Configure SAST in the UI](#configure-sast-in-the-ui) | **{dotted-circle}** | **{check-circle}** | -| [Customize SAST rulesets](#customize-rulesets) | **{dotted-circle}** | **{check-circle}** | -| [Detect False Positives](#false-positive-detection) | **{dotted-circle}** | **{check-circle}** | -| [Track moved vulnerabilities](#advanced-vulnerability-tracking) | **{dotted-circle}** | **{check-circle}** | +| Capability | In Free & Premium | In Ultimate | +|:---------------------------------------------------------------- -|:--------------------|:-------------------| +| [Configure SAST scanners](#configuration) | **{check-circle}** | **{check-circle}** | +| [Customize SAST settings](#available-cicd-variables) | **{check-circle}** | **{check-circle}** | +| Download [JSON Report](#reports-json-format) | **{check-circle}** | **{check-circle}** | +| See new findings in merge request widget | **{dotted-circle}** | **{check-circle}** | +| [Manage vulnerabilities](../vulnerabilities/index.md) | **{dotted-circle}** | **{check-circle}** | +| [Access the Security Dashboard](../security_dashboard/index.md) | **{dotted-circle}** | **{check-circle}** | +| [Configure SAST in the UI](#configure-sast-in-the-ui) | **{dotted-circle}** | **{check-circle}** | +| [Customize SAST rulesets](customize_rulesets.md) | **{dotted-circle}** | **{check-circle}** | +| [Detect False Positives](#false-positive-detection) | **{dotted-circle}** | **{check-circle}** | +| [Track moved vulnerabilities](#advanced-vulnerability-tracking) | **{dotted-circle}** | **{check-circle}** | ## Contribute your scanner @@ -320,382 +320,6 @@ brakeman-sast: SAST_ANALYZER_IMAGE_TAG: "2.21.1" ``` -### Customize rulesets **(ULTIMATE)** - -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/235382) in GitLab 13.5. -> - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/339614) support for -> passthrough chains. Expanded to include additional passthrough types of `file`, `git`, and `url` in GitLab 14.6. -> - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/235359) support for overriding rules in GitLab 14.8. - -You can customize the default scanning rules provided by our SAST analyzers. -Ruleset customization supports the following that can be used -simultaneously: - -- [Disabling predefined rules](index.md#disable-predefined-analyzer-rules). Available for all analyzers. -- [Overriding predefined rules](index.md#override-predefined-analyzer-rules). Available for all analyzers. -- Modifying the default behavior of a given analyzer by [synthesizing and passing a custom configuration](index.md#synthesize-a-custom-configuration). Available for only `nodejs-scan`, `gosec`, and `semgrep`. - -To customize the default scanning rules, create a file containing custom rules. These rules -are passed through to the analyzer's underlying scanner tools. - -To create a custom ruleset: - -1. Create a `.gitlab` directory at the root of your project, if one doesn't already exist. -1. Create a custom ruleset file named `sast-ruleset.toml` in the `.gitlab` directory. - -#### Disable predefined analyzer rules - -To disable analyzer rules: - -1. Set the `disabled` flag to `true` in the context of a `ruleset` section - -1. In one or more `ruleset.identifier` sub sections, list the rules that you want disabled. Every `ruleset.identifier` section has: - -- a `type` field, to name the predefined rule identifier that the targeted analyzer uses. -- a `value` field, to name the rule to be disabled. - -##### Example: Disable predefined rules of SAST analyzers - -In the following example, the disabled rules are assigned to `eslint` -and `sobelow` by matching the `type` and `value` of identifiers: - -```toml -[eslint] - [[eslint.ruleset]] - disable = true - [eslint.ruleset.identifier] - type = "eslint_rule_id" - value = "security/detect-object-injection" - - [[eslint.ruleset]] - disable = true - [eslint.ruleset.identifier] - type = "cwe" - value = "185" - -[sobelow] - [[sobelow.ruleset]] - disable = true - [sobelow.ruleset.identifier] - type = "sobelow_rule_id" - value = "sql_injection" -``` - -Those vulnerabilities containing the provided type and value are now disabled, meaning -they won't be displayed in Merge Request nor the Vulnerability Report. - -#### Override predefined analyzer rules - -To override analyzer rules: - -1. In one or more `ruleset.identifier` subsections, list the rules that you want to override. Every `ruleset.identifier` section has: - - - a `type` field, to name the predefined rule identifier that the targeted analyzer uses. - - a `value` field, to name the rule to be overridden. - -1. In the `ruleset.override` context of a `ruleset` section, - provide the keys to override. Any combination of keys can be - overridden. Valid keys are: - - - description - - message - - name - - severity (valid options are: Critical, High, Medium, Low, Unknown, Info) - -##### Example: Override predefined rules of SAST analyzers - -Before adding a ruleset, we verify which vulnerability will be overwritten by viewing the [`gl-sast-report.json`](#reports-json-format): - -```json -"identifiers": [ - { - "type": "gosec_rule_id", - "name": "Gosec Rule ID G307", - "value": "G307" - }, - { - "type": "CWE", - "name": "CWE-703", - "value": "703", - "url": "https://cwe.mitre.org/data/definitions/703.html" - } - ] -``` - -In the following example, rules from `gosec` are matched by the `type` -and `value` of identifiers and then overridden: - -```toml -[gosec] - [[gosec.ruleset]] - [gosec.ruleset.identifier] - type = "CWE" - value = "703" - [gosec.ruleset.override] - severity = "Critical" -``` - -If a vulnerability is found with a type `CWE` with a value of `703` then -the vulnerability severity is overwritten to `Critical`. - -#### Synthesize a custom configuration - -To create a custom configuration, you can use passthrough chains. - -A passthrough is a single step in a passthrough chain. The passthrough is evaluated -in a sequence to incrementally build a configuration. The configuration is then -passed to the target analyzer. - -A configuration section for an analyzer has the following -parameters: - -| Parameter | Explanation | -| ------------- | ------ | -| `description` | Description about the analyzer configuration section. | -| `targetdir` | The `targetdir` parameter defines the directory where the final configuration is located. If `targetdir` is empty, the analyzer uses a random directory. The maximum size of `targetdir` is 100MB. | -| `validate` | If set to `true`, the target files for passthroughs (`raw`, `file` and `url`) are validated. The validation works for `yaml`, `xml`, `json` and `toml` files. The proper validator is identified based on the extension of the target file. By default, `validate` is set to `false`. | -| `interpolate` | If set to `true`, environment variable interpolation is enabled so that the configuration uses secrets/tokens. We advise using this feature with caution to not leak any secrets. By default, `interpolate` is set to `false`. | -| `timeout` | The total `timeout` for the evaluation of a passthrough chain is set to 60 seconds. If `timeout` is not set, the default timeout is 60 seconds. The timeout cannot exceed 300 seconds. | - -A configuration section can include one or more passthrough sections. The maximum number of passthrough sections is 20. -There are several types of passthroughs: - -| Type | Description | -| ------ | ------ | -| `file` | Use a file that is already available in the Git repository. | -| `raw` | Provide the configuration inline. | -| `git` | Pull the configuration from a remote Git repository. | -| `url` | Fetch the analyzer configuration through HTTP. | - -If multiple passthrough sections are defined in a passthrough chain, their -position in the chain defines the order in which they are evaluated. - -- Passthroughs listed later in the chain sequence have a higher precedence. -- Passthroughs with a higher precedence overwrite (default) and append data - yielded by previous passthroughs. This is useful for cases where you need to - use or modify an existing configuration. - -Configure a passthrough these parameters: - -| Parameter | Explanation | -| ------------ | ----------- | -| `type` | One of `file`, `raw`, `git` or `url`. | -| `target` | The target file that contains the data written by the passthrough evaluation. If no value is provided, a random target file is generated. | -| `mode` | `overwrite`: if `target` exists, overwrites the file; `append`: append to file instead. The default is `overwrite`. | -| `ref` | This option only applies to the `git` passthrough type and contains the name of the branch or the SHA to be used. | -| `subdir` | This option only applies to the `git` passthrough type and can be used to only consider a certain subdirectory of the source Git repository. | -| `value` | For the `file` `url` and `git` types, `value` defines the source location of the file/Git repository; for the `raw` type, `value` carries the raw content to be passed through. | -| `validator` | Can be used to explicitly invoke validators (`xml`, `yaml`, `json`, `toml`) on the target files after the application of a passthrough. Per default, no validator is set. | - -The amount of data generated by a single passthrough is limited to 1MB. - -#### Passthrough configuration examples - -##### Raw passthrough for nodejs-scan - -Define a custom analyzer configuration. In this example, customized rules are -defined for the `nodejs-scan` scanner: - -```toml -[nodejs-scan] - description = 'custom ruleset for nodejs-scan' - - [[nodejs-scan.passthrough]] - type = "raw" - value = ''' -- nodejs-extensions: - - .js - - template-extensions: - - .new - - .hbs - - '' - - ignore-filenames: -- skip.js - - ignore-paths: - - __MACOSX - - skip_dir - - node_modules - - ignore-extensions: - - .hbs - - ignore-rules: - - regex_injection_dos - - pug_jade_template - - express_xss - -''' -``` - -##### File passthrough for Gosec - -Provide the name of the file containing a custom analyzer configuration. In -this example, customized rules for the `gosec` scanner are contained in the -file `gosec-config.json`: - -```toml -[gosec] - description = 'custom ruleset for gosec' - - [[gosec.passthrough]] - type = "file" - value = "gosec-config.json" -``` - -##### Passthrough chain for Semgrep - -In the below example, we generate a custom configuration under the `/sgrules` -target directory with a total `timeout` of 60 seconds. - -Several passthrouh types generate a configuration for the target analyzer: - -- Two `git` passthrough sections pull the head of branch - `refs/remotes/origin/test` from the `myrules` Git repository, and revision - `97f7686` from the `sast-rules` Git repository. From the `sast-rules` Git - repository, only data from the `go` subdirectory is considered. - - The `sast-rules` entry has a higher precedence because it appears later in - the configuration. - - If there is a filename collision between files in both repositories, files - from the `sast` repository overwrite files from the `myrules` repository, - as `sast-rules` has higher precedence. -- The `raw` entry creates a file named `insecure.yml` under `/sgrules`. The - full path is `/sgrules/insecure.yml`. -- The `url` entry fetches a configuration made available through a URL and - stores it in the `/sgrules/gosec.yml` file. - -Afterwards, Semgrep is invoked with the final configuration located under -`/sgrules`. - -```toml -[semgrep] - description = 'semgrep custom rules configuration' - targetdir = "/sgrules" - timeout = 60 - - [[semgrep.passthrough]] - type = "git" - value = "https://gitlab.com/user/myrules.git" - ref = "refs/remotes/origin/test" - - [[semgrep.passthrough]] - type = "git" - value = "https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/playground/sast-rules.git" - ref = "97f7686db058e2141c0806a477c1e04835c4f395" - subdir = "go" - - [[semgrep.passthrough]] - type = "raw" - target = "insecure.yml" - value = """ -rules: -- id: "insecure" - patterns: - - pattern: "func insecure() {...}" - message: | - Insecure function insecure detected - metadata: - cwe: "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor" - severity: "ERROR" - languages: - - "go" - """ - - [[semgrep.passthrough]] - type = "url" - value = "https://semgrep.dev/c/p/gosec" - target = "gosec.yml" -``` - -##### Interpolation - -The code snippet below shows an example configuration that uses an environment -variable `$GITURL` to access a private repositories with a Git URL. The variable contains -a username and token in the `value` field (for example `https://user:token@url`). -It does not explicitly store credentials in the configuration file. To reduce the risk of leaking secrets through created paths and files, use this feature with caution. - -```toml -[semgrep] - description = 'semgrep custom rules configuration' - targetdir = "/sgrules" - interpolate = true - - [[semgrep.passthrough]] - type = "git" - value = "$GITURL" - ref = "refs/remotes/origin/main" -``` - -##### Configure the append mode for passthroughs - -To append data to previous passthroughs, use the `append` mode for the -passthrough types `file`, `url`, and `raw`. - -Passthroughs in `override` mode overwrite files -created when preceding passthroughs in the chain find a naming -collision. If `mode` is set to `append`, a passthrough appends data to the -files created by its predecessors instead of overwriting. - -In the below Semgrep configuration,`/sgrules/insecure.yml` assembles two passthroughs. The rules are: - -- `insecure` -- `secret` - -These rules add a search pattern to the analyzer and extends Semgrep capabilities. - -For passthrough chains we recommend that you enable validation. To enable validation, -you can either: - -- set `validate` to `true` - -- set a passthrough `validator` to `xml`, `json`, `yaml`, or `toml`. - -```toml -[semgrep] - description = 'semgrep custom rules configuration' - targetdir = "/sgrules" - validate = true - - [[semgrep.passthrough]] - type = "raw" - target = "insecure.yml" - value = """ -rules: -- id: "insecure" - patterns: - - pattern: "func insecure() {...}" - message: | - Insecure function insecure detected - metadata: - cwe: "... - severity: "ERROR" - languages: - - "go" -""" - - [[semgrep.passthrough]] - type = "raw" - mode = "append" - target = "insecure.yml" - value = """ -- id: "secret" - patterns: - - pattern-either: - - pattern: "$MASK = \"...\"" - - metavariable-regex: - metavariable: "$MASK" - regex: "(password|pass|passwd|pwd|secret|token)" - message: | - Use of Hard-coded Password - cwe: "..." - severity: "ERROR" - languages: - - "go" -""" -``` - ### False Positive Detection **(ULTIMATE)** > Introduced in GitLab 14.2. @@ -706,6 +330,8 @@ False positive detection is available in a subset of the [supported languages](# - Ruby, in the Brakeman-based analyzer + + ### Advanced vulnerability tracking **(ULTIMATE)** > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5144) in GitLab 14.2. @@ -829,7 +455,7 @@ spotbugs-sast: dependencies: - build variables: - MAVEN_REPO_PATH: ./.m2/repository + MAVEN_REPO_PATH: $CI_PROJECT_DIR/.m2/repository COMPILE: "false" artifacts: reports: @@ -907,7 +533,7 @@ Some analyzers make it possible to filter out vulnerabilities under a given thre | CI/CD variable | Default value | Description | |------------------------------|--------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `SAST_EXCLUDED_PATHS` | `spec, test, tests, tmp` | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. You might need to exclude temporary directories used by your build tool as these can generate false positives. To exclude paths, copy and paste the default excluded paths, then **add** your own paths to be excluded. If you don't specify the default excluded paths, you will override the defaults and _only_ paths you specify will be excluded from the SAST scans. | +| `SAST_EXCLUDED_PATHS` | `spec, test, tests, tmp` | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs (see [`doublestar.Match`](https://pkg.go.dev/github.com/bmatcuk/doublestar/v4@v4.0.2#Match) for supported patterns), or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. You might need to exclude temporary directories used by your build tool as these can generate false positives. To exclude paths, copy and paste the default excluded paths, then **add** your own paths to be excluded. If you don't specify the default excluded paths, you will override the defaults and _only_ paths you specify will be excluded from the SAST scans. | | `SEARCH_MAX_DEPTH` | 4 | SAST searches the repository to detect the programming languages used, and selects the matching analyzers. Set the value of `SEARCH_MAX_DEPTH` to specify how many directory levels the search phase should span. After the analyzers have been selected, the _entire_ repository is analyzed. | | `SAST_BANDIT_EXCLUDED_PATHS` | | Comma-separated list of paths to exclude from scan. Uses Python's [`fnmatch` syntax](https://docs.python.org/2/library/fnmatch.html); For example: `'*/tests/*, */venv/*'` | | `SAST_BRAKEMAN_LEVEL` | 1 | Ignore Brakeman vulnerabilities under given confidence level. Integer, 1=Low 3=High. | @@ -963,6 +589,8 @@ removed, or promoted to regular features at any time. Experimental features available are: - Enable scanning of iOS and Android apps using the [MobSF analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/). +- Disable the following rules in the [Semgrep analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) that are known to cause a high rate of false positives: + - [`eslint.detect-object-injection`](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/6c4764567d9854f5e4a4a35dacf5a68def7fb4c1/rules/eslint.yml#L751-773) #### Enable experimental features diff --git a/doc/user/application_security/secret_detection/index.md b/doc/user/application_security/secret_detection/index.md index 02d50b0a857..93c32f998fa 100644 --- a/doc/user/application_security/secret_detection/index.md +++ b/doc/user/application_security/secret_detection/index.md @@ -200,7 +200,7 @@ Secret Detection can be customized by defining available CI/CD variables: | CI/CD variable | Default value | Description | |-----------------------------------|---------------|-------------| -| `SECRET_DETECTION_EXCLUDED_PATHS` | "" | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec` ). Parent directories also match patterns. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225273) in GitLab 13.3. | +| `SECRET_DETECTION_EXCLUDED_PATHS` | "" | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs (see [`doublestar.Match`](https://pkg.go.dev/github.com/bmatcuk/doublestar/v4@v4.0.2#Match) for supported patterns), or file or folder paths (for example, `doc,spec` ). Parent directories also match patterns. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225273) in GitLab 13.3. | | `SECRET_DETECTION_HISTORIC_SCAN` | false | Flag to enable a historic Gitleaks scan. | | `SECRET_DETECTION_IMAGE_SUFFIX` | "" | Suffix added to the image name. If set to `-fips`, `FIPS-enabled` images are used for scan. See [FIPS-enabled images](#fips-enabled-images) for more details. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/355519) in GitLab 14.10. | | `SECRET_DETECTION_LOG_OPTIONS` | "" | [`git log`](https://git-scm.com/docs/git-log) options used to define commit ranges. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/350660) in GitLab 15.1.| @@ -224,9 +224,9 @@ You can customize the default secret detection rules provided with GitLab. Ruleset customization supports the following capabilities that can be used simultaneously: -- [Disabling predefined rules](index.md#disable-predefined-analyzer-rules). -- [Overriding predefined rules](index.md#override-predefined-analyzer-rules). -- Modifying the default behavior of the Secret Detection analyzer by [synthesizing and passing a custom configuration](index.md#synthesize-a-custom-configuration). +- [Disabling predefined rules](#disable-predefined-analyzer-rules). +- [Overriding predefined rules](#override-predefined-analyzer-rules). +- Modifying the default behavior of the Secret Detection analyzer by [synthesizing and passing a custom configuration](#synthesize-a-custom-configuration). Customization allows replacing the default secret detection rules with rules that you define. @@ -334,7 +334,7 @@ To create a custom configuration, you can use passthrough chains. ``` Passthroughs can also be chained to build more complex configurations. -For more details, see [SAST Customize ruleset section](../sast/index.md#customize-rulesets). +For more details, see [SAST Customize ruleset section](../sast/customize_rulesets.md). ### Logging level diff --git a/doc/user/application_security/vulnerabilities/index.md b/doc/user/application_security/vulnerabilities/index.md index f0ac01000ef..ad397c3fe04 100644 --- a/doc/user/application_security/vulnerabilities/index.md +++ b/doc/user/application_security/vulnerabilities/index.md @@ -152,8 +152,8 @@ includes a **Resolve with merge request** option. The following scanners are supported by this feature: - [Dependency Scanning](../dependency_scanning/index.md). - Automatic Patch creation is only available for Node.js projects managed with - `yarn` when [FIPS mode](../../../development/fips_compliance.md#enable-fips-mode) is disabled. + Automatic patch creation is only available for Node.js projects managed with + `yarn`. Also, Automatic patch creation is only supported when [FIPS mode](../../../development/fips_compliance.md#enable-fips-mode) is disabled. - [Container Scanning](../container_scanning/index.md). To resolve a vulnerability, you can either: diff --git a/doc/user/application_security/vulnerability_report/pipeline.md b/doc/user/application_security/vulnerability_report/pipeline.md index 14c13f74a5e..32916f4c9c7 100644 --- a/doc/user/application_security/vulnerability_report/pipeline.md +++ b/doc/user/application_security/vulnerability_report/pipeline.md @@ -60,14 +60,14 @@ To download a security scan output: ## Scan results This shows a list of the combined results for all security report artifacts. The filters work like the -[Vulnerability Report filters](index.md#vulnerability-report-filters), but they are limited to **Severity** and **Tool**, with +[Vulnerability Report filters](index.md#vulnerability-report-filters), but they are limited to **Severity** and **Tool**, with the addition of a **Hide dismissed** toggle. -When you review the vulnerability findings reported in the pipeline, you can select one or more entries for dismissal, +When you review the vulnerability findings reported in the pipeline, you can select one or more entries for dismissal, similar to [Dismissing a vulnerability](index.md#dismissing-a-vulnerability) in the Vulnerability Report. When you merge the branch corresponding to the pipeline into the default branch, all reported findings are combined into -the [Vulnerability Report](index.md). Scan results in pipelines executed on the default branch are +the [Vulnerability Report](index.md). Scan results in pipelines executed on the default branch are incorporated once the pipeline finishes. | Existing vulnerability status | Dismissed in pipeline? | New vulnerability status | |
