Expose vendor assessment of an advisory in Container Scanning results
Release notes
Problem to solve
Vendors are doing an assessment of published advisories impacting components of their distributed software. E.g. RedHat provides an assessment and its own CVSS score for CVEs affecting software bundled in their distribution.
GitLab, as a company, leverages this data to improve the signal to noise ratio of Container Scanning results and help development teams focusing on actionable findings. Some of our internal tools also uses this information to add metadata to created security issues (e.g. Vulnerability::Vendor PackageWill Not Be Fixed).
Today though, this information is not provided in the Security report artifact generated by the Container Scanning analyzer, even though this information is available in the advisory data.
With Allow filtering of container scan findings wher... (#423954 - closed) we've added an option to filter findings based on this vendor status but this approach actually removes them from the report. In some cases we would prefer to still have the findings present in the report but with this information exposed as additional metadata. This would allow specific workflows like FedRAMP reporting for instance to get the full list of detected findings but easily distinguish the non-actionable ones.
Proposal
Add vendor assesment status as vulnerability metadata in the JSON security report artifact generated by Container Scanning.
Implementation Plan
The chosen implementation is to expose the vendor status in the existing details
properties of the security report:
- this is the boring solution and the fastest approach. There is no update needed on the security schema, the information is available in the JSON report artifact and automatically displayed in the UI on the vulnerability page (in the
Evidence
section). - the downside is the limited control over that property and its values. There is no enforcement by the schema and we can't prevent the data to be displayed in the UI. These are accepted limitations.
Steps:
-
update the templates we use to convert the scanner's native output into a format that is closer to our security report. -
Trivy - property name:
Results[].Vulnerabilities[].Status
- possible values (source): unknown, not_affected, affected, fixed, under_investigation, will_not_fix, fix_deferred, end_of_life
- property name:
-
GrypeSupport for Grype will be removed in 17.0, there is no need to implement this.property name:matches[].Vulnerability.fix.state
possible values (source): fixed, not-fixed, wont-fix, unknown
-
-
refactor how we've implemented the details
property to merge the content ofdetails
property if already present. -
update or add relevant specs
NB: There seems to be some edge cases when the provided fix status is not accurate. See https://gitlab.com/gitlab-org/gitlab/-/issues/433596#note_1710051681 (Internal) for instance.
See initial proposal
Two possible approaches to expose this information:
- Expose the vendor status in the existing
details
properties of the security report.- Pros: This is the boring solution and the fastest approach. There is no update needed on the security schema, the information is available in the JSON report artifact and automatically displayed in the UI on the vulnerability page (in the
Evidence
section). - Cons: The downside is the limited control over that property and its values. There is no enforcement by the schema and we can't prevent the data to be displayed in the UI.
- Pros: This is the boring solution and the fastest approach. There is no update needed on the security schema, the information is available in the JSON report artifact and automatically displayed in the UI on the vulnerability page (in the
- Expose the vendor status in a dedicated property of the security report.
- Pros: This allows for more control over this data and how it is processed by the rails application. We can normalize and validate the provided values, define more reliable behaviors in the backend (e.g. policies) based on this information and define exactly how we want to display it.
- Cons: This requires more work as we likely have to define a common property that will work for all (known) use cases accross scanners and update the security report schema accordingly. As we might want to normalize the possible values this also requires more work in the analyzer and potentially some maintenance later as scanner vendors update these values or change their behavior. This also requires additional Frontend work if we want to display this information in the UI.
The vendor status is available for both Trivy and Grype scanners but with some differences:
- Trivy
- property name:
Results[].Vulnerabilities[].Status
- possible values (source): unknown, not_affected, affected, fixed, under_investigation, will_not_fix, fix_deferred, end_of_life
- property name:
- Grype
- property name:
matches[].Vulnerability.fix.state
- possible values (source): fixed, not-fixed, wont-fix, unknown
- property name:
This feature can be implemented by updating the templates we use to convert the scanner native output into a format that is closer to our security report.
Depending on the chosen approach and if any normalization of the values is desired, this might need additional postprocessing using the Vulnerability class.
NB: if approach 1 is chosen we'll certainly have to revisit how we've implemented the details
property.