Skip to content

Back to the catalog

Version Control DFIR: a Cheatsheet to GitHub, GitLab, Bitbucket, and Azure DevOps
wiz.ioarticle

Version Control DFIR: a Cheatsheet to GitHub, GitLab, Bitbucket, and Azure DevOps

Wiz CIRT published a DFIR cheatsheet/poster covering the four most common version control platforms (GitHub, GitLab, Bitbucket Cloud/Data Center, Azure DevOps), detailing available log sources, default retention limits (e.g. GitHub's 7-day Git read/write event retention, GitLab not storing Git operations by default), a pre-incident configuration checklist (enabling source-IP metadata, extending retention, log streaming), and a MITRE ATT&CK-mapped matrix of platform-specific audit event names to hunt for during investigations. It illustrates the gaps with a real incident where a compromised token was used to mass-clone repositories containing plaintext secrets, and shows how the same action (e.g. mass repo cloning) surfaces under different event names per platform (git.clone in GitHub, repository_git_operation in GitLab, RepositoryCloneEvent in Bitbucket Data Center).

TL;DR Wiz CIRT's DFIR poster maps VCS audit log sources, retention gaps, and MITRE ATT&CK-mapped hunting queries across GitHub, GitLab, Bitbucket, and Azure DevOps.
Open original ↗
Document

What it is

A Wiz CIRT DFIR poster/cheatsheet for four VCS platforms (GitHub, GitLab, Bitbucket, Azure DevOps), structured in three parts: an available-log-sources table, an incident-readiness checklist, and an attack-detection/forensic matrix mapping adversary tactics to per-platform audit event names. The blog motivates it via VCS-targeting supply-chain campaigns, naming TeamPCP as an attributed example.

Preconditions / Affected

Relevant if you run any of the four platforms as a SaaS/hosted VCS — the post notes 88% of Wiz customers do, which is where the visibility gaps bite hardest. Log-streaming capability is frequently gated behind higher license tiers, so what telemetry you can even capture depends on your plan; check tier before assuming an event is available.

What to do

The page's concrete, DFIR-specific readiness actions (distinct from general hardening like branch protection, secret scanning, token scoping, MFA, IP allowlists):

  • Enable complete metadata now. GitHub does not log actor source IP addresses in audit logs by default — this requires manual configuration beforehand. Without it, tracing malicious activity origin during an investigation is significantly harder.
  • Stream events to an external datastore. Default retention is insufficient (GitHub keeps Git read/write events only 7 days; standard GitLab never writes Git operations to the DB at all). Streaming preserves logs for breaches discovered weeks or months later.
  • Turn on API request logging where possible. GitHub is the only one of the four hosted platforms that lets you log raw API requests, and only with explicit configuration + log streaming. These logs surface early-stage discovery/enumeration before impact.
  • Consider a CDR platform rather than a legacy SIEM as the streaming destination — the post argues it ingests cloud-scale volume and correlates SaaS context without the SIEM cost/overhead.

Use the poster's log-sources table to map, per provider and license tier, exactly which events you can rely on — before an incident rather than during one.

Caveats

  • The fetched page is truncated: Part 3 (the actual tactic→event-name matrix, arguably the most useful artifact) is cut off, so the specific event names and per-tactic mappings are only in the poster itself, not this text.
  • Scope is deliberately narrow: investigative/DFIR readiness only, not general security posture — the vendor explicitly defers hardening guardrails elsewhere.
  • Claims like the 88% SaaS figure and the CDR-over-SIEM recommendation are Wiz's own, drawn from their customer base and product framing.

Technologies named here

Threat actors named here

Related in Blue Team & Detection