Deduplicate synthetic Gemnasium-GLAM-... identifier on malware advisory findings

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Dependency-scanning findings sourced from a GLAM malware advisory show the same advisory id twice in their identifier list: once as a synthetic Gemnasium-GLAM-... identifier and once as the advisory's own GLAM-... identifier. Track deduplicating this.

Details

Example finding (polymarket-risk-manager@3.5.2) carries three identifiers, confirmed via GraphQL:

  • type=mal, name MAL-2026-6712
  • type=gemnasium, name Gemnasium-GLAM-2026-07-00010 (value GLAM-2026-07-00010)
  • type=glam, name GLAM-2026-07-00010 (value 2026-07-00010)

Root cause is in ee/lib/gitlab/vulnerability_scanning/dependency_scanning/finding_builder.rb#identifiers: it prepends a synthetic gemnasium-type identifier Gemnasium-#{advisory.xid} before concatenating the advisory's own identifiers. Advisory.from_malware_advisory sets xid = advisory.advisory_xid, which is the GLAM id itself, so the synthetic identifier becomes Gemnasium-GLAM-2026-07-00010 — a wrapped copy of the glam identifier that follows it.

This is generated server-side when the SBOM artifact is ingested (SecurityReportBuilder -> FindingBuilder), not by the CI SBOM/dependency-scanning analyzer, which only emits the CycloneDX SBOM. Any fix belongs in FindingBuilder.

Why it only shows on malware

For ordinary GLAD advisories, xid is an internal UUID, so the synthetic primary is Gemnasium-<uuid> and doesn't visually duplicate any CVE/GHSA identifier. Malware is the only case where xid is itself a human-readable GLAM- string, making the wrap visible as a duplicate.

Constraint

The gemnasium identifier is deliberately the load-bearing PRIMARY identifier for dependency-scanning finding tracking/dedup (#417787 (closed)). Naively removing or reordering it changes the finding fingerprint and causes existing findings to be re-created as duplicates. Any fix must keep the primary/fingerprint stable.

Proposed options

a. Suppress the synthetic identifier when its value already equals one of the advisory's own identifiers, keeping a stable primary. b. For malware advisories, use the glam identifier as primary directly instead of wrapping it.

Either option needs verification that the #417787 (closed) fingerprint stays stable, plus a regression test asserting a malware finding has exactly one identifier per GLAM id.

Out of scope

No analyzer change; malware detection behavior (keyed on presence of GLAM-/MAL- identifiers) is unaffected — the duplication is cosmetic in the UI/identifier list.

Relates to epic &20876 (malware advisory sync / GLAM).

Edited by 🤖 GitLab Bot 🤖