How do you detect GitHub repositories or organisations being transferred?

Detect transfers by monitoring repository and organisation audit events for ownership changes, then confirming the new owner and any permission resets. Review whether webhooks, secrets, collaborators, and Actions permissions changed during the transfer. Unexpected transfers can disrupt controls or move code and workflow trust to an unauthorised owner, so investigate immediately.

How to spot a repository or organisation transfer in GitHub

Transfers are usually visible first in GitHub audit events, so the key is to watch for ownership-change activity rather than waiting for a functional outage. The practical question is not just who owns the repository now, but whether the transfer also reset collaborators, Actions permissions, webhooks, or secrets in ways that changed the trust boundary.

For teams that rely heavily on GitHub as a delivery surface, the safest starting point is the transfer event itself and the permissions state immediately before and after it. NHIMG’s GitHub and GitHub Actions Security Guide is useful here because it ties repository governance to workflow trust, audit logging, and secret handling rather than treating them as separate problems.

What evidence confirms that a transfer really happened?

Audit logs should show the ownership change, but confirmation should not stop there. Verify the new owner, whether the repository moved between personal and organisation scope, and whether access controls were re-evaluated as part of the transfer. A repository can look intact while silently changing who can administer it, approve workflows, or reconfigure integrations.

In practice, the most useful confirmation checks are identity of the new owner, changes to collaborator membership, whether branch protection or rulesets were altered, and whether secrets or deploy-related settings were preserved or recreated. If the transfer was unexpected, treat the event as a trust shift first and a content move second.

What should you review after the ownership change?

Review the surrounding control surface, not just the repository name. Webhooks can redirect events to a new destination, Actions permissions can widen or narrow workflow execution, and secrets may be inherited, reissued, or made unavailable depending on the transfer path. If the repository is part of an organisation, also check whether organisation-level policy changed in parallel.

Unexpected repository movement is a common place where secret exposure and trust assumptions diverge. NHIMG’s Toyota T-Connect key exposure 2022 is a reminder that public GitHub exposure and secret lifecycle failures can persist for years when ownership and discovery controls are weak.

Risk and Threat Considerations

A transfer can create security exposure even when the code itself is unchanged. The main risk is that a legitimate ownership event may also move administrative control, workflow trust, and secret handling into a new boundary that your team no longer governs. If the transfer is unauthorised, it can also be used to redirect integrations or obscure subsequent malicious changes.

Failure mechanism: Attackers or insiders may abuse stale permissions, weak monitoring, or delegated admin paths to move a repository or organisation, then rely on the new trust state to alter workflows, webhook destinations, or secret access without immediate detection.

Impact: The result can be unauthorised code governance, broken CI/CD trust, hidden access to sensitive automation material, or loss of control over code and release processes.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1098 — Account Manipulation	Unauthorized ownership changes can reflect account or access manipulation.
Recommendation — Correlate repository transfers with account manipulation detections and review admin activity.
CIS Controls v8	CIS-5 — Account Management	Repository transfer review depends on tracking account and access changes around ownership.
Recommendation — Audit account and access changes tied to the transfer and revoke unnecessary permissions.
NIST SP 800-53 Rev 5	AU-6 — Audit Record Review, Analysis, and Reporting	Detecting transfers relies on reviewing audit events for ownership and permission changes.
	AC-6 — Least Privilege	Transfers can widen access if permissions are not reset to least privilege.
Recommendation — Review audit records for ownership changes and investigate unexpected transfer activity promptly. Revalidate post-transfer access and remove any excess permissions immediately.

Practitioner Guidance

What to verify: Confirm the transfer event in audit data, then compare pre-transfer and post-transfer states for owner, collaborators, Actions permissions, secrets availability, and webhook endpoints. If the repository is mission-critical, also validate whether any inherited automation now runs under a different trust boundary.

Escalation / exception: Treat any transfer you did not approve as a security incident, not a routine admin change. Even an expected transfer should be escalated if workflow permissions, secret scope, or repository visibility changed in a way that was not documented.

Practitioner takeaway: The transfer event is only the starting signal, the real control question is whether the move also changed who can execute code, reach secrets, or re-point integrations.