Expired
Milestone Feb 3, 2026–Mar 31, 2026

Service Ping Remediation - Snowflake Review

Objective

Remediate all PubSec-related data in Snowflake associated with the Service Ping pipeline and its downstream consumers, so that no PubSec data is accessible to non-PubSec staff until proper access gating is in place. Where feasible, preserve PubSec data in a secure, access-restricted location so it can be restored or ported once a compliant RBAC model is implemented.

Scope

  • All Snowflake databases/schemas/tables that currently contain PubSec data derived from Service Ping and related joins.
  • The ~86 identified downstream tables and any additional tables discovered during analysis.
  • Downstream systems that rely on this Snowflake data (e.g., dashboards, exports, health scores) to ensure they gracefully handle the remediation.

Exit Criteria & Checklist

1. Inventory & Ownership

  • Enterprise Data Team provides a complete inventory of all Snowflake databases/schemas/tables that currently contain PubSec data, including but not limited to the 86 identified downstream tables.
  • For each table in scope, document:
    • Database, schema, table name
    • Source(s) of PubSec data (e.g., telemetry, CRM joins, license joins)
    • Primary downstream consumers (dashboards, exports, tools)
  • DRIs and owning teams are identified for:
    • Snowflake objects in scope
    • Key downstream consumers that may need updates after remediation

2. Target State & Secure Archive Design

  • With Security/Compliance and Data/Analytics, agree on the interim target state for PubSec data in Snowflake (e.g., no PubSec data in general-access schemas; only in a secure, access-gated location if preserved)
  • Decide on feasibility and design of a secure archive for existing PubSec data, including:
    • Location (e.g., dedicated Snowflake database/schema or equivalent secure storage)
    • Access model (e.g., limited to U.S.-citizen GitLab Federal staff and Enterprise Data Team operators on a least-privilege basis)
    • Logging/auditing expectations and retention window
    • Conditions under which the archive can be used to rehydrate production models once permanent access gating is in place
  • If a secure archive is not feasible, document:
    • Rationale and risk assessment
    • Confirmation from Security/Compliance that permanent purge is the approved interim control

3. Data Purge / Quarantine Execution

If a secure archive is approved:

  • Create the secure archive location with the agreed RBAC model and logging
  • Take a point-in-time snapshot of all in-scope PubSec data and move/copy it into the secure archive prior to purge from general-access locations

Purge PubSec data from all in-scope Snowflake tables:

  • Purge criteria correctly and consistently identify PubSec rows
  • Purge scripts/queries are versioned and stored with this milestone

Update transformations:

  • Update or re-run transformations (e.g., dbt models, materialized views) to remove reliance on purged PubSec rows where needed
  • Ensure pipelines, dashboards, and exports continue to function without errors

Downstream coordination:

  • Coordinate with owners of downstream systems (e.g., reporting, health scores, exports) to:
    • Purge or re-scope any locally stored PubSec data derived from Snowflake
    • Verify that user-facing artifacts no longer expose PubSec data while remediation is in effect

4. Access Validation & Controls

  • For all non-PubSec roles/groups, validate via queries and role tests that:
    • PubSec data is no longer visible in Snowflake tables outside the secure archive (or is fully purged where no archive exists)
    • Any remaining PubSec data is only accessible to explicitly approved, least-privilege roles
  • Confirm that role definitions and grants match the intended interim control design, and that:
    • New users cannot be accidentally granted access to PubSec data
    • Access changes are logged and auditable

5. Evidence, Documentation & Hand-off

  • Attach remediation evidence to this milestone, including:
    • Final inventory of affected tables
    • Purge and/or archive SQL scripts
    • Before/after row counts (or equivalent metrics) demonstrating successful remediation
    • Access-test results for representative roles
  • Update the Service Ping child epic and associated PubSec telemetry documentation with:
    • Final state of PubSec data in Snowflake
    • Description of the secure archive (if implemented) and conditions for its future use
    • Known functional impact on downstream systems (e.g., gaps in historical telemetry, health scores, or dashboards)
  • Record a clear re-onboarding plan for PubSec data once permanent Snowflake access gating is implemented (e.g., restore from secure archive, rebuild models, re-enable exports), with:
    • Owners and prerequisites
    • Dependencies on broader PubSec internal telemetry & BI controls work

Done when: All items above are complete and validated — PubSec-related data in Snowflake is either fully purged from general-access locations or preserved only in a secure, access-gated archive, eliminating unauthorized visibility while preserving a path to safely restore the data once compliant access controls are in place.

The work for this milestone was recorded here: https://gitlab.com/gitlab-data/analytics/-/work_items/26538

Sensitive Domain Data Remediation — Executive Summary

Investigation and remediation of .gov, .mil, .fed.us, and gitlab-dedicated.us host/usage records across version.gitlab.com, S3, and Snowflake.

Scope of Affected Data

Domain Suffix Host Records Notes
.gov 3,200
.mil 1,861
gitlab-dedicated.us 13
.fed.us 2
Total ~5,000 + ~500k usage payloads since 2026-01-01

Access pattern: 95 search queries over 12 months (clustered early 2026, mostly top-level domains). No evidence of broad or targeted abuse.

Key Decisions

  1. Purge all affected domain data from Version DB, S3 exports, and all Snowflake layers (RAW + downstream).
  2. Block future ingestion of these domain suffixes at the Version app level.
  3. Monitor via alerts to prevent reintroduction into Snowflake.

Remediation Status

As of late February 2026

Completed

System Action Detail
Version App — Ingestion Deployed MR to block new data Suffix-based filtering (e.g., test.gov blocked; test.gov.example.com not)
Version App — Hosts Purged ~3,939 records Cascade deletions cleared Current Host Stats and Usage Ping Errors
Version App — Usage Data Purged 254,035 records
Version App — Raw Usage Data Batch-purged large JSON table ~1 month/hour; fully removed as of 2026-02-18
S3 Removed all exports with sensitive hostnames usage_data, raw_usage_data, hosts, usage_data_errors
Snowflake RAW Deleted matching rows raw.version_db.hosts, raw.version_db.raw_usage_data, raw.version_db.usage_data
Access Logs Reviewed via Google Cloud Logging Validated history; confirmed no suspicious access patterns

In Progress

Item Approach Detail
Snowflake downstream tables (86 identified) Monthly full-refresh pipeline (1st Sunday/month) Avoids costly one-off DELETEs; additional validation needed where tables also depend on non-Version sources (e.g., Salesforce)
Monte Carlo alerts Detect prohibited suffixes in Snowflake Early warning if ingestion controls regress
Post-refresh verification Confirm zero occurrences in PROD Ensure non-Version sources are cleansed or governed under appropriate policies

Executive Takeaways

  • Exposure was limited to hostnames and usage records — no evidence of widespread or malicious access.
  • New data is blocked at the source; historical records are purged from primary and raw stores.
  • Remaining work is verification and governance: confirming downstream models and non-Version sources are fully compliant and monitored.