CRACI und JFrog Artifactory

Zwei Blickwinkel auf dieselbe Lieferkette

Viele Entwicklungsorganisationen leiten ihren Paketverkehr über JFrog Artifactory. Ein Remote-Repository fungiert als cachender Proxy für eine öffentliche Registry wie npm oder PyPI, lädt Pakete bei Bedarf und behält eine Kopie. Virtuelle Repositories fassen mehrere Quellen hinter einer URL zusammen. Ihre eigenen Build-Ausgaben liegen in lokalen Repositories. So haben Sie einen Ort, an dem Sie sehen und steuern, was ins Unternehmen gelangt.

CRACI sitzt woanders. Es ist der CI-Runner, auf dem Ihre GitHub-Actions-Jobs laufen, und während jeder Job läuft, zeichnet es die externen Abhängigkeiten auf, die der Job lädt. Artifactory beantwortet die Frage „Was ist durch unsere Repositories geflossen?“ CRACI beantwortet die Frage „Was hat dieser bestimmte Build genutzt, und welches Artefakt ist daraus entstanden?“

Was Artifactory gut kann

Artifactory ist ein ausgereifter Repository-Manager. Es gibt Teams zuverlässigen, gecachten Zugriff auf Upstream-Pakete, ein Zuhause für interne Artefakte und einen zentralen Kontrollpunkt für viele Pakettypen. Darum herum bietet die JFrog Platform weitere Funktionen:

• Build-Info. Mit der JFrog CLI ergänzen Sie Ihre Befehle um einen Build-Namen und eine Build-Nummer und veröffentlichen eine JSON-Aufzeichnung der aufgelösten Abhängigkeiten, erzeugten Artefakte, Umgebungsvariablen und Git-Details. Diese Aufzeichnung unterstützt Rückverfolgbarkeit, Build-Promotion und Xray-Scanning.
• Xray. Scannt Artefakte und Builds auf Schwachstellen und exportiert SBOMs in SPDX und CycloneDX. Laut der Lizenzmatrix von JFrog ist Xray in den Abonnements Pro X, Enterprise X und Enterprise+ enthalten (Stand September 2026).
• Curation. Blockiert bösartige oder verwundbare Pakete am Remote-Repository, bevor sie Entwickler erreichen, auch Pakete, die bereits im Remote-Cache liegen.

Das Blockieren auf Paketebene an der Registry ist eine echte Stärke. CRACI blockiert heute keine einzelnen Pakete; organisationsweite Paket-Blocklists sind auf der Roadmap von CRACI.

Was CRACI ergänzt

Transparenz, die nicht vom Routing abhängt

Artifactory sieht, was durch es hindurchgeleitet wird. Builds halten sich nicht immer daran. Ein Job lädt vielleicht eine Toolchain aus einem GitHub-Release, installiert OS-Pakete, zieht ein Basis-Image aus einer öffentlichen Registry oder führt ein Skript aus, das eine Binärdatei holt. Die Dokumentation von JFrog selbst hält fest, dass von anderen Tools geladene Abhängigkeiten manuell mit build-add-dependencies registriert werden können, und das heißt, dass jemand von ihnen wissen muss.

CRACI zeichnet auf dem Runner auf. Ein paketbewusster Proxy beobachtet während des Jobs den Datenverkehr zu Paketquellen und deckt npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen ab, dazu Download-Presets. Wenn Ihre npm- oder PyPI-Installationen über einen Artifactory-Mirror laufen, funktioniert das: CRACI zeichnet auch diese Pakete auf.

Nachweise pro Build ohne zusätzliche Schritte

Build-Info ist wertvoll, muss aber jeder Pipeline hinzugefügt werden. Auf CRACI gibt es die Aufzeichnung für jeden Job, weil der Runner sie erzeugt. Die Abhängigkeitsnachweise reisen mit CI-Caches mit, sodass auch ein aus einem Cache wiederhergestelltes Paket gezählt wird. Jede SBOM trägt einen Vollständigkeitsstatus pro Job und pro Cache: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded. Hat eine Aufzeichnung eine Lücke, sagt sie das.

Builds auf dem freigegebenen Weg halten

