VCS Blind Spot: Wiz CIRT Publishes DFIR Matrix for GitHub and GitLab

On August 27, 2026, the Wiz CIRT research team released a DFIR poster dedicated to SaaS version control platforms, mapping specific audit events to the MITRE ATT&CK framework for GitHub, GitLab, Bitbucket, and Azure DevOps. The document stems from an operational reality: 88% of Wiz customers use cloud VCS, yet the same offensive actions — from mass cloning to branch hijacking — generate logs with different names on each platform and often vanish after a few days. This fragmentation is not a translation problem; it is a visibility gap that turns incident response into guesswork.

Taxonomy as a Minefield: When the Same Attack Has Four Names

The core of the Wiz CIRT work is a systematic translation matrix. For each MITRE ATT&CK tactic identified in the VCS vector, the poster indicates the corresponding audit event name on each platform. The decision to publish this mapping is not academic: during real incident response, teams must build queries on logs whose meaning changes from one SaaS to another.

The most telling case is mass repository cloning. On GitHub the event is named git.clone; on GitLab it becomes repository_git_operation; on Bitbucket Data Center it turns into RepositoryCloneEvent. The difference is not terminological; it is structural, because each platform organizes its audit logs with different fields, filters, and retention. Bitbucket Cloud and Bitbucket Data Center, the source specifies, have "fundamentally different" audit logging mechanisms — a further complication for teams managing hybrid instances.

GitHub and GitLab maintain consistent audit log schemas between their SaaS and self-hosted versions, but this advantage is partially negated if data collection is not enabled in time. The poster's matrix functions as a cheat sheet for detection engineering: it translates offensive techniques into concrete queries, reducing detection rule development time.

Seven Days Then Darkness: Retention Limits That Force Credential Rotation

Retention emerges as a critical friction point. GitHub stores Git read and write events for seven days by default. Past this window, historical repository access is no longer reconstructible via the platform's native logs. A case documented by Wiz CIRT illustrates the operational consequence: during an investigation, "because historical Git clone events were not fully available due to standard retention limits, the scope of the exfiltrated repositories could not be determined." The inability to quantify what was cloned forced the organization into a full-scale credential rotation, without being able to establish whether the action was necessary or excessive.

GitLab presents a different but compatible profile: in its standard configuration, Git operations are not saved to the database. Full audit event streaming requires the Ultimate tier, according to official documentation. This means organizations on lower plans operate with partial visibility by definition, regardless of SOC team competence.

The quantitative figure is stated precisely: 88% of Wiz customers use SaaS VCS. This concentration on managed infrastructure makes the visibility gaps a mass problem, not a niche one. The absence of API logs on GitLab, Bitbucket, and Azure DevOps — with the sole exception of GitHub, which requires explicit configuration — completes the picture of an attack surface monitored discontinuously.

"Relying exclusively on the UI or API to fetch logs during an active incident leaves critical blind spots for detection and response capabilities."
— Wiz CIRT

From JINX-0164 to TeamPCP: What Happens When Logs Are Missing

The poster does not derive from abstract theory. Two campaigns documented by Wiz CIRT — JINX-0164 and TeamPCP — demonstrate VCS techniques the matrix is designed to detect. JINX-0164 employed commit impersonation, direct-to-main commits, and branch hijacking on GitHub repositories. TeamPCP, active in the cryptocurrency sector, combined mass git.clone, deletion of workflow logs, and pull requests with malicious workflows leveraging stolen personal access tokens. Approximately 24 hours elapsed between the credential theft and the start of AWS discovery operations.

Both campaigns share a trait: the post-compromise techniques — log deletion, mass cloning, branch manipulation — are detectable only if the corresponding events were logged and retained. When retention expires or streaming is not active, investigation falls back on inferences and indirect correlations, with response times lengthening proportionally. The DFIR poster does not fix platform gaps; it documents them systematically, giving teams a readiness checklist to identify in advance what will not be visible after an incident.

What to Do Now

The Wiz CIRT dossier does not list standardized operational recommendations, but the verified facts point to priority actions for teams managing SaaS VCS.

Verify API logging configuration on GitHub. It is the only platform among the four that supports this capability, but it requires explicit activation. Without this setting, programmatic calls remain outside operational visibility.

Evaluate audit event streaming for GitLab. The Ultimate tier is required for full coverage. Organizations on lower plans operate with a structural hole on Git operations, not recoverable retroactively.

Map your event nomenclature to the poster's. Detection engineering must translate MITRE ATT&CK rules into platform-specific queries, not assume semantic equivalence between logs with similar names.

Distinguish between Bitbucket Cloud and Bitbucket Data Center in playbooks. The audit logging mechanisms are fundamentally different: a runbook valid for one instance is not transferable to the other without revision.

Why the Problem Is Not Solved with More Tools

The publication of the DFIR poster brings into focus a structural tension in the enterprise cloud: operational centralization on SaaS does not coincide with centralization of visibility. VCS platforms are critical infrastructure — they host code, pipelines, secrets, and configurations — but their audit logs are designed for compliance and troubleshooting, not for high-fidelity forensics. The difference lies in granularity, retention, and cross-platform consistency.

The Wiz CIRT work does not propose a new technology: it organizes what exists, highlighting where there is less than security teams presume. The risk is not ignorance of the logs, but trust in their completeness. When an attacker clones hundreds of repositories and the logs expire before the alarm sounds, the investigation is not difficult; it is impossible. Mass credential rotation then becomes an act of desperation, not precision.

Frequently Asked Questions

Is the poster an open source tool?
No. It is produced by Wiz CIRT, the research and incident response team of Wiz, as a commercial resource for customers and security professionals.

Why does GitLab not save Git operations by default?
According to the dossier, the architectural choice is not to write them to the database in the standard configuration. Streaming at the Ultimate tier is the documented path for complete collection.

Is Azure DevOps less secure than the other platforms?
The brief does not allow absolute security comparisons. Available data indicates that Azure DevOps does not support API request logging, unlike GitHub with explicit configuration; on other visibility aspects, the dossier provides no comparative information.

Sources

• https://www.wiz.io/blog/vcs-dfir-threat-hunting-github-gitlab-azure-devops
• https://docs.gitlab.com/user/compliance/audit_event_types/
• https://www.wiz.io/blog/threat-actors-target-crypto-orgs
• https://www.wiz.io/blog/tracking-teampcp-investigating-post-compromise-attacks-seen-in-the-wild