diff options
Diffstat (limited to 'doc/development/sec/index.md')
| -rw-r--r-- | doc/development/sec/index.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/doc/development/sec/index.md b/doc/development/sec/index.md index 4ed0eadd92f..5ac5118aae8 100644 --- a/doc/development/sec/index.md +++ b/doc/development/sec/index.md @@ -85,7 +85,7 @@ a critical component to both describing and tracking vulnerabilities. In most other cases, the `identifiers` collection is unordered, where the remaining secondary identifiers act as metadata for grouping vulnerabilities (see [Analyzer vulnerability translation](#analyzer-vulnerability-translation) below for the exception). -Any time the primary identifier changes and a project pipeline is re-run, ingestion of the new report will “orphan” the previous DB record. +Any time the primary identifier changes and a project pipeline is re-run, ingestion of the new report will "orphan" the previous DB record. Because our processing logic relies on generating a delta of two different vulnerabilities, it can end up looking rather confusing. For example: [!Screenshot of primary identifier mismatch in MR widget](img/primary_identifier_changed_v15_6.png) @@ -95,14 +95,14 @@ After being [merged](../integrations/secure.md#tracking-and-merging-vulnerabilit ### Guiding principles for ensuring primary identifier stability - A primary identifier should never change unless we have a compelling reason. -- Analyzer supporting vulnerability translation must include the legacy primary identifiers in a secondary position to prevent “orphaning” of results. +- Analyzer supporting vulnerability translation must include the legacy primary identifiers in a secondary position to prevent "orphaning" of results. - Beyond the primary identifier, the order of secondary identifiers does not matter. - The identifier is unique based on a combination of the `Type` and `Value` fields (see [identifier fingerprint](https://gitlab.com/gitlab-org/gitlab/-/blob/v15.5.1-ee/lib/gitlab/ci/reports/security/identifier.rb#L63)). - If we change the primary identifier, rolling back analyzers to previous versions will not fix the orphaned results. The data previously ingested into our database is an artifact of previous jobs with few ways of automating data migrations. ### Analyzer vulnerability translation -In the case of the SAST Semgrep analyzer, there is a secondary identifier of particular importance: the identifier linking the report’s vulnerability +In the case of the SAST Semgrep analyzer, there is a secondary identifier of particular importance: the identifier linking the report's vulnerability to the legacy analyzer (that is, bandit or ESLint). To [enable vulnerability translation](../../user/application_security/sast/analyzers.md#vulnerability-translation) |