O que o CRACI consegue alcançar e o que guarda

Porque é que esta pergunta merece uma resposta direta

Um runner de CI vê mais do que a maioria das ferramentas da sua stack. Obtém o seu código-fonte, instala as suas dependências e detém os segredos que os seus workflows usam para publicar pacotes e implementar. Quando a GitHub Action tj-actions/changed-files foi comprometida em março de 2025, a CISA reportou que o código malicioso expôs segredos, incluindo chaves de acesso, tokens de acesso pessoal do GitHub, tokens npm e chaves RSA privadas. O runner é onde esses segredos residem enquanto um job é executado.

Por isso, antes de apontar um workflow para o CRACI, deve saber exatamente o que este consegue alcançar. As respostas estão abaixo, e o CRACI Trust Center e docs.craci.com têm os detalhes.

Para que serve a GitHub App

O CRACI substitui o runner, não o GitHub Actions. Mantém os seus workflows, altera runs-on para craci nos jobs que escolher, e as execuções continuam a aparecer na interface do GitHub. Para que isto funcione, a sua organização instala a GitHub App do CRACI.

Ao instalá-la, concede à App acesso a todos os repositórios ou a um conjunto selecionado. Apenas os repositórios aos quais concede acesso podem executar workflows no CRACI.

As permissões exatas que a App solicita estão indicadas no ecrã de instalação do GitHub, e pode revê-las depois nas definições da sua organização. Em resumo, a App pode ler o seu código e as suas execuções de Actions, e gere os runners que regista para a sua organização.

Onde é executado o seu código

Os jobs são executados em máquinas virtuais isoladas. A execução dos builds decorre em infraestrutura bare-metal europeia. O seu código-fonte é processado dentro da VM do job durante o build.

Cada job é executado numa de três imagens: CRACI Slim, CRACI Slim ARM64 ou uma imagem Ubuntu 24.04 compatível com o GitHub. Atualmente, os runners são apenas Linux; Windows e macOS estão no roadmap.

A forma como os jobs são isolados e o que acontece à VM de um job quando este termina estão documentados em docs.craci.com e no Trust Center.

O que o CRACI guarda e durante quanto tempo

O CRACI processa o seu código-fonte na VM do job enquanto o build decorre e não o guarda. O que retém são as evidências que regista sobre cada build, além das caches que os seus workflows guardam:

• Metadados de build
• Dados de pacotes, ou seja, as dependências que cada job obteve
• Traços de rede do job
• SBOM
• Registos de proveniência
• Caches
• Registos de auditoria

Uma cache contém tudo o que o seu workflow lá colocar, pelo que deve tratar o conteúdo das caches como trata qualquer outro resultado de build.

O período de retenção predefinido é de 180 dias. Os planos Enterprise podem definir um período de retenção personalizado. A eliminação de dados e a encriptação são abordadas no Trust Center.

Alojamento e residência de dados

O CRACI está alojado na Europa e oferece residência de dados na UE, com execução de builds em infraestrutura bare-metal europeia. A plataforma é executada na Hetzner, um fornecedor alemão, num centro de dados em Tuusula, na Finlândia. Consulte residência de dados para saber que dados o CRACI trata.

Controlos sobre o próprio build

Um runner que vê os seus segredos deve também permitir-lhe limitar para onde podem ir. As políticas de egress de rede do CRACI definem, para cada job, um comportamento predefinido de negar ou permitir, com 24 predefinições incorporadas para origens de software comuns e origens personalizadas tipificadas para registos como npm, PyPI, Cargo, Go proxy e OCI. Também pode escrever regras explícitas de TLS, TCP, UDP e ICMP. As políticas são validadas antes do início do job, falham em modo fechado e rejeitam campos desconhecidos. Os alertas assinalam violações de política.

Os jobs saem de um intervalo estável de IP de egress, pelo que pode permitir a passagem dos runners do CRACI nas suas próprias firewalls por endereço.

Acesso dentro da sua organização

• Os planos Enterprise suportam SAML single sign-on, com o Google Workspace como fornecedor de identidade.
• Um registo de auditoria de administração regista as ações administrativas. Está disponível na interface e ainda não pode ser exportado.
• Os tokens de API são criados por administradores, podem ser revogados a qualquer momento e expiram ao fim de 90 dias.

Como manter o âmbito reduzido

Não tem de dar ao CRACI toda a sua organização para o avaliar.

1. Instale em repositórios selecionados. Escolha "Only select repositories" ao instalar a App e selecione um ou dois. Pode alargar ou reduzir o conjunto mais tarde em Settings da sua organização, em GitHub Apps, CRACI, Configure. A alteração produz efeitos de imediato.
2. Mude um job de cada vez. Apenas os jobs com runs-on: craci são executados no CRACI. Tudo o resto continua no runner que usa atualmente.
3. Comece por um job com poucos segredos. Um job de testes ou de lint mostra-lhe a SBOM e as evidências de rede sem colocar credenciais de publicação ou de implementação num novo runner.
4. Ative uma política de egress de negação por predefinição. Permita as origens de pacotes de que o job precisa e mais nada.
5. Saiba como sair. No GitHub, pode suspender a App, o que lhe bloqueia o acesso mantendo-a instalada, ou desinstalá-la, o que lhe retira o acesso à sua organização.

A nossa postura de segurança

A nossa página de segurança explica a nossa abordagem: documentada, não apenas afirmada. O Trust Center reúne as políticas, os controlos e a documentação por trás da plataforma, e é aí que pode solicitar material para uma avaliação de fornecedor.

Esta página não faz afirmações de certificação. Para o estado atual do nosso programa de segurança e de qualquer trabalho de auditoria, consulte o Trust Center.