Ferramentas e plataformas de segurança da cadeia de abastecimento de software (2026)

A quem se destina esta página

É responsável por um mandato de "proteger a nossa cadeia de abastecimento de software" e tem de decidir para onde vai o orçamento. As ferramentas abaixo funcionam em pontos diferentes: nos seus repositórios e pipelines, no runner de build, no registo de pacotes ou no artefacto final. Somos nós que desenvolvemos o CRACI, que concorre diretamente nesta categoria, por isso tenha isso em conta. Descrevemos cada ferramenta a partir da sua própria documentação e dizemos onde outra ferramenta se adequa melhor.

O que é a segurança da cadeia de abastecimento de software?

Para o guia completo, consulte o que é a segurança da cadeia de abastecimento de software e a lista de verificação de boas práticas.

O seu software é o seu próprio código mais tudo aquilo de que depende: pacotes open source, imagens base, ferramentas de build, actions de CI de terceiros e o pipeline que transforma tudo isto numa versão. A segurança da cadeia de abastecimento de software é o trabalho de saber quais são essas partes, controlar de onde vêm e provar o que entrou em cada versão. A segurança aplicacional procura falhas no código que escreve; a segurança da cadeia de abastecimento cobre o que o rodeia.

Os atacantes visam todos os elos. Três incidentes recentes mostram onde:

• Uma dependência. Em março de 2024, foi encontrado código malicioso nas versões 5.6.0 e 5.6.1 do xz utils, uma biblioteca de compressão incluída em distribuições Linux (CVE-2024-3094).
• O pipeline de CI. Em março de 2025, a GitHub Action tj-actions/changed-files foi comprometida (CVE-2025-30066), expondo segredos como chaves de acesso, tokens de acesso pessoal do GitHub e tokens de npm dos workflows que a usavam.
• O registo de pacotes. Em setembro de 2025, o worm autorreplicante Shai-Hulud comprometeu mais de 500 pacotes npm. Roubou credenciais de programadores, incluindo tokens do GitHub e chaves de cloud, e usou-as para publicar mais pacotes infetados.

1:53

Que tipos de ferramentas de segurança da cadeia de abastecimento de software existem?

Nenhum produto cobre todos os elos, e os fornecedores abaixo querem dizer coisas diferentes com "segurança da cadeia de abastecimento". A maioria das soluções enquadra-se num de sete tipos, definidos pelo local onde funcionam.

Como escolher uma plataforma de segurança da cadeia de abastecimento de software?

Comece pela pergunta a que hoje não consegue responder e depois escolha a ferramenta que funciona onde essa resposta se encontra. Seis perguntas separam rapidamente as opções.

• Precisa de abrangência ou de profundidade? Uma plataforma de gestão da postura de segurança de aplicações (ASPM) liga-se aos seus repositórios, pipelines e scanners e prioriza o risco em todos eles. Uma ferramenta ao nível do build vai mais fundo num ponto: o que aconteceu enquanto o software foi compilado.
• Quer manter os seus runners? Agentes como o StepSecurity Harden-Runner e o Cimon do Cycode acrescentam monitorização aos runners que já usa. O CRACI substitui o runner para GitHub Actions.
• O risco está nas suas entradas? Se o que mais o preocupa são pacotes maliciosos ou imagens base cheias de CVE, as ferramentas que avaliam ou reforçam as entradas atacam diretamente o problema.
• Distribui software que não compilou? Só a análise de binários consegue ver o interior de um pacote sem o seu build.
• Que sistemas de CI utiliza? A maioria das ferramentas aqui presentes cobre vários. O CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap.
• O que terá de provar, e a quem? Os clientes, os auditores e regulamentos como o Cyber Resilience Act da UE pedem cada vez mais uma SBOM por versão e um registo de como as vulnerabilidades foram tratadas. Um dashboard de conclusões não é o mesmo que evidências do que foi distribuído.

Depois, faça as mesmas perguntas a cada fornecedor da sua lista restrita:

