Ferramentas de CI/CD comparadas: GitHub Actions, GitLab CI

A quem se destina

Está a escolher uma plataforma de CI/CD, ou a rever a que tem, e há uma nova pergunta na lista. Um cliente, um auditor ou o Cyber Resilience Act da UE pergunta o que entrou em cada versão. Todas as plataformas aqui presentes conseguem executar os seus builds. A diferença está na origem dessas evidências e em quanto delas tem de reunir por si.

O CRACI está nesta página por essa razão, e não é uma plataforma de CI. É um runner para GitHub Actions: continua a usar o GitHub Actions e basta mudar runs-on para craci. O CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. Os pipelines de GitLab CI, CircleCI e Buildkite não correm nele. Somos nós que desenvolvemos o CRACI, por isso tenha isso em conta; os outros produtos são descritos a partir da sua própria documentação.

De onde deve vir a SBOM?

Há três locais de onde uma plataforma a pode obter.

O repositório. A plataforma interpreta manifestos e lockfiles. O grafo de dependências do GitHub e a análise de dependências baseada em SBOM do GitLab funcionam assim. Está sempre ativa, é barata de executar e descreve o que o projeto declara. Não vê scripts de instalação, toolchains descarregadas nem pacotes restaurados de uma cache, e a exportação do GitHub reflete o branch predefinido e não um commit fixado.
Uma ferramenta que adiciona ao pipeline. Executa um gerador de SBOM como passo, através de um orb do CircleCI ou nos seus agentes Buildkite. É flexível, e o resultado depende da ferramenta e da sua configuração: cada gerador lê um conjunto diferente de ficheiros e resolve-os de forma diferente, pelo que dois deles apontados ao mesmo checkout limpo não devolvem a mesma lista de componentes. O CRACI não pode ser comparado nesses termos, porque regista builds em vez de analisar um diretório.
O runner que observou o build. A SBOM é registada a partir do tráfego que o job gerou durante a execução. É isto que o CRACI faz.

A proveniência segue a mesma divisão. As artifact attestations do GitHub, um passo que adiciona a um workflow, fornecem SLSA v1.0 Build Level 2, ou Level 3 com reusable workflows. O GitLab Runner pode gerar uma declaração de proveniência SLSA 1.0 em todos os planos. Os Buildkite Package Registries podem publicar proveniência SLSA que o Buildkite afirma cumprir o Build Level 1, nos planos Enterprise. A API do CRACI devolve dados de proveniência do runner que observou o job, sem assinatura e sem nível SLSA.

Visão geral

A coluna GitHub Actions inclui as funcionalidades da plataforma GitHub que as equipas usam com ele: o grafo de dependências, o Dependabot, as artifact attestations e o GitHub Advanced Security. Preços em setembro de 2026.

Em setembro de 2026. Não indicado significa que a documentação do fornecedor que consultámos não o refere.
Funcionalidade	CRACI	GitHub Actions	GitLab CI	CircleCI	Buildkite
O que é	Um runner para GitHub Actions	CI/CD integrado no GitHub	CI/CD na plataforma GitLab	CI/CD alojado	CI híbrido com agentes alojados por si
Controlo de código-fonte	GitHub	GitHub	GitLab	GitHub, GitLab, Bitbucket	GitHub, GitLab, Bitbucket e outros
Dependências registadas a partir do build	Descargas observadas, caches incluídas	Dados de build para Maven, Gradle, Python	Lê lockfiles
Exportação de SBOM	CycloneDX, SPDX por job	SPDX do grafo do repositório	Relatórios CycloneDX	Através de orbs que adiciona	Ferramentas nos seus agentes
Proveniência do build	Dados de proveniência via API; sem assinatura	SLSA Build L2 ou L3	Declaração SLSA 1.0	Não indicado	SLSA L1, Enterprise
Política de egress do build	Por job, falha em modo fechado	Rede Azure, runners maiores	A seu cargo, em runners próprios	Intervalos de IP para listas de permissões	A seu cargo, em agentes próprios
Alertas de vulnerabilidades em dependências	SBOM monitorizadas	Dependabot	Ultimate	Através de orbs	Não indicado
SAST e análise de segredos		Paga para repositórios privados	Básica em todos os planos	Através de orbs	Não indicado
Windows e macOS	Hoje apenas Linux		Alojados em beta
Corre nas suas próprias máquinas	Runners alojados pelo cliente, Enterprise				Modelo de base
Relatórios de conformidade	SBOM em CycloneDX ou SPDX, registos via API; sem exportação de relatórios	Security overview	Ultimate	Não indicado	Não indicado
Preço inicial	$0.004 por minuto com 2 vCPU, sem mensalidade	2.000 a 50.000 minutos consoante o plano	Free, 400 minutos; Premium $29 por utilizador	Free, 30.000 créditos; a partir de $15 por mês	Plano gratuito; Pro $30 por utilizador ativo

Incluído
Em parte
Não incluído
No roadmap

As plataformas

CRACI, um runner seguro para GitHub Actions

