Data from Container Scanning reports should be in the database, and consumers should use that backend instead of the raw JSON report.
This is required in order to present Container Scanning results in a group-level Security Dashboard.
Further details
If consumers need to elaborate or aggregate data from many reports (e.g., group level features) it is not possible to use artifacts for that without heavily affecting performances.
Proposal
Save Container Scanning reports in the database when they are collected from the Runner. Make this information available to the frontend via backend calls.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
We only process the JSON array .vulnerabilities. Other top-level keys of the JSON artifact like .image and .unapproved can be ignored. See mutations.js.
Conversely, the generated artifact (ensuring backward compatibility) will only contain .vulnerabilities. The alerts will be a JSON array made of all affections.metadata returned by a query.
The tool is always the same, so tools.name and others are hardcoded by the parser. Let's set tools.name and external_id to Clair and clair, respectively. The tool is fetched from the DB by its external_id.
affections.metadata_format is a constant set by the parser, something like clair.json.
parseSastContainer shows how to extract the vulnerability name (.vulnerability key) and build the fingerprint for the affection.
To be discussed: I'm not sure .vulnerability (the CVE id) can be used as the external_id. We may have to build an id using vulnerabilityfeaturename, featureversion and namespace.