## Proposal Vulnerabilities are added to or removed from a project whenever its SBOMs change. ### Iteration 1  In the initial iteration, the focus will be on re-using the existing security report ingestion foundation. The security report ingestion process is extensive and has grown overtime to meet the requirements of the various secure analyzers. Creating the required events, worker, and services to emulate its capabilities is a complex and large task that will take some time before it reaches a viable state. Because of this, the initial iteration will instead interface with the security report ingestion via synthetic security reports - specifically dependency scanning and container scanning reports. At a high level overview, the following will happen: 1. A pipeline with a job that creates an SBoM report completes. 1. The worker responsible for storing scan results runs if the artifact file type matches a known security report. This will be true for `cyclonedx` reports as they'll now be considered a security report file. 1. The worker iterates through all the eligible artifact types. Traditionally, these would be reports uploaded to object storage. For the `cyclonedx` artifact we will synthesize a security report on the fly. 1. The security report will then be passed further along to the service that [stores the scan results](https://gitlab.com/gitlab-org/gitlab/-/blob/35cd732221dfbe80b96a34f06f3693dfe17920f8/ee/app/services/security/store_scan_service.rb#L54-62). The following tradeoffs were considered: #### Benefits - We use a common interface to share results - the security report. - The changes to other areas of the product are minimized. For example, the MR security widget would not be impacted by this change. #### Risks - Performance issues in projects with many components and/or advisories. ### Iteration 2 TODO ## DRI @zmartins ## Implementation Plan **Scan after SBOM ingestion** - add worker to encapsulate the scan (parametrized by `pipeline`) - https://gitlab.com/gitlab-org/gitlab/-/issues/395704+ - after SBOM ingestion is complete, trigger a scan of this pipeline - add service for doing the scanning - https://gitlab.com/gitlab-org/gitlab/-/issues/371055+ - add finder which iterates over `sbom_component_occurrences` for the pipeline - for each occurrence - match `occurrence.component_name` against `advisories.package_name` - for each matching advisory (this happens in ruby - see https://gitlab.com/gitlab-org/gitlab/-/issues/363073#note_972557731 for more info) - test advisory's affected range against `occurrence.component_version` - https://gitlab.com/gitlab-org/gitlab/-/issues/371995+ - if there is a match add `vulnerable_component_version` ## Limitations - Go pseudo-versions aren't scanned. This might result in false negatives. See https://gitlab.com/groups/gitlab-org/-/epics/8025#note_1466442556 - It only scans CycloneDX 1.4 JSON SBOMs that provide the GitLab-specific properties. See https://gitlab.com/gitlab-org/gitlab/-/issues/418326#note_1476686688 - It doesn't provide [dependency paths](https://docs.gitlab.com/ee/user/application_security/dependency_list/#dependency-paths). This is related to https://gitlab.com/gitlab-org/gitlab/-/issues/366168+, but that closing that issue isn't sufficient to get the feature back. - It uses a Ruby gem to compare versions to affected ranges, instead of native code. This might result in both false positives and false negatives. This will be addressed by https://gitlab.com/gitlab-org/gitlab/-/issues/386070+.