• De onde vem a sua lista de componentes: manifestos, análise do código-fonte, o build ou o binário final?
• A SBOM diz-me quando está incompleta, e exporta em CycloneDX ou SPDX?
• Consegue impedir um build de chegar a um host inesperado, ou apenas reportá-lo depois?
• Posso verificar mais tarde se o artefacto que implemento é o que foi compilado?
• Que sistemas de controlo de código-fonte e de CI suporta hoje, e quais estão no roadmap?
• Qual é a unidade de preço: programadores, contribuidores, imagens, builds ou orçamento?

Como se comparam as ferramentas?

As ferramentas dividem-se em dois perfis, por isso há duas tabelas. A primeira compara plataformas e ferramentas de segurança de build na forma como veem e controlam o pipeline. A segunda compara ferramentas que trabalham sobre entradas e saídas. "Não indicado" significa que as páginas de fornecedores que citamos não dizem nem que sim nem que não.

Plataformas e segurança de build

Entradas e saídas

Quanto custam as ferramentas de segurança da cadeia de abastecimento de software?

Cinco das nove ferramentas abaixo têm preços por programador, e a maioria vende os planos pagos através da equipa comercial. O CRACI cobra apenas os minutos de build, pelo que o custo acompanha o volume de builds e não o número de pessoas que fazem commits. Os preços são os publicados por cada fornecedor em setembro de 2026; o Apiiro e a Legit Security ficam de fora porque as suas páginas não indicam preços.

O preço por programador cresce com a sua equipa; o preço por minuto de build cresce com os seus pipelines. O preço do CRACI inclui os minutos de runner, que substituem o que paga pelos runners alojados no GitHub. Consulte os preços do CRACI e os preços de runners comparados. Para gráficos dos preços publicados por dimensão da equipa, com o runner incluído, consulte preços de segurança da cadeia de abastecimento de software comparados.

CRACI

O CRACI é um runner para GitHub Actions. Muda runs-on para craci e, enquanto cada job é executado, um proxy que reconhece pacotes regista o que este obteve, incluindo pacotes restaurados de caches de CI. Cada SBOM indica um estado de completude por job e por cache, uma política de egress é validada antes de o job começar e falha em modo fechado, e o CRACI continua a reavaliar as SBOM do que foi distribuído. Ideal para equipas que distribuem software e têm de mostrar o que entrou em cada versão. A ter em conta: sem SAST, análise de segredos ou de IaC, verificações de postura ou análise de binários, e hoje apenas GitHub Actions (GitLab CI e Jenkins estão no roadmap). Geração de SBOM durante o build

Plataformas e ASPM

Apiiro

O Apiiro é uma plataforma de ASPM. O Deep Code Analysis mapeia a sua arquitetura do código ao runtime, e o Risk Graph correlaciona as conclusões dos scanners do próprio Apiiro e de ferramentas de terceiros em "toxic combinations". O seu módulo de cadeia de abastecimento inventaria repositórios e pipelines, incluindo shadow pipelines, e assinala proteções de branch fracas e commits anómalos. Liga-se através de APIs e não exige alterações na CI. Ideal para grandes programas de AppSec que querem contexto de arquitetura em muitos sistemas de controlo de código-fonte. A ter em conta: o seu inventário vem da análise do código, não da observação dos builds, e não controla aquilo a que um build pode chegar. CRACI vs Apiiro

Cycode

O Cycode é uma plataforma de ASPM com análise de SAST, SCA, segredos, contentores e IaC, postura de CI/CD e mais de 100 conectores. O seu componente de build, o Cimon, é um agente eBPF executado dentro dos seus jobs de CI. Monitoriza processos, egress de rede e acesso a ficheiros, aprende o comportamento normal de um pipeline antes de o impor, produz uma SBOM observada em runtime e assina proveniência SLSA. O Cycode afirma que o Cimon é gratuito e open source. Ideal para uma única plataforma para código e muitos sistemas de CI, com proteção do build em runtime nos runners que mantém. A ter em conta: o Cimon é um agente adicionado aos seus runners, não o próprio runner. CRACI vs Cycode

OX Security

