O token expira. A chave não.
A autenticação do GitHub App depende de uma private key que gera um JSON Web Token (JWT) com uma vida útil máxima de 10 minutos. Este JWT então solicita um token de acesso de instalação, válido por até uma hora. O GitHub impõe rigorosamente essas expirações de tokens downstream, criando uma ilusão de acesso transitório.
No entanto, a private key raiz, a fonte dessas credenciais, não possui um time-to-live (TTL) nativo. Ela pode gerar novos tokens perpetuamente até ser explicitamente revogada. Essa escolha arquitetural fundamental significa que uma chave comprometida ou esquecida permanece uma ameaça persistente, ao contrário dos tokens de curta duração que ela produz.
Embora alguns argumentem que isso espelha o comportamento das chaves SSH, que também geralmente carecem de expiração imposta pela plataforma, o escopo das permissões do GitHub App aumenta drasticamente o risco. Os aplicativos geralmente possuem acesso amplo a vários repositórios, incluindo:
- Privilégios administrativos de organização
- Acesso de escrita a código privado
- Controle sobre self-hosted runners e execução de workflow
A pesquisa da GitGuardian encontrou 474 chaves ativas, com 44 concedendo direitos totais de org-admin. Uma chave, vinculada ao US CDC, forneceu acesso de escrita a código privado por 17 meses após seu vazamento. Isso destaca por que as chaves de GitHub App não gerenciadas representam um risco de governança significativo e duradouro, muito além do de uma chave SSH típica.
474 chaves vazadas ainda abriram a porta
A pesquisa recente da GitGuardian revelou uma realidade nua e crua: de mais de 500.000 chaves RSA expostas, 4.802 estavam vinculadas a um ID de GitHub App. Impressionantes 474 dessas chaves ainda autenticavam, representando 440 aplicativos distintos, apesar de estarem expostas publicamente. Isso demonstra uma vulnerabilidade crítica na cadeia de segurança.
As implicações dessas exposições persistentes são graves. Quarenta e quatro aplicativos válidos tinham acesso total de administrador de organização, enquanto 72% podiam ler repositórios privados. Além disso, 207 aplicativos possuíam permissões de escrita, abrindo as portas para injeção arbitrária de código e envenenamento de pipeline, um risco significativo de segurança na cadeia de suprimentos.
A persistência do problema é preocupante. Uma chave do Crusher.dev estava pública desde 2020 e permaneceu ativa. Uma chave vinculada ao US CDC teria permanecido válida por 17 meses após sua exposição. Outro aplicativo amplamente utilizado, "Access Tokens for GitHub Actions", vazou uma private key em janeiro de 2024, afetando cerca de 300 organizações, incluindo a contratada de defesa Sierra Nevada Corp.
Esses exemplos ressaltam o perigo das GitHub App private keys: ao contrário dos JWTs de curta duração e dos tokens de acesso de instalação que elas geram, as próprias private keys raiz não têm expiração nativa. Esse descuido arquitetural transforma um único vazamento em uma ameaça de segurança perpétua, exigindo atenção imediata e estratégias robustas de rotação de chaves.
Um aplicativo esquecido pode se tornar uma base para ataques à cadeia de suprimentos
Um aplicativo esquecido apresenta uma base significativa para ataques à cadeia de suprimentos. Chaves vazadas podem permitir que um invasor leia código privado, escreva em repositórios, manipule workflows ou administre self-hosted runners. Tal acesso facilita diretamente a adulteração de código, o comprometimento de CI/CD e, finalmente, a tomada de controle organizacional.
Integrações obsoletas são facilmente ignoradas. O GitGuardian descobriu que 59% dos 440 aplicativos distintos com chaves ativas tinham apenas uma instalação, frequentemente para automação ad-hoc. Quando engenheiros saem ou projetos são abandonados, a propriedade desses aplicativos frequentemente desaparece, deixando uma vulnerabilidade persistente. A chave do aplicativo Crusher.dev, exposta desde 2020, permaneceu ativa anos após o projeto ter cessado a manutenção.
A organização US Centers for Disease Control and Prevention (CDC), por exemplo, teve uma chave privada vazada com acesso de escrita a repositórios privados por 17 meses, mediando o acesso à sua infraestrutura Microsoft Azure. Da mesma forma, o amplamente utilizado aplicativo "Access Tokens for GitHub Actions" vazou uma chave privada, expondo aproximadamente 300 organizações.
Embora uma chave válida não prove automaticamente a exploração ativa, ela significa exposição persistente. Os atacantes, uma vez que obtêm uma chave válida, podem agir com as permissões concedidas ao aplicativo a qualquer momento. Para mais detalhes sobre essas ameaças persistentes, veja a pesquisa do GitGuardian: GitHub App Private Keys: 474 Leaked Keys Still Work. Isso destaca a necessidade crítica de um gerenciamento rigoroso de GitHub App private keys e suas permissões associadas para mitigar supply-chain risks.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
Faça a rotação sem tempo de inatividade — e desative o que ninguém possui
Os proprietários de aplicativos devem implementar uma estratégia robusta de rotação de chaves. Gere uma nova private key, implante e verifique sua funcionalidade, então revogue a antiga. O GitHub permite até 25 chaves privadas ativas por aplicativo, permitindo a rotação em etapas sem interrupção do serviço.
Estabeleça uma cadência de rotação documentada, protocolos seguros de armazenamento de chaves e integre secret scanning em todos os repositórios, incluindo forks públicos de propriedade de desenvolvedores. Aplique o acesso de privilégio mínimo, limitando as permissões do aplicativo apenas aos repositórios e ações estritamente necessários para sua função. Isso minimiza o raio de explosão de qualquer possível comprometimento.
Os administradores da organização enfrentam um mandato crítico para auditar aplicativos instalados. Identifique e atribua proprietários responsáveis para cada integração. Remova prontamente aplicativos abandonados ou sem manutenção, pois eles se tornam alvos principais para atacantes que buscam uma base persistente.
Finalmente, verifique se todos os aplicativos sobreviventes operam com o mínimo absoluto de permissões necessárias. Revisar e restringir esses controles de acesso reduz a superfície de ataque, evitando que um aplicativo esquecido se torne uma porta aberta para os ativos mais sensíveis da sua organização.
Perguntas Frequentes
As GitHub App private keys expiram automaticamente?
Não. As GitHub App private keys não possuem uma data de expiração integrada, portanto, os proprietários devem rotacioná-las e revogá-las.
Como uma chave de GitHub App não expirada pode ser usada?
Ela pode assinar um JWT de curta duração, que pode ser trocado por um token de acesso de instalação que dura até uma hora.
Quantas GitHub App private keys podem estar ativas ao mesmo tempo?
O GitHub permite até 25 chaves privadas para um aplicativo, permitindo que as equipes implantem uma substituição antes de excluir a chave antiga.
O que uma organização deve fazer sobre aplicativos que ninguém mantém?
Audite os GitHub Apps instalados, remova integrações obsoletas ou sem dono e restrinja as permissões e repositórios concedidos aos que permanecerem.