Add a new `id` property to replace the legacy `cve` in JSON common security report format
Problem to solve
The current JSON common report format we use for security reports needs improvements, particularly as we are encouraging and adding third-party security vendors integrations. Specifically, the cve property is confusing, as it does not actually contain CVE data, and as a result it should be removed. Anyone leveraging the cve property in the security reports, with custom scripts or as an integrator into our Secure features, you will need to stop using the cve property.
Intended users
Further details
Based on feedback from vendors testing integrations, the cve property is confusing because it is not really a CVE; this is a compare key really. Also, many types of findings won't be CVEs so this further confuses the issue.
Currently, the common library uses the CompareKey to sort vulnerabilities having the same severity, and to reference a vulnerability from a remediation (auto-remediation result). It also provides code to automatically set the compare key of a vulnerability reported by Dependency Scanning.
Auto-remediation for Dependency Scanning has been implemented in Gemnasium, and currently it only supports Yarn. See gitlab-org/security-products/analyzers/gemnasium!5 (diffs)
Auto-remediation for Container Scanning is currently under review. See gitlab-org/security-products/analyzers/klar!18 (merged)
Proposal
Deprecate the cve property, replace it with a id to be used in the remediation.fixes as a reference for which vulnerabilities get fixed by that remediation.
Implementation plan
-
update the common library; see gitlab-org/security-products/analyzers/common!79 (merged) - add new, automatically generated
idfield when encoding vulnerabilities to JSON - add code comments to deprecate
Issue.CompareKeyandRef.CompareKey, but keep encoding these fields to JSON - add new
idfield to the vulnerability references, in remediation object
- add new, automatically generated
-
update all analyzers to the new version of the commonlibrary, so that they generate theidfield when encoding vulnerabilities to JSON - update analyzers that implement auto-remediation so that they reference vulnerabilities by id
-
update shared templates used during QA for SAST and DS, and ignore the idwhen comparing the vulnerabilities; see gitlab-org/security-products/ci-templates!85 (merged)
Not covered in this issue:
- updating the Rails backend to handle the new
idproperty: #209851 (closed) - migrate the vulnerability feedback to not use
cve: #205489 (closed).
Permissions and Security
N/A
Documentation
-
Update Reports JSON Formatsection in user documentation of DS, CS, and SAST !29133 (merged) -
Update Secure Scanner Integration documentation !29146 (merged)
Testing
This requires E2E integration, to make sure the Rails backend can process new reports where the cve field has been removed. We've got to make sure that auto-remediation results are properly presented in the GitLab UI, for the expected vulnerabilities. This is covered by #209851 (closed) and #205489 (closed).
What does success look like, and how can we measure that?
New version of JSON common security report format that includes replacement for cve field. Ideally, new version continues to accept cve instead of new field.
We can have at least one interested security vendor update their integration successfully to use the new field.