StepSecurity vs CRACI

A resposta curta

O StepSecurity é uma plataforma de segurança da cadeia de abastecimento de software que cobre quatro pontos de controlo: máquinas de programadores, registos de pacotes, repositórios de código e CI/CD. O seu produto de CI/CD, o Harden-Runner, é um agente que vigia cada ligação de saída, processo e escrita em ficheiros num job, associa cada um ao passo do workflow que o causou e pode bloquear o egress para tudo o que não esteja numa lista de permissões. O Enterprise custa $16 por programador contribuidor por mês, e os repositórios públicos em runners alojados no GitHub são gratuitos.

O CRACI substitui o próprio runner: a sua política de egress é aplicada pela plataforma de runners e validada antes de o job arrancar, e o mesmo job produz uma SBOM ao nível dos pacotes. Esta é a maior sobreposição que o CRACI tem com qualquer fornecedor de segurança, porque ambos restringem o que um build pode alcançar. A diferença está no local do controlo. O Harden-Runner protege os runners que mantém, incluindo os alojados no GitHub. A política do CRACI vem com o facto de ser o runner, e regista pacotes em vez de apenas destinos.

Visão geral

"Não indicado" significa que não conseguimos confirmá-lo nas páginas públicas do StepSecurity.

O que o StepSecurity faz bem

Harden-Runner

• Visibilidade ao nível do passo. Cada ligação de saída, operação em ficheiros e execução de processo é associada ao passo, job e workflow exatos em que ocorreu. O nível Enterprise acrescenta argumentos de processos, caminhos de escrita em ficheiros e alertas por e-mail, Slack, Microsoft Teams ou o seu SIEM.
• Primeiro auditar, depois bloquear. No modo egress-policy: audit, o Harden-Runner constrói uma linha de base das chamadas de saída normais de cada job e assinala tudo o que seja novo. Pode depois passar para o modo de bloqueio com uma lista de permissões de endpoints. Uma lista global de bloqueio de domínios conhecidos como maliciosos, mantida pelo StepSecurity, aplica-se mesmo em modo de auditoria.
• Deteção de adulteração. Alerta para alterações inesperadas ao código-fonte durante o build.
• Cobertura alargada. Suporte total em runners Linux alojados no GitHub, modo de auditoria em Windows e macOS alojados no GitHub e, no nível Enterprise, VM self-hosted, bare metal e Actions Runner Controller. O StepSecurity indica também GitLab CI, Azure DevOps e runners de terceiros como Blacksmith, Depot e Namespace. Em runners self-hosted, o agente é integrado na imagem do runner, pelo que os workflows não precisam de alterações.
• Historial. O StepSecurity afirma que o Harden-Runner detetou o comprometimento do tj-actions/changed-files (CVE-2025-30066) e o pacote npm axios comprometido, e que protege mais de 25 milhões de execuções de workflows por semana. O agente do nível community é open source sob Apache 2.0.

Onde é executado o Harden-Runner

A matriz de suporte do próprio StepSecurity para GitHub Actions, em setembro de 2026:

Não é suportado quando um job inteiro é executado num contentor em runners alojados no GitHub, nem em ubuntu-slim. No Actions Runner Controller, só são suportados jobs Linux.

O resto da plataforma

• Governação de actions: um inventário das actions de terceiros e dos reusable workflows que utiliza, fluxos de aprovação para os novos e as StepSecurity Maintained Actions como substitutos diretos revistos.
• Secure Registry: períodos de espera para novas versões de pacotes, bloqueio de versões conhecidas como comprometidas, proteção contra typosquatting e listas de bloqueio para toda a organização, com uma política para portáteis e CI.
• Code Repo Security: verificações de pull requests e o Orchestrate Security, que abre pull requests que fixam as actions a SHA de commits, definem permissões de privilégio mínimo para o GITHUB_TOKEN e implementam configurações do Dependabot.
• Dev Machine Guard: um inventário de agentes de programação com IA, servidores MCP, extensões de IDE e pacotes nas máquinas dos programadores.