O CRACI substitui o runner, não o GitHub Actions. Instale a GitHub App do CRACI e mude runs-on; as execuções continuam a aparecer na interface do GitHub. Durante a execução de cada job, um proxy que reconhece pacotes regista o que obteve, incluindo pacotes restaurados de caches de CI, e produz uma SBOM CycloneDX ou SPDX com um estado de completude por job e por cache. As políticas de egress são validadas antes de o job arrancar e falham em modo fechado. Ideal para equipas de GitHub Actions que distribuem software e precisam de evidências de cada versão. A ter em conta: hoje apenas GitHub Actions e Linux (GitLab CI, Jenkins, Windows e macOS estão no roadmap), e sem SAST nem análise de segredos.

Geração de SBOM durante o build

GitHub Actions

A página inicial de GitHub-hosted runners — github.com

CI/CD integrado no GitHub, com runners Linux, Windows e macOS alojados e runners self-hosted para as suas próprias máquinas. Os planos incluem 2.000 a 50.000 minutos por mês, e um runner Linux standard de 2 núcleos custa $0.006 por minuto em setembro de 2026. À sua volta estão o grafo de dependências, os alertas e as atualizações de segurança do Dependabot, as artifact attestations e os produtos pagos GitHub Secret Protection e GitHub Code Security. Ideal para código que já está no GitHub. A ter em conta: uma SBOM que descreve o repositório e não o build, a menos que adicione um gerador por sua conta.

CRACI vs runners alojados pelo GitHub e CRACI e GitHub Advanced Security

GitLab CI

Parte de uma plataforma DevSecOps completa: controlo de código-fonte, merge requests, planeamento e CI/CD num só produto. A SAST básica, a deteção de segredos e a análise de contentores funcionam em todos os planos; o Ultimate acrescenta análise de dependências, análise contínua de vulnerabilidades, DAST e o relatório de vulnerabilidades. Os runners alojados cobrem Linux em x86-64 e arm64, com Windows e macOS em beta. Em setembro de 2026, o Free inclui 400 minutos de computação e o Premium custa $29 por utilizador por mês, faturados anualmente. Ideal para quem quer um só fornecedor para todo o ciclo de vida. A ter em conta: a deteção de dependências a partir de lockfiles e as atestações SLSA Level 3 assinadas, que o GitLab lista como experimentais.

CRACI vs GitLab CI

CircleCI

Uma plataforma de CI/CD alojada, madura e flexível, que se liga ao GitHub, ao GitLab e ao Bitbucket. Executa jobs em classes de recursos Docker, Linux, Arm, Windows, macOS e GPU, com runners self-hosted para as suas próprias máquinas. A cache de camadas Docker está em todos os planos, e a divisão de testes distribui conjuntos por executores paralelos com base em dados de tempos. As suas orientações para a cadeia de abastecimento centram-se na proteção de credenciais com contextos e OIDC. Em setembro de 2026, o plano Free inclui 30.000 créditos por mês. Ideal para plataformas mistas e grandes conjuntos de testes. A ter em conta: as SBOM e a análise vêm dos orbs e das ferramentas que ligar.

CRACI vs CircleCI

Buildkite

Uma plataforma híbrida: o plano de controlo SaaS do Buildkite orquestra, e os agentes que executam os jobs estão na sua própria infraestrutura, pelo que o código-fonte e os segredos ficam no seu ambiente. Também há agentes alojados, a $0.004 por vCPU-minuto em Linux em setembro de 2026. Os pipelines assinados permitem aos agentes recusar jobs modificados após o carregamento, e o Test Engine trata dos testes instáveis e da divisão de testes. Ideal para builds que têm de correr no seu próprio hardware ou rede. A ter em conta: a segurança do build fica a seu cargo: as próprias orientações do Buildkite dizem-lhe para aplicar controlos rigorosos de egress de rede nos seus agentes.

CRACI vs Buildkite

Como o CRACI se enquadra

O CRACI é um complemento do GitHub Actions, não um substituto de uma plataforma de CI. No GitHub, uma configuração comum é o GitHub Advanced Security e o Dependabot em cada pull request, e o CRACI como o runner que regista cada build e aplica a política de egress. As SBOM monitorizadas são reavaliadas à medida que surgem novas vulnerabilidades e são exportadas em CycloneDX ou SPDX, incluindo vulnerabilidades. Automatiza uma parte significativa da visibilidade da cadeia de abastecimento de software e das evidências de que as empresas precisam para o seu processo mais amplo de conformidade com o Cyber Resilience Act.

Se os seus pipelines estão em GitLab CI, CircleCI ou Buildkite, usar o CRACI significa migrar esses pipelines para GitHub Actions. GitLab CI e Jenkins estão no roadmap. O CRACI não é a escolha certa quando:

Quer uma só plataforma para código, planeamento, CI e análise. O GitLab foi criado para isso.
Os builds têm de correr no seu próprio hardware ou rede. O Buildkite e os runners self-hosted adequam-se; o CRACI é hoje gerido, com runners alojados pelo cliente no roadmap para o plano Enterprise.
Precisa de builds Windows, macOS ou GPU. O CRACI é hoje apenas Linux; Windows e macOS estão no roadmap.
Precisa hoje de um nível SLSA documentado. As artifact attestations do GitHub fornecem-no.

Consulte os preços do CRACI e a integração com CI/CD.

O CRACI comparado com cada ferramenta

Lado a lado

Várias ferramentas numa só página, para quando está a escolher uma categoria e não um produto.

Runners de GitHub Actions comparados Alojados no GitHub, CRACI, Blacksmith, Depot, Namespace e WarpBuild lado a lado.

Ferramentas e plataformas de CI/CD comparadas