1. Know what the organization audit log contains
GitHub’s organization audit log records actions that affect the organization and identifies details such as the actor, action, time, affected user, and repository when applicable. Organization owners can search the log and GitHub Enterprise Cloud organizations can retrieve it through the audit log API.
This is not the same as repository contents, code-scanning alerts, a personal account security log, or an enterprise-wide audit stream. Keep those boundaries visible throughout the investigation.
GitHub reference: Reviewing the organization audit log
2. Bound the search with GitHub qualifiers
Begin with the organization, UTC time range, and strongest known field. GitHub supports qualifiers including actor, repo, action, operation, and created. Use the full owner/repository value for repository searches.
By default, GitHub displays recent events; older activity requires an explicit date range. Git event availability is shorter than other organization audit activity, so preserve relevant entries early.
3. Reconstruct the actor, action, and target
- Actor?
- Confirm the username or integration and whether it normally performs this action.
- Action?
- Record the exact category and operation rather than relying on a broad description.
- Target?
- Identify the organization, repository, team, member, application, or setting affected.
- When?
- Preserve exact UTC timestamps and inspect the sequence around the event.
- Where?
- Use available country or IP context carefully; GitHub does not disclose source IPs by default.
- Intent?
- Compare the action with pull requests, tickets, onboarding, offboarding, and owner confirmation.
4. Prioritize high-impact organization changes
Start with changes that can expand access, weaken a control, or expose a repository. Exact action names matter because similarly worded events can support different conclusions.
| Audit action | Observed change | First question to verify |
|---|---|---|
org.update_member | A member role changed; a member-to-owner transition is high impact when both roles are present. | Was the owner promotion approved and time-bounded? |
repo.access | Repository visibility changed, including private or internal to public when both values are present. | Does the repository contain code or configuration that should not be public? |
repository_ruleset.update | A ruleset changed; supplied transition fields may show enforcement being disabled. | Which enforcement state changed, and is there a matching change record? |
protected_branch.policy_override | A branch-protection policy override was recorded. | Who performed the override, against which repository and branch, and why? |
integration_installation.repositories_added | A GitHub App installation gained access to named repositories. | Was the application expected, and who approved the added repository access? |
personal_access_token.access_granted | A fine-grained token received organization resource access. | Does the token owner, resource scope, and approval match the intended task? |
secret_scanning.disable | Secret scanning was turned off for existing repositories. | Was the control disabled deliberately, and has it been restored? |
GitHub reference: organization audit-log event reference
5. Example investigation: an App gains repository access
This hypothetical walkthrough shows the evidence sequence; it is not a customer incident. An organization audit entry reports that a GitHub App installation gained access to two repositories. Preserve the source ID, actor, application, repositories, and UTC timestamp before interpreting it.
- Confirm whether the actor normally manages GitHub App installations and whether a ticket or owner approval exists.
- Inspect adjacent App installation or update events. Added repository access does not prove the App read or changed repository data.
- Review the App's current organization permissions and repository selection in GitHub. The audit entry may not describe every present-day permission.
- Check the affected repositories for coincident ruleset, visibility, deploy-key, collaborator, or workflow-policy changes.
- Record the supported conclusion separately from the open questions: access expanded to named repositories; intent and data use remain unproven.
6. Keep collection limits separate from conclusions
GitHub documents up to 180 days for organization audit activity, while Git events are retained for seven days and require the REST API. Source IP visibility is optional and conditional. A missing field or event can reflect collection, feature, plan, or configuration limits—not proof that an action did not occur.
Preserve the original record, query, timestamps, actor, target, and related change references. Escalate unexplained access or security-setting changes through your incident process.
GitHub references: organization audit-log events and source IP visibility
GitHub audit-log FAQ
What does the GitHub organization audit log contain?
It records organization-level actions and identifies evidence such as the actor, action, timestamp, affected user, repository, or setting when GitHub supplies those fields. It is not a copy of repository contents or an enterprise-wide stream.
How long are GitHub organization audit logs retained?
GitHub documents up to 180 days for organization audit activity. Git events have a shorter seven-day window and require the REST API, so preserve them early when they matter.
Which events should a small team review first?
Prioritize owner and membership changes, repository visibility or access changes, ruleset and branch-protection changes, App and token access, and security controls being disabled.
Saved reviews
GitHub audit log analysis in Flare
Flare’s GitHub App reads organization web audit events from GitHub Enterprise Cloud and reports directly observed changes with exact source IDs, caveats, and coverage limits. It uses deterministic rules without sending audit events to an AI provider, and never stores raw events. Findings are saved for 90 days. Git operations such as clone, fetch, and push are excluded, along with repository contents, personal security logs, enterprise-wide streams, and GitHub Enterprise Server logs.
Sign in to check connection availability. Connecting starts a saved 30-day retrospective; manual checks cover the last day, 7 days or 30 days, and each UTC day reads at most three pages or 300 web events. Deploy webhooks, file uploads and follow-up chat are unavailable for this source.
This source is separate from Flare’s GitHub Actions integrations, which are available today. Findings remain investigative leads.