Weil CRACI den Job ausführt, können Sie seine Egress-Richtlinie für das Netzwerk festlegen. Richtlinien sind standardmäßig sperrend oder standardmäßig erlaubend, mit 24 integrierten Presets für Softwarequellen, typisierten eigenen Quellen (npm, PyPI, apt, apk, der Go-Proxy, Nix, Cargo, OCI-Registries und Git) und expliziten TLS-, TCP-, UDP- und ICMP-Regeln. Sie werden vor dem Start des Jobs validiert und blockieren im Zweifel (fail closed). Eine Richtlinie, die Ihren Artifactory-Host erlaubt und den direkten Zugriff auf öffentliche Registries verweigert, hilft sicherzustellen, dass Builds tatsächlich den kontrollierten Weg nutzen. CRACI warnt Sie, wenn ein Job gegen seine Richtlinie verstößt.

Build-Nachweise neben Artifactory

Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert Provenienz nicht. Speichern Sie das Artefakt wie heute in Artifactory; die Aufzeichnung dessen, was der Build geladen hat, kommt von CRACI.

Für Teams, die der EU Cyber Resilience Act betrifft, fließt diese Aufzeichnung in Nachweise auf Release-Ebene ein. CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen, bewertet überwachte SBOMs laufend neu und exportiert sie als CycloneDX oder SPDX. Siehe CRA-Nachweise und CRA-Compliance.

Ein Inventar dessen, was wo im Einsatz ist

Die Inventaransicht von CRACI zeigt genau, welche Softwareversionen in welchen Produkten im Einsatz sind, weltweit. Wenn eine neue Schwachstelle bekannt wird, sehen Sie, welche Produkte die betroffene Version ausführen, statt es aus Release Notes und Tabellen zusammenzusuchen.

Wie beide zusammenpassen

1. Behalten Sie Artifactory als Paket-Proxy, Artefaktspeicher und Verteilpunkt für Releases.
2. Stellen Sie GitHub-Actions-Jobs auf CRACI um, indem Sie runs-on auf craci ändern. Workflows bleiben gleich, und Läufe erscheinen weiterhin in der GitHub-Oberfläche.
3. Richten Sie npm- und PyPI-Installationen wie heute auf Ihre Artifactory-Mirrors aus.
4. Halten Sie Builds mit einer Egress-Richtlinie von CRACI auf freigegebenen Quellen, einschließlich Artifactory.
5. Nutzen Sie die SBOM pro Build, die Provenienz und den Netzwerk-Trace von CRACI als Nachweise für jedes Release.

Wenn Sie sich heute auf JFrog Build-Info oder Curation verlassen, behalten Sie sie. CRACI unterstützt heute nur GitHub Actions (GitLab CI und Jenkins sind auf der Roadmap), Pipelines auf anderen CI-Systemen bleiben also, wo sie sind.

Wenn Sie Artifactory selbst ersetzen möchten, sehen Sie sich die JFrog-Artifactory-Alternativen an.

Häufige Fragen

Ersetzt CRACI Artifactory?

Nein. CRACI ist kein Repository-Manager. Es speichert weder Ihre Pakete noch Ihre Release-Binärdateien und verteilt sie auch nicht. Es führt Ihre Builds aus und zeichnet Nachweise darüber auf.

Überschneidet sich CRACI mit Xray?

Teilweise. Beide exportieren SBOMs in CycloneDX und SPDX, und beide helfen Ihnen, Schwachstellen zu verfolgen. Der Unterschied ist die Eingabe. Xray scannt die Artefakte und Builds, die JFrog kennt. Die SBOM und die Schwachstellenansicht von CRACI stammen aus dem, was jeder Build während des Laufs geladen hat, über Builds und Repositories hinweg. Wenn Xray fest in Ihrem Release-Prozess verankert ist, behalten Sie es und betrachten Sie die Aufzeichnung pro Build von CRACI als zweite, unabhängige Quelle.

Welche Artifactory-Repository-Typen funktionieren mit CRACI?

Für npm- und PyPI-Mirrors in Artifactory ist bestätigt, dass sie mit CRACI-Builds funktionieren. Sprechen Sie bei anderen Pakettypen mit uns über Ihr Setup, bevor Sie diese Pipelines migrieren.