Drop support for `cve` property in JSON common security report format

Problem to solve

Once we've replaced the cve property with id and other properties for feedback, we can drop support for this obsolete field and remove it from the common report format.

Further details

Currently all analyzer projects generate a .vulnerabilities[].cve field in their JSON reports, but it's been replaced with .vulnerabilities[].id, and it won't be used for vulnerability feedback anymore. .remediations[].fixes[].cve has only been replaced with .remediations[].fixes[].id, and is no longer needed to link vulnerability findings to their remediations. See #36777 (closed) and #205489 (closed).

Proposal

Make the cve fields optional in the schema, update the analyzers to stop generating these fields, and ultimately update the schema to remove the cve fields altogether. The Rails backend also needs to be updated so that it doesn't fall back on the cve field when the id field is missing.

GitLab rails application

The rails application still uses cve in a few places. Most of them seem to be optional but it would still be best to remove these (and their specs and fixtures) first so as not to get any unpleasant surprises:

  • ee/lib/gitlab/ci/parsers/security/common.rb
  • ee/lib/gitlab/ci/parsers/security/formatters/dast.rb
  • ee/lib/gitlab/ci/reports/security/identifier.rb
  • ee/app/services/security/store_report_service.rb
  • ee/app/services/vulnerability_exports/exporters/csv_service.rb
  • ee/app/controllers/projects/vulnerability_feedback_controller.rb
  • ee/app/models/vulnerabilities/finding.rb
  • ee/app/models/vulnerabilities/identifier.rb

The one seemingly non-optional place I found in the app was in the frontend code:

  • ee/app/assets/javascripts/security_dashboard/store/constants.js

Implementation plan

Note: The rails application should be updated first as per discussion in section above.

Remove the cve fields from .vulnerabilities and .remediations[].fixes in the following steps:

  1. Prepare a new version of the Security Report Schemas where the cve fields are removed, and where the MODEL is bumped gitlab-org/security-products/security-report-schemas!100 (merged)
  2. Release this new version of the schemas #363134 (closed)
  3. Update all projects producing a report with these fields to remove them and bump the version of the report they produce #209850 (comment 1032143625)
  4. Stop ingesting the cve fields #368371 (closed)

The analyzers in the following categories have to be updated:

Permissions and Security

N/A

Documentation

Documentation for docs.gitlab.com needs to be updated and any mention of z`

There's no need to update Secure Scanner Integration guide because it doesn't mention the cve field.

There's no need to update the Report JSON format sections of the docs because the the description of the report file structure nodes and their meaning will soon be removed. TODO: link to MR.

Availability & Testing

Analyzer projects are tested using QA jobs.

Risks to be considered:

  • Users run an old version of the Rails backend with a version of the analyzers that don't generate the cve fields. The backend wouldn't be able to process the security reports. This can be preventing by bumping the MAJOR version of the analyzers, or by pinning the MINOR, or simply by keeping the code that handles the cve field in the Rails backend.
  • Users run a new version of the Rails backend (that ignores the cve field) with old versions of the analyzers that don't generate the new id field. That can't possibly happen unless users run a GitLab instance behind a Docker proxy, and don't update the Docker images of the analyzers on a regular basis.

What does success look like, and how can we measure that?

Not a single occurrence of the cve field in the codebase, and CVE truly means Common Vulnerabilities and Exposures.

What is the type of buyer?

N/A

Edited by Fabien Catteau