A OX Security é uma plataforma de ASPM com scanners próprios, agregação de conclusões de terceiros de ferramentas como Checkmarx, Snyk e Black Duck, e políticas de postura de CI/CD que assinalam actions não fixadas, permissões excessivas de workflows e webhooks arriscados. A sua Pipeline Bill of Materials (PBOM) é um registo assinado por build das definições do pipeline, da identidade do runner, dos argumentos de build e das assinaturas dos artefactos. Ideal para políticas de postura e controlo de pull requests em GitHub Actions, GitLab, Jenkins, Azure Pipelines e CircleCI. A ter em conta: a sua SBOM é recolhida de fontes ligadas, e as suas políticas verificam a configuração do pipeline em vez de limitarem aquilo a que um job em execução pode chegar. CRACI vs OX Security e alternativas à OX Security

Legit Security

A Legit Security mapeia todo o seu ciclo de vida de desenvolvimento: um inventário continuamente atualizado de sistemas SDLC, pipelines e dos controlos de segurança que os protegem, com centenas de políticas em controlo de código-fonte, CI e registos. Orquestra scanners como Snyk, Checkmarx e GitHub Advanced Security, acrescenta SAST e SCA nativos, encontra segredos em registos de build, Slack e Confluence, bem como no código, e cria SBOM e atestações assinadas. Ideal para uma equipa de segurança que herdou muitos repositórios e vários sistemas de CI e precisa de uma única camada de governação. A ter em conta: lê a configuração e os resultados dos scanners através de APIs, pelo que não vê o tráfego de rede de um job enquanto este é executado. CRACI vs Legit Security e alternativas à Legit Security

Kusari

O Kusari vem da equipa que cocriou o GUAC, o grafo da OpenSSF para metadados da cadeia de abastecimento. A sua plataforma constrói um grafo de conhecimento a partir das suas SBOM, documentos VEX e resultados de scanners, mostra o raio de impacto de uma nova vulnerabilidade, analisa a alcançabilidade e abre pull requests AutoFix que valida primeiro. O Kusari Inspector revê pull requests em busca de pacotes maliciosos, segredos e workflows inseguros, e o Kusari afirma que a sua instalação é gratuita. Ideal para um único grafo para muitas fontes de SBOM e scanners. A ter em conta: um grafo reflete as SBOM que recebe, e as do Kusari vêm de um gerador (o conjunto de ferramentas waybill do próprio Kusari ou uma ferramenta sua) e não do build. CRACI vs Kusari e alternativas ao Kusari

Endor Labs

O Endor Labs foi construído em torno da alcançabilidade ao nível da função: a análise estática de programas verifica se o seu código pode chamar uma função vulnerável numa dependência direta ou transitiva, o que, segundo o Endor Labs, reduz as conclusões de SCA em 92%. A análise do impacto de atualizações, os pull requests automatizados e os Endor Patches, que aplicam correções à versão que utiliza, tratam da remediação. Cobre também AI SAST, segredos, contentores, um Package Firewall à frente dos seus registos e um SBOM Hub com VEX baseado em alcançabilidade. Ideal para equipas cujo principal problema é o volume de alertas. A ter em conta: o seu inventário vem da análise do código-fonte, e não executa nem restringe os seus builds. CRACI vs Endor Labs

Segurança de build e de runners

StepSecurity

O StepSecurity Harden-Runner é a maior sobreposição do CRACI com qualquer fornecedor de segurança. É um agente nos runners de GitHub Actions que já usa, incluindo os alojados no GitHub, e associa cada ligação de saída, processo e escrita de ficheiro ao passo do workflow que a causou. Pode auditar primeiro, construindo uma linha de base por job, e depois bloquear o egress para tudo o que esteja fora de uma lista de permissões. O StepSecurity vende também Secure Registry, pull requests de reforço de repositórios e Dev Machine Guard. Ideal para equipas que querem manter runners alojados no GitHub ou pela própria empresa, ou que utilizam GitLab CI ou Azure DevOps. A ter em conta: a sua lista de permissões é uma lista de endpoints, e regista destinos em vez de uma SBOM ao nível dos pacotes. CRACI vs StepSecurity

