## Summary Decide how to handle a package flagged by **both** a public GLAD advisory and a GLAM malware advisory. Three options are on the table. The options are listed first, then assessed one by one. ## The three options at a glance | | Option | Behaviour | Verdict | |---|---|---|---| | **A** | Dedup | Suppress the GLAM finding when GLAD already covers the package | **Cannot be chosen** — produces `malware = false` on real malware | | **B** | Identifier merge | Suppress the duplicate *vulnerability*, but append the `GLAM-` identifier to the existing finding | Viable, most correct, most work | | **C** | Keep both findings | No consolidation; GLAD and GLAM each keep their own vulnerability | ✅ **Chosen** | Either B or C is defensible. A is not, for the reason given below. ## Decision: Option C **Keep both findings.** Agreed on the tech side, then discussed with the team in Slack and confirmed there. Final decision from that discussion: > I agree we should keep both for now, this is 0.2% of advisories so negligible in number. > > There is a case for 'smart' correlation/deduplication across sources, but I kind of see that as an entirely separate feature. (This is also relevant to when we start ingesting third-party findings that may introduce more duplications into the system). Reasoning: - The true-duplicate set is ~0.2% of advisories, which is negligible in absolute terms. - It is the least implementation work and the fastest route to a first release. - It avoids Option B's confusing presentation, where `malware = true` would appear on a finding titled after an unrelated CVE. **Cross-source correlation is a separate feature, not a deferred fix.** Rather than treating Option B as tech debt with a milestone, the better framing is that "smart" correlation and deduplication *across sources* is its own capability. It becomes more valuable, and more clearly its own piece of work, once third-party findings ingestion starts introducing further duplication into the system. Option B is one possible implementation of that feature, scoped to GLAM and GLAD only. Consequence for this epic: there is no suppression or merge check to build pre-GA, so the VAC follow-up https://gitlab.com/gitlab-org/gitlab/-/work_items/612170 is no longer needed. --- ## Option A — Dedup: suppress the GLAM finding What the proof of concept prototyped (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/226519): an `ExistingDsVulnerabilityChecker` matching on `(name, version, file_path, project_id)`, filtered to active unresolved `dependency_scanning` findings, one CTE query per project batch with results held in a `Set`. **Pros** - Simplest to implement, and the code already exists in the POC. - No duplicate entries in the vulnerability report. - Preserves the existing finding's identity, history and user state, because nothing is written to it. **Cons** - Discards the malware signal entirely for any package GLAD already covers. - The suppression key has no notion of advisory identity, so an *unrelated* CVE suppresses the malware finding. **Why this cannot be chosen** Malware status is derived purely from identifier prefixes, in `Vulnerabilities::MalwareDetection`: ```ruby def malware_status_for(vulnerabilities, vulnerable) return true if vulnerabilities&.any?(&:has_glam_identifier?) # GLAM- or MAL- prefix ... end ``` `has_glam_identifier?` reads `vulnerability_read&.identifier_names`. If the GLAM finding is suppressed, the surviving GLAD finding carries only GLAD identifiers, so `malware_status` is **false for a package that is definitively malware**. This is measured, not theoretical. On the verification fixture, `chalk@5.6.1` — a real npm account-takeover compromise — is reported by GLAD with identifiers `[Gemnasium-ca765ff5…, CWE-506, GHSA-2v46-p5h4-248w]`. No `GLAM-`, no `MAL-`. So Option A hides the malware signal on exactly the highest-profile packages, which is the opposite of what this epic exists to do. That is a functional defect rather than a trade-off, which is why it is ruled out rather than weighed. Fixture: https://gitlab.com/gitlab-org/govern/threat-insights-demos/verification-projects/bala-test-group/malware-sbom-verification --- ## Option B — Identifier merge Keep one vulnerability and append `GLAM-…` to it as a secondary identifier. **Pros** - `malware_status` becomes true, so the signal survives. - No duplicate entry in the vulnerability report. - The UUID keys on the *primary* identifier fingerprint, so appending a secondary identifier does not change it. The surviving finding keeps its identity, history and user state. - Multi-identifier findings are already native: on the fixture, `debug@4.4.2` carries `CVE-2025-59144`, `Gemnasium-…`, `GHSA-…` and `CWE-506` on one finding. **Cons** - The most implementation work of the three, and it adds a write path from the malware scanner into existing findings, which must be idempotent. - Inherits the surviving finding's severity. `unknown` for "Malware in chalk", `medium` for an ordinary CVE. Needs an escalation rule — relates to https://gitlab.com/gitlab-org/gitlab/-/work_items/612089 - Title framing gets confusing: a user sees `malware = true` on a finding titled "Express.js Open Redirect". - One finding now represents two underlying claims, so divergent lifecycles need a rule. If the GLAM advisory is withdrawn but the CVE stands, what resolves? Relates to https://gitlab.com/gitlab-org/gitlab/-/work_items/612099 and https://gitlab.com/gitlab-org/gitlab/-/work_items/594793 - EventStore gives no ordering guarantee, so GLAD-after-GLAM needs the reciprocal merge, not just GLAM-after-GLAD. **Implementation detail that would silently defeat it** `has_glam_identifier?` reads the **denormalised** `vulnerability_reads.identifier_names`. Writing `vulnerability_occurrence_identifiers` alone is not enough; the read row has to be refreshed, or the merge looks successful while malware status stays false. --- ## Option C — Keep both findings No consolidation. GLAD keeps its primary identifier, GLAM keeps its own, both vulnerabilities exist. **Pros** - Correct today. The GLAM finding carries a `GLAM-` identifier, so `malware_status` is true. - Least work by a wide margin: there is no checker to port, and the VAC follow-up https://gitlab.com/gitlab-org/gitlab/-/work_items/612170 becomes unnecessary. This takes one Wave 0 item and one Wave 4 item off the pre-GA critical path. - Consistent with how the platform already behaves. GLAD itself emits two separate vulnerabilities for `debug@4.4.2` at the same location: `Malware in debug` (primary `Gemnasium-86915d38…`, severity `unknown`) and `debug@4.4.2 contains malware after npm account takeover` (primary `Gemnasium-9eb4fd23…`, severity `high`, additionally carrying `CVE-2025-59144`). Both are `dependency_scanning` and **both carry `CWE-506`** — they are two distinct advisory records about the same npm account-takeover incident, not a CVE-versus-malware pair. Each has its own primary identifier, so each gets its own UUID. Same-source overlap is already not deduplicated, and is not treated as a bug. - Both claims stay independently actionable: dismissing the CVE does not dismiss the malware finding. **Cons** - Duplicate entries in the vulnerability report for the true-duplicate set. - Consolidating later is harder than the reverse. See the section below. - Two findings for one package may read as a bug to users who do not look at the identifiers. --- ## Supporting evidence: how much overlap actually exists Measured against a local sync of the staging PDS dataset (npm only). Name-matched, so an upper bound, and indicative rather than production-exact. | | Count | Share of GLAM | |---|---|---| | GLAM npm packages | 215,111 | — | | Also present in GLAD, any advisory | 1,568 | 0.73% | | GLAD's own advisory is *also* malware — true duplicates | **458** | **0.213%** | The distinction matters for weighing Option C. Of the 1,568 name overlaps, roughly 1,110 are a GLAD **CVE** plus a GLAM **malware** advisory. Those are two different claims about the same package, not duplicates, and arguably both should exist. Only the 458 where GLAD itself reports malware are genuine duplication — about one fifth of one percent. ## Why the two do not collapse on their own Platform dedup is the vulnerability UUID (`Security::VulnerabilityUUID.generate`), a UUID v5 over: ``` "#{report_type}-#{primary_identifier_fingerprint}-#{location_fingerprint}-#{project_id}" # v1 "#{report_type}-#{primary_identifier_fingerprint}-#{location_fingerprint}-#{project_id}-#{context_id}" # v2, context-aware ``` The decisive term is `primary_identifier_fingerprint`. A GLAD finding's primary identifier is a Gemnasium or CVE id; a GLAM finding's is a `GLAM-` id. Different fingerprint, different UUID, two vulnerabilities for the same package — by design. Any consolidation has to be built deliberately on top. ## If C is chosen: moving to B later Feasible, and the migration surface is small, but the direction is asymmetric. B to C is trivial — stop appending. C to B requires consolidating existing records. What makes it cheap: - Merge candidates are trivially queryable: GLAM findings carry a `GLAM-` primary identifier and the pair is found by matching coordinates. No bookkeeping is needed now to reconstruct the set later. - Appending an identifier does not change the surviving finding's UUID, so it keeps identity and history. - The candidate set is ~0.2% of advisories, before intersecting with actual project dependencies. What is irreducible: - **User state on the finding merged away** — dismissals and their reasons, comments, linked issues, state transitions, severity overrides. There is no automatic right answer for where a dismissal goes. - Deleting vulnerabilities with audit trails is compliance-sensitive, so the realistic route is resolve-as-superseded, which is visible churn in customer reports. - External references break: vulnerability ids in URLs, API consumers, exported reports, and security policies. - Needs a batched background migration, with merge logic shipped before the backfill and a mixed-data window in between. **This cost scales with elapsed time in production, not with advisory volume.** Three months of accumulated user state is cheap to consolidate; two years is not. If C is chosen, B should carry a date rather than being left open-ended. ## Acceptance criteria - [x] Option chosen between B and C, with the reasoning recorded here. A is ruled out above. **Option C chosen.** - [x] ~~If B: severity escalation, title framing, both-direction ordering and divergent lifecycles are each resolved.~~ Not applicable — Option C chosen. - [x] No suppression or merge check is built pre-GA. The SBOM/CI implementation (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/249853) adds malware findings additively, and the VAC follow-up that assumed a check existed is closed (https://gitlab.com/gitlab-org/gitlab/-/work_items/612170). Verification moved to the implementing issues rather than tracked here, since this issue produces a decision and no code: - `malware_status` returning true for `chalk@5.6.1` and `debug@4.4.2` on the verification fixture, and the pure-GLAM controls (`base65-85x`, `db-convertor`, `polymarket-risk-manager`, `vitest-agent`) producing exactly one finding each — covered by https://gitlab.com/gitlab-org/gitlab/-/work_items/612091 (SBOM/CI path) and https://gitlab.com/gitlab-org/gitlab/-/work_items/612094 (CVS scanner). ## Not carried forward from here **Cross-source correlation has no home yet.** The Slack decision reframed it as its own feature rather than deferred work on this epic, and noted it becomes more relevant once third-party findings ingestion starts introducing further duplication. It is deliberately *not* tracked under https://gitlab.com/groups/gitlab-org/-/epics/21156, and no issue exists for it at the time of closing. It needs raising wherever cross-source findings correlation belongs. The analysis in this issue is the starting material for it: the overlap figures, the `malware_status` identifier-prefix dependency, and the note that the vulnerability UUID keys on the primary identifier fingerprint so two sources never collapse on their own. Parent epic: https://gitlab.com/groups/gitlab-org/-/epics/21156