Onde o CRACI é diferente

Ser o runner, não um agente nele

Em runners alojados no GitHub, o Harden-Runner é instalado por um passo que acrescenta como primeiro passo de cada job, e o seu alcance depende do que a infraestrutura do GitHub permite. Nada disto é uma falha do produto; resulta de funcionar em infraestrutura de outra entidade.

A política do CRACI faz parte do runner. É 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 execuções continuam a aparecer no GitHub, e migrar um job é uma alteração à sua etiqueta runs-on.

Pacotes, não apenas destinos

A lista de permissões do Harden-Runner é uma lista de endpoints, e as suas informações de rede mostram que hosts cada passo contactou. As fontes do CRACI são tipadas por ecossistema, com 24 predefinições integradas de fontes de software, fontes personalizadas para npm, PyPI, apt, apk, o proxy de Go, Nix, Cargo, registos OCI e Git sobre HTTPS e SSH, e regras explícitas de TLS, TCP, UDP e ICMP. Um proxy que reconhece pacotes regista que pacotes cada job 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.

Depois do build

• Os dados de proveniência são devolvidos pela API juntamente com SBOM e traços de rede. O CRACI não assina a proveniência e não reivindica nenhum nível SLSA.
• A monitorização reavalia as SBOM do que distribuiu à medida que surgem novas vulnerabilidades, e as equipas de segurança fazem a triagem das conclusões e enviam-nas às equipas responsáveis pela correção.
• O inventário mostra exatamente que versões de software estão implementadas em que produtos, a nível global, pelo que uma nova vulnerabilidade aponta diretamente para os produtos que executam a versão afetada.

Preço

Em setembro de 2026, o nível Community do StepSecurity é gratuito para repositórios públicos ilimitados em runners alojados no GitHub. O nível Enterprise custa $16 por mês por programador contribuidor, ou seja, qualquer pessoa que tenha contribuído para um repositório protegido nos últimos 90 dias, e inclui o Dev Machine Guard e o Secure Registry. Só o Dev Machine Guard custa $8 por dispositivo por mês. Os repositórios privados e os runners self-hosted precisam do Enterprise, ambos os níveis pagos têm uma avaliação gratuita de 14 dias, e o StepSecurity oferece descontos por volume. O Harden-Runner protege runners pelos quais já paga, pelo que os minutos de runner são um custo à parte.

O CRACI cobra apenas os minutos de build: $0.002 por vCPU-minuto ($0.004 para um runner predefinido de 2 vCPU), medido ao segundo, sem mensalidade. Como o CRACI é o runner, esse preço cobre a computação e também as evidências. Consulte os preços do CRACI para as condições atuais.

Qual se adequa

O StepSecurity adequa-se melhor quando

• Quer manter os runners alojados no GitHub, incluindo Windows e macOS.
• Utiliza runners self-hosted, GitLab CI ou Azure DevOps.
• Quer observar o tráfego em modo de auditoria antes de bloquear seja o que for.
• Precisa de visibilidade ao nível dos processos e dos ficheiros para a resposta a incidentes.
• O seu projeto open source é executado em runners alojados no GitHub e precisa de uma opção gratuita.

O CRACI adequa-se melhor quando

• Quer o runner e a política de egress num só lugar, sem nenhum agente para implementar.
• Precisa de uma SBOM ao nível dos pacotes de cada build, com um estado de completude.
• Quer monitorizar o que foi distribuído.
• Precisa de evidências para o CRA, ou de residência de dados na UE no plano Enterprise do CRACI.

Do que abdica ao migrar jobs para o CRACI

Para sermos claros: o CRACI ainda não tem modo de auditoria nem de monitorização (está no roadmap), não monitoriza processos nem escritas em ficheiros, ainda não funciona em runners alojados no GitHub nem noutros sistemas de CI (GitLab CI e Jenkins estão no roadmap), tem listas de bloqueio de pacotes apenas no roadmap, e os seus alertas cobrem apenas violações de políticas, sem integração com Slack, Teams ou SIEM. Se essas forem as suas prioridades, o StepSecurity cobre-as hoje.