Segurança de pacotes e de entradas

Socket

O Socket analisa o comportamento dos pacotes open source: scripts de instalação, acesso à rede e ao sistema de ficheiros, código ofuscado, malware conhecido e typosquats. Assinala adições arriscadas nos pull requests, e o Socket Firewall bloqueia pacotes maliciosos no momento da instalação, com uma versão gratuita para npm, yarn, pnpm, pip, uv e cargo. Oferece também análise de alcançabilidade. Ideal para travar pacotes maliciosos antes de chegarem, incluindo os que ainda não têm aviso de segurança. A ter em conta: lê o manifesto e os lockfiles que um projeto declara, e a sua firewall filtra instalações de pacotes, não o resto do tráfego de rede de um job. CRACI vs Socket

Chainguard

A Chainguard compila software open source a partir do código-fonte e distribui-o reforçado: imagens de contentor a que chama zero-CVE, bibliotecas Java, Python e JavaScript recompiladas a partir de código-fonte verificado, imagens de VM e GitHub Actions reforçadas, cada uma com uma SBOM assinada e proveniência SLSA. Para clientes com encomenda, compromete-se a remediar CVE críticas em 7 dias e de outras gravidades em 14 dias após um patch elegível. Ideal para equipas cujos scanners continuam a assinalar CVE em imagens base. A ter em conta: as suas SBOM e proveniência descrevem os artefactos da Chainguard. O seu próprio build continua a precisar do seu próprio registo, e é por isso que combina bem com uma ferramenta ao nível do build. CRACI e Chainguard

Análise de binários

ReversingLabs

O ReversingLabs Spectra Assure analisa pacotes de software finais sem código-fonte, usando análise estática de binários, 16 motores de deteção de malware e análise diferencial que assinala alterações suspeitas entre versões. Exporta SBOM CycloneDX e SPDX a partir do binário e pode avaliar software comercial e de terceiros antes de o implementar. Ideal para um controlo de lançamento contra malware e adulteração, e para software que não compilou. A ter em conta: trabalha de trás para a frente, a partir do resultado, pelo que não vê as ferramentas de build nem as dependências de teste que o build obteve mas não distribuiu. CRACI vs ReversingLabs

Referenciais e regulamentos por detrás da categoria

Grande parte da procura destas ferramentas vem de referenciais e regras que pedem um inventário de componentes, um registo de como o software foi compilado e um processo para tratar vulnerabilidades.

• SLSA (Supply-chain Levels for Software Artifacts) é um conjunto de orientações de adoção incremental, mantido como colaboração intersetorial sob a Linux Foundation. O seu Build track classifica a fiabilidade da proveniência de um build.
• NIST SSDF (SP 800-218, versão 1.1, fevereiro de 2022) estabelece práticas de desenvolvimento seguro de software para reduzir as vulnerabilidades no software lançado.
• A Executive Order 14028 dos EUA, secção 4(e), determinou orientações para a cadeia de abastecimento de software que incluem fornecer ao comprador uma SBOM de cada produto. Molda as orientações federais de aquisição em vez de vincular diretamente todos os fornecedores.
• A CISA, a NSA e o ODNI publicaram "Securing the Software Supply Chain: Recommended Practices Guide for Customers" em 2023, que abrange aquisição, testes, implementação, aplicação de patches e SBOM.
• O Cyber Resilience Act da UE (Regulamento (UE) 2024/2847) põe em vigor as suas obrigações de reporte a 11 de setembro de 2026 e aplica-se na íntegra a partir de 11 de dezembro de 2027.
• O artigo 21.º, n.º 2, da NIS2 inclui a segurança da cadeia de abastecimento e o tratamento de vulnerabilidades entre as medidas que exige, e a FDA dos EUA exige uma SBOM aos fabricantes de dispositivos cibernéticos.

Nenhum destes referenciais menciona uma categoria de produto. O que têm em comum são as evidências: uma lista de componentes exata por versão, um registo de como foi compilada e a prova de que as vulnerabilidades foram acompanhadas.

