Detection rules › Panther
GitHub Repository Collaborator Change
Detects when a repository collaborator is added or removed.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Initial Access | T1195 Supply Chain Compromise |
Rule body yaml
AnalysisType: rule
Filename: github_repo_collaborator_change.py
RuleID: "Github.Repo.CollaboratorChange"
DisplayName: "GitHub Repository Collaborator Change"
Enabled: true
LogTypes:
- GitHub.Audit
Tags:
- GitHub
- Initial Access:Supply Chain Compromise
Reports:
MITRE ATT&CK:
- TA0001:T1195
Severity: Medium
Description: Detects when a repository collaborator is added or removed.
Runbook: Determine if the new collaborator is authorized to access the repository.
Reference: https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/managing-an-individuals-access-to-an-organization-repository
Tests:
- Name: GitHub - Collaborator Added
ExpectedResult: true
Log:
{
"actor": "bob",
"action": "repo.add_member",
"created_at": 1621305118553,
"org": "my-org",
"p_log_type": "GitHub.Audit",
"repo": "my-org/my-repo",
"user": "cat",
}
- Name: GitHub - Collaborator Removed
ExpectedResult: true
Log:
{
"actor": "bob",
"action": "repo.remove_member",
"created_at": 1621305118553,
"org": "my-org",
"p_log_type": "GitHub.Audit",
"repo": "my-org/my-repo",
"user": "cat",
}
- Name: GitHub - Non member action
ExpectedResult: false
Log:
{
"actor": "bob",
"action": "repo.enable",
"created_at": 1621305118553,
"org": "my-org",
"p_log_type": "GitHub.Audit",
"repo": "my-org/my-repo",
"user": "cat",
}
Detection logic
Condition
action in ["repo.add_member", "repo.remove_member"]
Indicators
Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.
| Field | Kind | Values |
|---|---|---|
action | in |
|
Output fields
Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.
| Field |
|---|
user |
repo |