CRACI e JFrog Artifactory

Dois pontos de observação sobre a mesma cadeia de abastecimento

Muitas organizações de engenharia encaminham o tráfego de pacotes através do JFrog Artifactory. Um repositório remoto funciona como proxy com cache para um registo público como o npm ou o PyPI, obtendo pacotes a pedido e guardando uma cópia. Os repositórios virtuais combinam várias origens atrás de um URL. Os seus próprios resultados de build ficam em repositórios locais. Isso dá-lhe um só lugar para ver e governar o que entra na empresa.

O CRACI está noutro sítio. É o runner de CI em que os seus jobs de GitHub Actions correm e, enquanto cada job corre, regista as dependências externas que obtém. O Artifactory responde a "o que passou pelos nossos repositórios?" O CRACI responde a "o que usou este build específico, e que artefacto resultou dele?"

O que o Artifactory faz bem

O Artifactory é um gestor de repositórios maduro. Dá às equipas acesso fiável e em cache a pacotes upstream, um lugar para os artefactos internos e um único ponto de controlo para muitos tipos de pacotes. À sua volta, a JFrog Platform acrescenta mais:

• Build-info. Com a JFrog CLI, adiciona um nome e um número de build aos seus comandos e publica um registo JSON das dependências resolvidas, dos artefactos produzidos, das variáveis de ambiente e dos detalhes de Git. Esse registo suporta a rastreabilidade, a promoção de builds e a análise do Xray.
• Xray. Analisa artefactos e builds em busca de vulnerabilidades e exporta SBOM em SPDX e CycloneDX. A matriz de licenças da JFrog indica o Xray como incluído nas subscrições Pro X, Enterprise X e Enterprise+ (em setembro de 2026).
• Curation. Bloqueia pacotes maliciosos ou vulneráveis no repositório remoto antes de chegarem aos programadores, incluindo pacotes que já estão na cache remota.

O bloqueio ao nível do pacote no registo é um verdadeiro ponto forte. O CRACI não bloqueia hoje pacotes individuais; as listas de bloqueio de pacotes a nível da organização estão no roadmap do CRACI.

Onde o CRACI acrescenta

Visibilidade que não depende do encaminhamento

O Artifactory vê o que é encaminhado através dele. Os builds nem sempre colaboram. Um job pode transferir uma toolchain de uma release do GitHub, instalar pacotes do sistema operativo, obter uma imagem base de um registo público ou executar um script que obtém um binário. A própria documentação da JFrog nota que as dependências obtidas por outras ferramentas podem ser registadas manualmente com build-add-dependencies, o que significa que alguém tem de saber da sua existência.

O CRACI regista no runner. Um proxy que reconhece pacotes observa o tráfego para origens de pacotes durante o job, cobrindo origens npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de transferência. Se as suas instalações npm ou PyPI passam por um mirror do Artifactory, isso funciona: o CRACI regista também esses pacotes.

Evidências por build sem passos adicionais

O build-info é valioso, mas é algo que adiciona a cada pipeline. No CRACI, o registo existe para cada job porque é o runner que o produz. A evidência das dependências acompanha as caches de CI, pelo que um pacote restaurado de uma cache continua a ser contabilizado. Cada SBOM traz um estado de completude por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Quando um registo tem uma lacuna, indica-o.

Manter os builds no caminho aprovado

Como o CRACI executa o job, pode definir a sua política de egress de rede. As políticas são de negação ou de permissão por defeito, com 24 predefinições integradas de origens de software, origens personalizadas tipadas (npm, PyPI, apt, apk, o proxy de Go, Nix, Cargo, registos OCI e Git) e regras explícitas de TLS, TCP, UDP e ICMP. São validadas antes de o job arrancar e falham em modo fechado. Uma política que permita o seu host do Artifactory e negue o acesso direto a registos públicos ajuda a garantir que os builds usam realmente o caminho governado. O CRACI alerta-o quando um job viola a sua política.

Evidências do build ao lado do Artifactory

A API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência. Guarde o artefacto no Artifactory como faz hoje; o registo do que o build obteve vem do CRACI.

Para as equipas confrontadas com o Cyber Resilience Act da UE, esse registo alimenta as evidências ao nível da versão. O CRACI agrega vulnerabilidades de todos os builds e repositórios, reavalia continuamente as SBOM monitorizadas e exporta-as em CycloneDX ou SPDX. Consulte as evidências para o CRA e a conformidade com o CRA.

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.

Como se conjugam

1. Mantenha o Artifactory como proxy de pacotes, armazenamento de artefactos e ponto de distribuição de versões.
2. Passe os jobs de GitHub Actions para o CRACI alterando runs-on para craci. Os workflows mantêm-se iguais, e as execuções continuam a aparecer na interface do GitHub.
3. Aponte as instalações npm e PyPI para os seus mirrors do Artifactory, como faz hoje.
4. Use uma política de egress do CRACI para manter os builds em origens aprovadas, incluindo o Artifactory.
5. Use a SBOM, a proveniência e o traço de rede por build do CRACI como evidências de cada versão.

Se hoje depende do build-info ou do Curation da JFrog, mantenha-os. O CRACI suporta hoje apenas GitHub Actions (GitLab CI e Jenkins estão no roadmap), pelo que os pipelines noutros sistemas de CI ficam onde estão.

Se está a substituir o próprio Artifactory, consulte as alternativas ao JFrog Artifactory.

Perguntas frequentes

O CRACI substitui o Artifactory?

Não. O CRACI não é um gestor de repositórios. Não guarda os seus pacotes nem binários de lançamento, nem os distribui. Executa os seus builds e regista evidências sobre eles.

O CRACI sobrepõe-se ao Xray?

Em parte. Ambos exportam SBOM em CycloneDX e SPDX e ambos ajudam a acompanhar vulnerabilidades. A diferença está na entrada. O Xray analisa os artefactos e builds que a JFrog conhece. A SBOM e a vista de vulnerabilidades do CRACI vêm do que cada build obteve durante a execução, em todos os builds e repositórios. Se o Xray faz parte do seu processo de lançamento, mantenha-o e trate o registo por build do CRACI como uma segunda fonte independente.

Que tipos de repositório Artifactory funcionam com o CRACI?

Está confirmado que os mirrors npm e PyPI do Artifactory funcionam com builds do CRACI. Para outros tipos de pacotes, fale connosco sobre a sua configuração antes de migrar esses pipelines.