[SCB-Bot] Upgraded trivy from 0.19.2 to 0.20.2

[github-actions]

This is an automated Pull Request by the SCB-Bot. It upgrades trivy from 0.19.2 to 0.20.2

[Ilyesbdlala]

Changes have to be made to trivy's parser.js. This is due to the new json schema : Info here.

[malexmave]

Thanks for the heads up. I'll give this a shot, probably tomorrow, if no one else wants to claim it first.

[malexmave]

While rewriting the parser, I found that the location for each of the found vulnerabilities is set to the name of the scanned image. The individual Result objects also contain a Target that point to the exact place where the issue is (e.g., a specific dependency file). To maintain the same output format as before the change, I have not changed this - should I make the change / add a new key to the results? My preferred solution would be to use the location key to designate the exact place the issue was found (the Target from the result object) and then also include a scan_target or something similar that contains the ArtifactName, but that would be a breaking change for anyone who depends on our findings...

I have also removed most of the test cases since they all seem to test the same (a scan of a docker image) and have instead introduced a result from a repository scan. Was there any specific reason why there were so many similar test case? If so, I can bring them back - it just means re-running all of the analyses for the example cases and putting the JSONs in the repo + updating the snapshots.

[malexmave]

I have added two more things to the documentation: the extra parameters required to scan things other than docker images (#796) and some information on using the client-server mode to avoid issues with GitHub rate limiting on rule downloads. With this, I consider the PR ready for review and merge, aside from the questions raised above about the output format and unit tests.

[Ilyesbdlala]

While rewriting the parser, I found that the location for each of the found vulnerabilities is set to the name of the scanned image. The individual Result objects also contain a Target that point to the exact place where the issue is (e.g., a specific dependency file). To maintain the same output format as before the change, I have not changed this - should I make the change / add a new key to the results? My preferred solution would be to use the location key to designate the exact place the issue was found (the Target from the result object) and then also include a scan_target or something similar that contains the ArtifactName, but that would be a breaking change for anyone who depends on our findings...

I think a custom attribute as defined here and/or including it in the description field are more appropriate for the ArtifactName variable. The location attribute is a required field in the finding, and it doesn't make sense to make it something scanner-specific (artifact/dependency name) or something that not all scanners can provide (the exact place where the issue is). I always thought of the location attribute as an indication of what the finding pertains to. And then the user can then inspect the finding to find more information in the other attributes (including the custom ones)
But having a non-standarized location field is a known issue (#619) that we decided not to address for lack of feasible solutions.

Pertaining to #796, I agree. I think a documentation warning and adding some repo scans examples are the best we can do for now. It's a Trivy related issue. Silently ignoring parameters seems like something that will always cause issues.

[malexmave]

I have added the extra metadata, so this should be ready to review and merge from my side.