CRACI vs Sonatype

A resposta curta

O Sonatype destaca-se na governação de open source: políticas que decidem que componentes são permitidos, uma firewall que trava pacotes maliciosos no repositório e análises que lhe dizem o que acabou na sua aplicação. O CRACI é um runner de CI compatível com GitHub Actions que regista todas as dependências externas que um build traz e produz a SBOM, a proveniência e as evidências de conformidade a partir desse registo. O Sonatype é um scanner e um guardião. O CRACI é um registador, cujos policy gates também podem bloquear um build com base em conclusões. A maioria das equipas que precisa de ambos executá-los-ia lado a lado.

Qual é cada produto da Sonatype

A Sonatype vende vários produtos, e os nomes importam para esta comparação:

• O Sonatype Lifecycle é o produto de análise de composição de software (SCA) e de políticas, em alojamento próprio ou como SaaS.
• O Sonatype Repository Firewall bloqueia e coloca em quarentena os componentes que não cumprem as suas políticas antes de entrarem nos seus repositórios. Foi concebido para o Sonatype Nexus Repository. O Sonatype Firewall Pro cobre outros gestores de repositórios, como JFrog Artifactory, Cloudsmith e GitHub Packages, para npm, Maven, PyPI e NuGet.
• O Sonatype SBOM Manager importa, monitoriza e partilha SBOM, com um workflow de VEX.

A oferta está a mudar. A página de preços da Sonatype diz que todas as capacidades do Lifecycle estão agora incluídas no Sonatype Guide, que os novos clientes compram o Guide para SCA e governação, e que o Guide inclui também as capacidades de conformidade do SBOM Manager.

Visão geral

O que o Sonatype faz bem

Políticas em grande escala. O Lifecycle inclui 18 políticas predefinidas e mais de 30 restrições personalizáveis que cobrem regras de segurança, legais e de arquitetura. As políticas de licenças abrangem mais de 2.000 licenças open source. Prioriza as conclusões com dados de alcançabilidade, alterações incompatíveis e disponibilidade de atualizações, e pode abrir Golden Pull Requests com as atualizações sugeridas.

Olhar para o que o build produziu. As integrações do Lifecycle usam por defeito o Advanced Binary Fingerprinting, que examina tudo o que está incluído na aplicação depois do build, incluindo dependências incorporadas, e consegue identificar componentes renomeados ou modificados. Só depois recorre a lockfiles e manifestos. Cada relatório de análise pode ser exportado como SBOM CycloneDX ou SPDX.

Travar pacotes maliciosos à porta. O Repository Firewall aplica as suas normas de segurança, licenças e qualidade no momento da transferência e coloca em quarentena os componentes suspeitos. O CRACI não tem hoje equivalente: as listas de bloqueio de pacotes estão no seu roadmap.

Encaixa em qualquer pipeline. O Sonatype integra-se com Jenkins, GitHub Actions, GitLab CI, Azure DevOps e Bamboo, além de Maven, Gradle e uma CLI para outros servidores de CI. O CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap.

Onde o CRACI é diferente

Regista o build em vez de analisar o resultado

A impressão digital de binários diz-lhe o que está dentro da aplicação final. Não lhe diz o que o build transferiu pelo caminho: compiladores e toolchains, scripts de instalação, imagens base, binários de lançamento obtidos com curl ou pacotes restaurados de uma cache. O CRACI vê-os porque é o runner. Um proxy que reconhece pacotes observa o tráfego para fontes de pacotes durante a execução do job, abrangendo npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de fontes ou de descarga. A evidência das dependências acompanha as caches de CI, pelo que os pacotes em cache continuam a ser contabilizados.

Cada SBOM indica a sua própria completude, por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Quando o registo tem uma lacuna, fica a saber.

Controla até onde o build pode ir

O Repository Firewall governa o que passa pelo repositório. Uma política de egress do CRACI governa o que o build pode sequer alcançar. As políticas são de negação ou de permissão por defeito, com 24 predefinições integradas de fontes de software e fontes 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. Em conjunto, os dois permitem garantir que os jobs de build obtêm pacotes apenas das fontes que aprova, e que essas fontes servem apenas pacotes que permite.

Continua a vigiar o que foi distribuído

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

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.

Quando usar ambos

• Já utiliza o Nexus Repository com Firewall. Mantenha-o como barreira. Acrescente o CRACI para que cada build tenha um registo do que obteve e uma política de egress que mantenha os builds nas suas fontes aprovadas.
• A sua equipa jurídica depende das políticas de licenças do Lifecycle. Mantenha-as. O CRACI inclui metadados de licenças declaradas na sua exportação de SBOM e aplica também uma política de licenças.
• Reúne SBOM no SBOM Manager. O SBOM Manager importa CycloneDX e SPDX, os mesmos formatos que o CRACI exporta, pelo que as SBOM do build podem ficar ao lado das que já gere.
• Os seus pipelines estão em Jenkins ou Azure DevOps. O Sonatype encaixa hoje. Com o CRACI, esses pipelines teriam primeiro de passar para GitHub Actions; o Jenkins está no seu roadmap.

Para o Cyber Resilience Act

A Sonatype publica um guia do utilizador do CRA e uma lista de verificação do CRA, e posiciona o SBOM Manager como o seu produto para o CRA. O seu guia destaca a geração de ficheiros VEX para reportar vulnerabilidades conhecidas em SBOM, e o Nexus Repository como local de atualização para distribuir atualizações de segurança.

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

Adicionar o CRACI ao lado do Sonatype

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. Os seus passos do Sonatype ficam no workflow. Comece com um pipeline de lançamento, compare a SBOM do CRACI com o seu relatório do Lifecycle e veja o que apenas um deles detetou.