Arquitetura de segurança

Como o Latchkey isola cada job de CI: VMs dedicadas de uso único, nenhuma rede de entrada, credenciais efêmeras, criptografia em repouso e em trânsito, e as restrições sob as quais o agente de autorreparo é executado.

Esta página foi escrita para uma revisão de segurança. Ela descreve como a plataforma de runners é realmente construída - a fronteira de isolamento, o que sai da máquina, como as credenciais são tratadas e o que o agente de autorreparo tem e não tem permissão de fazer. Para o que o GitHub App pode ler e escrever nos seus repositórios, veja Segurança e permissões do GitHub.

Isolamento: um job, uma máquina#

O Latchkey não compartilha uma máquina entre jobs. Cada job roda em uma máquina virtual EC2 dedicada (classe m6a, Ubuntu 24.04 LTS) lançada para aquele job. Seu job não é um contêiner compartilhando um kernel com outro inquilino, e não é um processo em um host compartilhado de longa duração.

O uso único é imposto na camada de registro do GitHub, não apenas por convenção. Runners de cold start se registram com uma configuração just-in-time, que o GitHub aceita para exatamente um job. Runners de warm pool se registram com a flag --ephemeral, que faz o mesmo. Nos dois casos, a instância é configurada para terminar no desligamento, então não pode ser reutilizada mesmo que algo dê errado.

Grupos de runners são criados com visibility: selected e uma lista explícita de repositórios, então um runner registrado para o seu workspace só recebe jobs dos repositórios que você habilitou.

O que roda como root, e por que isso está contido#

Dentro da sua própria VM, seu job tem controle total: o usuário runner tem sudo sem senha e acesso ao Docker. Isso é normal em CI - builds instalam pacotes e executam contêineres - e é seguro justamente porque o raio de alcance é uma única máquina de vida curta, sem rede de entrada, que é destruída ao final do job. Preferimos afirmar isso claramente a insinuar um sandbox que não existe.

Rede#

Credenciais e segredos#

Os deploys se autenticam na AWS por assunção de papel via GitHub OIDC. Não há chaves de acesso AWS de longa duração na CI. As chaves de API da integração MCP são armazenadas apenas como um hash SHA-256 - a chave em texto puro é exibida uma vez na criação e nunca é persistida.

Criptografia#

Isolamento do cache de build#

Os objetos de cache são armazenados no S3 sob um prefixo de chave derivado do ID da sua organização, e o ID do inquilino é injetado pelo control plane a partir da requisição do job - um job não pode se declarar outro inquilino definindo uma variável de ambiente. Os objetos expiram após 14 dias.

O que sai do runner#

Dois tipos de dados saem da máquina, e vale ser preciso sobre o segundo.

• Metadados de execução e de job - nomes, tempos, status, labels e o YAML de workflow - que alimentam os recursos de análise e de otimização.
• Saída do passo que falhou. Quando um passo falha, o pipeline de autorreparo captura a saída padrão e a saída de erro daquele passo (limitadas a 1 MiB cada) e as armazena para que a falha possa ser diagnosticada e, quando pertinente, transformada em uma correção proposta. A retenção é de 90 dias.

Como o agente de autorreparo é restringido#

O autorreparo é a parte em que um revisor deve pressionar mais forte, porque é o único componente que altera um job em execução. Veja exatamente o que ele pode fazer.

• Ele roda como o usuário runner, não como root, na forma de um serviço systemd.
• Ele escuta em um socket de domínio Unix com permissões restritas ao grupo. Não tem listener TCP nem superfície de rede.
• Ele é invocado por um shim que intercepta apenas os scripts de passo do próprio agente do runner; todos os demais comandos passam direto, sem alteração.
• Ele falha aberto: se o agente atinge o tempo limite, recusa ou dá erro, o comando roda exatamente como rodaria sem o Latchkey. Um reparador quebrado não pode quebrar o seu build.

As operações privilegiadas que ele pode executar são definidas por allowlist, não por filtragem:

O que o GitHub App pode acessar#

Cada permissão abaixo existe para viabilizar um recurso específico. Elas estão agrupadas pelo propósito, em vez de uma lista plana, para que você veja o motivo ao lado da concessão.

Alterações nos seus repositórios#

O Latchkey nunca faz push na sua branch padrão. Toda alteração é um pull request que você revisa, e o caminho de escrita é restringido de três formas:

1. O caminho do arquivo precisa ser resolvido como editável contra um manifesto por repositório. Caminhos sem correspondência são, por padrão, não editáveis - a verificação falha fechada.
2. Pull requests originados de forks são rejeitados, e um sinal de fork ausente também é rejeitado, em vez de presumido seguro.
3. Uma correção proposta precisa corresponder à sua assinatura de falha nos logs capturados, ou é suprimida.

Segurança operacional#

• As imagens de runner são reconstruídas semanalmente, para que os patches de segurança do sistema operacional cheguem à frota em uma cadência definida.
• O papel de instância do runner é de menor privilégio, incluindo uma negação explícita que restringe o acesso ao Parameter Store em toda a conta, concedido por uma política gerenciada pela AWS, apenas aos caminhos de runner do próprio Latchkey.
• Toda ação administrativa que altera estado é gravada em um log de auditoria com operador, ação, alvo, parâmetros e resultado.
• O acesso ao painel e à API é autenticado por um autorizador JWT no API gateway. Os papéis de workspace são Owner, Admin e Member, com os owners protegidos contra remoção ou rebaixamento.

Retenção de dados#

O que o Latchkey armazena, e por quanto tempo.

Desabilitar um repositório interrompe a coleta para ele. Excluir o seu workspace remove os dados dele. Se você precisa de uma janela de retenção específica para a sua organização, peça e conversaremos a respeito.

Reportando uma vulnerabilidade#

Envie um e-mail para security@latchkey.dev. Por favor, não abra uma issue pública no GitHub para um relato de segurança.