CRACI vs Mend.io

A resposta curta

O Mend.io é uma plataforma de segurança aplicacional. O Mend AppSec combina o Mend SAST para o seu próprio código com o Mend SCA para dependências open source e contentores, e o Mend Renovate mantém as dependências atualizadas com pull requests automatizados. O CRACI é um runner de CI compatível com GitHub Actions que regista todas as dependências externas que um build obtém e produz a SBOM, a proveniência e as evidências de conformidade a partir desse registo. O Mend é um scanner. O CRACI é um registador. Se usa hoje o Mend, o CRACI acrescenta uma camada em vez de substituir uma.

Visão geral

O que o Mend.io faz bem

Priorizar o que é alcançável. O Mend SCA segue o grafo de chamadas desde o seu código, através de dependências diretas e transitivas, para determinar se a sua aplicação invoca realmente uma função vulnerável. Isso reduz a lista de conclusões sobre as quais uma equipa tem de agir. O CRACI agrega vulnerabilidades de todos os builds e repositórios, mas não faz análise de alcançabilidade.

Código além de dependências. O Mend SAST cobre mais de 30 linguagens, e a Mend CLI analisa componentes open source, código próprio, imagens de contentor e infraestrutura como código. O CRACI não faz nada disto.

Manter as dependências atualizadas. O Mend Renovate abre pull requests para pacotes desatualizados em mais de 90 gestores de pacotes. As edições Renovate CLI e Community são gratuitas; a Enterprise acrescenta funcionalidades de segurança e suporte.

Licenças, pacotes maliciosos e SBOM. O Mend SCA deteta as licenças de dependências diretas e transitivas e aplica políticas, como bloquear AGPL em produtos comerciais. Assinala typosquats, confusão de dependências e pacotes com backdoors ou código de exfiltração de dados. Produz SBOM SPDX e CycloneDX, importa SBOM de terceiros e aplica dados VEX.

Onde o CRACI é diferente

Observação em vez de reconstrução

A própria documentação do Mend recomenda analisar depois do passo de build, porque é o build que dá ao scanner acesso a registos privados e artefactos externos, e analisar sem construir pode dar resultados inexatos. É um bom instinto. O CRACI leva-o um passo mais longe: em vez de ler o projeto depois de o build terminar, regista o próprio build.

Um proxy que reconhece pacotes no runner do CRACI observa o tráfego para origens de pacotes durante a execução do job: 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 os pacotes restaurados de uma cache continuam a ser contabilizados. Cada SBOM indica a sua completude por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

Controlo sobre a rede do build

Como o CRACI executa o job, pode limitar para onde o job vai. As políticas de egress 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. São validadas antes de o job arrancar e falham em modo fechado. O Mend deteta um pacote malicioso depois de estar na sua árvore de dependências. Uma política de egress limita desde logo as origens que um build pode alcançar. As duas camadas atuam em momentos diferentes.

Evidências a partir do build

A API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência.

Um inventário do que está implementado e onde

A vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global. Quando surge uma nova vulnerabilidade, pode ver que produtos executam a versão afetada, em vez de o reconstituir a partir de notas de lançamento e folhas de cálculo.

Qual escolher

• O seu principal problema é um backlog de conclusões no código e nas dependências. O Mend, com SAST, alcançabilidade e Renovate, foi feito para isso.
• Precisa de provar o que entrou em cada versão. O CRACI regista-o por build e indica quão completo é o registo.
• Os seus builds fazem mais do que instalar a partir de um lockfile. As transferências de toolchains, as imagens base e as descargas com curl são onde a observação mais acrescenta.
• Os seus pipelines estão em Azure DevOps, Bitbucket ou CircleCI. O Mend é hoje a opção certa. O CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap.

Para o Cyber Resilience Act

O Mend.io publica um guia de conformidade com o CRA e uma página de conformidade que mapeia os seus produtos para o regulamento: Mend AppSec para SBOM CycloneDX e SPDX e priorização baseada em alcançabilidade, Mend Renovate para o tratamento contínuo de vulnerabilidades através de atualizações de dependências, e a conformidade de licenças documentada a par da postura de segurança.

O CRACI contribui com evidências a partir do build: uma SBOM para cada versão com a sua completude indicada, proveniência, monitorização contínua e exportação de 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 ferramenta por si só torna um produto conforme. Consulte a conformidade com o CRA e o que é o CRA.

Adicionar o CRACI ao lado do Mend.io

O CRACI substitui o runner, não o GitHub Actions. Altere runs-on para craci num workflow, e as execuções continuam a aparecer na interface do GitHub. O seu passo da Mend CLI fica onde está, depois do build. Execute um pipeline de lançamento no CRACI e compare a sua SBOM com o inventário do Mend para o mesmo commit.