GitHub telemetry sources
GitHub Enterprise provides an audit log that covers: organisation and repository settings changes, team membership changes, Actions workflow runs, secret access events, and deployment events. The audit log is the primary source for security monitoring — it captures intent-level actions rather than system-level events.
GitHub Advanced Security (GHAS) adds secret scanning alerts, code scanning alerts, and Dependabot findings. These should be ingested as enrichment signals in the entity graph — when a secret scanning alert fires for a repository that has an active Actions workflow with deployment permissions, the risk profile of that workflow escalates.
Critical GitHub events for detection
Repository settings: branch protection rule removed, required reviews reduced to zero, Actions permissions changed to allow any action. Organisation settings: new organisation owner added, OAuth application granted organisation-wide access, SAML SSO disabled. Actions: workflow run with new or modified workflow file, secret accessed in a workflow run not matching the expected pattern.
Workflow file modification is particularly high-signal: a new commit modifying a .github/workflows/*.yml file in a repository with deployment permissions should always generate a finding. The entity graph correlates the committer identity, the repository's deployment targets, and the secrets accessible in that workflow environment.
# detections/github/branch_protection_removed.yaml
key: github.branch_protection_removed
domain: code_repository
severity: high
type: streaming
where:
class_uid: 3005
source: github_audit_log
action: "protected_branch.destroy"
outcome: success
graph:
condition: repository_has_active_deployment_environment
attck:
tactic: TA0003
techniques: [T1195.001]
stage: activeActions secrets and supply chain risk
GitHub Actions secrets are credentials that exist only within the Actions runtime — they are not queryable via the API and do not appear in audit logs. What you can detect is the workflow run context: which secrets were requested, which environment they came from, and whether the workflow file requesting them was modified in the same commit.
A workflow run that requests deployment credentials but was triggered by a PR from a fork, or by a user who was added to the repository in the last 24 hours, is a high-risk pattern. The entity graph models repository membership tenure and deployment trigger patterns — these two dimensions together are highly discriminative.
Response patterns for GitHub incidents
For a confirmed malicious commit: immediate branch protection rule enforcement on the affected branch, revocation of the committer's repository access, rotation of all secrets referenced in modified workflow files, and notification of the deployment targets.
For a compromised Actions runner: investigation of all workflow runs in the last 24 hours that used the runner, review of all secrets accessed, and audit of deployment events from those runs. The entity graph makes the blast radius determination fast — query all downstream resources that received a deployment from the compromised runner.
Key takeaways
- GitHub is both a repository and an execution environment — compromise reaches every downstream deployment.
- Workflow file modification in a repository with deployment access is always a high-severity finding.
- Branch protection removal, Actions permissions changes, and new org owners are critical control-plane events.
- GitHub App installations are persistent access grants — monitor new installations on sensitive repositories.
- Blast radius determination for runner compromise requires correlating deployment targets via entity graph.
- GHAS findings are enrichment signals that elevate risk when combined with workflow activity.