Common security incident investigation areas

Reference for investigating security incidents across multiple attack vectors, including the key surfaces and tools to check on GitHub.

This reference article shows you which GitHub tools to use and which GitHub surfaces to check when you're responding to a security incident. Use this article to guide your investigation across major threat categories.

For full guidance on how to respond to a security incident, including containment strategies, see Responding to a security incident.

Exposed or compromised credentials

This section may apply when:

You suspect a token or key has been stolen or exploited, received a secret scanning alert, or found credentials exposed in code, logs or a public repository.

What to check

• Search the audit log for:
  • Actions taken by the compromised token, by searching for all events associated with that token. See Identifying audit log events performed by an access token.
  • Actions taken by unexpected actors or unknown IP addresses (if IP address disclosure is enabled).
• Review secret scanning alerts for relevant findings to assess a leaked secret's location, exposure and validity.
• Use security overview for your enterprise or organization to identify trends or activity across repositories.
• Use GitHub code search to check for secrets exposed in code, .env files, or configuration files across repositories.

Key tools

Key resources

• Containment actions
• Remediating a leaked secret in your repository

Unauthorized access and account compromise

This section may apply when:

You noticed unusual login activity, saw unexpected commits or changes, or detected suspicious account behavior.

What to check

• Search the audit log for member access, permissions, or role changes. For example, look for events such as org.add_member, repo.add_member, org.add_outside_collaborator, org.update_member, repo.update_member, role.create, role.update.
• For any suspicious events in the audit log, identify the actor. Check if the actor is an unknown user, a potentially compromised account, or an unrecognized app.
• If you have IP address visibility enabled, check if the IP address associated with unusual events or suspicious activity is recognized.
• Search the audit log for events relating to newly created deploy keys or apps, for example public_key.create, integration_installation.create.
• Review the audit log for unexpected repository changes, such as new public repositories or repository visibility changes (private to public), for example repo.create, repo.access.
• Use the activity view (repository-level) to build a timeline of recent pushes. Look for pushes from unexpected actors, force pushes, or unusual branch names.

Key tools

Key resources

• Containment actions

Data exfiltration

This section may apply when:

You detected large downloads, unusual API activity, or received reports of your data appearing externally.

What to check

• Search audit logs for high-volume git operations (git.clone, git.fetch) or API requests, particularly from an unfamiliar actor (actor) or IP address (if IP address visibility is enabled), that indicate bulk data collection.
  • Note that Git events in the audit log have special access requirements and retention policies that differ from other audit log events. For GitHub Enterprise Cloud, you can access Git events via the REST API and data is retained for seven days, unless you are streaming the audit log. For GitHub Enterprise Server, Git events must be enabled in the audit log configuration and are not included in search results.
  • Similarly, capturing API activity in the audit logs requires prior configuration and is not available by default.
• Check the audit logs for repository replication or exposure events, for example, repository visibility changes (from private to public), unexpected new repositories being created (such as new public repositories) or repositories being renamed or transferred (repo.create, repo.access (visibility changes), repo.rename, repo.transfer).
• Check for outbound mechanisms, for example webhooks being created or updated (hook.create or similar events in the audit logs), and check if any webhook points to an unrecognized domain.

Key tools

Key resources

• Containment actions

Malicious code and workflow changes

This section may apply when:

You found suspicious code in your repository, a security researcher reported an issue, or you noticed unexpected workflow behavior.

What to check

• Review the Actions tab for unexpected workflow runs, especially those triggered by unfamiliar users or at unusual times.
• Inspect workflow run logs for suspicious output.
• Review the credentials accessible to suspicious workflow runs, including the default GITHUB_TOKEN, any personal access tokens, GitHub App tokens, or other credentials stored as secrets. The GITHUB_TOKEN is scoped to the job and expires when the job completes, but other credentials have their own lifecycle and do not expire with the job. Any credential that may have been exposed should be treated as compromised and rotated or replaced immediately.
• Be aware that workflow run logs only capture standard output from workflow steps. Activity that does not write to standard output (such as network calls, file system modifications, or background processes) will not appear in the logs. For a more comprehensive investigation, correlate with audit log events.
• Use GitHub code search to find suspicious files or code additions, particularly in workflow files (.github/workflows/), shell scripts, or configuration files.
• Use the Activity view to check for pushes to unusual branch names, force pushes, pushes from unexpected actors.
• Check the audit logs for changes to security settings or disablement actions (look for events like repository_ruleset.destroy, repository_secret_scanning_push_protection.disable, or other .delete, .disable, .destroy events).
• Check the audit logs for events relating to new self-hosted runners being added (for example, org.register_self_hosted_runner, repo.register_self_hosted_runner events).
• Check for Dependabot alerts or the GitHub Advisory Database for advisories related to GitHub Actions used in your workflows.

Key tools

Key resources

• Containment actions
• GITHUB_TOKEN
• Secure use reference

Malware and supply chain attacks

This section may apply when:

You received a malware or dependency alert, suspect a malicious package, or noticed unexpected dependencies in your projects.

What to check

• Check for a Dependabot malware alert, which can tell you details about the malicious package (such package name, affected versions, and the patched version), as well as remediation steps. Currently supported for packages in the npm ecosystem only.
• Search the GitHub Advisory Database to see if GitHub is reporting advisories for dependencies (or dependency versions) that your projects are using. For malware specifically, search type:malware in the advisory database.
• Use GitHub code search to search for references to the suspected package or action across your organization.
• Review the dependency graph for your repositories to identify any new or unexpected dependencies.
• Use activity view and check commit history to review recent changes to dependency manifests or lockfiles (for example, package.json, package-lock.json, Gemfile.lock). Check blame views and pull requests to identify who introduced the changes and whether they were reviewed.
• Review recently created security alerts in your organization's security overview.

Key tools

Key resources

• Containment actions

Further reading

• Responding to a security incident
• Reviewing the audit log for your organization
• Audit log for an enterprise