As threat actors increasingly target Version Control Systems (VCS) to execute both targeted attacks and broad supply chain compromises (such as the campaigns attributed to TeamPCP), it is essential to understand available telemetry, recommended configurations, and available audit events. Preventing an initial compromise is challenging, making post-compromise visibility and rapid response capabilities critical.
To assist security teams, Wiz CIRT has created a Version Control Digital Forensics and Incident Response (DFIR) poster summarizing available logs, a pre-incident configuration checklist, and specific audit event names to hunt for during an investigation. We chose to focus on the four most common VCS platforms across Wiz customers: GitHub, GitLab, Bitbucket, and Azure DevOps.
Part 1 – Available Log Sources
Relying exclusively on the UI or API to fetch logs during an active incident leaves critical blind spots for detection and response capabilities. Standard audit logs do not capture all activity, and default retention limits can severely restrict historical investigations. For example, GitHub retains Git read/write events for only 7 days by default, and standard GitLab configurations do not save Git operations to the database at all, making these events unavailable unless log streaming is preconfigured.
The lack of API logs present another major visibility challenge. 88% of Wiz customers rely on SaaS VCS solutions, which frequently abstract away the raw API requests sent to the server. Currently, GitHub is the only hosted platform out of the four that allows organizations to log these requests, and doing so requires explicit configuration and log streaming. When accessible, these API logs are invaluable as they shed light on early-stage discovery and enumeration by threat actors, potentially alerting security teams to malicious activity before any impact occurs.
Given these visibility gaps, configuring log streaming prior to an incident is necessary to detect compromise in real time and establish an accurate timeline of attacker activity. While organizations have relied on legacy SIEMs for this telemetry, directing these logs to a Cloud Detection and Response (CDR) platform provides an effective alternative, natively ingesting cloud-scale volumes and correlating SaaS context without the cost and operational overhead of a legacy SIEM. However, regardless of the destination platform, log streaming capabilities within the VCS itself are frequently restricted by higher license tiers, introducing operational and billing considerations for organizations when selecting their provider.
To help navigate this, “Available Log Sources” table in the poster provides a breakdown of telemetry availability across the four major platforms. Rather than discovering critical missing logs during an active crisis, security teams can use this table to map out exactly which events are accessible based on their current provider and licensing tier. By cross-referencing your environment with this table, you can proactively identify blind spots in your architecture and establish exactly what telemetry you can rely on when an incident occurs.
Part 2 – Incident Readiness Checklist
The poster contains a readiness checklist derived from Wiz CIRT’s real-world incident response experience, based on multiple supply chain attacks and targeted campaigns. Rather than focusing on general security enforcement, this section is tailored specifically toward investigative readiness, to ensure the environment captures the necessary telemetry and context before a breach occurs. Enabling complete metadata and extending data retention are two critical examples organizations should configure today:
Enable Complete Metadata: Ensure the environment is configured to capture maximum context. For example, GitHub requires manual configuration to expose the source IP addresses of actors within audit logs. Without this setting enabled beforehand, tracing the origin of malicious activity during an investigation becomes significantly harder.
Extend Data Retention: Default retention windows are insufficient for most investigations. Streaming events to an external datastore is necessary to ensure logs remain available when an incident is discovered weeks or months after the initial breach.
These two examples represent just a fraction of an effective readiness strategy. The “Incident Readiness Checklist” section of the poster provides a platform-by-platform guide to preparing your environment before an investigation is required.
It is important to note the scope of this checklist: it focuses strictly on VCS-specific investigative readiness rather than general security hardening. While security teams should also familiarize themselves with proactive posture guardrails such as enforcing branch protections, scanning for plaintext secrets, tightly managing token scopes, and adhering to general SaaS best practices (such as MFA enforcement and IP allowlists), the poster concentrates specifically on configurations that directly impact your DFIR capabilities.
Ultimately, proactive configuration serves a dual purpose: it prepares the organization for a potential investigation while simultaneously hardening the environment. Because many observed supply-chain and VCS attacks rely on automated scripts, establishing proper visibility and baseline configurations can disrupt these attack chains and help surface anomalies earlier in the lifecycle.
Part 3 – Attack Detection and Forensic Matrix
During an active incident, security teams must quickly translate known adversary behaviors into specific, actionable queries within their SIEM or detection platform. However, every VCS provider uses different terminology and logging schemas for the same actions. Beyond naming conventions, providers also vary in what they capture by default, as well as how long those specific event types are retained. Understanding which event names correspond to a malicious tactic, and recognizing the underlying visibility and retention limitations for those specific events across different platforms, is critical for effective threat hunting and detection engineering.
For example, during a recent Wiz CIRT investigation while hunting for Exfiltration and Lateral Movement, a compromised token was discovered being used to mass clone repositories which contained plaintext secrets. The attackers then used these secrets to move laterally into other cloud environments. Because historical Git clone events were not fully available due to standard retention limits, the scope of the exfiltrated repositories could not be determined. This lack of historical visibility forced a broad, highly disruptive credential rotation across the entire organization, rather than a precise targeted response scoped to only the impacted resources.
In instances of Defense Evasion, attackers frequently delete workflow execution logs to cover their tracks and obfuscate which sensitive secrets were exposed during malicious pipeline execution. To identify these activities, it is useful to know exactly which audit events correspond to log deletion.
The “Attack Detection and Forensic Matrix” section in the poster maps the VCS audit events to the MITRE ATT&CK framework, organized by tactics, spanning the full intrusion lifecycle from Initial Access through Impact. For each tactic, it defines the attacker’s goal at that stage, alongside the specific forensic indicators and corresponding audit event names to hunt for, on each platform. Because the same action is named differently across providers, this side-by-side view lets defenders translate a single behavior into the correct query for their environment. The mass repository cloning described above, for example, surfaces as a git.clone event in GitHub, a repository_git_operation in GitLab, and a RepositoryCloneEvent in Bitbucket Data Center. By reading across a row, teams can quickly identify where their chosen platform provides rich telemetry and where it leaves gaps that must be compensated for before an incident occurs.
Architectural and Logging Differences Across Providers
Different VCS providers offer varying degrees of visibility and logging capabilities, as demonstrated in the matrix, that focus on the four most common providers.
The separation between Bitbucket Cloud and Data Center is a necessary distinction, because their audit logging mechanisms are fundamentally different. Bitbucket Cloud relies heavily on Atlassian Guard for centralized auditing, whereas Data Center operates as a self-hosted environment with entirely different log formats, locations, and retrieval methods.
Conversely, GitHub and GitLab maintain consistent audit log schemas between their SaaS and self-hosted deployments. However, self-hosted instances of GitHub and GitLab provide defenders with access to deep system-level logs such as raw HTTP request logs, database errors, and application exception logs—that are otherwise abstracted away in cloud environments. Notably, for Azure DevOps, centralized auditing and audit streaming are exclusively available in the cloud service and are not natively supported in on-premises Azure DevOps Server deployments.
A Note on Self-Hosted Solutions
Self-hosted VCS enterprise editions bring certain incident response benefits, but implementing and securing a self-hosted environment is complex and demands significant organizational responsibility, making it a challenging fit for many small and medium-sized businesses.
The primary DFIR advantage of a self-hosted solution is that all telemetry is generated and stored locally on the server. Organizations retain total ownership of ingress and egress traffic logs at the network and host levels, rather than relying solely on application-layer audit logs. Because these logs are already on-premises, responders avoid the delay of requesting extended telemetry from a SaaS vendor (a step Wiz CIRT routinely coordinates), allowing for a faster response during urgent incidents.
Operationalizing the DFIR Matrix
VCS environments are constantly evolving, and logging capabilities change with them. The poster is based on official vendor documentation and direct experience from Wiz CIRT incident response engagements.
We recommend downloading it, cross-referencing the information with current VCS configuration, and applying the recommended hardening guidelines. While platforms differ, the core DFIR methodology remains consistent: secure access, control visibility by streaming logs, and proactively monitor for behavioral anomalies.
Wiz Defend natively ingests audit logs from supported VCS platforms. Customers benefit from built-in, real-time detections that automatically monitor for the tactics and techniques detailed in the matrix.
If you experience a VCS-related breach or any cloud security incident, contact Wiz CIRT for incident response support.
Note: This guide focuses specifically on Version Control Systems. CI/CD pipeline security and logging require a distinct approach, include more providers, and will be covered in a subsequent publication.
