GitHub Audit Log Monitoring
Every bypass and cover-up leaves a trace in the audit log — the only question is whether anyone is watching. This is a catalogue of the events worth alarming on: branch-protection overrides, force-pushes to protected branches, workflow run deletion, new secrets, new OAuth tokens / PATs, app installs, member role changes and SSO/2FA being disabled — each with the audit-log action name(s) and copyable example detection logic. Mark what you alert on today for a coverage score. Nothing is uploaded.
For each event, mark whether you alert on it, merely log it, or have no coverage, and copy the detection note into your SIEM. Events tagged LiteLLM are the ones a bypass-and-cover-up produces. Action names follow GitHub's audit-log reference but change over time — confirm against your own log. Scored in your browser.
- Branch-protection / ruleset override or changeLiteLLMcritical
Someone bypassing or weakening a protected-branch rule or ruleset is the single highest-signal event — it is how a bypass is set up or an admin steps around review.
protected_branch.policy_overrideprotected_branch.update_admin_enforcedprotected_branch.destroyrepository_ruleset.updaterepository_ruleset.destroyaction IN ( "protected_branch.policy_override", "protected_branch.destroy", "repository_ruleset.update", "repository_ruleset.destroy" ) => alert: "Branch protection changed/overridden" enrich with actor, repo, branch; page on destroy/override of a release branch
- Force-push to a protected branchLiteLLMcritical
Force-push rewrites history and is the classic cover-up move. On a protected branch it should be impossible — so any occurrence is an incident.
protected_branch.policy_overridegit.force_pushaction = "git.force_push" AND ref IN (protected_branches) OR (action = "protected_branch.policy_override" AND note ~ "force") => alert: "Force-push to protected branch" (page immediately) Note: git events must be enabled in the audit log to see git.force_push.
- Workflow run / log deletionLiteLLMhigh
Deleting Actions run records destroys the evidence of what CI did. In a supply-chain cover-up, run deletion follows the exfiltration and release steps.
workflows.delete_workflow_runworkflows.cancel_workflow_runrepo.remove_actions_secretaction IN ("workflows.delete_workflow_run", "workflows.cancel_workflow_run") => alert: "Workflow run deleted/cancelled" baseline is near-zero for most orgs; alert on any, correlate with release activity - New Actions / environment / Dependabot secret added or changedLiteLLMhigh
A new or overwritten secret can redirect a pipeline (a swapped registry token, an attacker-controlled endpoint). Secret writes should be rare and attributable.
org.create_actions_secretrepo.create_actions_secretenvironment.add_secretenvironment.update_secretdependabot_secrets.createaction ~ "create_actions_secret" OR action ~ "add_secret" OR action ~ "update_secret" => alert: "Secret created/updated" (actor, repo/env, secret name — never the value) flag writes outside change windows or by unexpected actors
- OAuth token / PAT created or authorized against the orgLiteLLMhigh
A new token acting on the org is new standing reach. A PAT authorized under SSO, or an OAuth grant to an app, is exactly the credential an attacker wants to mint or approve.
oauth_authorization.createoauth_access.createpersonal_access_token.access_grantedpersonal_access_token.request_createdaccount.pat_access_grantedaction ~ "oauth_authorization.create" OR action ~ "personal_access_token.access_granted" => alert: "New token/OAuth grant on org" compare against expected automation; alert on broad scopes or unknown apps
- Third-party OAuth / GitHub App approved or installedhigh
Each approved OAuth app or installed GitHub App holds a continuous, scoped credential on your org. Approvals and installs should be deliberate and reviewed.
oauth_application.createintegration_installation.createintegration_installation_request.createorg.oauth_app_access_approvedaction IN ("integration_installation.create", "org.oauth_app_access_approved") => alert: "New app installed/approved on org" review requested permissions and target repos before/at approval - Member role change / new owner / team privilege changeLiteLLMhigh
Promotion to owner (or admin) is privilege escalation. An attacker who lands a foothold often grants themselves or a sock-puppet more access.
org.update_memberorg.add_memberteam.add_memberteam.promote_maintainerbusiness.add_adminaction = "org.update_member" AND permission_to = "admin" (promotion to owner) OR action = "org.add_member" AND role = "admin" => alert: "Org owner/admin granted" (page on new owner)
- SSO / 2FA requirement disabled or weakenedhigh
Turning off enforced SSO or the org 2FA requirement removes a central control. It should never happen quietly.
org.saml_disabledorg.disable_two_factor_requirementorg.update_saml_provider_settingsaction IN ("org.saml_disabled", "org.disable_two_factor_requirement") => alert: "Org-wide auth control disabled" (page immediately) - Repository made public / transferred / deletedmedium
A private repo flipped public is an instant data exposure; a transfer or deletion can be exfiltration or destruction.
repo.accessrepo.renamerepo.transferrepo.destroyaction = "repo.access" AND visibility_to = "public" OR action IN ("repo.transfer", "repo.destroy") => alert: "Repo visibility/ownership change" - New repository / org webhook createdmedium
A webhook is a quiet exfiltration channel — it can stream events and payloads to an attacker-controlled endpoint.
hook.createorg.hook_createrepo.config.enable_anonymous_git_accessaction IN ("hook.create", "org.hook_create") => alert: "New webhook" (inspect destination URL; flag non-allowlisted hosts)
Everything is scored and generated in your browser — nothing is uploaded. Audit-log action names follow GitHub's documentation and change over time; confirm each against your own log before deploying a rule. Educational — not affiliated with GitHub.
What this catalogue is
- A catalogue of the GitHub audit-log and org-webhook events worth alarming on — branch-protection overrides, force-pushes to protected branches, workflow run deletions, new secrets, new OAuth tokens/PATs, app installs, member role changes, SSO/2FA being disabled, repos going public and new webhooks.
- Each event comes with the audit-log action name(s) to match, why it matters, and copyable example detection logic you can adapt for your SIEM.
- Mark whether you Alert / Log only / have No coverage on each to get a weighted 0–100 detection-coverage score and a list of what is still unmonitored.
- Events tagged "LiteLLM" are exactly the ones a bypass-and-cover-up produces: override a rule, delete the run record, add a secret, mint a token, force-push, escalate a role.
- 100% client-side. Copy one note or all of them, or export. GitHub revises audit-log action names over time, so confirm each against your own log before deploying.
Why this matters
In the October 2026 LiteLLM GitHub-identity supply-chain compromise, as publicly reported, the attacker exfiltrated CI secrets, shipped a release built from a fork source, deleted workflow run records and force-pushed to cover up. Each of those actions is an audit-log event. The difference between catching it in hours and discovering it much later is simply whether a detection was watching those actions.
Prevention controls — branch protection, least-privilege tokens, release gates — are the first line, but they are never perfect, so detection is the backstop. The highest-value alerts are the ones whose normal rate is essentially zero: nobody should be overriding a protected branch or deleting run records on a healthy repo, so a single occurrence is worth paging on. Stream the audit log somewhere durable, alert on the critical events, tune the rest to your baseline, and test that each rule actually fires — a detection you have never seen trigger is a detection you cannot trust. This is an educational resource referencing a real, reported incident for context; PlayCISO is not affiliated with LiteLLM or GitHub.
Frequently asked questions
Where do I find these events?
In your organisation's audit log (Settings → Logs → Audit log), and better, by enabling audit log streaming to your SIEM or log pipeline so the events are retained and alertable rather than only visible in the UI for a window. Some events — like git.force_push — only appear if Git events are enabled in the audit log settings. Org webhooks can deliver a subset of these in near-real-time too.
Are the action names exact?
They follow GitHub's audit-log reference and are correct as patterns to look for, but GitHub adds and renames audit-log actions over time, and some vary by plan (for example Enterprise-only events). Treat the provided names and logic as a starting point: validate each against your own audit log, confirm the field names your export uses, then deploy the rule. The tool says this on every note.
Which events should page a human versus just raise a ticket?
The critical-tagged ones — a branch-protection/ruleset override or a force-push to a protected branch — should page immediately, because on a healthy org their baseline is essentially zero and each is a strong bypass signal. Workflow run deletions, new org owners, and SSO/2FA being disabled are close behind. Lower-severity events (a new webhook, a repo going public) are worth a reviewed alert but rarely a page. Tune thresholds to your own baseline.
How does this tie to the LiteLLM incident?
The October 2026 LiteLLM compromise, as publicly reported, included CI secret exfiltration, a fork-sourced release, deletion of workflow run records, and a force-push to cover the tracks. Every one of those leaves a trace in the audit log — a secret event, a run deletion, a force-push/override — so whether the attack is caught in hours or discovered much later comes down to whether anyone was alerting on those actions. That is what this catalogue is for. It references a real, reported incident for context and is not affiliated with LiteLLM or GitHub.
Does my input leave the browser?
No. The checklist is scored and the detection notes are assembled entirely client-side. Nothing is read from GitHub and nothing is uploaded; you copy or download what you want to keep.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.