## Summary On a VAC-enabled (`vulnerabilities_across_contexts`) project's **first-ever default-branch pipeline**, SAST findings are silently dropped. The SAST scan reports `status: succeeded` with a valid artifact, but `security_scans.processing_errors` contains an `IngestionError` and ingestion raises a `NoMethodError`. `secret_detection` on the same pipeline ingests fine. Reported via Zendesk ticket 742858 (customer: Macy's, project `macys/ESS_SUP/Location`) — the customer's very first default-branch pipeline for a newly VAC-enabled project. Observed production state: ``` pipeline.security_scans.map { |s| [s.scan_type, s.status, s.processing_errors] } => [["sast", "succeeded", [{"type"=>"IngestionError", "message"=>"Ingestion failed for some vulnerabilities"}]], ["secret_detection", "succeeded", []]] ``` ## Verified root cause (confirmed against `origin/master`) The finding-UUID version flips between the two parse phases on the first default-branch pipeline, so the ingestion join misses on every finding. **1. Finding storage runs first, with no tracked context yet → v1 (context-unaware) UUIDs.** `app/services/security/vulnerability_uuid.rb:10` ```ruby if tracked_context.nil? || !tracked_context.context_aware_uuids_enabled? return generate_v1(...) # no context id end generate_v2(..., tracked_context.id) # appends "-#{context_id}" ``` On the first default-branch pipeline no `ProjectTrackedContext` exists, so stored `Security::Finding.uuid` values are **v1**. **2. Ingestion find-or-creates the default-branch context mid-pipeline, then re-parses.** `ee/app/services/security/ingestion/finding_map_collection.rb:28-38` — args evaluate left-to-right, so `tracked_context(pipeline)` (which `find_or_create`s and **persists** the default context) runs *before* the re-parse that builds `report_findings_map`. `ee/lib/ee/gitlab/ci/reports/security/report.rb:14` → `ProjectTrackedContext.for_pipeline(pipeline).tracked.first` now returns that freshly-created context. **3. The anomaly: the create service stamps *every* new context — including the default branch — as `uuid_version: 2`.** `ee/app/services/security/project_tracked_contexts/find_or_create_service.rb:117` ```ruby Security::ProjectTrackedContext.create( ..., is_default: is_default, uuid_version: Security::ProjectTrackedContext::CONTEXT_AWARE_UUID_VERSION) # = 2 ``` combined with the model guard, which short-circuits on `uuid_version == 2` **before** the `is_default?` check: `ee/app/models/security/project_tracked_context.rb:180-184` ```ruby def context_aware_uuids_enabled? return true if uuid_version == CONTEXT_AWARE_UUID_VERSION # 2 <-- fires first return true if uuid_version == CONTEXT_UNAWARE_UUID_VERSION && !is_default? false end ``` So the just-created default context is `is_default=true` **and** `uuid_version=2` → `context_aware_uuids_enabled? == true` → the re-parse computes **v2** UUIDs. **4. The join is keyed by the re-parsed v2 UUID but looked up by the stored v1 UUID → nil for every finding.** `ee/app/services/security/ingestion/finding_map_collection.rb:31,42` ```ruby report_findings_map = report_findings.index_by(&:uuid) # keyed by v2 report_findings_map[security_finding.uuid] # looked up by stored v1 -> nil ``` **5. Nil deref → `NoMethodError` → slice dropped.** `ee/app/services/security/ingestion/finding_map.rb:19,30` ```ruby delegate :evidence, :context_unaware_uuid, to: :report_finding # nil -> NoMethodError def identifiers @identifiers ||= report_finding.identifiers.first(...) # nil -> NoMethodError end ``` Caught at `ee/app/services/security/ingestion/ingest_report_service.rb:41` → `add_processing_error!({type: 'IngestionError', message: 'Ingestion failed for some vulnerabilities'})`, so the whole slice is dropped and the findings never ingest. ### Why the guard was supposed to prevent this `context_aware_uuids_enabled?` was designed to keep the **default** branch on v1 (only non-default refs go context-aware). The DB default for `uuid_version` is `1` (`db/structure.sql`), and the post-migrate `db/post_migrate/20260727234134_update_non_default_tracked_branches_to_v2.rb` deliberately upgrades **only `is_default = false`** rows. The create-service line stamping default contexts as `2` is the anomaly that defeats the guard. ### Prior art A fix already exists on a non-master demo branch (`summit-ch6-gdk-demo`, commit `8ea72946`, Ryan Wells) that moves the guard toward `is_default?`. Master is unfixed. Noting as direction, not a merged fix. ## Steps to reproduce 1. Enable `vulnerabilities_across_contexts` for a brand-new project (no prior pipelines, no tracked contexts). 2. Run the **first** pipeline on the default branch with a SAST report that produces findings. 3. Observe: `pipeline.security_scans` shows `sast` `succeeded` with an `IngestionError` in `processing_errors`; Sidekiq logs a `NoMethodError` in the ingestion path; SAST findings are absent. ## Expected vs actual - **Expected:** first default-branch SAST findings ingest normally. - **Actual:** every SAST finding is dropped; scan is marked with a generic `IngestionError`. ## Impact VAC-enabled customers lose **all** SAST findings on a project's first default-branch scan. Silent (findings just missing) apart from the processing error. `secret_detection` is unaffected due to how its findings map. ## Suggested fix direction (to be confirmed after local repro) - **Preferred:** in `find_or_create_service` `create_context`, do **not** set `uuid_version: 2` for `is_default` contexts (leave the default-branch context at v1), so `context_aware_uuids_enabled?` stays false and both parse phases produce v1 on the default branch. - **Defense-in-depth:** create the default-branch tracked context **before** finding storage so both phases agree on the same context/version; and/or make the finding-map join tolerant of a nil `report_finding` (skip + log) so a UUID-version skew degrades gracefully instead of raising a hard `NoMethodError` that drops the whole slice. ## Next steps - [ ] Reproduce locally to 100% confirm the ordering/version mechanism - [ ] MR with fix + regression spec (first default-branch pipeline on a VAC-enabled project ingests SAST findings) - [ ] Verify against the customer scenario (ZD 742858) ## Related - Epic gitlab-org&3430 (Track Vulnerabilities Across Contexts) - Context-aware UUID work: #587624, !221246, !232275 /cc @rwells @minac