GitHub Enterprise Audit Log Events
Location
GitHub Enterprise or organization audit log UI and REST APIDescription
Audit events for enterprise and organization activity in GitHub, including repo administration, membership changes, authentication and token events, app changes, and security-relevant administrative actions.
Forensic Value
GitHub audit logs are essential for source-code and CI/CD investigations. They show who changed org membership, created or rotated tokens, modified repository settings, added apps, or accessed administration features that could enable code theft or supply-chain abuse.
Tools Required
Collection Commands
gh CLI
gh api /enterprises/<enterprise>/audit-log?phrase=created:>=2026-03-01 > github_enterprise_audit_log.json
GitHub UI
Enterprise settings > Audit log > Filter by actor, repo, action, and date range > Save the results and query parameters used
Collection Constraints
- •Audit log retention in the UI or API is limited; long-term preservation depends on regular export or audit streaming.
- •Enterprise-level visibility depends on the GitHub plan and the privileges of the account performing the collection.
MITRE ATT&CK Techniques
References
Used in Procedures
Related Blockers
Cloud or Container Logging Coverage Missing
The investigation depends on cloud-control-plane or container telemetry that was never enabled, was retained too briefly, or was routed to an unavailable destination. This creates blind spots around identity misuse, cluster administration, and workload behavior.
SaaS Audit Logging Not Enabled or Not Licensed
The investigation depends on SaaS audit evidence that was never enabled, is unavailable under the current subscription tier, or requires a higher-privilege admin role than the response team currently has. This creates blind spots for identity abuse, collaboration-platform misuse, and source-code access.
SaaS Audit Retention Expired Before Collection
The response started after the native retention window for Google Workspace, Okta, Slack, GitHub, or similar SaaS evidence had already passed. The necessary events are no longer available in the vendor UI or API even though the underlying accounts and content may still exist.
Attack Delivered via Legitimately Signed Update
The malicious artifact carries a valid signature from the vendor's real signing key, so traditional allow-by-signature controls (Authenticode policy, Cosign verification, macOS notarization) do not flag it. Detection must pivot to behavioral indicators, reputation, and anomaly-based signals.
Compromised Vendor Artifact Provenance Lost
The compromised software was distributed through a legitimate channel (update server, package registry) but the vendor cannot or will not produce the exact pre-compromise build artifacts, build manifests, or signing-chain evidence needed to validate provenance. Without that baseline, it is difficult to definitively identify what was malicious versus legitimate in the distributed artifact.