O Secure Registry, o Code Repo Security e o Dev Machine Guard do StepSecurity protegem pontos em que o CRACI não toca: o registo de onde vêm os seus pacotes, os seus repositórios e os portáteis dos programadores. Não dependem do runner, pelo que não são afetados pelo local onde os seus jobs são executados.

Para o Cyber Resilience Act

O Cyber Resilience Act pede aos fabricantes que conheçam os componentes dos seus produtos, tratem as vulnerabilidades neles presentes e guardem evidências. O StepSecurity concentra-se em prevenir e detetar ataques à cadeia de abastecimento, e as suas informações de runtime ajudam quando investiga um incidente na CI. O CRACI 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: SBOM do build exportadas em CycloneDX ou SPDX, acompanhamento de vulnerabilidades e proveniência através da API. Consulte evidências para o CRA.

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 a ser executado sob uma política de egress no CRACI.

StepSecurity: perguntas frequentes

O que é o StepSecurity?

O StepSecurity é uma plataforma de segurança da cadeia de abastecimento de software. O seu produto mais conhecido, o Harden-Runner, é um agente que monitoriza o egress de rede, a integridade dos ficheiros e a atividade de processos em runners de CI/CD e pode bloquear o egress fora de uma lista de permissões. A plataforma cobre também registos de pacotes (Secure Registry), repositórios de código (Code Repo Security), máquinas de programadores (Dev Machine Guard) e informações sobre ameaças.

Quanto custa o StepSecurity?

Em setembro de 2026, o nível Community é gratuito para repositórios públicos ilimitados. O Enterprise custa $16 por programador contribuidor por mês, sendo programador contribuidor qualquer pessoa que tenha contribuído para um repositório protegido nos últimos 90 dias, e inclui o Dev Machine Guard e o Secure Registry. Só o Dev Machine Guard custa $8 por dispositivo por mês. Ambos os níveis pagos têm uma avaliação gratuita de 14 dias, e os minutos de runner são um custo à parte.

O Harden-Runner é gratuito?

Sim, para repositórios públicos em runners alojados no GitHub. Os repositórios privados e os runners self-hosted, incluindo runners self-hosted para repositórios públicos, precisam do nível Enterprise. O agente do nível community é open source sob a licença Apache 2.0.

Que runners suporta o Harden-Runner?

Runners Linux alojados no GitHub em modo de auditoria e de bloqueio, runners Windows e macOS alojados no GitHub em modo de auditoria e, no Enterprise, VM self-hosted, bare metal e Actions Runner Controller. O StepSecurity indica também GitLab CI, Azure DevOps e runners de terceiros como Blacksmith, Depot e Namespace. Não é suportado quando um job inteiro é executado num contentor em runners alojados no GitHub, nem em ubuntu-slim.

Qual é a diferença entre o StepSecurity e o CRACI?

O Harden-Runner é um agente que acrescenta aos runners que mantém. O CRACI é o runner: a sua política de egress é aplicada pela plataforma de runners, validada antes de o job arrancar e falha em modo fechado, e cada job produz também uma SBOM ao nível dos pacotes com um estado de completude. O StepSecurity está à frente no modo de auditoria, na monitorização de processos e de ficheiros e na cobertura de runners e de CI.

O CRACI pode substituir o Harden-Runner?

Para jobs de GitHub Actions em Linux, sim: migrar um job para o CRACI dá-lhe controlo de egress a partir do próprio runner, pelo que não é preciso nenhum agente nesse job. Abdica do modo de auditoria (no roadmap do CRACI), da monitorização de processos e de ficheiros, e da cobertura de runners alojados no GitHub, Windows, macOS e fora do GitHub.

O StepSecurity gera uma SBOM?

O Harden-Runner regista os destinos, processos e ficheiros com que um job interagiu, não uma SBOM do build ao nível dos pacotes. O CRACI regista que pacotes cada job obteve, incluindo pacotes restaurados de caches de CI, e exporta CycloneDX e SPDX.