Onde se enquadra o CRACI?

O CRACI é um runner para GitHub Actions. Muda runs-on para craci e, enquanto cada job é executado, um proxy que reconhece pacotes regista o que este obteve, incluindo pacotes restaurados de caches de CI. Cada SBOM indica um estado de completude por job e por cache. Uma política de egress, de negação ou de permissão por predefinição, é validada antes de o job começar e falha em modo fechado. O CRACI continua a reavaliar as SBOM do que foi distribuído. A vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global. O resultado é uma SBOM por build, um registo daquilo a que cada build chegou e dados de proveniência a partir da API, o que automatiza uma parte significativa da visibilidade da cadeia de abastecimento e das evidências de que o seu processo de CRA precisa.

O CRACI não é a escolha certa se precisar de SAST, análise de segredos ou de IaC, verificações de postura nos seus repositórios, um modo de auditoria antes de bloquear, listas de bloqueio de pacotes (no roadmap), análise de binários ou, hoje, de sistemas de CI que não sejam o GitHub Actions (GitLab CI e Jenkins estão no roadmap). Muitas equipas combinam-no com uma ferramenta acima: uma plataforma de ASPM para código e postura, Socket ou Chainguard para as entradas, ReversingLabs para a saída. Saiba mais sobre a geração de SBOM durante o build, a integração de CI/CD e os preços, ou marque uma demo para ver um build registado de ponta a ponta.

Compare ferramentas para cada parte da cadeia de abastecimento

Esta página é a visão geral. Cada área tem a sua própria comparação aprofundada e guias.

• SBOM: ferramentas de SBOM comparadas, geração de SBOM durante o build, porquê SBOM durante o build e como gerar uma SBOM em GitHub Actions.
• Runners e segurança de CI/CD: fornecedores de runners de GitHub Actions, ferramentas de segurança de runners, lista de verificação de segurança de pipelines de CI/CD e política de egress para GitHub Actions.
• Dependências: ferramentas de SCA comparadas, dependências transitivas explicadas e o que é a análise de composição de software.
• Regulamentação: ferramentas de conformidade com o CRA.
• Porquê o build: porque é que a segurança da cadeia de abastecimento pertence à CI, segurança da cadeia de abastecimento de software com o CRACI e porque é que o software interno e de baixo risco também precisa dela.

O CRACI comparado com cada ferramenta

• CRACI face a Apiiro Grafo de risco a partir do código face a evidências a partir do build.
• CRACI face a Cycode ASPM com um agente de build face ao próprio runner de build.
• CRACI face a OX Security PBOM a partir de ferramentas ligadas face a um registo a partir do runner.
• CRACI face a Legit Security Proteger o SDLC face a registar o build.
• CRACI face a Kusari Grafo da cadeia de abastecimento face a SBOM do build com monitorização.
• CRACI face a ReversingLabs Análise binária do resultado face a evidências a partir do build.
• CRACI face a Socket Análise do comportamento de pacotes face a observação do build.
• CRACI face a Chainguard Entradas seguras face a um build seguro e registado.
• CRACI face a Xygeni Plataforma de AppSec com atestações de build face a ser o runner de build.
• CRACI face a Wiz Conclusões sobre a postura dos workflows face a aplicação de regras dentro do job.
• CRACI face a Safeguard Análise e correção automática com IA face a registar o próprio build.

Segurança da cadeia de abastecimento de software: perguntas frequentes

Respostas curtas às perguntas que os compradores mais fazem

O que são soluções de segurança da cadeia de abastecimento de software?

Ferramentas que protegem tudo o que entra no seu software entre o primeiro commit e o lançamento: dependências open source, imagens base, ferramentas de build, pipelines de CI e os artefactos que distribui. Os principais tipos são as plataformas de ASPM que mapeiam o risco em todo o ciclo de vida de desenvolvimento, a análise de composição de software para dependências, a segurança de build e de runners, as firewalls de pacotes, as imagens reforçadas, a análise de binários e as ferramentas de SBOM e proveniência.

