CRACI vs CircleCI

A resposta curta

O CircleCI é uma plataforma de CI/CD madura e flexível. Liga-se ao GitHub, ao GitLab e ao Bitbucket, executa jobs numa vasta gama de máquinas, desde contentores Docker até macOS e GPU, e permite empacotar configuração reutilizável como orbs. Em matéria de segurança, o CircleCI protege as credenciais e deixa a análise a orbs e ferramentas de terceiros.

O CRACI segue a abordagem oposta: o runner é o registo de segurança. Executa jobs de GitHub Actions, observa todas as dependências externas que cada build obtém, aplica uma política de egress à rede do build e produz SBOM, dados de proveniência e evidências para o CRA a partir do que viu. Essa é a diferença entre um CI tradicional e um CI consciente da segurança.

O CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. O CircleCI ainda não é suportado. As equipas no CircleCI teriam de passar um pipeline para GitHub Actions para usar runners do CRACI, ou aguardar por outros sistemas de CI, que estão no roadmap.

O que o CircleCI faz bem

Amplitude de computação. O CircleCI oferece classes de recursos Docker, Linux VM, Arm, Windows, macOS e GPU, pelo que uma só plataforma pode compilar um backend, um cliente Windows e uma aplicação iOS. Os runners self-hosted alargam isso às suas próprias máquinas Linux, Windows e macOS e ao Kubernetes, e o tempo de jobs nos runners não consome créditos.

Funcionalidades de velocidade. A cache de camadas Docker está disponível em todos os planos. A divisão de testes distribui um conjunto por executores paralelos por nome, tamanho de ficheiro ou dados históricos de tempos, o que reduz o tempo real de grandes conjuntos de testes.

Configuração reutilizável. Os orbs empacotam jobs, comandos e executores para que as equipas os possam reutilizar em vários projetos, e simplificam a ligação de ferramentas de terceiros, incluindo scanners de segurança.

Higiene de credenciais. As orientações do CircleCI para a cadeia de abastecimento centram-se na proteção de segredos: dividi-los em contextos, colocar as chaves de implementação e de assinatura em contextos restritos governados pelos seus grupos de VCS, e usar tokens OIDC para que os jobs acedam a serviços cloud sem credenciais de longa duração guardadas no CircleCI.

Onde o CRACI é diferente

O build é a fonte da verdade

Numa plataforma de CI tradicional, uma SBOM é produzida por uma ferramenta que adiciona ao pipeline e que normalmente lê manifestos e lockfiles. O CRACI, em vez disso, observa o build. Um proxy que reconhece pacotes regista o tráfego para fontes de pacotes durante a execução do job, em fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de descarga. As evidências de dependências acompanham as caches de CI, pelo que um pacote restaurado de uma cache continua a ser contabilizado.

Sabe quão completa é a SBOM

Cada job produz uma SBOM CycloneDX ou SPDX com um estado de completude por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

A rede do build tem uma política

A funcionalidade de intervalos de IP do CircleCI encaminha os jobs através de endereços conhecidos do CircleCI, para que os seus próprios sistemas os possam colocar numa lista de permissões. Isso resolve o acesso de entrada. O CRACI acrescenta controlo na direção contrária: políticas de egress para cada job, de negação ou de permissão por defeito, com 24 predefinições integradas de fontes de software, fontes personalizadas tipadas e regras explícitas de TLS, TCP, UDP e ICMP. As políticas são validadas antes de o job arrancar e falham em modo fechado. O CRACI também disponibiliza um intervalo estável de IP de egress.

Proveniência e monitorização a partir do mesmo registo

A API devolve SBOM, traços de rede e proveniência. O CRACI agrega vulnerabilidades de todos os builds e repositórios e continua a reavaliar as SBOM monitorizadas.

Qual escolher

• Fique com o CircleCI se o seu código está no GitLab ou no Bitbucket, se depende de builds Windows, macOS ou GPU, ou se executa jobs no seu próprio hardware.
• Considere o CRACI se o seu código está no GitHub e está a ponderar entre GitHub Actions e CircleCI, e distribui software em que tem de mostrar o que entrou em cada versão.
• Use ambos durante uma migração gradual: mantenha os pipelines macOS e Windows no CircleCI e execute os workflows Linux de GitHub Actions no CRACI, onde as evidências de build mais importam.

Para o Cyber Resilience Act

O Cyber Resilience Act da UE espera que os fabricantes saibam o que está em cada versão e tratem as suas vulnerabilidades, com obrigações de reporte a partir de setembro de 2026 e aplicação plena a partir de dezembro de 2027. No CircleCI, essas evidências vêm dos scanners e orbs que ligar aos seus pipelines. O CRACI produ-las a partir do registo do build e exporta SBOM 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 CRA.

Migrar um pipeline para o CRACI

O CRACI executa workflows de GitHub Actions, pelo que um pipeline do CircleCI precisa primeiro de um equivalente em GitHub Actions. Depois de o ter, instale a GitHub App do CRACI na sua organização e defina a etiqueta do runner:

runs-on: craci

As execuções continuam a aparecer na interface do GitHub. Os jobs dispõem de Docker Engine, Buildx e Compose v2, tamanhos de runner de 1 a 32 vCPU com 3 GB de RAM cada, e suporte para a cache do GitHub Actions. Saiba mais sobre a geração de SBOM durante o build, ou consulte os preços e o programa para startups.