### Problem A customer on 17.1 getting the following error: ``` [Schema] Version 15.2.1 for report type dependency_scanning is unsupported, supported versions for this report type are: 15.0.0, 15.0.1, 15.0.2, 15.0.4, 15.0.5, 15.0.6, 15.0.7, 15.1.0, 15.1.1, 15.1.2. GitLab will attempt to validate this report against the earliest supported versions of this report type, to show all the errors but will not ingest the report [Schema] root is missing required keys: dependency_files ``` The content of the security report is not ingested. NB: the second error `root is missing required keys: dependency_files` should be discarded here. This error is reported due to current validation logic using the oldest vendored schema to validate a version that doesn't have any corresponding `MODEL.REVISION` found in the instance. In this case this led to validate the `15.2.1` report against `15.0.0`, which is a report we used before GitLab 17.0, and that was indeed requiring the `dependency_files` property. Since `17.0` we use schema `15.1.0` which no longer require this property. This is being addressed with https://gitlab.com/gitlab-org/gitlab/-/issues/497415+ ### Root cause **TLDR:** unless particular mechanisms are put in place in the Secure analyzers and CI templates, the schema version must stick to the same `MODEL.REVISION` for the whole year, until the next major release of GitLab. This has not been observed. [The security report schema versioning scheme is following SCHEMAVER](https://gitlab.com/gitlab-org/security-products/security-report-schemas#versioning-schemas), not SEMVER. So the versioning scheme is: `MODEL-REVISION-ADDITION` rather than `MAJOR.MINOR.PATCH` The schema validation process in place in the GitLab rails application does not have full forward capabability, and is only able to validate newer versions that matches the same `REVISION` number: **A `15.2.1` compatible report can be validated against schema `15.2.0` and be ingested if valid. But if the most recent version in the instance is `15.1.x` (not the same `REVISION`) the ingestion won't happen.** This can be confusing as in software engineering we mostly use semver, with which backward compatibility is expected up to the same `MAJOR` version (`MODEL` in schemaver). Additionally our security scanners are enabled via CI templates and the default configuration pulls the `MAJOR` image tag of the analyzer image. And when a new minor or patch version of an analyzer is released, the corresponding `MAJOR.MINOR.PATCH` docker image tag is created but it also ovverrides the existing `MAJOR.MINOR` and `MAJOR` image tags. **This means older instances will pull the new analyzer unless they manually pin the docker image tag used by the CI job.** #### What happened - In GitLab 17.0, we've published and vendored version `15.1.0` of the schema, which is what these instances will use to validate submitted reports. - During 17.1, 17.2, and 17.3 only the `ADDITION` (aka `PATCH`) version of the schema has been updated, ensuring old instances can still validate the newly emitted reports. - In GitLab 17.4 or 17.5 (TBC) the version `15.2.0` of the schema has been released which increases the `REVISION` version. - Somewhere around that time (TBC) secure analyzers have started to use this new version, sometimes transparently as they rely on a shared module to generate the report. - Self-managed instances of GitLab 17.1 to 17.4 (TBC) that started using these new analyzers outputting `15.2.x` schema version have seen the security report rejected due to the validation mechanism only ablo to validate report with schema up to `15.1.2`. ## Customer Impact Security Reports are not ingested, meaning no vulnerabilities are incorporated into the Vulnerability Management System Possibly all customers matching these criteria are impacted: - self-managed versions 17.0.0 to 17.4.1 - ultimate mostly but also premium and free for security scans available in these tiers - using an up to date analyzer image (default configuration) that output a report with schema `15.2.x` ### Affected security analyzers: - [x] Composition Analysis - [x] Dependency Scanning: :x: 15.2.1 - [x] Container Scanning: :white_check_mark: 15.1.1 ([source](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/blob/master/lib/gcs/converter.rb#L8)) - [x] OCS: :white_check_mark: (do not generate a security report, upload via internal API) - [x] Dynamic Analysis - [x] DAST: :white_check_mark: 15.0.4 - [x] API Security: :white_check_mark: 15.0.0 - [x] Static Analysis - [x] spotbugs: :white_check_mark: - [x] pmd-apex: :white_check_mark: - [x] kubesec: :white_check_mark: - [x] sobelow: :white_check_mark: - [x] GLAS: :x: 15.2.1 - [x] Secret Detection: :white_check_mark: 15.1.4 ### Duration - Dependency Scanning: from 2024-09-27_08:45 UTC (Release of [v5.7.1](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/releases/v5.7.1) to 2024-10-02_22:35 UTC (Release of [v5.7.3](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/releases/v5.7.3) - GLAS: from 2024-09-26_22:07 UTC (Release of [v1.0.16](https://gitlab.com/gitlab-org/security-products/analyzers/gitlab-advanced-sast/-/releases/v1.0.16) to 2024-10-02_22:41 UTC (Release of [v1.0.17](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/releases/v1.0.17) ## Workaround Customer affected by the bug can pin the impacted analyzers to an earlier patch version in the meantime. TODO list previously working versions: - Dependency Scanning: `5.7.0` - GLAS: `1.0.15`