Migrate old container scanning location_fingerprint to new ones and switch using new location_fingerprint
Problem to solve
Following the Design conclusion of Allow Container Scanning to scan multiple container images for a single change we need to update the way we store the location fingerprint for Container Scanning findings
Intended users
Internal: devopssecure & ~"devops::defend"
Further details
Proposal
This is second and third phase for rolling out new location_fingerprint. First phase has to be completed before starting to this one.
-
Create background migration to update all fingerprints to v2
-
After migrations completed, we have new
location_fingerprint
for existing container scanning vulnerabilities and new vulnerabilities are saved with new location_fingerprint. Update StoreReportsService and make new fingerprint default fingerprint.
Implementation Plan
-
Add conditional index to container scanning vulnerabilities. -
Migrate all existing container scanning vulnerabilities in the DB to use the above value -
Loop through each entry in the vulnerability_occurrences
table and copy thedocker_image_without_tag
andpackage_name
from theraw_metadata
column, and insert it into thelocation_fingerprint
column
-
-
Update StoreReportsService make new fingerprint default fingerprint. -
Manually test to ensure multiple Docker images can be scanned with the same vulnerability and they show up as separate vulnerabilities
Documentation
Availability & Testing
The underlying change to be tested by engineer using a unit test. SET to look at setting up an end to end test as per gitlab-org/quality/testcases#991
What does success look like, and how can we measure that?
Two Container Scanning findings with the same primary identifier (CVE) but coming from different docker images (image name must be different, not only the tags) are successfully kept in the database.
What is the type of buyer?
Is this a cross-stage feature?
@matt_wilson this is relevant for Category:Vulnerability Management of groupthreat insights.