Skip to content

[meta] Feature name: Continuous Vulnerability Scanning vs SBOM Vulnerability Scanner

Why are we doing this work

As brought-up by @gonzoyumo in &8026 (comment 2028976783), our Continuous Vulnerability Scanning feature is currently conflating two principles: WHAT is scanned, and WHEN it's scanned:

  • WHEN an Advisory is published:
    • Components (dependencies) recorded in the postgres DB are scanned
  • WHEN an SBOM is ingested:
    • Modified components (dependencies) reported in a CDX artifact are scanned

Proposal

See previous proposal Give the functionality different names. Example:
  • Continuous Vulnerability Scanning: scans components already known to GitLab when an advisory is published or updated.
  • SBOM Vulnerability Scanning: scans components present in an artifacts:reports:cyclonedx report.

There are other considerations that haven't been captured here yet, such as the suggested name. If/when we allow components to be managed via an interface other than a CI artifact, "SBOM scanning" doesn't make much sense, but still falls under "Dependency Scanning".

Fondamentally, the feature are still Container Scanning and Dependency Scanning and the difficulty resides more in explaining the transistion to the new implementation based on SBOM reports rather than CI based execution. Though, this is just a temporary situation and eventually the SBOM based implementation will be the only one available, fulfilling the same underlying goal. As such it's been decided to keep the focus on the core features which are Container Scanning and Dependency Scanning, and simply highlight the various workflows available for them (CVS vs full scan on sbom changes).

As we are also likely to offer granular enablement/disablement option for these features, it makes even more sense to distinguish them.

  • revisit the organization of the documentation and split the existing CVS page into:
    • Continuous Container Scanning (under Container Scanning)
    • Continuous Dependency Scanning (under Dependency Scanning)
    • Optional: keep the existing CVS page as a placeholder to reference the new pages?
  • revisit the DS documentation page to better handle the migration between the existing and the new feature implemenation

Relevant links

Example of confusion: #477092 (comment 2033828543)

Non-functional requirements

  • Documentation:
  • Feature flag:
  • Performance:
  • Testing:

Implementation plan

/assign @

/epic &

-->

Verification steps

Edited by Olivier Gonzalez