Comparar
Ferramentas de segurança de CI/CD comparadas
As ferramentas de segurança de CI/CD dividem-se em quatro grupos: scanners que leem o seu código, ferramentas que reforçam o pipeline em torno dele, agentes que vigiam o runner e runners que controlam e registam o build. Veja o que cada grupo cobre e onde se enquadra o CRACI.
Atualizado a
Cada comparação indica o que o outro produto faz bem, em que o CRACI é diferente e quando faria sentido usar ambos. Para todas as categorias, consulte todas as comparações.
Porque é que o pipeline precisa das suas próprias ferramentas de segurança
Um pipeline de CI/CD guarda credenciais, obtém código da internet e produz os artefactos que os seus clientes executam. Isso faz dele um alvo por si só. Um atacante que consiga alterar o que um build transfere, ou o que produz, nem precisa de tocar no seu código-fonte. Os scanners de código não foram construídos para isso, porque leem o repositório, não o build.
As ferramentas de segurança de CI/CD colmatam essa lacuna a partir de direções diferentes. Algumas verificam como o pipeline está configurado, outras vigiam o que acontece no runner enquanto um job é executado, e outras controlam o próprio runner. Saber a que grupo pertence uma ferramenta diz-lhe mais do que a sua lista de funcionalidades, porque determina o que a ferramenta consegue ver e o que consegue travar.
Tipos de ferramentas de segurança de CI/CD
Scanners que leem o seu código
A análise estática (SAST), a análise de segredos e a análise de composição de software (SCA) leem o repositório: ficheiros-fonte, manifestos e lockfiles. O GitHub Advanced Security, por exemplo, combina a análise de código CodeQL com a análise de segredos e a push protection, e alertas do Dependabot a partir da GitHub Advisory Database. Estas ferramentas encontram problemas antes de um build ser executado. Não veem o que o build realmente obteve nem a que se ligou.
Ferramentas que reforçam o pipeline em torno do build
As ferramentas de postura e de governação verificam a configuração do pipeline. O Cycode monitoriza políticas de segurança, configurações e a governação de CI/CD. O StepSecurity mantém um inventário das actions de terceiros que utiliza, com fluxos de aprovação para as novas, e abre pull requests que fixam as actions a SHA de commits e definem permissões de privilégio mínimo para o GITHUB_TOKEN. Estas ferramentas tornam o pipeline mais difícil de usar indevidamente, mas trabalham sobre a definição do build e não sobre o build em execução.
Agentes que vigiam o runner
Os agentes de runtime são executados dentro do job, nos runners que mantém. O StepSecurity Harden-Runner monitoriza ligações de saída, processos e escritas em ficheiros, associa cada um ao passo do workflow que o causou e pode bloquear o egress fora de uma lista de permissões. O Cimon do Cycode monitoriza a execução de processos, o egress de rede e o acesso a ficheiros ao nível do kernel com eBPF, produz uma SBOM observada em runtime e assina proveniência SLSA. Os agentes funcionam em muitos sistemas de CI e em runners alojados, porque são adicionados a infraestrutura que já existe.
Runners que controlam e registam o build
O CRACI segue a última abordagem: substitui o runner. Os jobs são executados no CRACI com runs-on: craci, e as execuções continuam a aparecer no GitHub. A política de egress faz parte do runner, é validada antes de o job arrancar e falha em modo fechado. Um proxy que reconhece pacotes regista cada pacote que o job obteve, incluindo pacotes restaurados de caches de CI, pelo que cada job produz uma SBOM com um estado de completude, um traço de rede e dados de proveniência.
Lado a lado
| Funcionalidade | CRACI | StepSecurity Harden-Runner | Cycode (Cimon) | GitHub Advanced Security |
|---|---|---|---|---|
| Onde é executado | É o próprio runner | Agente nos runners que mantém | Agente dentro do seu CI atual | Analisa repositórios no GitHub |
| Controlo de egress do build | Negar ou permitir por predefinição, falha em modo fechado | Lista de permissões em modo de bloqueio | Modo de prevenção com hosts permitidos | |
| Modo de auditoria antes de bloquear | Modo de monitorização ou de simulação | Linhas de base por job | Modo de deteção | Sem controlo de egress |
| Monitorização de processos e ficheiros | eBPF | Não indicado | ||
| SBOM registada a partir do build | Por job, com um estado de completude | Regista destinos, processos, ficheiros | SBOM observada em tempo de execução | Grafo a partir de manifestos, mais dados de build submetidos |
| Proveniência do build assinada | Sem proveniência assinada | Não indicado | SLSA Provenance v1.0 | Atestações de artefactos |
| SAST | Não indicado | CodeQL | ||
| Deteção de segredos | Não indicado | Secret Protection | ||
| Cobertura de CI | Atualmente GitHub Actions; GitLab CI e Jenkins no roadmap | GitHub Actions, GitLab CI, Azure DevOps | GitHub Actions, Azure Pipelines, Jenkins, GitLab CI, Buildkite, Harness | GitHub, e Azure DevOps como compra separada |
- Incluído
- Em parte
- Não incluído
- No roadmap
"Não indicado" significa que não conseguimos confirmá-lo nas páginas públicas do fornecedor. Para o detalhe de cada coluna, consulte CRACI vs StepSecurity, CRACI vs Cycode e CRACI vs GitHub Advanced Security.
Que ferramenta cobre que risco de CI/CD
O OWASP Top 10 CI/CD Security Risks é a lista mais usada do que pode correr mal num pipeline. Os seus dez riscos são:
- CICD-SEC-1: Insufficient Flow Control Mechanisms
- CICD-SEC-2: Inadequate Identity and Access Management
- CICD-SEC-3: Dependency Chain Abuse
- CICD-SEC-4: Poisoned Pipeline Execution (PPE)
- CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)
- CICD-SEC-6: Insufficient Credential Hygiene
- CICD-SEC-7: Insecure System Configuration
- CICD-SEC-8: Ungoverned Usage of 3rd Party Services
- CICD-SEC-9: Improper Artifact Integrity Validation
- CICD-SEC-10: Insufficient Logging and Visibility
Nenhuma ferramenta cobre os dez sozinha. Estes são os quatro em que os controlos do CRACI se aplicam:
| Funcionalidade | Em que consiste o risco | O que o CRACI faz |
|---|---|---|
| CICD-SEC-3: Dependency Chain Abuse | Um build obtém um pacote malicioso ou inesperado | A política de egress limita as origens de onde um job pode obter pacotes, e a SBOM do job regista cada pacote que obteve |
| CICD-SEC-7: Insecure System Configuration | Definições fracas nos sistemas que executam o pipeline | Os jobs são executados em máquinas virtuais isoladas, e uma política que não pode ser aplicada falha em modo fechado |
| CICD-SEC-9: Improper Artifact Integrity Validation | Um artefacto adulterado circula no pipeline como se fosse legítimo | Sem proveniência assinada; a API devolve dados de proveniência para cada build |
| CICD-SEC-10: Insufficient Logging and Visibility | Os ataques no pipeline passam despercebidos e não podem ser investigados | Um traço de rede para cada job, alertas sobre violações de políticas e uma API que devolve SBOM, traços de rede e proveniência |
No CICD-SEC-7, o CRACI cobre o runner. A configuração dos seus repositórios e da sua organização do GitHub continua a seu cargo. Para sermos claros quanto ao resto: o CRACI não trata a gestão de identidades e acessos (CICD-SEC-2) nem a higiene de credenciais (CICD-SEC-6), e não governa o controlo de fluxo, as permissões do pipeline nem os serviços de terceiros (CICD-SEC-1, 5 e 8). A análise de segredos, como o Secret Protection do GitHub ou a deteção de segredos do Cycode, e as ferramentas de postura acima foram construídas para isso.
Como escolher uma ferramenta de segurança de CI/CD
- Substituir os seus runners ou mantê-los. Se quiser manter runners alojados no GitHub, runners self-hosted ou outro sistema de CI, um agente é a forma de acrescentar controlos de runtime. Se estiver aberto a mudar de runner, um runner como o CRACI traz controlo de egress e um registo do build sem nenhum agente para implementar.
- Modo de auditoria hoje. O Harden-Runner e o Cimon conseguem vigiar o tráfego antes de bloquearem seja o que for. O modo de monitorização ou dry-run do CRACI está no seu roadmap.
- Análise forense ao nível dos processos. Se precisar de saber que processo escreveu que ficheiro durante um incidente, um agente que monitoriza processos e ficheiros cobre isso. O CRACI não monitoriza processos nem escritas em ficheiros.
- SBOM e evidências para o CRA. Se precisar de uma SBOM ao nível dos pacotes para cada build, de proveniência e de evidências para o Cyber Resilience Act, veja o que cada ferramenta regista e se continua a monitorizar o que foi distribuído. O CRACI regista a SBOM enquanto o build é executado, reavalia as SBOM monitorizadas à medida que surgem novas vulnerabilidades e exporta SBOM em CycloneDX ou SPDX.
- Plataformas de CI e sistemas operativos. O CRACI suporta hoje o GitHub Actions, com GitLab CI e Jenkins no roadmap, e executa Linux em x86-64 e ARM64, com Windows e macOS no roadmap. Se compila noutros sistemas de CI ou precisa já de runners Windows ou macOS, verifique primeiro a cobertura dos agentes.
- Código e segredos. Os scanners de código-fonte e de segredos cobrem terreno que nenhum runner cobre. O CRACI não tem SAST nem análise de segredos, por isso planeie-os à parte.
Um agente no runner vs ser o runner
Um agente é adicionado a infraestrutura concebida por outra pessoa. Em runners alojados no GitHub, é instalado por um passo no início de cada job, e o seu alcance depende do que essa infraestrutura permite. É isso que permite aos agentes cobrir runners alojados, frotas self-hosted e vários sistemas de CI ao mesmo tempo, e é uma vantagem real quando os seus builds estão distribuídos por todos eles.
Um runner que aplica ele próprio a política funciona ao contrário. No CRACI, a política de egress é validada antes de o job arrancar, rejeita campos desconhecidos e falha em modo fechado, pelo que uma política que não pode ser aplicada não produz uma execução desprotegida. As suas origens são tipificadas por ecossistema, com 24 predefinições integradas de origens de software e origens personalizadas para npm, PyPI, apt, apk, o proxy Go, Nix, Cargo, registos OCI e Git, pelo que o registo é de pacotes, não apenas de hosts. Nos jobs executados no CRACI, substitui os agentes de runtime em vez de funcionar ao lado deles. Saiba mais sobre a integração de CI/CD e a geração de SBOM durante o build, ou marque uma demo para ver um job de GitHub Actions a ser executado sob uma política de egress.
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.
Ferramentas de segurança de CI/CD: perguntas frequentes
O que são ferramentas de segurança de CI/CD?
As ferramentas de segurança de CI/CD protegem o pipeline que transforma código-fonte em software lançado. Dividem-se em quatro grupos: scanners que leem o seu código e as suas dependências (SAST, análise de segredos, SCA), ferramentas que reforçam a configuração do pipeline em torno do build, agentes que vigiam o runner enquanto um job é executado, e runners que controlam e registam o próprio build. O OWASP Top 10 CI/CD Security Risks é uma forma comum de verificar que riscos uma ferramenta trata.
Qual é a diferença entre segurança de CI/CD e SCA?
A análise de composição de software (SCA) lê os seus manifestos e lockfiles e indica que dependências declaradas têm vulnerabilidades conhecidas. A segurança de CI/CD protege o próprio pipeline: quem o pode alterar, o que um build pode alcançar e se o artefacto que distribui é o que foi compilado. O CRACI trabalha a partir do build: regista os pacotes que cada job realmente obteve, incluindo pacotes restaurados de caches de CI, e continua a monitorizá-los face a novas vulnerabilidades depois do lançamento.
Preciso de um agente de runtime se usar o CRACI?
Não para o controlo de egress nem para um registo do build. No CRACI, a política de egress faz parte do runner, é validada antes de o job arrancar e falha em modo fechado, pelo que o CRACI substitui agentes como o Harden-Runner e o Cimon nos jobs executados nele. O que perde é a monitorização de processos e de ficheiros, que o CRACI não oferece, e o modo de auditoria, que está no roadmap do CRACI. Se a análise forense ao nível dos processos for um requisito absoluto, um agente nos runners que mantém cobre-a hoje.
As ferramentas de segurança de CI/CD conseguem bloquear pacotes maliciosos?
Algumas conseguem, de formas diferentes. O controlo de egress impede um build de alcançar origens fora de uma política, pelo que uma transferência de um host inesperado falha. As listas de bloqueio de pacotes e os controlos de registo impedem que uma versão conhecida como maliciosa sequer seja instalada. O CRACI aplica hoje uma política de egress por job, com origens tipificadas por ecossistema; as listas de bloqueio de pacotes ao nível da organização estão no roadmap do CRACI.
Que ferramentas de segurança de CI/CD funcionam para além do GitHub Actions?
Em setembro de 2026, o StepSecurity indica GitLab CI e Azure DevOps a par do GitHub Actions, e o Cimon do Cycode também funciona em Azure Pipelines, Jenkins, GitLab CI, Buildkite e Harness. O GitHub Advanced Security também é vendido para Azure DevOps. O CRACI suporta hoje o GitHub Actions, com GitLab CI e Jenkins no roadmap.
Outras categorias
Veja o CRACI no seu próprio pipeline
Marque uma demo e analisaremos consigo os seus builds, as suas SBOM e as suas evidências de conformidade.
Marcar demo