Wazuh GitHub audit log monitoring

The first decision is which collection method the Wazuh documentation describes for GitHub audit events, because that choice determines who holds the credential, how quickly events reach the server and what happens during an outage. Before you build anything, open the GitHub integration guide in the Wazuh documentation for the release line you plan to run (the current line is 4.14) and confirm which methods it describes, what each one requires on the GitHub side and what each one requires on the Wazuh side. Record the answer in the design document so the later decisions in this section have a fixed reference point.

The data path has four stops. GitHub produces audit events for the organization. The collection method, whichever one you choose, moves those events to the Wazuh server. The server applies decoders, which break each raw event into named fields, and then rules, which decide whether an event matters and how severe it is. Matching events become alerts, and the Wazuh indexer stores them for search and analysis before the Wazuh dashboard displays them. Check that the decoders and rules shipped with your Wazuh version cover the GitHub event types you care about, such as membership changes, team and permission changes, repository visibility changes and changes to protected branches. Gaps in rule coverage are a common reason detection looks complete on paper and misses real activity.

If the method polls the GitHub API on a schedule, the polling interval sets the trade-off between detection latency and API consumption. A short interval shortens the time between an account change and its alert, but it spends more of your API budget. GitHub applies rate limits to API calls, and those limits are shared by every tool that uses the same token. Confirm the current limits for the audit log endpoints and the token type you plan to use, then size the interval so normal collection stays well below them with room for retries. Also plan for collection to stall, and alert when the most recent event timestamp falls behind the expected time.

GitHub does not keep audit events indefinitely, so the retention window on GitHub's side limits how far back you can recover after a collector outage. Ask GitHub to confirm the retention period that applies to your organization's plan and then compare it with the longest outage your operations team could take to repair. If the window is shorter than that outage, a polling design needs a monitoring alert that fires before the window closes. If the method forwards events to a receiver you operate, retention moves to your side, but the receiver becomes an internet-facing or network-reachable service you must secure. Confirm whether your organization's plan supports the forwarding option at all before you choose it.

Whoever holds the GitHub credential can read the organization's audit trail, so treat that credential as a high-value secret. Use a dedicated service identity rather than a personal account, grant only the read permissions the chosen method needs, record a named owner, store the token in a secrets manager and set a rotation schedule. In a polling design, the Wazuh server holds the credential, so restrict access to its configuration files and to the host. In a forwarding design, you manage a shared secret or endpoint credential that GitHub or the receiver must present, and you should decide who can rotate it. Finally, monitor the service identity's own activity, because a compromised collector credential is one of the cases this monitoring is meant to catch.

A single GitHub audit event rarely justifies waking anyone up. Adding a member, changing a repository setting or creating a token can each be routine. The signal comes from sequences that a compromised account tends to produce within a short window. In a Wazuh deployment, that usually means writing a base rule for each relevant audit event, then a correlation rule on the Wazuh server that fires only when related events occur together within a set timeframe. Five patterns are worth starting with: a new member added to an admin team shortly after a token or SSH key is created, a repository switched to public, branch protection removed before a push, sign-ins or token use from unexpected locations or outside working hours, and many changes made by one actor in a short period. Confirm the exact action names and fields your GitHub audit log produces before writing any rule.

None of these patterns should ship with default thresholds. What counts as unusual depends on how your organization already works. Release managers may remove branch protection every sprint, CI service accounts may create tokens on a schedule, and some teams may add contractors to admin groups during onboarding. Before tuning, collect a baseline of normal change activity covering at least one full release cycle, and record which actors, teams and hours appear in it. Then decide, for each pattern, the time window, the number of events that counts as a bulk change, and which locations or hours are expected. Those decisions belong to the client's security and engineering leads, and each value should be written down with its reason so auditors and future responders can follow it.

Location and time-of-day checks depend on data your environment actually contains. Confirm whether the audit entries you ingest include the source address for sign-ins and token use, how your team maps those addresses to known office, VPN and CI ranges, and whether the dashboard can filter on them without extra enrichment. Also confirm how delayed audit events arrive. A correlation rule that expects a token creation before a membership change will miss the pair if the events land out of order or outside the timeframe. Build the rule so that a late event does not silently break the chain, or document the gap so triage knows to check the raw log.

Treat each pattern as an indicator that starts triage, not as proof of compromise. The alert should tell the responder which account acted, which events matched, and what the approved change process would have looked like, so they can confirm with the account owner and the change record. Test every rule before it pages anyone. Replay known benign sequences from a sandbox or staging organization, run simulated sequences that match each pattern, and count the false positives and misses. Record the rule identifiers, the tuned values and the test results, because those records show how the detection was built and when it was last reviewed.

Before any GitHub audit log alert is treated as a control, the team should prove that a known action produces the expected event, decodes correctly in Wazuh and triggers the intended rule. The test plan is the mechanism for that proof. It should run against a sandbox GitHub organization or a dedicated test team, never against production teams, and every test action must be approved in writing by the GitHub organization owner before it runs. Agree the approver, the test window and the rollback steps in that approval so the person who owns the organization knows exactly what will change and when it will be reversed.

Choose test changes that are controlled and reversible, and that map to the alert categories the page covers. A useful first set is adding a test user to a test team and then removing them, changing the visibility of a throwaway repository and changing it back, and creating a fine-grained personal access token or other credential in a test account and then revoking it. For each action, record the exact time, the actor, the target and the expected audit log action name. Then confirm three things in Wazuh: the event was ingested, the decoder extracted the fields the rule depends on (actor, organization, action and target), and the rule that should match did match, at the level you expect. A test that only shows an event arrived is not enough, because a missing or mis-decoded field can silently stop a rule from firing.

Measure the end-to-end delay from the GitHub action to the point where the alert is visible in the Wazuh dashboard. Run each test several times, at different times of day, and record the minimum, maximum and typical delay. GitHub's audit log delivery, the collection method you chose, and the Wazuh ingestion path all contribute to this number, so note which component you are timing. Ask the team that will act on alerts what delay they can tolerate for each category, such as a removed administrator versus a routine membership change. If the measured delay is longer than that tolerance, the alert is a record rather than a response trigger, and the runbook should say so.

Record every result as evidence in a test log that can be reviewed later. For each test, keep the action taken, the approval reference, the raw audit log entry, the decoded fields in Wazuh, the rule ID and level that matched, the measured delay, the pass or fail outcome and the name of the person who checked it. Keep the rule definitions and their version alongside the log, because a later rule change can invalidate an earlier pass. Also plan for failures: a failed test should open a tracked defect against the decoder, the rule or the collection setup, and the alert should not be relied on until the test passes again. Repeat the full test set after each Wazuh upgrade or change to the GitHub integration, since either can change decoding behavior.

Before you start, confirm with the GitHub organization owner which audit log events your plan and plan tier expose, which API or streaming method you will use, and whether the test accounts can be created and removed without affecting billing or security policies. Confirm the Wazuh components and versions in your environment against the Wazuh release notes and your own change records, because the rules and decoders you test must be the ones that will run in production. These checks determine whether the test plan can be executed as written, and they belong in the approval request.