Qual é a melhor plataforma de segurança da cadeia de abastecimento de software?

Não existe uma única melhor, porque cada uma cobre um elo diferente. As plataformas de ASPM como o Apiiro, o Cycode, a OX Security e a Legit Security destacam-se pela abrangência em repositórios e sistemas de CI. O Endor Labs foca-se na alcançabilidade das conclusões de dependências, o Socket nos pacotes maliciosos, a Chainguard nas entradas reforçadas e o ReversingLabs nos binários finais. O CRACI é a escolha quando precisa de um registo do que cada build de GitHub Actions realmente trouxe, com controlo de egress e dados de proveniência.

Em que difere a segurança da cadeia de abastecimento de software da segurança aplicacional?

A segurança aplicacional procura falhas no código que a sua equipa escreve, com ferramentas como SAST e DAST. A segurança da cadeia de abastecimento de software cobre o que rodeia esse código: componentes de terceiros, o sistema de build, o pipeline de CI e o caminho do build até ao lançamento. A backdoor do xz utils, o comprometimento do tj-actions/changed-files e o worm npm Shai-Hulud entraram todos pela cadeia de abastecimento, e não por um erro no código das próprias vítimas.

Por que ferramenta de segurança da cadeia de abastecimento devo começar?

Comece pela pergunta a que hoje não consegue responder. Se não sabe que dependências vulneráveis distribui, comece pela SCA. Se os pacotes maliciosos são a sua maior preocupação, considere uma firewall de pacotes. Se tem de provar o que entrou em cada versão, para clientes ou para o Cyber Resilience Act da UE, precisa de um registo feito durante o build. Os grandes programas com muitos repositórios e sistemas de CI acrescentam muitas vezes uma plataforma de ASPM por cima.

Preciso de uma SBOM para a segurança da cadeia de abastecimento de software?

Cada vez mais, sim. O Cyber Resilience Act da UE exige que os fabricantes identifiquem os componentes dos seus produtos, nomeadamente elaborando uma SBOM, e que tratem as respetivas vulnerabilidades. A FDA dos EUA exige uma SBOM para dispositivos cibernéticos, e a Executive Order 14028 dos EUA moldou orientações federais que pedem uma aos fornecedores. Uma SBOM só é tão útil quanto é completa, por isso pergunte a cada fornecedor de onde vem a sua lista de componentes e se lhe diz quando a lista está incompleta.

Em que difere o CRACI de um scanner de segurança da cadeia de abastecimento?

Os scanners leem ficheiros a posteriori: um manifesto, um lockfile, código-fonte ou um binário final. O CRACI é um registador. É o runner dos seus jobs de GitHub Actions e, enquanto cada job é executado, regista os pacotes que o job realmente trouxe, incluindo pacotes restaurados de caches de CI. Cada SBOM indica a sua própria completude, uma política de egress controla aquilo a que o build pode chegar, e a API devolve SBOM, traços de rede e proveniência.

Que sistemas de CI suporta o CRACI?

GitHub Actions hoje; outros sistemas de CI estão no roadmap, entre eles o GitLab CI e o Jenkins. Os runners são Linux em x86-64 e ARM64, com Windows e macOS no roadmap. A maioria das plataformas desta página cobre vários sistemas de CI, por isso tenha isso em conta se também utiliza Jenkins ou Azure Pipelines.

Quanto custam as ferramentas de segurança da cadeia de abastecimento de software?

A maioria cobra por programador. Em setembro de 2026, o StepSecurity Enterprise custa $16 por programador contribuidor por mês e o Socket Team $25 por programador por mês, enquanto o Cycode, a OX Security e o Endor Labs vendem os planos pagos através da equipa comercial. O ReversingLabs Community+ custa um valor fixo de $500 por mês, a Chainguard oferece até cinco imagens gratuitas, e o CRACI cobra apenas os minutos de build, $0.002 por vCPU-minuto ($0.004 para um runner predefinido de 2 vCPU), sem mensalidade.