Insights

    AI Security

    474 live GitHub App keys make rotation an identity control, not a scanning task

    Devence Lab

    · 2 min read

    Share
    474 live GitHub App keys make rotation an identity control, not a scanning task
    Photograph · Pixabay / Pexels

    GitGuardian found 474 exposed GitHub App private keys still authenticating, including apps with organisation-admin and repository-write access. Treat App keys as privileged machine identities with enforced rotation.

    GitGuardian tested 4,802 exposed GitHub App private keys and found 474 still authenticating as 440 distinct Apps. The 22 September research matters because these are not stale strings in old commits: 72% of the affected Apps could read private repository content, 207 could write to repositories and 44 held organisation-administration privileges.

    The obvious response is more secret scanning. That is necessary, but incomplete. GitHub App private keys do not expire automatically; they remain valid until manually deleted. Detection therefore finds the symptom, while the control failure is an unmanaged privileged machine identity with no enforced end of life.

    Inventory Apps by effective authority, not installation count

    A GitHub App signs a short-lived JWT with its private key and exchanges that identity for installation tokens carrying the App's granted permissions. A leaked private key can therefore keep minting fresh access while the underlying key remains trusted.

    Build an inventory that joins App ownership, private-key age, installation scope and effective permissions. Prioritise Apps with organisation administration, workflow control, self-hosted runner administration or repository write access. GitGuardian found 98 affected Apps able to control workflows and 40 able to administer self-hosted runners, which turns forgotten automation into a software-supply-chain path.

    A short-lived token does not create short-lived risk when the key that mints it never expires.

    Make key age a policy violation

    Rotation should not depend on discovering a public leak. Set a maximum cryptoperiod for GitHub App private keys, record the next rotation date when a key is created and alert when an App has no accountable owner. Revoke superseded keys after validating the replacement rather than allowing old and new credentials to coexist indefinitely.

    The long tail is the warning. GitGuardian reported a Crusher.dev App key leaked in 2020 that still worked years later because the project was abandoned but installations remained. A CDC-related key leaked in April 2025 retained repository-write access until September 2026, when it was revoked after disclosure.

    Monitor the machine identity after rotation

    Rotation closes one credential but does not prove the App was unused while exposed. After a leak, review App installations, token issuance, repository writes, workflow changes and runner administration for the exposure window. Where an App can modify code or CI, validate downstream repository and build integrity as part of containment.

    For agentic development and automated delivery, GitHub Apps belong in the same governance tier as service principals and privileged workload identities. Secret scanning should trigger the incident; identity inventory, bounded key lifetime and post-exposure activity review should determine whether the incident actually ends.

    Sources

    1. GitHub App Private Keys: 474 Leaked Keys Exposed · GitGuardian
    2. 500,000 Active Credentials Left Exposed on GitHub · SecurityWeek

    Written by the Devence Lab research team.

    Share