Segurança em runnerhut

Isolamento

• Um trabalho, um microVM, com seu próprio kernel — nunca um contêiner em um kernel compartilhado
• A VM é destruída no final do trabalho; os discos são apagados criptograficamente, não reutilizados
• Os objetos de cache são criptografados e têm escopo definido por repositório
• Nenhum acesso de shell do operador para VMs de trabalho em execução

Conformidade

• SOC 2 Tipo 2, auditado anualmente, relatório disponível sob NDA
• Teste anual de penetração de terceiros
• GDPR DPA com subprocessadores publicados e aviso de alteração com 30 dias de antecedência
• Residência de dados na UE e nos EUA para computação, cache, logs e métricas

Acesso e identidade

• Integra-se como um GitHub App com tokens de instalação com escopo definido – nunca um token de acesso pessoal
• SSO SAML e OIDC com provisionamento SCIM
• Log de auditoria somente anexado com exportação SIEM
• Política de saída de negação padrão disponível por grupo de executores

O que um trabalho comprometido poderia ou não alcançar

Vale a pena afirmar claramente, porque é a pergunta que um revisor está realmente fazendo. Um trabalho é executado em seu próprio microVM com seu próprio kernel, portanto, escapar para o host é o limite rígido, e não um namespace de contêiner. Ele pode alcançar a rede, a menos que uma política de saída o restrinja, e é por isso que a saída negada por padrão é mais importante do que a maioria dos controles. Ele não pode ler o cache de outro locatário porque os objetos de cache são criptografados por repositório. Não pode persistir porque a VM e seu disco são destruídos no final do trabalho.

Onde realmente reside o risco residual

• Seu fluxo de trabalho: GITHUB_TOKEN com permissão excessiva, ações de terceiros não fixadas, pull_request_target com checkout do chefe de relações públicas
• Suas dependências: um script pós-instalação comprometido é executado com qualquer acesso de rede que o executor tenha
• Seus segredos: qualquer coisa descriptografada em um trabalho fica visível para o código em execução nesse trabalho, incluindo o código de uma dependência extraída

Podemos restringir o segundo e o terceiro com políticas de saída e credenciais de curta duração. A primeira é sua, e a lista de verificação de segurança GitHub Actions cobre-a em cinco alterações.