## Database for configuration ### Benefits - instant application of changes to settings instead of not applying to all pre-existing MRs - bulk application across tags, groups, workspaces - Better able to tell when something is configured, or not - examples: https://gitlab.com/gitlab-org/gitlab/-/issues/297530 ## Database for found items ### Benefits - consistent load for Dependency list page - no need to parse an artifact, and we can have it show all in specific branches that are merged in the future (i.e. see all in projects vs see all in specific branch / main) - Able to alert on old (prior found) dependencies for new vulnerability database entries (could be done then as a scheduled job not pipeline? - Able to alert of old or EOL dependencies found new and prior - improved experience (consistency) with showing what is "all" vs "new" and "new since" or "new in" i.e. they could check ALL found dependencies ALL branches (incl main). ALL found and merged dependences ALL branches (incl main). ALL found dependencies in branch X (main/default is a choice). ALL found and merged dependences in branch X (main/default is a choice). ## Database content Just spitballing feel free to change ### Secure SCA Database Contents - By workspace (customer)? (shared key) - added to project (shared key) - Dependency ID (shared key) - added in branch (array? b/c could be multiple branches) - FIRST added on date (would this be useful) - MOST RECENT added on date (assume needed if branch array) - Removed date (date when removed from project, all branches) - merged? true/false in the above for each project a D is in there would be an entry, is that too inefficient? we could make project an array and then have another table for branches and dates? Concern, many branches could add it but only one branch gets merged? we may not be sure which branch they consider prod? they may have multiple prod branches? so i want to know what dependencies are merged, and not, and into where ### GitLab new database for tracking dependencies? - Dependency ID (guid) - Dependency name - Dependency version - source (array) - EOL? True/False - EOL Date (date) - More recent version? True/False - content last updated (i.e. last time we checked) date Maybe coordinate this with @trizzi so it contains things they need as well (assuming they would make their own DB like our other DB that references the IDs)