Access drift becomes invisible. Teams can review roles while old tokens, stale collaborators, and over-broad team grants continue to work, so the effective attack surface stays larger than the policy says. The control fails when review, secret lifecycle, and deprovisioning are not linked to the same identity event stream.
Why GitHub Permission Reviews Fail When Secrets and Offboarding Are Split
Separating repository permissions, secret handling, and offboarding breaks the control loop. A role review can look clean while a token still authenticates, a former collaborator still has access through a team path, or a secret remains valid after the account is removed. The failure is not just process fragmentation, it is a broken view of who can still act.
GitHub access is effective authority, not just listed membership. If the secret lifecycle and user lifecycle do not move together, the security team sees one state in the UI and a different state in the runtime path. That is why the question is really about whether your governance model tracks entitlement, credential validity, and removal events as one control plane.
The practical implication is that offboarding must invalidate every surviving access path, not only the human account. In GitHub environments that usually means reviewing direct grants, team inheritance, deploy tokens, personal access tokens, app credentials, and any automation tied to the departed user or stale integration.
Where Access Drift Hides in Practice
Access drift usually appears in three places: inherited repository access, long-lived secrets, and orphaned automation. Each can survive a clean-looking role review because the review only covers one object type, not the whole relationship between identity, secret, and execution authority.
In practice, the drift is easiest to miss when collaborators are added through teams, when secrets are copied into multiple repositories, or when old tokens remain valid after the person who created them has gone. The visible control says “removed,” but the effective control path still says “usable.”
This is why linking review, rotation, and deprovisioning matters more than checking each one in isolation. A GitHub repository can be formally compliant on paper and still be reachable through a forgotten secret or an indirect grant that no one revisits during offboarding.
GitHub secret sprawl is a common amplifier of this problem, especially when credentials are embedded in CI/CD or copied into multiple workflows. The Secret Sprawl Challenge is useful here because it frames the same issue from the remediation side: if secrets are not inventoried and rotated as a class, offboarding only solves part of the exposure.
Why One Identity Event Stream Has to Drive All Three Controls
The correct mental model is a single event stream for identity changes: joiner, mover, leaver, plus secret issuance, rotation, and revocation. When those events are handled separately, each team optimizes its own checklist while the attacker benefits from the overlap between them.
That overlap matters because GitHub access often persists through more than one mechanism. A former employee may lose direct access but retain a valid token; a contractor may lose a role but still belong to a team; a service path may outlive the person who approved it. The control only works when the same event that removes human access also forces a review of all derived permissions and credentials.
The strongest pattern is to treat offboarding as a revocation event, not an HR notification. That means access removal, secret invalidation, and ownership transfer all need to be triggered from the same source of truth and verified together before closure.
The lifecycle view is especially important for non-human access paths that keep working long after the original owner is gone. NHI Lifecycle Management Guide and API Key Management Guide both reinforce the same principle: rotate and revoke credentials as part of lifecycle management, not as an afterthought.
Risk and Threat Considerations
When permissions, secrets, and offboarding are disconnected, the main risk is hidden residual access. An attacker, or even a careless former insider, can keep using a valid token or inherited grant after the account review is complete, which leaves the real attack surface larger than policy reports suggest.
Failure mechanism: the organisation revokes the visible user record but leaves one or more functional access paths intact, such as a token, app credential, deploy key, or team-based grant that was not tied to the same offboarding event.
Impact: unauthorized repository access, secret reuse, persistence after departure, and delayed detection because the control evidence says access was removed even though the runtime path still works.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Offboarding gaps leave non-human access paths active after departure. |
| NHI-02 — Secret Leakage | Stale tokens and copied secrets preserve access after role review. | |
| NHI-07 — Long-Lived Secrets | Long-lived tokens keep working after the human owner is removed. | |
| Recommendation — Tie GitHub deprovisioning to revocation of every surviving credential and grant. Scan, rotate, and revoke exposed GitHub secrets as part of offboarding. Replace durable GitHub credentials with short-lived or tightly rotated secrets. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Accounts, collaborators, and teams must be provisioned and removed consistently. |
| IA-5 — Authenticator Management | Tokens and keys need lifecycle control, rotation, and revocation. | |
| Recommendation — Reconcile GitHub collaborators, teams, and automation accounts at every leaver event. Rotate and revoke GitHub tokens, keys, and secrets on the same schedule as access removal. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity records must reflect current access and removal state. |
| A.5.18 — Access rights | Access rights must be provisioned, reviewed, and withdrawn without orphaned paths. | |
| Recommendation — Keep GitHub identities, team memberships, and ownership records continuously reconciled. Withdraw GitHub access rights and confirm inherited access is removed at offboarding. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Cloud identity control must cover access lifecycle and entitlement removal. |
| Recommendation — Unify GitHub access review, secret rotation, and deprovisioning under one IAM workflow. | ||
Practitioner Guidance
What to verify: Offboarding should not be considered complete until you can prove that direct access, inherited team access, and all associated GitHub secrets or tokens have been removed or rotated. If you cannot show revocation for every effective path, the control is incomplete.
Common mistake: treating access review as separate from secret lifecycle. That split is what creates the blind spot, because the reviewer can close the account ticket while the credential continues to authenticate in automation or CI/CD.
Practitioner takeaway: The safest operating model is to make one identity event invalidate every GitHub path that can still act, because the attacker only needs one surviving credential, not a perfect account record.