CVS adds links to GLAD advisories

Release notes

Problem to solve

Unlike the legacy Dependency Scanning (DS) job based on the Gemnasium analyzer, Continuous Vulnerability Scanning (CVS) no longer links to YAML files of the GitLab Advisory Database (GLAD). CVS users can't easily access to the source advisory of a vulnerability detected in their project.

Proposal

TBD

Proposal A

Update the Rails backend so that the report finding builder of CVS links to YAML files of gemnasium-db when rendering the Gemnasium identifier of an advisory.

Pros

  • We only change the Rails backend.

Cons

  • It's not accurate.
    • We can't know for sure the base name of the YAML file. It might not match the first identifier.
    • We would always point to the default branch of gemnasium-db (master), but the YAML file might no longer exist in that branch.

See #408978 (comment 1571383850)

Proposal B

  • Update the Package Metadata DB and its exporter in order to add a gemnasium identifier when exporting GLAD advisories, and with a link to gemnasium-db.
  • Remove the code that generates the gemnasium identifier from the report finder builder, in the backend.

Pros & cons: it's accurate but we need to change both the PM DB and the backend.

Further details

See https://gitlab.com/gitlab-org/gitlab/-/blob/87056eb4635ac33b0c5b6a1f47541317f18e3b55/ee/lib/gitlab/vulnerability_scanning/dependency_scanning/finding_builder.rb#L53-59

        def gemnasium_identifier
          {
            type: "gemnasium",
            value: advisory.xid,
            name: "Gemnasium-#{advisory.xid}"
          }.with_indifferent_access.freeze
        end

quoting @fcatteau in !126792 (comment 1474225683):

The base name might not be the CVE id. It should be the first identifier; this is not guaranteed by the YAML schema, but AFAIK YAML files are built that way. See https://gitlab.com/gitlab-org/security-products/gemnasium-db/-/blob/master/npm/22lixian/GMS-2017-269.yml for instance.

quoting @hacks4oats in !126792 (comment 1477980326)

Usually, a git tag is used instead of the default branch to ensure that we use a permalink (well semi-permanent since git tags can change). The usage of a tag was possible to do before because we had a local copy of the advisory repo when a security job ran in the CI pipeline. Now that we're moving the jobs to the Rails backend, we won't be able to know what commit or what tag was used to match the advisories, so the master url was assumed in all cases. The change wasn't needed to pass any of the specs for the reason stated above, but I think it's fine if the file stays as is. This way the expectation is set that we are always expected to use the latest changes in the GitLab advisory database.

/cc @hacks4oats

Edited by Fabien Catteau