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:
- Prepare a new version of the Security Report Schemas where the
cve
fields are removed, and where theMODEL
is bumped gitlab-org/security-products/security-report-schemas!100 (merged) - Release this new version of the schemas #363134 (closed)
- Update all projects producing a report with these fields to remove them and bump the version of the report they produce #209850 (comment 1032143625)
- Stop ingesting the
cve
fields #368371 (closed)
The analyzers in the following categories have to be updated:
- Dependency Scanning; covered by Dependency Scanning uses Security Report Schema... (&8409 - closed)
- SAST
- DAST
- Fuzzing
- Container Scanning
-
Cluster Image Scanning#364369 (comment 972298080)
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 thecve
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 newid
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