CRACI et JFrog Artifactory

Deux points de vue sur la même chaîne d'approvisionnement

De nombreuses organisations d'ingénierie font passer leur trafic de paquets par JFrog Artifactory. Un dépôt distant sert de proxy de mise en cache pour un registre public tel que npm ou PyPI : il récupère les paquets à la demande et en conserve une copie. Les dépôts virtuels combinent plusieurs sources derrière une seule URL. Vos propres sorties de build résident dans des dépôts locaux. Vous disposez ainsi d'un seul endroit pour voir et gouverner ce qui entre dans l'entreprise.

CRACI se situe ailleurs. C'est le runner CI sur lequel s'exécutent vos jobs GitHub Actions et, pendant l'exécution de chaque job, il enregistre les dépendances externes que le job récupère. Artifactory répond à la question « qu'est-ce qui a transité par nos dépôts ? ». CRACI répond à la question « qu'a utilisé ce build précis, et quel artefact en est sorti ? ».

Ce qu'Artifactory fait bien

Artifactory est un gestionnaire de dépôts mature. Il offre aux équipes un accès fiable et mis en cache aux paquets amont, un emplacement pour les artefacts internes et un point de contrôle unique pour de nombreux types de paquets. Autour de lui, la JFrog Platform ajoute d'autres éléments :

• Build-info. Avec la JFrog CLI, vous ajoutez un nom et un numéro de build à vos commandes et publiez un enregistrement JSON des dépendances résolues, des artefacts produits, des variables d'environnement et des informations Git. Cet enregistrement sert à la traçabilité, à la promotion de build et au scan Xray.
• Xray. Scanne les artefacts et les builds à la recherche de vulnérabilités et exporte des SBOM en SPDX et CycloneDX. La matrice de licences de JFrog indique que Xray est inclus dans les abonnements Pro X, Enterprise X et Enterprise+ (en septembre 2026).
• Curation. Bloque les paquets malveillants ou vulnérables au niveau du dépôt distant avant qu'ils n'atteignent les développeurs, y compris les paquets déjà présents dans le cache distant.

Le blocage au niveau des paquets sur le registre est un vrai point fort. CRACI ne bloque pas de paquets individuels aujourd'hui ; les listes de blocage de paquets à l'échelle de l'organisation figurent sur la roadmap de CRACI.

Ce que CRACI y ajoute

Une visibilité qui ne dépend pas du routage

Artifactory voit ce qui passe par lui. Les builds ne coopèrent pas toujours. Un job peut télécharger une chaîne d'outils depuis une release GitHub, installer des paquets système, récupérer une image de base depuis un registre public ou exécuter un script qui va chercher un binaire. La documentation de JFrog elle-même note que les dépendances récupérées par d'autres outils peuvent être déclarées manuellement avec build-add-dependencies, ce qui signifie que quelqu'un doit les connaître.

CRACI enregistre au niveau du runner. Un proxy qui comprend les paquets observe le trafic vers les sources de paquets pendant le job, pour npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que les presets de téléchargement. Si vos installations npm ou PyPI passent par un miroir Artifactory, cela fonctionne : CRACI enregistre aussi ces paquets.

Des preuves par build sans étape supplémentaire

Build-info est précieux, mais c'est quelque chose que vous ajoutez à chaque pipeline. Sur CRACI, l'enregistrement existe pour chaque job, car c'est le runner qui le produit. Les preuves de dépendances suivent les caches CI : un paquet restauré depuis un cache reste donc comptabilisé. Chaque SBOM porte un état de complétude par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Lorsqu'un enregistrement présente une lacune, il le dit.

Garder les builds sur la voie approuvée

Comme CRACI exécute le job, vous pouvez définir sa politique de trafic sortant. Les politiques sont en refus par défaut ou en autorisation par défaut, avec 24 presets de sources logicielles intégrés, des sources personnalisées typées (npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git) et des règles TLS, TCP, UDP et ICMP explicites. Elles sont validées avant le démarrage du job et bloquent tout en cas d'échec. Une politique qui autorise votre hôte Artifactory et refuse l'accès direct aux registres publics aide à s'assurer que les builds empruntent bien la voie contrôlée. CRACI vous alerte lorsqu'un job enfreint sa politique.

Les preuves de build à côté d'Artifactory

L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance. Stockez l'artefact dans Artifactory comme vous le faites aujourd'hui ; l'enregistrement de ce que le build a récupéré vient de CRACI.

Pour les équipes confrontées au Cyber Resilience Act de l'UE, cet enregistrement alimente les preuves au niveau de la release. CRACI agrège les vulnérabilités de l'ensemble des builds et des dépôts, réévalue en continu les SBOM surveillées et les exporte en CycloneDX ou SPDX. Voir les preuves pour le CRA et la conformité au CRA.

Un inventaire de ce qui est déployé et où

La vue d'inventaire de CRACI montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale. Lorsqu'une nouvelle vulnérabilité apparaît, vous voyez quels produits exécutent la version concernée, au lieu de reconstituer l'information à partir de notes de version et de tableurs.

Comment ils s'articulent

1. Gardez Artifactory comme proxy de paquets, stockage d'artefacts et point de distribution des releases.
2. Faites passer les jobs GitHub Actions sur CRACI en remplaçant runs-on par craci. Les workflows restent les mêmes, et les exécutions apparaissent toujours dans l'interface GitHub.
3. Faites pointer les installations npm et PyPI vers vos miroirs Artifactory, comme aujourd'hui.
4. Utilisez une politique de trafic sortant CRACI pour garder les builds sur les sources approuvées, Artifactory compris.
5. Utilisez la SBOM, la provenance et la trace réseau de chaque build CRACI comme preuves de chaque release.

Si vous vous appuyez aujourd'hui sur JFrog build-info ou Curation, gardez-les. CRACI ne prend en charge que GitHub Actions aujourd'hui (GitLab CI et Jenkins figurent sur la roadmap) : les pipelines sur d'autres systèmes CI restent donc où ils sont.

Si vous remplacez Artifactory lui-même, consultez les alternatives à JFrog Artifactory.

Questions fréquentes

CRACI remplace-t-il Artifactory ?

Non. CRACI n'est pas un gestionnaire de dépôts. Il ne stocke ni vos paquets ni vos binaires de release, et il ne les distribue pas. Il exécute vos builds et enregistre des preuves à leur sujet.

CRACI fait-il double emploi avec Xray ?

En partie. Tous deux exportent des SBOM en CycloneDX et SPDX et tous deux aident à suivre les vulnérabilités. La différence tient aux données d'entrée. Xray scanne les artefacts et les builds que JFrog connaît. La SBOM et la vue des vulnérabilités de CRACI proviennent de ce que chaque build a récupéré pendant son exécution, sur l'ensemble des builds et des dépôts. Si Xray est intégré à votre processus de release, gardez-le et traitez l'enregistrement par build de CRACI comme une seconde source indépendante.

Quels types de dépôts Artifactory fonctionnent avec CRACI ?

Le fonctionnement des miroirs npm et PyPI d'Artifactory avec les builds CRACI est confirmé. Pour les autres types de paquets, parlez-nous de votre configuration avant de migrer ces pipelines.