diff options
Diffstat (limited to 'doc/development/integrations')
| -rw-r--r-- | doc/development/integrations/jenkins.md | 2 | ||||
| -rw-r--r-- | doc/development/integrations/secure.md | 32 |
2 files changed, 15 insertions, 19 deletions
diff --git a/doc/development/integrations/jenkins.md b/doc/development/integrations/jenkins.md index f430fc380b1..bb541d26df2 100644 --- a/doc/development/integrations/jenkins.md +++ b/doc/development/integrations/jenkins.md @@ -24,7 +24,7 @@ brew services start jenkins GitLab does not allow requests to localhost or the local network by default. When running Jenkins on your local machine, you need to enable local access. 1. Log into your GitLab instance as an administrator. -1. On the top bar, select **Menu > Admin**. +1. On the top bar, select **Main menu > Admin**. 1. On the left sidebar, select **Settings > Network**. 1. Expand **Outbound requests** and check the following checkboxes: diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md index 55e57a3c2ee..2c5dd1c0500 100644 --- a/doc/development/integrations/secure.md +++ b/doc/development/integrations/secure.md @@ -1,6 +1,6 @@ --- -stage: Protect -group: Container Security +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 --- @@ -254,7 +254,7 @@ Following the POSIX exit code standard, the scanner exits with 0 for success and Success also includes the case when vulnerabilities are found. When a CI job fails, security report results are not ingested by GitLab, even if the job -[allows failure](../../ci/yaml/#allow_failure). The report artifacts are still uploaded to GitLab and available +[allows failure](../../ci/yaml/index.md#allow_failure). The report artifacts are still uploaded to GitLab and available for [download in the pipeline security tab](../../user/application_security/vulnerability_report/pipeline.md#download-security-scan-outputs). When executing a scanning job using the [Docker-in-Docker privileged mode](../../user/application_security/sast/index.md#requirements), @@ -488,8 +488,8 @@ the risk. End-users interact with this field, whereas GitLab automatically proce ##### Identifiers The `identifiers` array describes the detected vulnerability. An identifier object's `type` and -`value` fields are used to tell if two identifiers are the same. The user interface uses the -object's `name` and `url` fields to display the identifier. +`value` fields are used to [tell if two identifiers are the same](../../user/application_security/vulnerability_report/pipeline.md#deduplication-process). +The user interface uses the object's `name` and `url` fields to display the identifier. We recommend that you use the identifiers the GitLab scanners already define: @@ -509,12 +509,10 @@ which is shared by some of the analyzers that GitLab maintains. You can [contrib new generic identifiers to if needed. Analyzers may also produce vendor-specific or product-specific identifiers, which don't belong in the [common library](https://gitlab.com/gitlab-org/security-products/analyzers/common). -The first item of the `identifiers` array is called the -[primary identifier](../../user/application_security/terminology/index.md#primary-identifier). -The primary identifier is particularly important, because it is used to +The first item of the `identifiers` array is called the +[primary identifier](../../user/application_security/terminology/index.md#primary-identifier), and +it is used to [track vulnerabilities](#tracking-and-merging-vulnerabilities) as new commits are pushed to the repository. -Identifiers are also used to [merge duplicate vulnerabilities](#tracking-and-merging-vulnerabilities) -reported for the same commit, except for `CWE` and `WASC`. Not all vulnerabilities have CVEs, and a CVE can be identified multiple times. As a result, a CVE isn't a stable identifier and you shouldn't assume it as such when tracking vulnerabilities. @@ -666,11 +664,14 @@ Users may give feedback on a vulnerability: GitLab tracks vulnerabilities so that user feedback is not lost when new Git commits are pushed to the repository. -Vulnerabilities are tracked using a combination of three attributes: +Vulnerabilities are tracked using a +[`UUIDv5`](https://gitlab.com/gitlab-org/gitlab/-/blob/1272957c4a55e616569721febccb685c056ca1e4/ee/app/models/vulnerabilities/finding.rb#L364-368) +digest, which is generated by a `SHA-1` hash of four attributes: - [Report type](#category) -- [Location fingerprint](#location) - [Primary identifier](#identifiers) +- [Location fingerprint](#location) +- Project ID Right now, GitLab cannot track a vulnerability if its location changes as new Git commits are pushed, and this results in user feedback being lost. @@ -678,12 +679,7 @@ For instance, user feedback on a SAST vulnerability is lost if the affected file is renamed or the affected line moves down. This is addressed in [issue #7586](https://gitlab.com/gitlab-org/gitlab/-/issues/7586). -In some cases, the multiple scans executed in the same CI pipeline result in duplicates -that are automatically merged using the vulnerability location and identifiers. -Two vulnerabilities are considered to be the same if they share the same [location fingerprint](#location) -and at least one [identifier](#identifiers). Two identifiers are the same if they share the same `type` and `id`. -CWE and WASC identifiers are not considered because they describe categories of vulnerability flaws, -but not specific security flaws. +See also [deduplication process](../../user/application_security/vulnerability_report/pipeline.md#deduplication-process). ##### Severity and confidence |