Follow-up from "Store container scanning results in the database"
The location_fingerprint
must not be a static value but generated from a meaningful set of properties that reflect the location of the vulnerability.
The following discussion from !8797 (merged) should be addressed:
-
@gonzoyumo started a discussion: (+9 comments) About the location, the goal is to provide data to be able to identify the same vulnerability in another execution of the report (e.g. in next pipeline).
In the case of container scanning, the location exists but is of a different nature than for SAST or Dependency Scanning.
I'd suggest to generate the following structure:
{ layer: vulnerability["namespace"], dependency: { package: { name: vulnerability["featurename"] }, version: vulnerability["featureversion"] } }
This will partially reuse the
dependency
struct we introduced in common for dependency scanning. I'm not 100% suredependency
is a good fit here though... The impacted item reported by clair is a library present in a specific layer of the image. This could be considered as a dependency by extension but it's not like it was explicitly declared as such within the project (like we do for Rubygems). I'd like to get @fcatteau opinion on this.Otherwise we can use a new struct:
{ layer: vulnerability["namespace"], library: { name: vulnerability["featurename"] version: vulnerability["featureversion"] } }
Also, in a recent discussion @fcatteau also pointed that we "could" link this with a file in the repo too: the
Dockerfile
. Though this is not provided by the tool and a project could have different Dockerfiles so I'd rather not deal with this yet.I also wonder about the word
layer
vsnamespace
, not sure what is the most meaningful in Docker world, but I think layer is more used🤔