How should security teams find inactive contributors who still have access to business-critical repositories containing secrets?

Security teams should query for contributors who are inactive but still linked to repositories that hold secrets or production assets. Then revoke access, rotate any exposed credentials, and add alerts for suspicious activity. The key is to treat departed users and stale permissions as an active exposure path, not a housekeeping issue. Fast review of repository ownership closes a common entry point.

Why This Matters for Security Teams

Inactive contributors are often treated as an HR hygiene issue, but the real risk is authorization drift around repositories that contain secrets, deployment configs, or production access paths. Once a former contributor can still read code, browse history, or clone a repo, the organisation may already have exposed API keys, tokens, certificates, or workflow credentials. That makes access review and secret rotation one process, not two. NHI Management Group has repeatedly highlighted how secret sprawl turns ordinary repo access into a durable compromise path in the Guide to the Secret Sprawl Challenge.

This is also why static permission models are fragile. A contributor can appear inactive in identity records while still retaining access to business-critical repositories through inherited roles, forgotten team membership, or stale service ownership. OWASP’s Non-Human Identity Top 10 is useful here because the same failure pattern applies: long-lived access and untracked secrets create an easy path from repo visibility to broader compromise. In practice, many security teams discover inactive-but-privileged accounts only after a leaked secret is already being used from elsewhere.

How It Works in Practice

The practical workflow is to correlate contributor activity, repository sensitivity, and secret exposure in one review. Start by identifying repos that contain production assets, CI/CD credentials, signing material, or infrastructure code. Then query for contributors who have not committed, reviewed, or accessed the repo within a defined window, but who still retain read, write, maintainer, or workflow privileges. Repository inactivity alone is not enough; the real signal is stale membership combined with a high-value repository.

From there, security teams should move in a fixed order: revoke or narrow access, rotate any secrets that may have been visible, and verify whether those secrets were copied into forks, clones, issues, or chat tools. The State of Secrets in AppSec research shows that leaked secrets are often slow to remediate, which is why the access cut and the credential rotation need to happen together. NIST control families around access enforcement and credential management support this operationally, especially NIST SP 800-53 Rev. 5 Security and Privacy Controls, while the same discipline is reflected in the 52 NHI Breaches Analysis, where overlooked identities and stale access repeatedly amplified damage.

• Use repo-level sensitivity labels so critical repositories are reviewed first.
• Cross-check contributor activity against team membership, not just last login.
• Revoke inherited access from departed or dormant contributors immediately.
• Rotate any secret that was stored, referenced, or potentially exposed in the repo.
• Add alerts for new pushes, credential use, or permission changes after access removal.

These controls tend to break down when repository ownership is distributed across many teams and no single system can reliably say who still needs access.

Common Variations and Edge Cases

Tighter access review often increases operational overhead, requiring organisations to balance faster revocation against developer friction and release pressure. That tradeoff is especially visible in monorepos, shared build pipelines, and long-lived maintenance branches, where contributors may look inactive in one project but still need access for release support or incident response. Best practice is evolving, but current guidance suggests using a risk-based threshold rather than a single inactivity date for every repository.

Edge cases matter. A contributor may be inactive in code review but still own a secrets manager entry, a release workflow, or a break-glass process. In those cases, repo membership alone is not the full picture. Security teams should check whether access is tied to individual users, shared accounts, or automation identities, because inactive humans often leave behind active non-human access. That is where NHI governance and repository governance overlap, and why the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack are relevant reminders that repo access can become a credential distribution mechanism. Teams should also treat forks, cached CI logs, and exported artifacts as part of the exposure surface, not afterthoughts.

Where this guidance is weakest is in environments with poor asset inventory, because security teams cannot reliably protect what they cannot map.

Related resources from NHI Mgmt Group

• How should security teams manage access governance when a single application has multiple instances across the business?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams make NHI best practices usable across the business?