Comparação
CRACI vs GitLab CI
O GitLab analisa o seu projeto e reporta o que os lockfiles declaram. O CRACI é o runner, pelo que regista o que cada build realmente obteve. A diferença está na origem da sua SBOM e da sua proveniência.
Atualizado a
A resposta curta
O GitLab é uma plataforma DevSecOps completa: controlo de código-fonte, merge requests, planeamento e CI/CD num só produto, com um amplo conjunto de scanners de segurança e gestão de vulnerabilidades no plano Ultimate. Se quer um único fornecedor para todo o ciclo de vida do software, o GitLab foi feito para isso.
O CRACI é mais restrito. É um runner compatível com GitHub Actions que regista todas as dependências externas que um build obtém, controla o que o build pode alcançar e transforma esse registo em SBOM, dados de proveniência e evidências para o CRA. A diferença essencial é entre a CI tradicional com scanners acoplados e uma CI em que o próprio runner é o registo de segurança.
Há um ponto prático que vem primeiro. O CRACI suporta hoje apenas GitHub Actions; o GitLab CI e o Jenkins estão no roadmap. Se os seus pipelines estão no GitLab CI, teria de os passar para GitHub Actions para usar runners do CRACI, ou aguardar pelo suporte de GitLab CI, que está no roadmap.
| Funcionalidade | CRACI | GitLab |
|---|---|---|
| Dependências registadas a partir do build | Obtenções observadas, incluindo pacotes de caches de CI | Os scanners leem lockfiles e exportações do grafo de dependências |
| Exportação de SBOM | CycloneDX ou SPDX por build, com estado de completude | Relatórios CycloneDX; exportação da lista de dependências no Ultimate |
| Política de egress de rede do build | Negação ou permissão por defeito, falha em modo fechado | Os seus próprios controlos de rede em runners self-managed |
| Proveniência do build | Dados de proveniência via API; não assinados | Declaração de proveniência SLSA 1.0 a partir do runner |
| Monitorização contínua de vulnerabilidades | As SBOM monitorizadas são reavaliadas continuamente | Análise contínua de vulnerabilidades no Ultimate |
| Relatórios de conformidade | SBOM em CycloneDX ou SPDX, registos via API; sem exportação de relatórios | Funcionalidades de conformidade e governação no Ultimate |
| SAST, deteção de segredos, DAST | SAST básico e segredos em todos os planos; DAST no Ultimate | |
| Controlo de código-fonte e planeamento | Funciona com os seus repositórios GitHub | Repositórios, merge requests e planeamento numa só plataforma |
| Sistemas de CI suportados | Hoje GitHub Actions; GitLab CI e Jenkins no roadmap | GitLab CI/CD, alojado ou self-managed |
| Plataformas de runners alojados | Linux em x86-64 e ARM64, 1 a 32 vCPU. Windows e macOS no roadmap. | Linux em x86-64 e arm64; runners alojados Windows e macOS em beta. |
| Preços | Paga por minuto de build: $0.004 por minuto com 2 vCPU, medido ao segundo. Sem mensalidade e sem custo por SBOM. | Gratuito com 400 minutos de computação; Premium a $29 por utilizador por mês, faturado anualmente; Ultimate com preço personalizado (em setembro de 2026). |
- Incluído
- Em parte
- Não incluído
- No roadmap
O que o GitLab faz bem
Uma só plataforma. Código, revisões, pipelines, conclusões de segurança e planeamento ficam no mesmo lugar, com um único modelo de permissões. Para muitas organizações, só isso decide a questão.
Análise de segurança, por plano. É preciso ser exato quanto ao que cada plano inclui. Segundo o GitLab, o SAST básico, a deteção de segredos e a análise de contentores correm em todos os planos, incluindo o Free. No Free e no Premium, essas análises produzem artefactos de relatório JSON. O Ultimate acrescenta o workflow à sua volta: conclusões em merge requests, o relatório de vulnerabilidades, a lista de dependências, aprovações de segurança e o GitLab Advanced SAST. A análise de dependências, a análise contínua de vulnerabilidades e o DAST são funcionalidades do Ultimate. A análise de contentores também pode produzir um relatório SBOM CycloneDX em todos os planos.
Proveniência. O GitLab Runner pode gerar uma declaração de proveniência de artefactos no formato SLSA 1.0 em todos os planos. Também existem atestações SLSA Level 3 assinadas, mas o GitLab apresenta-as como uma experiência no GitLab.com para o Ultimate, atrás de uma feature flag desativada por defeito.
Escolha de runners. Os runners alojados pelo GitLab cobrem Linux em x86-64 (2 a 32 vCPU) e arm64, com Windows e macOS em beta. Pode também executar os seus próprios runners em qualquer lado, e o GitLab indica que os jobs nos seus próprios runners não consomem minutos de computação. O GitLab Dedicated acrescenta residência de dados numa região à sua escolha.
Onde o CRACI é diferente
A SBOM vem do build, não do lockfile
A análise de dependências baseada em SBOM do GitLab deteta dependências a partir de lockfiles suportados ou de exportações do grafo de dependências. É uma abordagem sólida quando o lockfile conta toda a história. Os builds fazem muitas vezes mais: executam scripts de instalação, transferem toolchains, restauram caches e obtêm imagens base.
O CRACI vê essa atividade porque é o runner. Um proxy que reconhece pacotes observa o tráfego para origens de pacotes durante a execução do job, em origens npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de transferência. A evidência das dependências acompanha as caches de CI, pelo que um pacote restaurado de uma cache continua a ser contabilizado. Cada job produz uma SBOM em CycloneDX ou SPDX.
A completude é indicada, não assumida
Cada SBOM traz um estado de completude por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Quando o registo tem uma lacuna, consegue vê-la.
A rede do build é uma política
As políticas de egress do CRACI são de negação ou de permissão por defeito, com 24 predefinições integradas de origens de software e origens personalizadas tipadas para npm, PyPI, apt, apk, o proxy de Go, Nix, Cargo, registos OCI e Git. As políticas são validadas antes de o job arrancar, falham em modo fechado e enviam um alerta em caso de violação. No GitLab, o controlo de rede dos builds é aquele que configurar em torno dos seus próprios runners.
Proveniência
A API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência e não reivindica nenhum nível SLSA.
Monitorizar o que foi distribuído
O CRACI agrega vulnerabilidades de todos os builds e repositórios e continua a reavaliar as SBOM monitorizadas à medida que surgem novos avisos de segurança.
Qual é o mais adequado
- Fique com o GitLab se o seu código e os seus pipelines estão no GitLab e quer uma só plataforma, ou se precisa de SAST, DAST e deteção de segredos no mesmo produto.
- Escolha o CRACI se o seu código está no GitHub e usa GitHub Actions, e precisa de evidências do que entrou em cada versão, de controlo sobre o que os builds podem alcançar e de SBOM que possa defender numa auditoria.
- Use ambos se a sua organização utiliza as duas plataformas. O GitLab continua a cobrir os projetos e scanners que nele tem; o CRACI executa o lado do GitHub Actions e regista esses builds.
Para o Cyber Resilience Act
Ao abrigo do Cyber Resilience Act da UE, os fabricantes precisam de saber o que está em cada versão do produto e de tratar as respetivas vulnerabilidades. As obrigações de reporte de vulnerabilidades aplicam-se a partir de setembro de 2026, e o regulamento aplica-se integralmente a partir de dezembro de 2027. O GitLab Ultimate ajuda a encontrar e gerir vulnerabilidades em todos os seus projetos. O CRACI regista a partir de que foi construída cada versão, continua a monitorizá-la e exporta SBOM em CycloneDX ou SPDX. 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 CRA. Nenhuma das ferramentas o torna conforme por si só.
Adicionar o CRACI
Para um repositório no GitHub, instale a GitHub App do CRACI na sua organização, para todos os repositórios ou para um conjunto selecionado, e altere a etiqueta do runner:
runs-on: craciOs workflows, as actions e a interface do GitHub mantêm-se iguais. O CRACI substitui o runner, não o GitHub Actions. Saiba mais sobre a geração de SBOM durante o build e as evidências para o CRA, ou consulte os preços.
Veja o que um build realmente obtém
Execute um workflow de GitHub Actions no CRACI e compare a SBOM resultante com a que os seus scanners produzem hoje.
Marcar demo